Domain 3 - Security Architecture and Engineering

About this note

This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 3 - Security Architecture and Engineering (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience. Domain 3 is the broadest domain of the CISSP — threat modeling, formal security models, system evaluation, hardware, virtualization, cryptography, and physical security all live here.

Threat Modeling

Threat modeling is structured pessimism: systematically asking what can go wrong with a design before it’s built, instead of discovering it in the pentest report. The methodologies differ mainly in perspective — who models, and around what the analysis is organized.

PASTA — Process for Attack Simulation and Threat Analysis

PASTA is the risk-centric methodology: it ties every technical finding back to business impact, which makes it the natural choice when threat modeling has to justify itself to management. It’s a dynamic threat identification, enumeration, and scoring process in seven stages:

1. Definition of the Objectives (DO) — what does the business need this system to do, and what would loss look like?
2. Definition of the Technical Scope (DTS) — the attack surface: components, dependencies, trust boundaries.
3. Application Decomposition and Analysis (ADA) — break the application into its parts, data flows, and trust relationships.
4. Threat Analysis (TA) — which threat actors and threat scenarios apply, informed by real intelligence.
5. Weakness and Vulnerability Analysis (WVA) — map threats to actual weaknesses in the design and implementation.
6. Attack Modeling & Simulation (AMS) — model and simulate the attacks to validate feasibility.
7. Risk Analysis & Management (RAM) — score the risk and drive it into the risk management process from Domain 1.

The through-line: PASTA starts with business objectives and ends in risk management. It’s heavyweight, but the output speaks the language of the people who fund remediation.

STRIDE

STRIDE is Microsoft’s developer-focused model — the one you actually use in a design review, walking a data-flow diagram element by element and asking six questions. Its elegance is that each threat category maps 1:1 to the security property it violates:

1. Spoofing — threat to authenticity: pretending to be someone or something else.
2. Tampering — threat to integrity: unauthorized modification of data or code.
3. Repudiation — threat to non-repudiation: performing an action and plausibly denying it.
4. Information disclosure — threat to confidentiality: data reaching parties who shouldn’t see it.
5. Denial of service — threat to availability.
6. Elevation of privilege — threat to authorization: gaining capabilities you weren’t granted.

The property mapping is the exam-relevant part, and it’s also the practical part: for each STRIDE finding, the mitigation class is implied by the violated property (spoofing → authentication, tampering → integrity controls, and so on).

Trike

Trike’s distinguishing feature is that it’s organized around acceptable risk: stakeholders define how much risk they’re willing to accept per asset, and the model audits whether the system’s actual risk stays within those boundaries. Less widely used than STRIDE/PASTA, but conceptually it’s the threat-modeling expression of Domain 1’s risk-appetite idea.

DREAD

DREAD is not a threat identification model but a threat scoring scheme — typically used to rank what STRIDE found. Five factors, each scored 1–10:

• Damage — how bad is it if it happens?
• Reproducibility — how reliably can the attack be repeated?
• Exploitability — how much skill and effort does it take?
• Affected users — what fraction of the user base is hit?
• Discoverability — how likely is an attacker to find it?

The averaged score gives a prioritization order. DREAD’s known weakness is subjectivity (Microsoft itself retired it internally for exactly that reason, and CVSS fills the niche today), but the five questions remain a useful mental checklist for gut-ranking findings.

Secure Design Principles

A set of principles the exam expects you to recognize and that genuinely separate good architectures from bad ones.

Trust but Verify

The traditional model: implicit trust inside the perimeter, verification at the boundary. Once a user or device is inside the network, it’s largely trusted. This is perimeter-based security — castle and moat — and its failure mode defined a decade of breaches: one phished endpoint inside the wall, and lateral movement is nearly free. Listed here as the contrast case for what follows.

Zero Trust

Never trust, always verify — the direct repudiation of perimeter thinking, formalized in NIST SP 800-207. The defensive focus shifts from static network location to the users, assets, and resources themselves: every access request is authenticated and authorized based on identity, device posture, and context, regardless of where the request originates. Network position stops being an authentication factor. Practically, zero trust is less a product than an architecture program: strong identity, device health attestation, microsegmentation, and per-request policy enforcement — the logical endpoint of the defense-in-depth assumption that every outer layer is already compromised.

Privacy by Design

Three commitments: proactive not reactive (privacy is engineered in before problems occur, not patched after), privacy as the default (the out-of-the-box configuration is the most private one; users opt in to sharing, not out), and end-to-end security across the entire data lifecycle from Domain 2 — acquisition through destruction. GDPR made this legally mandatory (Art. 25), so it has moved from design philosophy to compliance requirement.

Shared Responsibility

The cloud-computing division of labor: security responsibility is shared between customer and provider, with the split depending on the service model (detailed in the IaaS/PaaS/SaaS section below). The provider secures the cloud; the customer secures what they put in the cloud. Most cloud breaches — exposed storage buckets, over-permissive IAM — happen on the customer side of the line, usually because someone assumed the provider’s side covered it.

Secure Defaults

Software should ship as secure as possible out of the box — hardened configuration, minimal exposed services, no default credentials. The engineering tension is real: maximum security can strangle usability, so the principle explicitly calls for risk analysis and usability testing to find the right balance. The test: a user who never touches the settings should end up safe, not exposed.

Fail Securely

When a system fails, it must fail into a secure state. The canonical example: a firewall under overload must not start passing traffic unfiltered. The vocabulary pair to keep straight: fail-open/fail-safe (failure preserves safety/availability — a door that unlocks during a fire so people can escape) versus fail-closed/fail-secure (failure preserves security — the same door staying locked to protect the vault). Which one is correct is a design decision per component, and human life always wins the tiebreak.

Keep It Simple

Complexity is the enemy of security: the more complex a security mechanism, the larger its attack surface, the harder it is to configure correctly, and the more likely users are to bypass it. Simple security is understandable and accepted — and a control that people accept and use correctly beats a theoretically stronger one they route around.

Security Models

Formal security models are the mathematical skeletons under access control — each one formalizes a specific protection goal. The exam wants the rules cold; the practice value is recognizing which model a real system is (often unknowingly) implementing.

DAC — Discretionary Access Control

The owner decides: a subject has full control over objects it created and can grant access to others at its discretion. Unix file permissions and NTFS ACLs are DAC. Flexible, and precisely therefore prone to permission sprawl — protection depends on every owner making good decisions forever.

MAC — Mandatory Access Control

The system decides: access is governed by labels and clearances enforced centrally; owners cannot override policy. This is the classification machinery from Domain 2 in enforcement form — and the models below (Bell-LaPadula, Biba) define the rules MAC systems enforce.

Bell-LaPadula

The confidentiality model — only confidentiality; it says nothing about integrity or availability. Built for military classification systems, its rules control information flow between clearance levels:

• Simple Security Property: “No READ UP” — a subject may not read data classified above its clearance. (A Secret-cleared user cannot read Top Secret.)
• * (Star) Security Property: “No WRITE DOWN” — a subject may not write data to a lower classification level. This is the less intuitive one: it prevents a Top Secret process (or a trojan running as one) from leaking secrets by writing them into an Unclassified file.
• Strong Star Property: “No READ or WRITE UP and DOWN” — subjects interact only with objects at exactly their own level.

Mnemonic that holds up: confidentiality means secrets flow up, never down — you can’t read above yourself, and you can’t push knowledge below itself.

Biba

Bell-LaPadula’s mirror image, focused only on integrity — and its rules are BLP’s rules inverted:

• Simple Integrity Axiom: “No READ DOWN” — don’t read data of lower integrity than yourself (don’t base high-integrity decisions on low-integrity input; think of it as “don’t take medical advice from a random forum”).
• * (Star) Integrity Axiom: “No WRITE UP” — a low-integrity subject may not write into high-integrity data (a random process must not modify the audited financial ledger).
• Invocation Property: “No READ or WRITE UP” — a subject may not invoke (request services from) a subject at higher integrity.

The pattern to memorize: BLP protects confidentiality (no read up, no write down); Biba protects integrity (no read down, no write up). If you remember one, invert it to get the other.

Lattice-Based Access Control

The mathematical generalization underneath both BLP and Biba: security levels and compartments form a lattice — a partial ordering where every pair of labels has a defined least upper bound and greatest lower bound. Access is permitted when the subject’s label dominates the object’s label in the lattice. In practice this is what allows MAC systems to handle not just linear levels (Confidential < Secret < Top Secret) but compartments ({Secret, Crypto} vs. {Secret, Nuclear}) with well-defined comparison rules.

Graham-Denning

A model for distributed systems, focused on the relationship between subjects and objects — specifically on how they are securely created, deleted, and granted rights, which BLP and Biba simply assume already happened. It defines eight rules (protection commands) a subject can execute:

1. Transfer Access
2. Grant Access
3. Delete Access
4. Read Object
5. Create Object
6. Destroy Object
7. Create Subject
8. Destroy Subject

The contribution: it made the administration of access rights itself subject to formal rules, not just the access decisions.

HRU — Harrison-Ruzzo-Ullman

An extension of Graham-Denning, focused on integrity of the access rights themselves, with one important generalization: subjects can also be objects (a process can be operated on by another process). It reduces the command set to six operations against an access matrix:

1. Create Object
2. Create Subject
3. Destroy Subject
4. Destroy Object
5. Enter right into access matrix
6. Delete right from access matrix

HRU’s theoretical claim to fame: it proved that determining whether a right can ever leak in a general access-matrix system is undecidable — the formal reason why real systems constrain their access-control machinery rather than allowing arbitrary rules.

Clark-Wilson

The commercial integrity model, and philosophically different from Biba: instead of integrity levels, it enforces integrity through well-formed transactions and separation of duties. Its core move: end users are separated from backend data — subjects never touch objects directly, but only through programs (the access triple: subject → program → object) that enforce that data is only modified in valid, constrained ways.

Separation of duties is the second pillar: no single person completes a sensitive process end to end — the person who creates a purchase order is not the person who approves payment of the invoice. Clark-Wilson is effectively how every serious business application (ERP, banking cores) actually structures integrity, whether its architects have heard the name or not.

Brewer-Nash (“Chinese Wall”)

Focused on information barriers to mitigate conflicts of interest — built for consultancies, law firms, and auditors. Its defining property: access rights change dynamically based on the subject’s history. Once you’ve accessed Bank A’s data, the model automatically denies you access to competing Bank B’s data, because your knowledge now constitutes a conflict. The only classic model where past behavior alters future permissions.

Take-Grant Protection Model

Governs how rights propagate between subjects and objects using a directed graph and four rules: Take (take rights another node holds), Grant (give your rights to another node), Create (create a new node with rights), and Remove (remove rights). Its analytical value: given a rights graph, you can compute whether a subject can ever obtain a given right through chains of takes and grants — turning “could this ever leak?” into a graph reachability question.

Access Control Matrix

The conceptual data structure behind all of it: a table — one row per subject, one column per object — with each cell holding the subject’s rights over that object. Real systems store it decomposed (columns as ACLs on objects, rows as capability lists held by subjects) because the full matrix is enormous and sparse, but every access control mechanism is answering “what’s in the cell?”

Zachman Framework

Not a security model but an enterprise architecture framework that security architecture borrows: a two-dimensional grid crossing six questions — What, How, Where, Who, When, Why — with six perspectives/roles — Planner, Owner, Designer, Builder, Programmer, User. Each of the 36 cells is one view of the enterprise. Its use for security architects: it forces completeness — the security design has answered all six questions from all relevant perspectives, or you can point at the empty cell.

Security Modes of Operation

Classification of how a (MAC-style) system operates, defined by which of four conditions hold for all users versus only some: signed NDA, proper clearance, formal access approval, and need-to-know. The staircase, from most to least restrictive uniformity:

• Dedicated Security Mode — all users have signed NDAs, proper clearance, formal access approval, and need-to-know for all data on the system. Everyone can access everything; the system runs at a single level for a fully cleared population.
• System High Mode — NDA, clearance, and formal approval for all; need-to-know for only some. Everyone could see everything clearance-wise, but need-to-know now restricts actual access: all users can access some data.
• Compartmented Mode — NDA and clearance for all; formal access approval and need-to-know for only some. Compartments now formally partition access.
• Multilevel Mode — NDA for all; clearance, formal approval, and need-to-know for only some. The system simultaneously processes multiple classification levels for users who aren’t all cleared for all of it — the hardest mode to secure, and the one BLP was invented for.

Memorization aid: walking down the list, one requirement per step degrades from “all” to “some”, in the order clearance-related conditions were listed: dedicated (everything all) → system high (need-to-know drops) → compartmented (formal approval drops) → multilevel (clearance drops).

Evaluation Methods and Assurance

How do you know a security product actually delivers the security it claims? Evaluation frameworks answer that with independent, standardized assessment.

The Orange Book (TCSEC) — the US DoD’s Trusted Computer System Evaluation Criteria, the original evaluation standard with its D-through-A1 ratings. Retired, but its vocabulary (trusted computing base, reference monitor) survives everywhere. The Red Book (TNI) extended TCSEC concepts to trusted networking — evaluating network components and communications rather than standalone systems. ITSEC, the European IT Security Evaluation Criteria, was Europe’s parallel effort with a notable innovation: it evaluated functionality and assurance separately. Also retired. All three converged into their successor:

ISO/IEC 15408 — Common Criteria

The current international standard for evaluating security products and systems, with mutual recognition across member countries (evaluate once, accept in many jurisdictions). The vocabulary:

• Target of Evaluation (TOE) — the product or system being evaluated.
• Protection Profile (PP) — an implementation-independent statement of security requirements for a product category (“what any firewall of this class must provide”), typically written by customer communities.
• Security Target (ST) — the vendor’s document: the security claims of this specific TOE, possibly claiming conformance to one or more PPs.
• Evaluation Assurance Level (EAL) — how rigorously the claims were verified, on a scale of 1–7:

1. EAL1 — Functionally tested
2. EAL2 — Structurally tested
3. EAL3 — Methodically tested and checked
4. EAL4 — Methodically designed, tested and reviewed (the ceiling for most commercial products — the highest level economically retrofittable to an existing product line)
5. EAL5 — Semi-formally designed and tested
6. EAL6 — Semi-formally verified design and tested
7. EAL7 — Formally verified design and tested (mathematical proof territory; reserved for small, critical components like separation kernels)

The misreading to avoid: EAL measures assurance depth, not security strength. An EAL4 firewall is not “more secure” than an EAL2 one — its claims were examined more rigorously. What it claims is in the ST; whether those claims fit your threat model is still your problem.

Secure System Design Concepts

NIST SP 800-160v1 — Systems Security Engineering — is the reference discipline for everything in this section: building trustworthy systems by engineering security in from the start rather than certifying it on afterwards.

Layering

Systems are built in layers — Application ↔ OS ↔ Kernel and Drivers ↔ Hardware — with the rule that each layer interacts only with its direct neighbors through defined interfaces. Security value: a well-enforced layer boundary contains compromise; an application bug shouldn’t be able to reach the kernel except through the syscall interface the kernel chooses to expose. Every kernel privilege-escalation CVE is a hole in exactly this containment.

Security Domains

A security domain is the set of resources sharing a trust level, with transitions between domains mediated and controlled. The fundamental pair is kernel mode (unrestricted hardware access) versus user mode (restricted, mediated by the kernel) — the CPU-enforced boundary everything else builds on.

Related vocabulary: open systems are built and evaluated to public standards with documented interfaces (assessable, interoperable), while closed systems are proprietary — which often amounts to security by obscurity: hoping nobody figures out the internals. Kerckhoffs already settled this in 1883 for cryptography, and it generalizes: obscurity can be a layer, never the design.

The Ring Model

Protection rings formalize privilege hierarchically. In the classic x86 model there are four rings (0–3), of which practice uses two — plus one below:

• Ring 3 — user applications: untrusted.
• Ring 0 — kernel: trusted, full hardware control. (Rings 1–2 were meant for drivers/services; mainstream OSes never used them.)
• Ring −1 — hypervisor: hardware virtualization support (Intel VT-x/AMD-V) lets a hypervisor sit below the guest’s ring 0, more privileged than the guest kernels it hosts — the architectural basis of the virtualization section below.

Lower ring = more privilege = more attractive target: compromise at ring 0 owns the OS; at ring −1 it owns every guest on the box, invisibly to all of them.

Hardware Architecture

The classic (pre-SoC) PC architecture the exam still references: the Northbridge connects the fast components — CPU (with its ALU and Control Unit), RAM, GPU — while the Southbridge handles slower I/O — USB, input devices, optical drives, disks — with the two bridges interconnected. (Modern CPUs have absorbed the Northbridge, but the fast-path/slow-path split remains conceptually accurate.)

CPU execution concepts — a vocabulary set the exam likes:

• Multitasking — one CPU rapidly switching between multiple tasks, appearing simultaneous.
• Multiprogramming — the older batch-era sibling of multitasking: multiple programs resident, CPU switches when one blocks.
• Multithreading — multiple concurrent execution threads within a single process, sharing its address space.
• Multicore — multiple independent execution cores on one CPU die: true parallelism.
• Multiprocessing — multiple physical CPUs in one system. SMP (Symmetric Multiprocessing): one OS instance schedules across all processors — the normal server case. MPP (Massively Parallel Processing): each processor runs its own OS instance, coordinated across nodes — supercomputer/cluster territory.

Memory protection mechanisms — the hardware/OS features that keep processes honest: process isolation (each process in its own virtual address space, unable to read or write another’s memory), hardware segmentation (hardware-enforced memory regions), virtual memory with paging (fixed-size pages mapped between RAM and disk) and swapping (moving processes/pages out to disk under memory pressure). Secondary memory is anything not directly CPU-addressable — disks, optical media, USB storage — reachable only via I/O, and where the Domain 2 remanence problems live.

Three named defenses worth knowing precisely:

• TPM (Trusted Platform Module) — a dedicated security chip providing key storage, cryptographic operations, and hardware random number generation. The root of trust for measured/secure boot and the key protector behind BitLocker-style full-disk encryption: keys live in tamper-resistant hardware and are only released to an unmodified platform.
• DEP (Data Execution Prevention) — marks memory pages as non-executable (NX bit), so injected shellcode sitting in a data buffer can’t simply run. Forced attackers toward return-oriented programming — which is what the next control addresses.
• ASLR (Address Space Layout Randomization) — randomizes the memory layout (stack, heap, libraries) per execution, so exploits can’t rely on known addresses. DEP and ASLR together are why memory corruption exploitation became an engineering discipline instead of a copy-paste exercise — raising attacker cost, which is what mitigations are for.

Virtualization, Cloud and Distributed Computing

Virtualization Benefits

The drivers are operational: lower cost (consolidation cuts hardware, power, and cooling), easier maintenance (templates, live migration, standardized images), and easier backup (snapshots capture consistent machine state in seconds). Security inherits both directions: snapshots make rollback after an incident trivial, but VM sprawl means forgotten, unpatched machines accumulating in the inventory.

Hypervisors

• Type 1 (bare metal) — runs directly on hardware (ESXi, Hyper-V, KVM, Proxmox); the guests’ ring −1. Smaller attack surface, the datacenter standard.
• Type 2 (hosted) — runs as an application on a conventional OS (VirtualBox, VMware Workstation). Inherits the entire host OS attack surface underneath it; fine for labs, not for production isolation.

Virtualization Vulnerabilities

The risks specific to the model: VM escape — breaking out of a guest into the hypervisor or host, the worst-case event because ring −1 compromise silently owns every guest; hypervisor security itself — patching and hardening the layer below all your systems; resource exhaustion — one guest starving its neighbors (noisy neighbor as an availability attack); and VM segregation — guests of different trust levels must be separated, both logically and on the virtual network. VMs of comparable sensitivity should share network segments; mixing a DMZ guest and a domain controller on the same host and vSwitch quietly collapses the network segmentation the physical design intended.

Cloud Deployment Models

The canonical definitions come from NIST SP 800-145 — the NIST Definition of Cloud Computing, which fixed the vocabulary for deployment and service models everyone uses since:

• Private cloud — the organization runs its own cloud infrastructure: full control, full responsibility, capex model.
• Public cloud — shared tenancy on a provider’s infrastructure (AWS, Azure, Google Cloud): elasticity and opex, with isolation between tenants delegated to the provider.
• Hybrid cloud — a mix, typically keeping sensitive workloads private while bursting or fronting in public.
• Community cloud — infrastructure shared by a specific community of organizations with common concerns (regulatory, mission) — e.g. government or healthcare clouds.

Service Models and the Responsibility Split

The service models are best understood as points on the shared-responsibility slider — what the customer still secures:

• IaaS (Infrastructure as a Service) — the provider gives you compute, storage, network; you are responsible for the OS, database, application, and its security. Maximum control, maximum residual duty.
• PaaS (Platform as a Service) — the provider manages the platform up through the runtime; you are responsible for the application you deploy on it.
• SaaS (Software as a Service) — the provider runs the whole application; you are responsible for your data — and, always, for identity, access decisions, and configuration.

The constant across all three: data classification, access control, and accountability never transfer to the provider. You can rent the stack, not the responsibility — Domain 2’s controller/processor logic in cloud form.

Emanation and Covert Channels

Electrical emanation is the unintentional leakage of information-bearing signals — electromagnetic radiation from cables, screens, and keyboards — which, intercepted and analyzed, can compromise data without any logical access at all (the threat class TEMPEST shielding standards exist for). Hardware keyloggers exploit the same physical layer from the other direction. The lesson: information doesn’t only leave through the network stack.

Covert channels transfer information through mechanisms not intended for communication — two classic flavors: storage channels (signaling via shared resource state, e.g. file locks) and timing channels (signaling via measurable delays). Covert channels matter because they bypass the entire access-control model: Bell-LaPadula’s no-write-down is useless if a high process can signal a low process by modulating CPU load. Modern side-channel attacks (Spectre/Meltdown-class) are this concept weaponized against hardware.

Steganography and Watermarking

Steganography hides a message inside another medium (image, audio, video) — concealing the existence of communication, where encryption only conceals content. Malware uses it to smuggle payloads and C2 traffic past inspection. Digital watermarking is the defensive cousin: embedding an (often hidden) identifier to fingerprint a file — tracing leaks by marking each recipient’s copy uniquely.

Web Architecture and Attacks

The applet history the exam still carries: Java applets ran OS-agnostic in a browser sandbox; ActiveX ran Microsoft-specific with certificate-based trust instead of a sandbox — signed code got broad system access, an architecture that aged badly. Both are dead technology now, but the design contrast (sandboxing vs. signed-but-unconstrained) remains instructive.

OWASP Top 10 (2017 edition, matching these notes) — the canonical list of web application risk categories:

• A1 Injection — untrusted data interpreted as commands (SQLi, command injection)
• A2 Broken Authentication — flawed session and credential handling
• A3 Sensitive Data Exposure — missing/weak encryption of data at rest and in transit
• A4 XML External Entities (XXE) — XML parsers resolving hostile external entities
• A5 Broken Access Control — authorization failures: IDOR, missing function-level checks
• A6 Security Misconfiguration — defaults, verbose errors, unnecessary services
• A7 Cross-Site Scripting (XSS) — injecting script into pages other users view
• A8 Insecure Deserialization — hostile serialized objects executing on deserialization
• A9 Using Components with Known Vulnerabilities — the unpatched-dependency problem
• A10 Insufficient Logging & Monitoring — breaches that nobody notices for months

(Later editions reshuffled — Broken Access Control took the top spot in 2021 — but the categories themselves are evergreen.)

Database Security

Five concepts, two of which form the attack/defense pair the exam cares about:

• Aggregation — collecting individually harmless pieces of data whose combination is sensitive.
• Inference — the attack built on it: deducing restricted information from the aggregate evidence. Classic example: salary totals per department published before and after one person joins reveal that person’s salary. No individual query violated policy; the combination did.
• Polyinstantiation — the defense: the database maintains two versions of the same record depending on who accesses it. The low-clearance user sees a cover row where the high-clearance row exists, so the absence or lock-state of data stops being an inference signal. This is MLS database machinery (BLP applied to rows).
• Data mining — discovering patterns in large datasets; data analytics — in the security context: building a behavioral baseline and monitoring for deviations, the principle underneath UEBA and anomaly-based detection.

Mobile Security

The control set for endpoints that leave the building: good policies enforced technically — lock down USB ports and optical drives, control network ports, disable auto-run, mandate full-disk encryption (the control that makes a lost laptop an inconvenience instead of a breach), enable remote wipe, and maintain user awareness. MDM (Mobile Device Management) is the enforcement platform for all of it at fleet scale; BYOD is the policy question of applying corporate control to private hardware — usually resolved via containerization (corporate profile/workspace) because users reasonably object to the company wiping their family photos. NIST SP 800-46r2 — the Guide to Enterprise Telework, Remote Access, and BYOD Security — is the reference for exactly this problem space.

Industrial Control Systems

OT (operational technology) — where computers control physical processes, and where availability and safety outrank confidentiality:

• SCADA (Supervisory Control and Data Acquisition) — supervisory systems for geographically distributed infrastructure (grids, pipelines, water). Speaks protocols like DNP3, designed decades before adversarial networks — authentication and encryption were not design goals, which is why ICS security leans so heavily on segmentation and unidirectional gateways.
• DCS (Distributed Control System) — the control system for a single process or plant (refinery, chemical line): local, tightly integrated, real-time.
• PLC (Programmable Logic Controller) — the ruggedized digital computer adapted for the manufacturing environment, directly driving actuators and reading sensors. The device class Stuxnet made famous.

The structural problem: 20–30 year equipment lifecycles meet modern threat actors, patching requires production downtime, and “air gaps” erode with every remote-maintenance contract. Segmentation (Purdue model zones) is the load-bearing control.

Cryptography

The Discipline, Precisely

Three terms the exam distinguishes: cryptology is the umbrella science of securing communication; cryptography is the constructive half — creating messages whose meaning is hidden; cryptanalysis is the adversarial half — the science of breaking encrypted communication. Every cipher’s real strength is measured against the cryptanalysis of its era, which is why “secure” always carries an implicit date.

Mathematical Building Blocks

Modern ciphers are built from boolean logic — OR, AND, NOT, and above all XOR — plus modular arithmetic, which asymmetric cryptography lives on. XOR’s special role: it’s perfectly balanced (output reveals nothing about either input alone) and self-inverting — XOR with the same key twice and you’re back at plaintext. That makes it the mixing operation of symmetric encryption: with the key you decipher trivially; without it, ideally, you learn nothing.

The design goals XOR and its friends serve (Shannon’s terms): confusion — the relationship between key/plaintext and ciphertext should be as complex and random-looking as possible; diffusion — each plaintext bit should influence many ciphertext bits, so local patterns spread and vanish. The two mechanical primitives that implement them: substitution (replace symbols) and permutation/transposition (reorder them). Every modern block cipher is rounds of substitution and permutation stacked until confusion and diffusion are thorough.

Cipher Vocabulary and Classical Types

A cipher is the cryptographic algorithm transforming plaintext into ciphertext (encryption) and back (decryption). The classical families:

• Monoalphabetic substitution — one fixed substitution alphabet. Trivially broken by frequency analysis: letter frequencies of the underlying language (in English: E, T, A…) shine straight through the substitution.
• Polyalphabetic substitution — multiple substitution alphabets, rotating with each character (a different starting point each round). Defeats naive frequency analysis; falls to period-finding methods.
• Transposition cipher — symbols aren’t replaced but reordered; all the original letters are present, scrambled.
• Running key / book cipher — the key is a passage from a well-known text; both parties need only agree on the book and position.

History of Cryptography

The historical arc, compressed — each entry is a milestone in the arms race between cryptography and cryptanalysis:

• Spartan Scytale — transposition by wrapping a leather strip around a rod of agreed diameter; the diameter is the key.
• Caesar cipher — monoalphabetic substitution by fixed alphabet shift. Keyspace of 25: enumerable by hand.
• Vigenère cipher — polyalphabetic substitution keyed by a repeating word; unbroken for three centuries until Kasiski’s period analysis.
• Cipher disk — the mechanical tool making polyalphabetic substitution practical in the field.
• Enigma — the German rotor machine of WWII; its break at Bletchley Park (building on Polish work) founded modern computing and demonstrated that operational sloppiness (predictable message formats, key reuse) kills even strong machinery.
• Purple — the Japanese rotor-based diplomatic cipher, broken by the US before the war’s end.
• One-time pad / Vernam cipher — XOR with a truly random key as long as the message, never reused: the only provably unbreakable cipher. The proof is real; the operational burden (generating, distributing, and destroying pad material securely) is why it’s rarely practical — and any deviation breaks the proof, as the next entry shows.
• Project VENONA — the US decades-long decryption of Soviet traffic, possible precisely because the Soviets reused one-time pad pages. The definitive case study that key reuse converts perfect secrecy into eventual full compromise. (Same era: the Jefferson disk and SIGABA, the US cipher machine that, unlike Enigma, was never broken.)

Export Controls

Cryptography is treated as a weapon by export law: COCOM was the Cold War regime preventing export of critical technology to the Eastern Bloc; its successor, the Wassenaar Arrangement, limits export of military and dual-use technology — strong cryptography included. Why practitioners care: export-grade deliberately-weakened ciphers from the 1990s haunted protocols for decades (the FREAK and Logjam attacks exploited servers still accepting export-grade parameters twenty years later). Legal constraints on crypto have a long technical half-life.

Encryption Today

Asymmetric Cryptography

Asymmetric (public-key) cryptography uses mathematically linked key pairs: encrypt with the recipient’s public key, decrypt with their private key — solving the key-distribution problem that plagues symmetric crypto, at the cost of being slow (orders of magnitude slower than symmetric). Which is why real systems are hybrid: asymmetric crypto exchanges or wraps a symmetric session key, and the bulk data runs symmetric — the TLS pattern.

Used in the reverse direction — encrypt (sign) with your private key, verify with your public key — the same math provides digital signatures, and with them authentication and non-repudiation: only the private-key holder could have produced it.

The hard problems the security rests on:

• Prime number factorization — multiply two large primes: easy. Recover the primes from the product: infeasible at scale. RSA’s foundation.
• Discrete logarithms — the inverse of modular exponentiation is similarly one-way. Foundation of Diffie-Hellman (the original key-agreement protocol — old, but its ephemeral variants still power forward secrecy in TLS) and of:
  • ElGamal — encryption/signatures built on DH, used in GnuPG/PGP.
  • DSA — the Digital Signature Algorithm; operates in two phases: generate domain parameters, then compute the key pair.
  • ECC — elliptic-curve variants of the discrete-log problem: equivalent security at far smaller key sizes (a ~256-bit EC key ≈ 3072-bit RSA), hence the choice for low-power devices — and by now for most of the modern web.
• Knapsack (Merkle-Hellman) — an early scheme based on the subset-sum problem; broken, no longer secure. Historical footnote and exam distractor.

Looming over all of the number-theoretic schemes: a sufficiently large quantum computer (Shor’s algorithm) breaks factorization and discrete logs, which is what the current NIST post-quantum migration is about.

Symmetric Cryptography

One shared key for encryption and decryption: fast, but the key must be distributed secretly — and pairwise. The scaling formula worth memorizing: number of keys = n(n−1)/2 for n parties. Ten users need 45 keys; a thousand need 499,500 — the arithmetic that makes PKI necessary.

Block cipher modes of operation — how a cipher processing fixed blocks handles arbitrary-length data. Five classics:

• ECB (Electronic Codebook) — each block encrypted independently. Identical plaintext blocks → identical ciphertext blocks: patterns survive (the famous ECB-penguin image). Never use for real data.
• CBC (Cipher Block Chaining) — each block XORed with the previous ciphertext block before encryption; needs an IV, errors propagate one block.
• CFB (Cipher Feedback) — turns the block cipher into a self-synchronizing stream cipher.
• OFB (Output Feedback) — generates a keystream independent of the data; no error propagation.
• CTR (Counter) — encrypts an incrementing counter to produce the keystream: parallelizable, seekable, the modern favorite (and the basis of GCM, which adds authentication).

The algorithms:

• DES — 64-bit block cipher, effective 56-bit key, 16 Feistel rounds. No longer secure — 56 bits fell to brute force in the late 1990s; today it’s hours of commodity compute. Historically important as the first public standard cipher.
• 3DES — three passes of DES (encrypt/decrypt/encrypt) over the same 64-bit blocks. Keying option 1: three independent keys, ~112-bit effective strength (meet-in-the-middle eats the rest) — the common mode. Keying option 2: two keys (K1, K2, K1), ~80-bit. Keying option 3: one key three times — exactly DES, exactly as broken. The notes’ “secure until 2030” was NIST’s original deprecation horizon; NIST has since accelerated: 3DES is deprecated for new use and disallowed after 2023. The 64-bit block size is its own problem (Sweet32 collision attacks on long-lived connections).
• IDEA — 64-bit blocks, 128-bit key, designed as a DES replacement; technically sound but patents killed adoption (its niche was classic PGP).
• AES (Rijndael) — the standard, and the one to know in detail. 128-bit blocks; key size determines rounds: 10 for 128-bit, 12 for 192-bit, 14 for 256-bit keys. Not a Feistel design but a substitution-permutation network — each round applies SubBytes (substitution), ShiftRows (permutation), MixColumns (diffusion), and AddRoundKey, with the final round omitting MixColumns. Hardware acceleration (AES-NI) makes it effectively free on modern CPUs.
• Blowfish — 64-bit Feistel cipher, 32–448-bit keys. The small block size is the weakness; the designer (Schneier) himself recommends Twofish instead. (Its key-schedule slowness lives on usefully in the bcrypt password hash.)
• Twofish — the successor: 128-bit Feistel cipher, 128/192/256-bit keys, an AES finalist, considered secure — just outcompeted by AES’s hardware support.
• Feistel structure (the pattern behind DES, 3DES, Blowfish, Twofish, RC5/6): split the block into left and right halves; each round transforms one half with a function of the other and swaps. The elegance: encryption and decryption use the same structure with reversed round keys, and the round function itself never needs to be invertible. The original note’s “right half never changes” refers to within a single round — the untouched half is what gets swapped forward.
• RC4 — a stream cipher (not block), 40–2048-bit keys, once ubiquitous in WEP/WPA(TKIP) and SSL/TLS. Keystream biases broke it in practice; prohibited in TLS since RFC 7465. Historical.
• RC5 — flexible block cipher: 32/64/128-bit blocks, 0–2040-bit keys, Feistel-like structure; parameterizable and still regarded as sound with adequate parameters.
• RC6 — RC5’s evolution and an AES finalist (“AES3” in the notes = third-round finalist): 128-bit blocks, 128/192/256-bit keys. Considered secure; simply lost the standardization race.

Hashing

A hash function proves integrity: a one-way function taking variable-length input to fixed-length output, where any input change produces a completely different digest, and reversing or forging is computationally infeasible. A collision — two different inputs producing the same hash — is the death of a hash function, because forgeable collisions let an attacker substitute documents under a valid signature.

• MD5 — 128-bit digest. Collisions are practical (demonstrated with colliding certificates); acceptable only as a non-security checksum. MD6 was its intended successor but lost to SHA-2/3.
• SHA-1 — 160-bit digest; practically broken for collisions (Google’s SHAttered, 2017). Do not use.
• SHA-2 — the current workhorse family: SHA-224/256/384/512, structurally SHA-1-like but with no practical attacks. What TLS, code signing, and almost everything else uses today.
• SHA-3 (Keccak) — a deliberately different construction (sponge), standardized as insurance in case SHA-2’s structure ever cracks. Secure; adoption is gradual because SHA-2 remains unbroken.
• RIPEMD / RIPEMD-160 — the European academic family; RIPEMD-160 survives mainly because Bitcoin addresses use it.

Two supporting concepts: salting — unique random data mixed into each password before hashing, defeating precomputed rainbow tables and preventing identical passwords from producing identical hashes; and a nonce — a number used once, guaranteeing freshness in protocols and preventing replay. Related in spirit, different in job: salt makes hashes unique, a nonce makes sessions unique.

Attacks on Cryptography

Organized by what the attacker has and does — the taxonomy matters because cipher security claims are always relative to an attack model:

Against keys and operations:

• Steal the key — never forget the cheapest attack: why break math when you can compromise the endpoint, bribe the admin, or read the key from an unprotected config file?
• Brute force — try every possible key. Defeated by keyspace size and by key stretching — deliberately slow derivation functions (bcrypt, PBKDF2, Argon2) that add a second or two per verification: unnoticeable to a user, catastrophic to an attacker attempting billions of guesses.
• Rainbow tables — precomputed plaintext→hash mappings traded as lookup tables; the attack that salting exists to kill.
• Social engineering — the key holder as the vulnerability.

Classical cryptanalysis by attacker knowledge (ascending capability):

• Known plaintext — attacker possesses plaintext/ciphertext pairs and hunts the key.
• Chosen plaintext — attacker gets plaintexts of their choosing encrypted (a webapp encrypting attacker-supplied cookies qualifies).
• Adaptive chosen plaintext — chosen plaintext where each round’s choices adapt to previous results.
• Known key (partial) — attacker knows something about the key: length, syntax, character set — shrinking the search space.
• Digraph attack — frequency analysis extended to letter pairs rather than single letters.
• Meet-in-the-middle — attacks layered ciphers from both ends simultaneously; the attack that reduces 3DES’s nominal 168 bits to ~112 effective, and the reason “double DES” was never worth building.

Modern analytic techniques:

• Differential cryptanalysis — study how controlled differences in related plaintexts propagate into ciphertext differences.
• Linear cryptanalysis — given a large corpus of plaintext/ciphertext pairs under the same key, find linear approximations of the cipher’s behavior. Differential-linear combines both. (DES’s S-boxes turned out to be pre-hardened against differential attacks — the NSA knew the technique decades before academia.)

Against implementations rather than algorithms — where the practical action is:

• Side-channel attacks — exploit physical leakage: timing, power consumption, CPU cycles, EM emissions, cache behavior. The algorithm is untouched; its physical execution betrays it.
• Implementation attacks — flaws in how the crypto was coded: bad randomness, padding-oracle behavior, non-constant-time comparisons. Real-world crypto failures are overwhelmingly here, not in the math.

Against protocols and sessions:

• Man-in-the-middle — attacker relays and possibly alters traffic through a box they control; authentication of endpoints (certificates) is the countermeasure.
• TCP session hijacking — taking over an established session ID to masquerade as the authenticated user.

Design pathology:

• Key clustering — when two different keys encrypt the same plaintext to the same ciphertext, either key decrypts the other’s traffic. A cipher design flaw that silently multiplies attacker chances.

Implementing Cryptography

PKI — Public Key Infrastructure

PKI is the machinery that makes asymmetric crypto usable at scale: it combines symmetric and asymmetric encryption plus hashing to provide and manage digital certificates — solving the problem the n(n−1)/2 formula creates. Operational rules: the private key stays secret (compromise = identity theft), key pairs are backed up securely, and key recovery follows the four-eyes principle — no single person can retrieve escrowed keys alone, because recovery capability is itself a master key to everything.

Key escrow — keys held by a third party — exists in two flavors: corporate (recovering an ex-employee’s encrypted files: legitimate and necessary) and governmental (lawful-access mandates: the Clipper-chip debate that never dies). Either way, the escrow becomes the highest-value target in the system.

Digital Signatures

A digital signature provides integrity (the content demonstrably unaltered) and non-repudiation (only the private-key holder could have signed). The full flow, worth walking once precisely:

Alice hashes her data → encrypts the hash with her private key (that encrypted hash is the signature) → sends data + signature. Bob independently hashes the received data, decrypts the signature with Alice’s public key, and compares the two hashes. Match ⇒ the data is unaltered (hashing = integrity) and it was signed by Alice’s private key (= non-repudiation). Note what’s absent: confidentiality — the data itself travels in the clear. If needed, Alice additionally encrypts the whole package with Bob’s public key — possible, just not the default, since signing and secrecy are separate goals.

Digital Certificates

A certificate is a public key plus identity, signed by an authority — the binding that tells you whose key this is. The ecosystem:

• CA (Certificate Authority) — issues and revokes certificates; the trust anchor. Server certificates drive SSL/TLS; client certificates provide user authentication and signing.
• RA/ORA (Organizational Registration Authority) — verifies identities on the CA’s behalf before issuance; registration desk, not signer.
• CRL (Certificate Revocation List) — the CA’s periodically published list of revoked certificates. Reliable but heavy and laggy: clients download the whole list, and revocation takes effect at the next publication.
• OCSP (Online Certificate Status Protocol) — the client/server alternative: query the status of one certificate in real time. Faster and better balanced than CRLs; OCSP stapling fixes its privacy and latency drawbacks by having the server attach a fresh signed status to the handshake itself.

MAC and HMAC

• MAC (Message Authentication Code) — a hash computed with a shared key, providing integrity and authenticity (an unkeyed hash proves only integrity: anyone can recompute it; a keyed one proves the sender knew the key). CBC-MAC builds one from a block cipher in CBC mode.
• HMAC — the standardized keyed-hash construction: a pre-shared key is combined with the message through a nested hash. The receiver repeats the computation and compares. HMAC is everywhere — TLS record integrity, API request signing, JWT HS256 — because it’s simple and provably as strong as its underlying hash.

SSL / TLS

SSL topped out at version 3.0 — and every SSL version is now broken and prohibited (POODLE finished SSLv3). TLS is its successor and the actual protocol behind every “SSL certificate” sold today — the name outlived the protocol. Originally framed as “SSL for web, TLS for mail/chat”; in reality TLS secures effectively all of it, with TLS 1.2 and 1.3 the only versions that belong in a current configuration.

IPsec — Internet Protocol Security

A protocol suite adding a cryptographic layer to IP traffic — built into IPv6, retrofitted onto IPv4, and the workhorse of site-to-site VPNs. The components:

• AH (Authentication Header) — per-packet authentication and integrity, plus replay protection (sequence numbers). No confidentiality — the payload is authenticated but visible. AH also breaks through NAT (it authenticates the IP header NAT rewrites), which is why in practice it lost to:
• ESP (Encapsulating Security Payload) — provides confidentiality, and can provide authentication and integrity too. Modern deployments run ESP with authentication and skip AH entirely.
• SA (Security Association) — the negotiated parameter set for one protected simplex (one-way) connection, identified by a unique 32-bit SPI (Security Parameter Index). Simplex is why the accounting doubles: a bidirectional ESP tunnel needs two SAs; running AH and ESP both ways needs 2 × 2 = four.
• ISAKMP — the framework managing SA creation and key exchange.
• IKE (Internet Key Exchange) — the negotiation protocol: since IPsec supports many ciphers and hashes, the two endpoints use IKE to agree on the strongest mutually supported set (and to authenticate each other and derive keys — in practice IKEv2 is ISAKMP’s living implementation).

The two modes — which apply to how ESP/AH encapsulate, and which the exam loves:

• Tunnel mode — the entire original packet (header included) is encrypted/authenticated and wrapped in a new IP header. Site-to-site VPNs: internal topology hidden, gateways speak for whole networks.
• Transport mode — only the payload is protected; the original IP header stays. Host-to-host protection between endpoints that are themselves the communicating parties.

PGP — Pretty Good Privacy

End-to-end email/file crypto providing confidentiality, integrity, authentication, and non-repudiation through a serial combination: hash → compress → symmetric-encrypt the message with a random session key → asymmetric-encrypt the session key for the recipient — the textbook hybrid construction. Its distinguishing trust model: no CAs, but a web of trust — users sign each other’s keys, and trust accumulates transitively through the signature graph. Decentralized and surveillance-resistant in theory; in practice the usability burden kept it a specialist tool (and its modern descendants — GnuPG for artifacts and package signing — quietly run half the software supply chain).

MIME and S/MIME

MIME is simply the standard for formatting email beyond plain ASCII — attachments, character sets, multipart bodies. No security whatsoever. S/MIME adds it: PKI-based encryption and signing of MIME email — the CA-and-certificate counterpart to PGP’s web of trust, and therefore the variant that wins in enterprises, where certificates can be issued and managed centrally.

Physical Security

Domain 3 closes with physical security — the layer where all the logical models become irrelevant if someone can simply carry the server away. The functional control types (from Domain 1) recur here constantly, so once more, physically flavored: preventive (stops the action — locks, bollards), detective (notices it — CCTV, alarms), deterrent (discourages it — fences, visible guards), compensating (stands in where the primary control is impractical or too costly), and administrative (the framework — policies, compliance, law). Most physical controls serve several functions at once, and exam questions hinge on naming which.

Perimeter Defense

Working from the property line inward — with each control’s functions in parentheses:

• Fences (deterrent, preventive) — height determines function: ~1 m deters casual crossing, ~2 m+ with barbed wire actually prevents.
• Gates (deterrent, preventive) — rated by ASTM classes 1–4: residential, commercial, industrial, restricted-access (crash-rated).
• Bollards (preventive) — stop vehicles, including the ram-raid scenario, while letting people pass.
• Lights (detective, deterrent) — attackers prefer the dark; lighting is cheap denial of it.
• CCTV (detective, deterrent) — detective in real time only if someone watches; otherwise it’s forensic evidence after the fact. The visible camera also deters.
• Locks (preventive) — the taxonomy: key/bitting-code locks, pin tumbler locks (the standard mechanical design, pickable by design tolerance), master-keyed and core systems (convenience at the cost of a catastrophic single secret — the master bitting), and combination locks (shoulder-surfable, shareable). Locks buy time, and are rated in minutes of resistance — the honest metric for every physical barrier.
• Access cards — magnetic stripe (trivially cloneable, legacy), contact smart cards and contactless smart cards (cryptographic challenge-response; clone resistance depends on the chip generation — legacy MIFARE Classic is broken, modern DESFire is solid).
• Mantrap — two interlocked doors with an airlock between: defeats tailgating structurally, because only one person fits per cycle.
• Turnstile (deterrent, preventive) — the lighter-weight tailgating control.
• Contraband checks (detective, deterrent, preventive) — inspection of what enters and leaves; airports and courthouses, and data centers worried about walking disks.
• Motion detectors (detective, deterrent) — by physics: ultrasonic, microwave, infrared (PIR), laser — each with characteristic false-alarm profiles (PIR: heat sources; microwave: movement behind thin walls).
• Guards (deterrent, preventive, detective, and compensating) — the only control with judgment: guards can evaluate ambiguity, challenge pretexts, and adapt — which is why they compensate for so many gaps. Classified as professional (trained and armed), amateur (armed, untrained — arguably the worst quadrant), and pseudo (unarmed presence).
• Dogs (deterrent, detective, compensating) — effective and hard to social-engineer; liability is the standing caveat.

Site Selection and Design

Selection factors: greenfield (building fresh vs. inheriting constraints), topography (flood plains, visibility, natural barriers), utilities (redundant power feeds, carrier diversity), and local crime profile.

Design doctrine: don’t advertise — a data center should be non-descript, unlabeled, revealing as little as possible about what’s inside. Lock the wiring closets (the perennially forgotten interior perimeter — network access without touching the server room). Know your demarc — the point of demarcation where the carrier’s responsibility ends and yours begins. And design for the future: how much HVAC headroom, what environmental events to factor in, whether power capacity survives growth — blackouts and brownouts included — and what kind and capacity of UPS bridges the gap until generators take over.

Supporting Infrastructure

Media storage: encrypted (it’s data at rest), stored off-site, in temperature- and humidity-controlled conditions — Domain 2’s storage requirements, physically implemented.

Asset tracking: an accurate inventory (you can’t protect what you don’t know you have), hardware hardening, and USB ports disabled physically or logically — the endpoint’s most abused physical interface.

Electricity must be clean and reliable. The fluctuation vocabulary — six terms, three axes (power vs. voltage, long vs. short, loss vs. excess):

Term	Meaning
Blackout	long total loss of power
Fault	short total loss of power
Brownout	prolonged low voltage
Sag	short low voltage
Surge	prolonged high voltage
Spike	short high voltage

The defense chain: surge protectors (clip the high-voltage events) → UPS (battery bank ensuring clean, uninterrupted power and bridging to…) → generator (fueled, for sustained outages — sized and tested under load) → PDU (delivering the right voltage to the racks).

Electromagnetic interference (EMI) — including cable crosstalk — maps to all three CIA properties: corrupts data (integrity), can be intercepted (confidentiality — the emanation problem again), and disrupts transmission (availability). Shielding, cable separation, and distance from power runs are the fixes.

HVAC: temperature 20–25 °C (overcooling wastes money and raises humidity), positive pressure inside the DC (air leaks out, dust and smoke stay out), humidity 40–60% — the two failure directions being the exam favorite: too dry → static electricity; too humid → corrosion.

Detectors: heat detectors (threshold or rate-of-rise), smoke detectors — ionization (fast, flaming fires) vs. photoelectric (smoldering fires) — and flame detectors sensing the infrared signature of open flame.

Personnel Safety

The non-negotiable ordering: people before property, always. Clear policies and procedures, evacuation plans with defined meeting points (so headcount can establish who’s missing), explicit plans for disabled employees, fire and evacuation drills quarterly or at least annually (an untrained plan is a document, not a capability), and warning signage and sirens.

Fire: Theory, Classes, Suppression

Fire requires the fire triangle — oxygen, heat, and fuel ; every suppression method works by removing one of the three (or interrupting the chain reaction, the fourth element of the extended tetrahedron).

Fire classes, with the memory hooks:

• Class A (ash) — ordinary combustibles: wood, paper, trash.
• Class B (barrel) — flammable liquids and gases.
• Class C (current) — electrical fires: the data center’s native class.
• Class D (dynamite) — combustible metals: magnesium, lithium.
• Class K (kitchen) — fats and cooking oils.

Water systems — effective on Class A, not what you want over live electronics; where water systems exist near IT space:

• Sprinkler heads trigger independently, each by its own thermal bulb — color-coded by trigger temperature: orange 57°C / red 68°C / yellow 79–89°C / green 93°C. One head opening does not open the floor.
• Wet pipe — water standing in the pipes: simple, fast, and a freezing/leak risk over equipment.
• Dry pipe — pipes hold pressurized air; water enters only on activation. Slower, safer for cold or IT-adjacent spaces.
• Deluge — dry pipe with open heads and no pressurized air: on activation, everything floods at once. High-hazard industrial use.

Gas suppression — the data-center answer, displacing oxygen or interrupting combustion without wrecking the electronics:

• CO₂ — effective, odorless, colorless, and lethal: unmanned areas only, with pre-discharge alarms.
• Halon 1301 — fast and effective; banned from new production since 1994 (ozone depletion, Montreal Protocol). Legacy systems persist.
• FE-13 (fluoroform) and FM-200 (HFC-227ea) — the modern clean agents; FM-200 is the common data-center choice today.
• Inergen — a nitrogen/argon/CO₂ blend that lowers oxygen enough to kill the fire while remaining breathable for occupants.

Fire extinguishers — clearly marked, matched to the fire class, operated by PASS: Pull the pin, Aim at the base, Squeeze the lever, Sweep side to side. Agent notes: soda-acid is obsolete; dry powder lowers temperature and smothers — the agent for metal (Class D) fires; wet chemical smothers with foam — the Class K kitchen agent.

---

Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 3 - Security Architecture and Engineering (Original-Stichpunkte)