Core Security Foundations

Before you learn any specific attack or defense, you need the mental scaffolding that every security engineer reasons from. This section gives you five building blocks, in order: what we protect (the CIA triad), how we control who gets in (AAA), how we build systems safely (design principles), how we talk precisely about danger (vulnerability, threat, risk, exploit), and how we think (the security mindset, trust boundaries, attack surface, and the shared responsibility model). Master these and almost everything else in security becomes a variation on a theme you already understand.

2.1 The CIA Triad — what "secure" actually means

The CIA triad (nothing to do with the spy agency) is the canonical model of the three properties that security exists to preserve. Use it as a checklist: when you read about any attack, ask "which leg does this hit?"

Confidentiality

Only authorized parties can read the data. Mechanisms: encryption (scrambling data so only key-holders can read it) at rest and in transit, access control, multi-factor authentication (MFA), and data classification. A violation is a data breach — information disclosed to people who shouldn't see it.

Integrity

Data is accurate, complete, and changed only by authorized actions. Mechanisms: hashing (a fingerprint that changes if even one byte changes), digital signatures, checksums, version control, input validation, and write permissions. A violation is tampering, fraud, or corruption.

Availability

Authorized users can reach the system and data when they need it. Mechanisms: redundancy, backups, DDoS protection, failover, and capacity planning. A violation is an outage, ransomware lockout, or denial-of-service.

The three legs are in tension. Perfect confidentiality — lock everything in a vault with no network — destroys availability. Security engineering is the art of balancing them according to how valuable the data is. Some models extend CIA with Authenticity, Non-repudiation, and Accountability; the "Parkerian Hexad" adds Possession and Utility. Know they exist, but keep CIA central.

2.2 AAA — how access is controlled

AAA is a three-step access framework that originated in networking (RADIUS and TACACS+ protocols) and is now used everywhere. The order matters.

2.3 Core design principles

Most of these come from Saltzer & Schroeder's 1975 paper "The Protection of Information in Computer Systems" — eight principles still taught 50 years later. OWASP's Developer Guide modernizes them. Treat them not as checkboxes but as trade-off lenses you apply while designing.

1. Defense in depth — layer multiple independent controls so one failure isn't fatal. A modern addition, not in the original eight.
2. Least privilege — give every user, process, and service the minimum rights to do its job, no more. This limits the "blast radius" when something is compromised, and is core to Zero Trust.
3. Fail securely / fail-safe defaults — when something errors, default to deny, not allow. Grant access on explicit permission, never by accidental fall-through.
4. Separation of duties (SoD) — no single person has enough power to abuse the system alone. The requester of a payment must not also be its approver.
5. Complete mediation — every access to every object is checked for authority every time. Never cache a "yes" and trust it forever.
6. Secure defaults — ship locked down; users opt into risk, not out of safety. Default passwords and open storage buckets are anti-patterns.
7. Economy of mechanism (KISS) — keep the design as small and simple as possible. Complexity hides bugs and resists auditing.
8. Open design / no security through obscurity — security must not depend on the design being secret (Kerckhoffs's Principle, 1883: a system should stay secure even if everything but the key is public).
9. Psychological acceptability — if security is too painful, users bypass it. The secure path must be the easy path. Usability is a security property.
10. Least common mechanism — minimize resources and state shared between users, to limit cross-contamination.

OWASP added A06:2025 "Insecure Design" precisely because so many flaws are architectural, not coding bugs — you cannot patch your way out of a bad design.

2.4 The vocabulary you must never conflate

Asset

Anything of value worth protecting — data, systems, money, people, reputation, intellectual property. You cannot secure what you have not inventoried.

Vulnerability

A weakness that could be exploited — unpatched software, weak password, missing MFA, misconfiguration. Public ones are catalogued as CVEs; OWASP's 2025 analysis drew on 175,000+ CVE records.

Threat

A potential event or actor that could exploit a vulnerability to cause harm — a ransomware gang, a flood, a careless insider. Threats exist whether or not you are vulnerable.

Exploit

The actual technique or code that takes advantage of a specific vulnerability. A zero-day is an exploit for a vulnerability that has no patch yet.

Risk

Risk = Likelihood × Impact. This is what executives actually manage. Risk is reducible but rarely zero; leftover (residual) risk is accepted, transferred (insurance), or avoided.

Threat actors are categorized by motivation and skill: cybercriminals (financial, ransomware-as-a-service), nation-states / APTs (espionage and sabotage, long undetected dwell times), hacktivists (ideological), insiders (malicious or merely negligent — the biggest blind spot), and script kiddies (low skill, public tools). Note the human factor: MGM and Change Healthcare both began with people-and-process gaps, not exotic zero-days.

2.5 How to think: the security mindset

Bruce Schneier described the security mindset (2008): security professionals instinctively ask "how can this be made to fail or be abused?" — the opposite of normal engineering, which asks "how do I make this work?" You think like an attacker, hunt for the unintended path, and distrust assumptions. It is learnable, not innate.

Attack surface

The sum of all points where an attacker could try to get in or pull data out — every input, API, open port, dependency, employee, and third party. The goal is to minimize it. Your software supply chain is now a huge slice, which is why OWASP added A03:2025 "Software Supply Chain Failures."

Trust boundary

A line where the level of trust or control changes — user→app, app→database, your code→third-party API, internet→internal network. Data crossing a trust boundary must be validated and authenticated. Every trust boundary is also attack surface. Zero Trust means "never trust, always verify" — assume the boundary is already breached.

        TRUST BOUNDARY        TRUST BOUNDARY       TRUST BOUNDARY
            |                     |                    |
 Internet --|-->  Your App  ------|-->  Database  ------|--> 3rd-party API
 (untrusted)|   (validate &       |   (authZ each      |   (verify certs,
            |    sanitize all     |    query, least    |    scope tokens,
            |    input here)      |    privilege)      |    least trust)
 attacker probes EVERY arrow = the attack surface; validate at EVERY '|'

2.6 The shared responsibility model (cloud)

In the cloud, security is split between provider and customer. The mantra: the provider secures "of the cloud" (hardware, hypervisor, datacenter, managed-service internals); the customer secures "in the cloud" (their data, identity and access configuration, OS patching, app code, network rules). The split shifts by service model.

2.7 Current framework anchors (2025–2026)

• OWASP Top 10:2025 — announced Nov 2025, finalized Jan 2026. Order: A01 Broken Access Control (still #1), A02 Security Misconfiguration, A03 Software Supply Chain Failures (new), A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software/Data Integrity Failures, A09 Logging & Alerting Failures, A10 Mishandling of Exceptional Conditions (new). SSRF folded into A01.
• NIST Cybersecurity Framework (CSF) 2.0 — released Feb 2024, first major update since 2014. Added a sixth, central function, Govern, wrapping the original five (Identify, Protect, Detect, Respond, Recover). Now meant for all organizations, not just critical infrastructure.
• IBM Cost of a Data Breach 2025 — global average $4.44M (down ~9% year-on-year, credited to faster AI-assisted detection); the U.S. hit a record $10.22M. Your "why it matters" number.
• EU AI Act — prohibited-practice and AI-literacy rules live since Feb 2, 2025; general-purpose AI obligations and the penalty regime (fines up to €35M or 7% of global turnover) since Aug 2, 2025; most high-risk rules apply Aug 2026. Security now intersects AI governance and compliance.

Common mistakes

• Confusing authentication (who you are) with authorization (what you may do).
• Thinking encryption alone equals "secure" — it ignores integrity and availability.
• Believing hidden code is secure (obscurity is not a control).
• Using "threat" and "risk" as synonyms.
• Assuming the cloud provider protects your data.
• Letting error handlers "fail open" by accident.
• Bolting security on at the end instead of designing it in.

Best practices

• For every feature, ask which CIA leg it affects and which design principle it tests.
• Default to deny; require explicit permission for access.
• Apply least privilege to users, services, and machine accounts alike.
• Validate and authenticate all data crossing a trust boundary.
• Minimize attack surface — fewer ports, features, and dependencies.
• Make the secure path the easy path so people don't route around it.
• Log enough to investigate later; you can't detect what you didn't record.