Key Takeaways: Security Principles

A one-page reference. Reread this before an exam or before moving on. Dense by design.

The CIA triad (the foundation)

Property Means Attacked by Protected by Meridian asset that leads with it
Confidentiality Disclosed only to the authorized Disclosure / data theft Encryption, access control, authN Customer PII, cardholder data
Integrity Accurate, unaltered except by the authorized Tampering, fraud, forgery Hashing, digital signatures, change control, audit logs Core-banking ledger
Availability Reachable by authorized users when needed Denial — ransomware, DoS, deletion Backups, redundancy, DoS defense, recovery Online-banking service
  • Availability is security, not just operations — ransomware/DoS that discloses and alters nothing can be the worst incident of all.
  • The triad is in tension: maximal confidentiality kills availability and vice versa. Security = balance to the actual risk per asset, not maximize one leg.
  • Habit: for every asset and control, name the leg(s). Per asset, ask which leg matters most here?

AAA + non-repudiation (accountability)

Property Question it answers Attacker's move Enforced by
Authentication Who are you? Impersonation (steal/guess credentials) Passwords, MFA, FIDO2 keys (Ch.16)
Authorization What may you do? Privilege escalation RBAC/ABAC, access control (Ch.17)
Accounting What did you do? Log tampering / anti-forensics Audit logs, SIEM (Ch.21)
Non-repudiation Can you deny it? Act via shared/ambiguous identity Digital signatures, unique 2FA, tamper-evident logs
  • AuthN ≠ AuthZ — verify identity then constrain actions; conflating them = over-authorization.
  • Logging ≠ non-repudiation. The #1 killer of non-repudiation is shared accounts — they record that something happened while destroying who did it. Bind every privileged action to a named human.

Control taxonomy: function × nature (classify every control on BOTH axes)

Function (what it does in the attack timeline) Nature (how it's implemented)
Preventive — stop it before it happens (firewall, MFA, encryption, locked door) Administrative — policy, procedure, training, background checks
Detective — see that it is/was happening (IDS/IPS, SIEM, log review, camera) Technical (logical) — firewall, encryption, ACL, MFA, SIEM
Corrective — restore after it (backup restore, failover, quarantine, IR) Physical — locks, fences, badge readers, guards, cameras
Compensating — alternative meeting a primary control's intent (isolate + monitor an unpatchable box)

(Relatives you'll see on exams: deterrent ≈ discourages trying — relative of preventive; directive ≈ instructs people what to do — relative of administrative.)

The matrix is a GAP-ANALYSIS tool. Plot real controls; the empty cells are the finding. Classic immature shape: all preventive + technical, empty detective row, empty administrative column — well armored against entry, blind once inside, ungoverned humans.

Control Function Nature
Firewall rule (inbound block) Preventive Technical
Security-awareness training Preventive Administrative
Locked server room Preventive Physical
SIEM alert / IDS Detective Technical
Quarterly access review Detective Administrative
CCTV camera Detective Physical
Restore from backup Corrective Technical
Incident-response plan Corrective Administrative
Isolate + monitor an unpatchable system Compensating Technical

The access & layering principles

Principle One-line statement Stops (abuse) Enemy / defeated by Built on later in
Least privilege Exactly the access required, no more Lateral movement / privilege escalation after a foothold Privilege creep (fight with access reviews) Ch.17, 19
Separation of duties No one completes a high-risk process alone The lone insider (malicious/coerced/compromised) An over-powerful admin account Ch.17, 19
Fail-safe default On failure or no rule, default to secure (deny/closed) Every failure becoming an opening Fail-open (right only for life-safety) Ch.7 (default-deny), 33
Defense in depth Independent layers, each assuming the prior failed A single control failure becoming a breach Layers that fail dependently; all-preventive (no detection) everywhere (6,7,11,32)
Assume breach Design as if an attacker is already inside Long unobserved dwell after prevention fails Prevention-only thinking Part V, Ch.32
Zero trust (principle) Never trust, always verify — no implicit trust Free movement after the perimeter is breached "Zero trust in a box" (it's a posture, not a SKU) Ch.32 (architecture)
  • Least privilege vs. separation of duties: LP controls how far one compromised identity reaches; SoD controls whether one identity can complete a whole process. Together → one compromise = a near-miss, not a breach.
  • Defense in depth needs independence (diverse types/natures/tech) and must interleave detection between preventive layers.
  • Dual control (two people for one action) and job rotation are members of the SoD family.

Zero trust: principle (Ch.3) vs. architecture (Ch.32)

Zero trust principle (this chapter) Zero trust architecture / ZTA (Chapter 32)
What it is The mindset: never trust, always verify The engineering that implements it
Owns The idea + why the perimeter failed NIST SP 800-207 tenets, PDP/PEP, ZTNA, microsegmentation
Key point A synthesis of least privilege + fail-safe default + assume breach, per request A pragmatic migration built on identity (16), authZ (17), network (6–7)

Do not build ZT from §3.6 alone — understand it here, build it in Ch.32. It is never a product.

Certification crosswalk

Concept CompTIA Security+ (ISC)² CISSP domain
CIA triad 1.0 General Security Concepts Security & Risk Management
AAA / non-repudiation 1.0; 4.0 Security Operations Identity & Access Management; Security Operations
Control types (function × nature) 1.0 General Security Concepts Security Architecture & Engineering
Least privilege / separation of duties 1.0; 4.0 Security & Risk Management; IAM
Fail-safe defaults / secure design principles 1.0; 3.0 Security Architecture Security Architecture & Engineering
Defense in depth / assume breach 1.0; 3.0 Security Architecture & Engineering
Zero trust 1.0; 3.0 Security Architecture & Engineering; Comms & Network Security

Project additions this chapter

  • Meridian program: the control framework skeleton — the function × nature matrix as the organizing grid; the Chapter 1 phishing controls entered as the first classified entries; the gap (thin detective layer) recorded. Each cell maps later to NIST SP 800-53 / CIS / ISO 27002 (Ch.28).
  • bluekit toolkit: controls.py — classify(control) → (function, nature), validating both axes so the framework stays consistently labeled.

Common pitfalls

  • Treating availability as "just IT/operations," not security.
  • Confusing logging with non-repudiation (shared accounts destroy attributability).
  • A defense that is all preventive + technical — no detection, no governance of people.
  • Believing a present control is an effective one (untested backups, un-drilled IR plans).
  • Designing separation of duties and then handing one person both roles, or keeping an all-powerful super-user/override that defeats it.
  • Failing open in an information system (fine only for life-safety: fire exits, safety interlocks).
  • Thinking layers add protection when they fail dependently (same vendor, same flaw).
  • Treating zero trust as a product you buy rather than a posture you build incrementally.