Security Fundamentals

Information security protects data and systems from unauthorized access, modification, and destruction. All security decisions flow from a small set of core principles and systematic threat analysis.

The CIA Triad

The three fundamental security objectives:

Confidentiality: Only authorized parties can access information. Achieved through encryption, access controls, and data classification. Violation example: an attacker reads credit card numbers from a database.

Integrity: Data is accurate and unmodified by unauthorized parties. Achieved through hashing, digital signatures, and checksums. Violation example: an attacker modifies a wire transfer amount in transit.

Availability: Systems and data are accessible when needed. Achieved through redundancy, backups, and DDoS mitigation. Violation example: a ransomware attack takes a hospital's systems offline.

Extended Properties

• Authenticity: Verifying that entities are who they claim to be.
• Non-repudiation: A party cannot deny having performed an action (achieved via digital signatures and audit logs).
• Accountability: Actions can be traced to a responsible entity.

Threat Modeling

Systematic identification of threats, vulnerabilities, and mitigations before building or deploying a system.

STRIDE

Microsoft's threat classification model. Each category maps to a CIA violation:

| Threat | Property Violated | Example | |--------|-------------------|---------| | Spoofing | Authenticity | Forging a session cookie | | Tampering | Integrity | Modifying a config file | | Repudiation | Non-repudiation | Denying a transaction occurred | | Information disclosure | Confidentiality | SQL injection leaking user data | | Denial of service | Availability | SYN flood attack | | Elevation of privilege | Authorization | Exploiting a kernel bug for root |

DREAD (Risk Scoring)

Score each threat 1-10 on five factors, then average:

• Damage potential: How severe is the impact?
• Reproducibility: How easy to reproduce?
• Exploitability: How much skill is needed?
• Affected users: How many users are impacted?
• Discoverability: How easy to find the vulnerability?

Risk = (D + R + E + A + D) / 5. Scores above 7 are critical; below 3 are low priority.

Attack Trees

Hierarchical decomposition of an attack goal into sub-goals:

Goal: Steal user credentials
├── Phishing attack
│   ├── Craft convincing email
│   └── Host fake login page
├── SQL injection on login form
│   ├── Find unparameterized query
│   └── Extract credentials table
└── Compromise password database
    ├── Exploit server vulnerability
    └── Exfiltrate hashed passwords
        └── Run offline cracking

Each leaf node can be annotated with cost, difficulty, and likelihood. AND nodes require all children; OR nodes require any one child.

MITRE ATT&CK Framework

A knowledge base of adversary tactics and techniques based on real-world observations. Organized as a matrix:

Tactics (the "why" -- columns): Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control, Impact.

Techniques (the "how" -- rows under each tactic): Specific methods like T1566 (Phishing), T1059 (Command and Scripting Interpreter), T1078 (Valid Accounts).

Used for: gap analysis in defenses, red team planning, incident classification, and detection rule development.

Risk Assessment

Risk = Likelihood x Impact

Qualitative Assessment

Rate likelihood and impact as Low/Medium/High and plot on a risk matrix:

Impact →     Low      Medium     High
Likelihood
  High     Medium     High     Critical
  Medium   Low        Medium   High
  Low      Low        Low      Medium

Quantitative Assessment

Single Loss Expectancy (SLE) = Asset Value x Exposure Factor

Annualized Rate of Occurrence (ARO) = Expected frequency per year

Annualized Loss Expectancy (ALE) = SLE x ARO

Example: A server worth $100,000 with 40$100,000 x 0.4 x 0.5 = $20,000. Any countermeasure costing less than$20,000/year is justified.

Core Security Principles

Defense in Depth

Layer multiple independent security controls so that the failure of one does not compromise the system:

Internet → [Firewall] → [WAF] → [Load Balancer]
  → [App Server (input validation)] → [DB (access controls, encryption at rest)]
     + Network segmentation + IDS/IPS + Logging & monitoring

No single layer is assumed to be impenetrable. An attacker must defeat multiple controls.

Principle of Least Privilege

Grant the minimum permissions necessary for a task, and only for the required duration.

// Bad: function takes full database access
PROCEDURE GENERATE_REPORT(db: DatabaseAdmin) → Report

// Good: function takes only read access to the specific table
PROCEDURE GENERATE_REPORT(reader: SalesTableReader) → Report

Applied everywhere: file permissions (chmod 600 vs 777), database roles (SELECT-only vs full DBA), IAM policies (specific resource ARNs vs wildcard), container privileges (non-root, dropped capabilities).

Fail-Safe Defaults

The default state should be denial of access. Access is granted explicitly, not implicitly.

PROCEDURE CHECK_ACCESS(user, resource) → boolean
    // Fail-safe: deny by default
    allowed ← FALSE
    FOR EACH p IN user.permissions DO
        IF p GRANTS_ACCESS_TO resource THEN
            allowed ← TRUE
            BREAK
    IF NOT allowed THEN
        LOG_WARNING("Access denied: user=" + user.id + " resource=" + resource.id)
    RETURN allowed  // FALSE unless explicitly permitted

If an authorization system crashes, users should be locked out rather than granted access. Whitelists are preferred over blacklists.

Separation of Duties

No single individual should control all aspects of a critical operation. Examples: code requires peer review before merge, financial transactions require two signatories, key ceremonies involve multiple key holders.

Complete Mediation

Every access to every resource must be checked against access control. No bypasses, no caching of authorization decisions without proper invalidation.

Economy of Mechanism

Security mechanisms should be simple and small. Complex systems are harder to analyze and more likely to contain vulnerabilities. Prefer well-audited standard libraries over custom cryptography.

Open Design (Kerckhoffs's Principle)

Security should not depend on secrecy of the mechanism, only secrecy of the key. AES is publicly known; its security depends entirely on the key. "Security through obscurity" is not a valid strategy on its own.

Security Development Lifecycle

1. Requirements: Define security requirements and abuse cases alongside functional requirements.
2. Design: Threat modeling (STRIDE), architecture review, define trust boundaries.
3. Implementation: Secure coding practices, static analysis (SAST), dependency scanning.
4. Verification: Dynamic analysis (DAST), penetration testing, fuzzing.
5. Release: Final security review, incident response plan.
6. Maintenance: Patch management, monitoring, vulnerability disclosure handling.

Real-World Applications

• Zero Trust Architecture: Never trust, always verify. Every request is authenticated and authorized regardless of network location. Microsegmentation replaces perimeter-based security.
• Supply Chain Security: SBOM (Software Bill of Materials), signed builds, dependency pinning (Cargo.lock), reproducible builds.
• Incident Response: Preparation, Detection, Containment, Eradication, Recovery, Lessons Learned (NIST SP 800-61).