Security Principles and Approaches

• Security Principles and Approaches
  • A mental model for the whole course
  • The CIA triad
    • Extending the triad
  • Thinking like an attacker
  • Risk: you manage it, you don’t eliminate it
  • The recurring defensive principles
  • Security is a process, not a product
  • How this course is organized
  • Key takeaways
  • References

A mental model for the whole course

Before any specific tool or attack, it helps to have a frame to hang everything on. Security is not a product you install or a box you check — it is a process of reasoning about what you are protecting, who might attack it, and what it costs to defend. This page introduces the vocabulary and the handful of principles that recur on every later page of the course, from access control to supply-chain security. If you internalize these, the rest of the term is variations on a theme.

The CIA triad

The foundational model of what security protects is the CIA triad — three properties, every one of which an attacker may target:

• Confidentiality — information is disclosed only to those authorized to see it. Broken by eavesdropping, data theft, weak access control. Protected by encryption (cryptography), access controls, and least privilege.
• Integrity — information and systems are not modified by unauthorized parties (or in unauthorized ways). Broken by tampering, memory corruption, supply-chain attacks. Protected by hashing, digital signatures, and access controls.
• Availability — systems and data are accessible to authorized users when needed. Broken by DDoS, ransomware impact, hardware failure. Protected by redundancy, backups, and rate limiting.

The three are in constant tension — encrypting everything (confidentiality) can hurt availability if you lose the key; locking a system down hard can make it unusable. Security is the art of balancing them for a given context, not maximizing one.

Extending the triad

CIA is the core, but practitioners add properties it doesn’t capture cleanly:

• Authenticity — the data/identity is genuinely what it claims (the goal of authentication and email anti-spoofing).
• Non-repudiation — a party cannot deny having performed an action (provided by digital signatures and audit logs).
• Accountability — actions can be traced to a responsible entity (logging, the A in AAA below).

A useful companion is AAA: Authentication (who are you?), Authorization (what may you do? — see access control), and Accounting/Auditing (what did you do?).

Thinking like an attacker

The single most important shift in mindset: stop asking “how is this supposed to work?” and start asking “how can this be made to misbehave?” Defenders who cannot think like attackers protect only the front door.

• Attack surface — the sum of all points where an attacker could try to enter or extract data. Every open port, input field, dependency, and user is part of it. Reducing attack surface is one of the cheapest, most effective defenses.
• Trust boundaries — the lines where data crosses from less-trusted to more-trusted (user input entering a program, traffic crossing from the Internet to your LAN). Most vulnerabilities live at trust boundaries where validation was assumed but not enforced. Threat modeling is the discipline of mapping these systematically.
• The weakest link — an attacker attacks the easiest path, not the one you spent the most time hardening. A bank vault with a cardboard back wall is a cardboard box. This is why social engineering is so effective: why pick the lock when you can ask someone to hold the door?

Risk: you manage it, you don’t eliminate it

There is no such thing as perfect security; the question is always how much security is worth it. Security decisions are risk decisions:

Risk ≈ Threat × Vulnerability × Impact

A vulnerability nobody can reach (no threat) or that does no damage (no impact) is low risk; a reachable flaw in something critical is high risk. You can never drive risk to zero, so you choose how to treat each risk:

• Mitigate — add controls to reduce likelihood or impact (most of this course).
• Transfer — shift it elsewhere (insurance, outsourcing).
• Accept — decide the cost of fixing exceeds the risk, and live with it (consciously).
• Avoid — stop doing the risky thing entirely.

This is why blanket statements like “is X secure?” are unanswerable without “secure against whom, protecting what, at what cost?”

The recurring defensive principles

A small set of principles, drawn largely from Saltzer and Schroeder’s classic 1975 paper, show up again and again. They get their fullest treatment on the access control page; here is the orientation:

• Defense in depth — layer independent controls so that no single failure is fatal. You saw this made explicit in the memory-corruption mitigation arms race and the layered host and social-engineering defenses. Assume each layer will eventually fail — and most pages in this course are one layer.
• Least privilege — every subject gets only the access it needs, for only as long as it needs it. The most-cited principle in the course; most privilege-escalation attacks are violations of it.
• Fail-safe defaults — deny by default and grant explicitly; an allowlist fails closed, a denylist fails open.
• Complete mediation — check every access, every time; no cached “we already approved this.”
• Separation of duties — require more than one party for high-impact actions (the defense against BEC wire fraud).
• Economy of mechanism (KISS) — simpler systems have fewer bugs and are easier to verify; WireGuard’s tiny codebase is this principle as a design choice.
• Open design — security must not depend on the secrecy of the mechanism (only of the keys). “Security through obscurity” is not security — a corollary of Kerckhoffs’s principle.
• Psychological acceptability — if the secure path is too hard, users route around it. Usability is a security property.

Security is a process, not a product

Systems, threats, and people change constantly, so security is never “done.” It is a continuous loop — identify what matters, assess the risks, apply controls, monitor, respond to incidents, and improve. A firewall bought in 2020 does not secure a system in 2026. This is also why every page in this course carries a maintenance note: the specifics go stale even when the principles endure.

How this course is organized

The rest of the term applies these principles across the stack. Roughly:

Every one of those is, at heart, an application of confidentiality/integrity/availability defended in depth with least privilege. Keep that lens and the details fall into place.

Key takeaways

• Security protects confidentiality, integrity, and availability — always in tension, always context-dependent; extended by authenticity, non-repudiation, and accountability (AAA).
• Adopt the attacker’s mindset: map the attack surface and trust boundaries, and remember an attacker hits the weakest link, which is often a human.
• You manage risk (Threat × Vulnerability × Impact), you don’t eliminate it — mitigate, transfer, accept, or avoid each risk consciously.
• A few principles recur everywhere: defense in depth, least privilege, fail-safe defaults, complete mediation, separation of duties, economy of mechanism, open design, and psychological acceptability.
• Security is a continuous process, not a one-time product — the specifics decay even though the principles endure.

References

• J. H. Saltzer and M. D. Schroeder, The Protection of Information in Computer Systems (1975) — the design principles. https://www.cs.virginia.edu/~evans/cs551/saltzer/
• NIST SP 800-12 Rev. 1 — An Introduction to Information Security. https://csrc.nist.gov/pubs/sp/800/12/r1/final
• NIST FIPS 199 — Standards for Security Categorization (CIA impact levels). https://csrc.nist.gov/pubs/fips/199/final
• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments. https://csrc.nist.gov/pubs/sp/800/30/r1/final
• CISA — Cybersecurity Best Practices. https://www.cisa.gov/topics/cybersecurity-best-practices
• A. Kerckhoffs, La cryptographie militaire (1883) — origin of “no security through obscurity.” https://www.petitcolas.net/kerckhoffs/

Related course pages: Access Control and Authorization · Roles and Careers in Cybersecurity · Threat Modeling · Cryptography · DevSecOps Fundamentals

🛠️ Maintenance note: principles here are stable (Saltzer–Schroeder has aged 50 years gracefully), but the framing of “extended” properties and zero-trust evolves — revisit the course-map table whenever pages are added or renamed so the links stay live.