Security Fundamentals

The CIA triad is the foundational model for information security. Every security control, Vulnerability, and threat maps to one or more of these three properties.

Confidentiality ensures that data is accessible only to authorized parties. It is enforced through Encryption, access controls, and data classification.

Mechanisms that enforce confidentiality:

Confidentiality is not binary. A system that encrypts data at rest but logs the plaintext to an Unsecured file has failed confidentiality. A system that uses AES-256 but stores the key alongside The ciphertext has failed confidentiality. The entire data lifecycle must be considered.

Integrity ensures that data has not been altered by unauthorized parties. It covers both malicious Tampering and accidental corruption.

Integrity failures are often subtler than confidentiality failures. A single bit flip in a Configuration file can change a firewall rule. A modified dependency in a supply chain attack can Introduce a backdoor without changing any visible behavior. Integrity verification must be Continuous, not one-time.

Availability ensures that authorized users can access systems and data when needed. It is defended Against both malicious attacks (DDoS) and operational failures (hardware faults, misconfigurations).

Availability is the most operationally visible of the three triad elements. When confidentiality or Integrity fails silently, you may not know for months. When availability fails, everyone notices Immediately.

STRIDE is a threat classification framework developed by Microsoft (Shostack, 2014). It categorizes Threats against a system into six classes, each mapping to a specific security violation.

STRIDE is applied through data flow diagrams (DFDs). For each component, element, and data flow In the diagram, you systematically ask: “Which STRIDE threats apply here?”

graph TD
    U[User Browser] -->|HTTPS| LB[Load Balancer]
    LB -->|HTTP| APP[Web Application]
    APP -->|SQL| DB[(Database)]
    APP -->|API Call| EXT[External API]
    APP -->|Write| FS[File System]

    style U fill:#f9f,stroke:#333
    style LB fill:#bbf,stroke:#333
    style APP fill:#bfb,stroke:#333
    style DB fill:#fbb,stroke:#333
    style EXT fill:#fdd,stroke:#333
    style FS fill:#fdd,stroke:#333

For the diagram above, a partial STRIDE analysis:

A threat tree decomposes a threat into its prerequisite conditions, creating a boolean Expression that describes the attack. The root node is the attacker”s goal. Leaf nodes are the Specific conditions the attacker must achieve.

For example, a threat tree for “Attacker reads customer PII from database”:

Attacker reads PII
├── Attacker gains SQL access
│   ├── SQL injection in web app
│   │   ├── Unsanitized user input reaches query
│   │   └── No WAF or input validation
│   └── Stolen database credentials
│       ├── Credential in source code
│       ├── Credential in CI/CD logs
│       └── Phished DBA
└── Attacker gains filesystem access
    ├── Server compromise
    └── Backup theft

Each leaf represents a countermeasure opportunity. If you eliminate enough leaves that no complete Path from root to leaf remains, the threat is mitigated.

The attack surface of a system is the set of all points where an untrusted actor can interact with It. Reducing the attack surface is one of the highest-leverage security activities.

Attack surface can be quantified using Microsoft’s Relative Attack Surface Quotient (RASQ), Which assigns a cost to each attack vector (network port, service, RPC endpoint, etc.) and compares The total cost across configurations or versions.

For practical purposes, the key metric is: how many distinct paths exist from an untrusted input To a protected asset? Each path represents a potential vulnerability.

• Remove unused software, services, and dependencies
• Disable default accounts and change default credentials
• Minimize network exposure (close ports, restrict IP ranges)
• Implement allowlists over denylists for input validation
• Remove debug endpoints, test APIs, and development tools from production
• Apply the principle of least functionality

Risk assessment is the process of identifying, analyzing, and prioritizing risks. It is the bridge Between threat modeling and security investment.

Risk is commonly expressed as:

Where likelihood and impact are each rated on a defined scale. A common 5-point scale:

Risks scoring 15 or above require immediate mitigation. Risks scoring 8-14 require a Mitigation plan with defined timelines. Risks below 8 may be accepted with documentation.

The FAIR (Factor Analysis of Information Risk) model provides a more rigorous quantitative Framework. It decomposes risk into:

• Loss Event Frequency (LEF): How often a threat event occurs
• Loss Magnitude (LM): How much loss results from each event

LEF is further decomposed into Threat Event Frequency (how often the threat actor attempts the Attack) and Vulnerability (the probability that an attempt succeeds). Loss Magnitude includes Both Primary Loss (direct costs) and Secondary Loss (response, reputation, regulatory).

FAIR produces a probability distribution over loss amounts rather than a single point estimate, Enabling risk-informed decision-making.

The principle of least privilege states that every subject (user, process, service account) should Operate with the minimum permissions necessary to perform its function, and for the minimum duration Necessary.

Privilege escalation is involved in the majority of successful breaches. An attacker who gains Access to a low-privilege service account does not need a kernel exploit if that account already has Admin access to the database.

Static privilege assignment accumulates permissions over time. JIT access grants elevated privileges On demand, with automatic expiration. Systems like AWS IAM, HashiCorp Vault, and Teleport support JIT patterns.

Related to least privilege is separation of duties: no single individual should control all aspects Of a critical operation. A developer who writes code should not be the sole approver for deploying It to production. A database administrator should not be the sole reviewer of audit logs.

Defense in depth is the practice of layering multiple independent security controls so that no Single point of failure results in total compromise.

graph TD
    subgraph Layer7["Application Layer"]
        A7[Input Validation]
        A7B[Output Encoding]
        A7C[Authentication]
    end
    subgraph Layer6["Service Layer"]
        A6[API Gateway]
        A6B[Rate Limiting]
        A6C[CORS Policy]
    end
    subgraph Layer5["Platform Layer"]
        A5[Container Isolation]
        A5B[Runtime Security]
        A5C[Secret Management]
    end
    subgraph Layer4["Network Layer"]
        A4[Firewall]
        A4B[Network Segmentation]
        A4C[IDS/IPS]
    end
    subgraph Layer3["Host Layer"]
        A3[OS Hardening]
        A3B[File Permissions]
        A3C[Audit Logging]
    end
    subgraph Layer2["Physical Layer"]
        A2[Data Center Security]
        A2B[Hardware Security Modules]
    end
    subgraph Layer1["Human Layer"]
        A1[Security Training]
        A1B[Access Reviews]
    end

1. Diversity: Use controls from different vendors and different technologies. Two firewalls from the same vendor with the same ruleset are one control, not two.
2. Redundancy: If one control fails, another should still provide protection. This does not mean identical controls — it means complementary ones.
3. Fail-safe defaults: When a control fails, it should fail to a more restrictive state, not a more permissive one.
4. Depth over breadth: It is better to have 3 controls protecting a critical asset than 1 control protecting 3 assets.

Zero trust is a security model that eliminates implicit trust based on network location. The Traditional perimeter model assumes that everything inside the network is trustworthy and everything Outside is not. Zero trust assumes that no network location, user, or device is inherently Trustworthy.

1. All data sources and computing services are considered resources: Whether on-premises or cloud.
2. All communication is secured regardless of network location: TLS everywhere, no exceptions.
3. Access to resources is granted on a per-session basis: Not per-connection, not per-login.
4. Access is determined by dynamic policy: Based on identity, device posture, location, and data sensitivity.
5. The enterprise monitors and measures the integrity and security posture: Continuous verification, not one-time authentication.
6. All resource authentication and authorization are dynamic and strictly enforced: Before and during the session.
7. The enterprise collects as much information as possible about the current state: Asset inventory, network traffic, user behavior.

• Identity provider (IdP): Centralized identity management with MFA (Okta, Azure AD, Keycloak)
• Policy engine: Evaluates access requests against policies (OPA, Cedar)
• Policy enforcement point (PEP): Enforces decisions at the resource (Envoy, service mesh proxies)
• Device trust: Evaluates device health certificates, OS version, patch level
• Continuous monitoring: Detects anomalous behavior and triggers re-evaluation

A security boundary is a logical or physical perimeter within which a consistent set of security Policies is enforced. Crossing a security boundary requires authentication, authorization, and encryption.

A trust boundary is where the authority controlling the security policy changes. Trust boundaries Exist:

• Between user and application (authentication)
• Between application tiers (service-to-service auth)
• Between organization and cloud provider (shared responsibility)
• Between application and third-party dependencies (supply chain)
• Between processes on the same host (process isolation)

graph LR
    subgraph Untrusted["Untrusted Zone"]
        U[User]
    end
    subgraph DMZ["DMZ / Edge"]
        WAF[Web Application Firewall]
        LB[Load Balancer]
    end
    subgraph AppZone["Application Zone"]
        API[API Server]
        AUTH[Auth Service]
    end
    subgraph DataZone["Data Zone"]
        DB[(Database)]
        CACHE[(Cache)]
    end

    U -->|TLS| WAF --> LB --> API --> AUTH
    API --> DB
    API --> CACHE

    style Untrusted fill:#fdd,stroke:#333
    style DMZ fill:#fbb,stroke:#333
    style AppZone fill:#bfb,stroke:#333
    style DataZone fill:#bbf,stroke:#333

Every time data crosses a trust boundary, you must consider:

1. Authentication: Is the sender who they claim to be?
2. Authorization: Is the sender allowed to perform this action?
3. Integrity: Has the data been modified in transit?
4. Confidentiality: Can unauthorized parties observe the data?
5. Auditability: Is this access logged?

In cloud environments, the security boundary between provider and customer is critical. AWS, Azure, And GCP each define shared responsibility models, but the general principle is:

The OWASP Top 10 is a standard awareness document for web application security. The 2021 edition:

Each of these is covered in detail in subsequent sections. See Web Security for mitigation details.

CVE is a dictionary of publicly known cybersecurity vulnerabilities. Each CVE entry is assigned a Unique identifier (e.g., CVE-2024-12345) and describes the vulnerability in standardized terms.

CVE is maintained by MITRE Corporation under sponsorship of CISA. It is the industry-standard Identifier referenced by vulnerability scanners, package managers, and security advisories.

CVSS provides a numerical score (0.0-10.0) representing the severity of a vulnerability. CVSS v3.1 Uses three metric groups: