Chapter 1: Introduction to Cybersecurity#
“The only truly secure system is one that is powered off, cast in a block of concrete, and sealed in a lead-lined room with armed guards, and even then I have my doubts.” – Gene Spafford
Learning Objectives#
After completing this chapter, you will be able to:
Define cybersecurity and distinguish it from information security and computer security.
State the CIA triad and explain each property with a real-world example, and extend it with the AAA, DAD, and Parkerian models.
Identify the four elements of an attack: threat, vulnerability, attack surface, and exploitation, and relate them through the risk equation.
Explain the adversary model: who attacks, why, and with what capability, from script kiddies to advanced persistent threats (APTs).
Describe the NIST Cybersecurity Framework 2.0 functions and map them to defensive practice.
Apply the single loss expectancy (SLE), annualized rate of occurrence (ARO), annualized loss expectancy (ALE), and return on security investment (ROSI) formulas to quantify risk in monetary terms.
Explain the defense-in-depth principle and the layered security model.
Distinguish security controls by function (preventive, detective, corrective, deterrent, compensating, directive) and by type (administrative, technical, physical).
Describe the hardware foundations of security: CPU protection rings and the more privileged levels beneath ring 0, the software and hardware that run at each level, why rings 1 and 2 were meant for device drivers yet go unused, kernel and user mode, System Management Mode, where trusted platform modules (TPMs) and trusted execution environments (TEEs) fit, from enclaves to confidential virtual machines, the trusted computing base (TCB), and the reference monitor.
Key Terms#
Cybersecurity: the practice of protecting systems, networks, programs, and data in cyberspace from digital attack, damage, or unauthorized access.
Information security (InfoSec): the broader discipline of protecting information in any form, digital or physical, across its entire lifecycle.
CIA triad: Confidentiality, Integrity, and Availability; the three core security properties.
AAA: Authentication, Authorization, and Accounting; the operational pillars of access control.
Threat: any circumstance or event with the potential to harm an asset.
Threat actor: the entity (person, group, or automated process) that carries out a threat.
Vulnerability: a weakness in a system that a threat can exploit.
Attack surface: the sum of all points where an unauthorized user can try to enter or extract data.
Attack vector: the specific path or method a threat actor uses to reach a target.
Exploit: code or a technique that takes advantage of a vulnerability.
Risk: the likelihood that a threat will exploit a vulnerability, multiplied by the resulting impact.
Asset: anything of value to an organization that warrants protection.
Control (safeguard, countermeasure): a measure that reduces risk by mitigating a vulnerability or the impact of a threat.
Negative rings: informal names for the levels beneath ring 0: ring -1 (the hypervisor), ring -2 (System Management Mode) and ring -3 (the platform security processor).
System Management Mode (SMM): an x86 operating mode, entered only through a system management interrupt, in which firmware runs from protected memory that the operating system cannot see.
User-mode driver: a device driver that runs in an ordinary ring 3 host process, so that its failure does not crash the operating system.
Trusted platform module (TPM): a root of trust that securely stores keys and records platform measurements; it may be a discrete chip, integrated circuitry, or firmware.
Trusted execution environment (TEE): an area that hardware protects even from more privileged software, such as an SGX enclave or the Arm TrustZone secure world.
Confidential virtual machine: a virtual machine whose memory and processor state hardware protects from the hypervisor and the cloud operator, such as a trust domain under Intel Trust Domain Extensions (TDX).
Trusted computing base (TCB): the totality of hardware, firmware, and software responsible for enforcing a system’s security policy.
Reference monitor: the abstract machine that mediates every access of a subject to an object.
Principle of least privilege (PoLP): grant only the minimum privileges needed, for as long as needed, to contain compromise.
1.1 What Is Cybersecurity?#
We start with the most basic question of all, what the field actually is, because every later idea, from cryptography to incident response, is a specialized answer to the problem this section frames.
Cybersecurity is the discipline concerned with protecting computer systems, networks, software, and the data they hold from unauthorized access, disruption, modification, or destruction. The term is often used interchangeably with information security, but the two are not identical. Information security is the older and broader field: it protects information in any form, whether printed on paper, spoken aloud, stored on a hard drive, or transmitted across a fiber-optic cable. Cybersecurity is the subset of information security that deals specifically with information and systems that exist in or are reachable through cyberspace, the interconnected domain of digital networks. A third adjacent term, computer security, narrows the focus still further to the protection of individual machines and their operating systems. In practice these boundaries blur, and most practitioners treat the three terms as members of the same family, choosing whichever word best fits the audience.
The reason the field exists at all is that modern society has become utterly dependent on digital systems. Hospitals schedule surgeries and dispense medication through networked software. Power grids, water treatment plants, and pipelines are operated by industrial control systems. Banks move trillions of dollars as nothing more than authenticated messages. When these systems fail, whether through accident or attack, the consequences spill out of the digital world and into the physical one. A ransomware infection is no longer merely an inconvenience to an IT department; it can close a hospital emergency room or halt fuel delivery to an entire region. Cybersecurity is therefore best understood not as a narrow technical specialty but as a form of risk management for a society that runs on code.
It is useful to internalize early that security is a process, not a product. There is no single device, license, or configuration that makes an organization “secure” once and for all. Threats evolve, software changes, people make mistakes, and yesterday’s strong defense becomes today’s known weakness. Security is achieved and maintained through continuous cycles of identifying assets, assessing risks, applying controls, monitoring for failures, and improving. This mindset, sometimes summarized as continuous improvement, underlies every framework discussed in this book.
A second foundational idea is that perfect security is impossible, and pursuing it is usually wasteful. Gene Spafford’s famous quip at the top of this chapter captures the point with deliberate absurdity: even a computer encased in concrete and guarded around the clock is not perfectly secure, and it is also perfectly useless. Every real system must balance security against usability, cost, and performance. The goal of the cybersecurity professional is not to eliminate risk, which cannot be done, but to reduce it to a level the organization is willing to accept, at a cost the organization is willing to bear. This is why the language of risk, introduced later in this chapter, pervades the entire profession.
It is also worth noting how recently this field matured. Through the 1970s and 1980s, computer security was largely the concern of governments and a handful of researchers; the famous Morris Worm of 1988, which disrupted a large fraction of the early internet, was a wake-up call that networked systems created entirely new categories of risk. The commercialization of the internet in the 1990s, the rise of e-commerce, the explosion of mobile and cloud computing in the 2000s and 2010s, and the more recent spread of connected devices and artificial intelligence have each enlarged the attack surface and drawn in new adversaries. Cybersecurity today is thus a young, fast-moving discipline in which the fundamentals endure even as the specific technologies and threats turn over rapidly, which is exactly why this book emphasizes durable principles alongside current practice.
1.2 The CIA Triad and Its Extensions#
Having defined cybersecurity as the management of risk to information, we need to say precisely what property of information we are trying to preserve. That is the job of the CIA triad and its extensions.
The most enduring model in all of security is the CIA triad: Confidentiality, Integrity, and Availability. These three properties define what it means for information to be secure, and almost every control, attack, and incident can be understood in terms of which of them is being protected or violated. Note that “CIA” here has nothing to do with the intelligence agency; it is simply an acronym for the three properties.
Confidentiality means that information is disclosed only to those authorized to see it. It is the property violated when an attacker steals a database of customer records, when an employee emails a spreadsheet of salaries to the wrong recipient, or when someone reads sensitive documents left on a shared printer. Confidentiality is enforced through mechanisms such as encryption, access control lists, authentication, and the principle of least privilege. The opposite of confidentiality is disclosure.
Integrity means that information is accurate and has not been altered in an unauthorized or undetected way. It is the property violated when an attacker changes the dollar amount on a wire transfer, when malware modifies system files, or when a transmission error silently corrupts a record. Integrity is enforced through cryptographic hashes, digital signatures, message authentication codes, version control, and rigorous change management. The opposite of integrity is alteration.
Availability means that information and services are accessible to authorized users when they need them. It is the property violated by a distributed denial-of-service (DDoS) attack that floods a web server, by ransomware that encrypts files and holds them hostage, or by a simple power failure in a data center. Availability is enforced through redundancy, backups, failover systems, capacity planning, and resilient network design. The opposite of availability is destruction or denial.
A pharmacy holds all three properties at once, which is why it is a better teaching example than three separate ones. Confidentiality is that nobody but the pharmacist reads your prescription. Integrity is that the dose on the label is the dose in the bottle, and an integrity failure here is more dangerous than a confidentiality failure. Availability is that the pharmacy is open when you need the medicine. Each can be lost without the others, and each loss is a genuine harm, which is the point the triad exists to make. The picture has one limit that must be stated alongside it: the three properties are presented as equal and they rarely are. Which one dominates depends on the system, and in industrial control and medical settings availability and integrity routinely outrank confidentiality, which is the opposite of the usual office assumption.
These three opposites form a complementary model sometimes called the DAD triad: Disclosure, Alteration, and Destruction (or Denial). Where CIA describes the defender’s goals, DAD describes the attacker’s goals, and the two map directly onto each other. A useful mental exercise when analyzing any incident is to ask which CIA property was the target and which DAD action the adversary performed.
The CIA triad is powerful but incomplete, and several extensions address its gaps. The AAA model, Authentication, Authorization, and Accounting, describes the operational machinery of access control: authentication establishes who a subject is, authorization determines what that subject may do, and accounting records what the subject actually did. Closely related are non-repudiation, the assurance that a party cannot credibly deny having performed an action (typically provided by digital signatures), and authenticity, the assurance that data genuinely originates from its claimed source.
The most thorough extension is the Parkerian hexad, proposed by Donn Parker, which adds three further properties to the original three: possession or control (having physical or logical custody of data, which can be lost even when confidentiality is preserved, for example when an encrypted laptop is stolen), authenticity (the data is genuine and correctly attributed), and utility (the data is useful, which is lost, for instance, when the only copy of an encryption key is destroyed, leaving the ciphertext intact but worthless). While the simple CIA triad suffices for most everyday reasoning, the hexad is valuable when an incident does not fit neatly into the three classical properties.
The CIA triad and its attacker mirror, the DAD triad, are shown side by side below.
The operational AAA model and the six-property Parkerian hexad extend this vocabulary:
The DIE Model: A Modern Complement to CIA#
A newer model, proposed by Sounil Yu, reframes security for cloud-native infrastructure: the DIE triad, Distributed, Immutable, Ephemeral. Where the CIA triad describes properties we want for data, the DIE model describes properties we want for infrastructure, and the two are complementary rather than competing. Distributed systems spread workloads across many replicas so that losing any one does little harm, supporting availability by design. Immutable infrastructure is never modified after deployment; instead of patching a running server (which risks integrity drift and configuration rot), you replace it wholesale with a new, known-good image, which removes whole classes of tampering and persistence. Ephemeral resources are short-lived, continually torn down and recreated, so a compromised component exists only briefly and there is little long-lived state for an attacker to steal or hide in, which indirectly bolsters confidentiality. The popular shorthand is “cattle, not pets”: treat servers as interchangeable and disposable rather than as cherished, hand-maintained individuals.
The insight behind DIE is that many attacks depend on systems that are singular, mutable, and long-lived: an attacker exploits a unique server, modifies it, and persists on it for months. Distributed, immutable, ephemeral infrastructure denies all three preconditions, which is why cloud-native and DevSecOps practice (Chapters 5 and 17) increasingly designs for DIE while still protecting the underlying data with CIA. The two models together, CIA for data and DIE for infrastructure, give a more complete picture than either alone.
1.3 The Anatomy of an Attack#
Knowing what we want to protect (the CIA properties) naturally leads to the opposite question: how is that protection lost? To answer it we need a precise vocabulary for the pieces of an attack.
To defend systems systematically, we need a precise vocabulary for the elements of an attack. Five terms recur throughout this book, and confusing them is a common source of muddled thinking.
An asset is anything of value worth protecting: a customer database, a domain controller, an employee’s credentials, a company’s reputation, or the availability of a production website. A threat is any potential event or circumstance that could harm an asset. Threats may be deliberate (a criminal seeking to steal data), accidental (an administrator who mistypes a command), or environmental (a flood, fire, or power surge). The entity that carries out a deliberate threat is the threat actor or adversary.
A vulnerability is a weakness that a threat can exploit. Vulnerabilities take many forms: an unpatched software bug, a default password, a misconfigured cloud storage bucket, an employee susceptible to a phishing email, or a building with an unlocked server-room door. A vulnerability is harmless in isolation; it becomes dangerous only when a threat exists that can take advantage of it.
The attack surface is the sum of all the points, the vulnerabilities and entry paths, where an unauthorized actor could attempt to interact with a system. Every running network service, every input field on a web form, every USB port, every employee with email, and every third-party integration adds to the attack surface. A central goal of defensive engineering is attack surface reduction: disabling unused services, closing unnecessary ports, removing default accounts, and applying the principle of least functionality so that there is simply less for an attacker to target. The specific route an attacker takes across the attack surface is the attack vector.
An exploit is the actual code, command, or technique that takes advantage of a vulnerability to produce an unintended effect, such as executing arbitrary code, escalating privileges, or crashing a service. When an exploit is used successfully, exploitation has occurred. The window between the public disclosure of a vulnerability and the availability of a fix is especially dangerous; a vulnerability that is exploited before any patch exists is called a zero-day.
Finally, risk ties these concepts together. Informally, risk is the probability that a threat will successfully exploit a vulnerability, multiplied by the magnitude of the resulting harm. The relationships among these elements are shown below.
graph LR
A[Threat Actor] -->|launches| B[Threat]
B -->|exploits| C[Vulnerability]
C -->|resides in| D[Attack Surface]
B -->|via| E[Attack Vector]
E --> C
C -->|leads to| F[Exploitation]
F -->|causes| G[Impact / Loss]
G -->|combined with probability| H[Risk]
I[Control] -->|reduces| C
I -->|reduces| G
The diagram makes an important point visible: a control can reduce risk either by removing or hardening the vulnerability (lowering the probability of exploitation) or by limiting the impact when exploitation does occur. Effective security programs apply both kinds of control rather than relying on prevention alone. The relationship among threats, vulnerabilities, and mitigations can be pictured as a dam: a reservoir of threats presses against the wall of defenses, a crack is a vulnerability, and a patch placed over the crack is a mitigation (a control). The water level represents the pressure of the threat environment, and the assets sit downstream, at risk if the wall fails.
A Concept Map of the Core Terms#
These foundational terms, flaw, vulnerability, attack surface, threat, attack, exploitation, and risk, are easy to confuse, so the concept map below shows how they relate.
flowchart TD
Flaw["Flaw (loophole)"] -->|is a| Vuln[Vulnerability]
Vuln -->|resides in| AS[Attack Surface]
Threat -->|launches| Attack
Attack -->|exploits| Vuln
Attack -->|results in| Exploit[Exploitation]
Exploit -->|causes harm| Impact[Impact]
Risk -->|probability of| Exploit
Threat -.->|with capability + intent| Risk
Read it as a chain: a flaw is a specific vulnerability that resides in the attack surface; a threat with capability and intent launches an attack that exploits the vulnerability, producing exploitation and impact; and risk is the probability of that exploitation times its impact (quantified in Section 1.8 and Chapter 5). Removing the vulnerability, shrinking the attack surface, or deterring the threat each lowers the risk.
1.4 Threat Actors and the Adversary Model#
The previous section treated the threat abstractly. But defenses must be sized to a real opponent, so we now ask who the threat actors actually are and what they can do.
Not all attackers are equal, and a defense calibrated for a bored teenager will not stop a nation-state intelligence service. Understanding the adversary model, who might attack, what they want, and what resources they command, lets defenders allocate effort proportionately. Security professionals describe an adversary’s strength in terms of capability (skill, tooling, and funding), intent (motivation and goals), and opportunity (access to the target). A credible threat requires all three.
The weakest deliberate actors are script kiddies, individuals with little original skill who run pre-built tools and published exploits they do not fully understand. Their motivation is often curiosity, vandalism, or bragging rights. They are numerous and noisy, and basic hygiene, patching, strong passwords, and default-deny firewalls, defeats most of them.
Hacktivists attack to advance a political or social cause, defacing websites, leaking documents, or launching denial-of-service campaigns against organizations they oppose. Their capability varies widely, but their public, ideological motivation makes their targeting somewhat predictable.
Cybercriminals and organized crime groups attack for financial gain. This is the largest category by volume and includes ransomware operators, banking-trojan crews, business-email-compromise fraudsters, and the sprawling underground economy that sells stolen data and access. Modern cybercrime is professionalized, with specialized roles, customer support, and ransomware-as-a-service affiliate programs. Their capability ranges from moderate to very high.
Insiders are employees, contractors, or partners who abuse legitimate access. A malicious insider acts deliberately, perhaps a disgruntled administrator or an employee bribed by a competitor, while a negligent insider causes harm through carelessness. Insiders are dangerous precisely because they begin inside the trust boundary, bypassing perimeter defenses entirely.
The most capable adversaries are advanced persistent threats (APTs), typically nation-state intelligence and military services or their contractors. The label captures three characteristics: advanced (sophisticated, sometimes custom tooling and zero-day exploits), persistent (long-term campaigns that may maintain covert access for months or years), and threat (well-resourced, patient, and goal-directed). APTs pursue espionage, sabotage, or strategic advantage rather than quick profit. Defending against them requires assuming breach, detecting subtle anomalies, and limiting lateral movement, because preventing initial access against an adversary with effectively unlimited time and budget is unrealistic.
Actor |
Typical capability |
Primary motivation |
Defining trait |
|---|---|---|---|
Script kiddie |
Low |
Curiosity, status |
Uses others’ tools |
Hacktivist |
Low to high |
Ideology |
Public, cause-driven |
Cybercriminal |
Moderate to high |
Financial gain |
Professionalized, scalable |
Insider |
Variable |
Grievance, greed, error |
Starts inside the perimeter |
APT / nation-state |
Very high |
Espionage, sabotage |
Patient, resourced, stealthy |
A complementary tool for reasoning about adversaries is the cyber kill chain, which breaks an intrusion into ordered stages, reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on objectives. Disrupting any single stage can defeat the whole attack, which is the strategic basis for layered defense. The kill chain and the related MITRE ATT&CK knowledge base are developed further in the chapters on penetration testing and detection.
The picture to hold is a burglary: choosing the street, watching the house, obtaining a key, entering, taking things, leaving. Breaking any one stage ends the attempt and breaking an early one costs least, and Section 12.5 draws the picture out and says where it stops being true, since real intrusions loop back and skip stages rather than running once in order.
1.5 Defense in Depth and Security Controls#
Once we accept that capable adversaries exist and that no single barrier stops all of them, the design response follows directly: layer many controls so that one failure is not fatal. This section develops that principle and the vocabulary of controls.
Because no single safeguard is perfect, sound security architecture relies on defense in depth: multiple, overlapping, independent layers of control, so that the failure of any one layer does not result in a breach. The traditional image is a medieval castle with a moat, outer walls, a keep and armed guards, and it is worth naming mainly in order to set it aside: concentric rings imply that everything inside the innermost one is safe, and that perimeter assumption is exactly what Section 11.4 abandons. In a modern enterprise the layers might include perimeter firewalls, network segmentation, host-based protection, application hardening, encryption of data at rest and in transit, strong authentication, continuous monitoring, and a trained, alert workforce. A closely related idea is layered security; the two terms are often used synonymously, though purists distinguish defense in depth (diverse controls across people, process, and technology) from layered security (multiple technical controls of the same kind).
A bank is the working version of the same idea. It does not protect cash with a good front door: there is a door, a guard, a vault, a time lock and cameras, and the design does not assume any one of them works. It assumes each will fail eventually and arranges that a single failure is survivable. That assumption, rather than the number of layers, is what defense in depth means, and it is also the test for whether a set of controls really is layered. If one control failing makes the rest useless, they were a chain and not a depth. Where the picture breaks is worth keeping in view: layers that share a dependency fail together, so five controls that all authenticate against the same directory are one control wearing five hats, which is the common way this principle is claimed without being practiced.
A security control (also called a safeguard or countermeasure) is any mechanism that reduces risk. Controls are classified along two independent axes, and being fluent in this taxonomy is essential both for examinations and for designing real defenses.
The first axis is the control’s type, describing how it is implemented:
Administrative (managerial) controls are policies, procedures, standards, training, and governance, the human and organizational rules that direct behavior.
Technical (logical) controls are implemented in hardware and software: firewalls, encryption, access control lists, intrusion detection systems, and authentication mechanisms.
Physical controls protect the tangible environment: locks, fences, badge readers, security guards, cameras, and mantraps.
The second axis is the control’s function, describing what it does relative to an incident:
Preventive controls stop an incident before it occurs (a firewall blocking traffic, a lock on a door, mandatory access control).
Detective controls identify and signal an incident in progress or after the fact (intrusion detection systems, audit logs, security cameras, file-integrity monitoring).
Corrective controls restore systems after an incident (restoring from backup, applying a patch, removing malware).
Deterrent controls discourage an attacker from attempting an attack (warning banners, visible cameras, the credible threat of prosecution).
Compensating controls provide an alternative when a primary control is not feasible (network isolation of a legacy system that cannot be patched).
Directive controls instruct or mandate behavior (signage, acceptable-use policies).
A single safeguard can play several roles at once. A surveillance camera, for example, is simultaneously physical in type, detective in that it records intrusions, and deterrent in that its visible presence discourages them. When you encounter a control, practice classifying it on both axes; this habit sharpens the analytical reasoning that examinations such as CISSP and Security+ reward, and it ensures that a real-world control set is balanced rather than, say, heavy on prevention but lacking detection and recovery.
1.6 Hardware Foundations: Rings, Modes, and the Trusted Computing Base#
The controls just described are enforced, ultimately, by mechanisms built into the machine itself. Before leaving foundations, we descend to the hardware layer to see what makes any software control trustworthy in the first place.
Security is not only a matter of policy and software; it rests on a foundation built into the processor itself. Modern CPUs enforce protection rings, hierarchical privilege levels that constrain what code is allowed to do. On the x86 architecture there are four rings numbered 0 through 3, drawn as concentric circles in which the innermost ring is the most privileged. The figure below shows them together with the more privileged levels that later hardware added beneath ring 0.
In practice most operating systems use only two of these levels: kernel mode (ring 0), where the operating-system core runs with unrestricted access to memory and hardware, and user mode (ring 3), where ordinary applications run with sharply limited privileges. A user-mode program cannot directly touch hardware, access another process’s memory, or execute privileged instructions. When it needs the kernel to do something on its behalf, such as reading a file or sending a network packet, it makes a system call, a controlled transition that traps into kernel mode, performs the privileged operation under the kernel’s supervision, and returns. This boundary is the single most important security mechanism in a general-purpose computer: it is what stops a buggy or malicious application from simply taking over the machine.
The ring model has been extended downward over time, and security researchers count the additions as negative rings, a naming popularized by conference talks on attacks against them (Tereshkin and Wojtczuk, 2009; Domas, 2015). Hardware virtualization added ring -1 for the hypervisor, which runs beneath guest operating systems that each have a ring 0 of their own, and decides what every guest may touch. Ring -2 is System Management Mode (SMM): a system management interrupt switches the processor into it to run firmware from a protected region of memory that the operating system can neither see nor alter. Ring -3 is not a processor mode at all but a separate security processor on the platform, such as Intel’s Converged Security and Management Engine (CSME) or the AMD Secure Processor, which runs its own firmware independently of the main processor; the AMD Secure Processor even boots before the x86 cores do (Buhren and Eichner, 2020). The negative numbers are informal names rather than hardware ring numbers, but the ordering they express is real: each deeper layer is more powerful and, if compromised, more catastrophic, which is why firmware and hypervisor security have become major concerns. Attackers, for their part, constantly seek privilege escalation: techniques to cross a ring boundary, moving from user mode into kernel mode, or from a guest virtual machine into the hypervisor, in order to gain control the system never intended to grant. Privilege escalation is examined in detail in the chapter on exploitation.
Two security components that readers often look for in this picture are not rings at all, and the figure marks where they sit. A trusted platform module (TPM) is a microcontroller that securely stores keys, certificates and passwords and records measurements of the platform that show whether it is still in a trustworthy state (Trusted Computing Group). The Trusted Computing Group defines three forms of it: a discrete TPM, a separate component in its own package on the board and therefore outside every ring; an integrated TPM, built from dedicated circuitry inside another chip; and a firmware TPM, which runs in a protected mode of a general-purpose processor (Intel, 2022). Intel Platform Trust Technology (PTT) resides in the CSME, and AMD’s firmware TPM is one application of the operating system that runs on the AMD Secure Processor (Buhren and Eichner, 2020), so on a system that uses either one the TPM itself lives at ring -3. A trusted execution environment (TEE) is an area that hardware protects even from more privileged software. On x86, TEEs provide isolation rather than rank. An Intel Software Guard Extensions (SGX) enclave runs as ring 3 code, yet it is designed to keep its code and data safe even when the kernel and the hypervisor are malicious (Costan and Devadas, 2016), and Intel Trust Domain Extensions (TDX) applies the same idea to a whole virtual machine, treating the host platform as untrusted (Cheng et al., 2023).
Arm processors call their privilege levels exception levels, and on them the TEE does have levels of its own. A common arrangement runs applications at exception level 0 (EL0), a rich operating system such as Linux at exception level 1 (EL1), a hypervisor at exception level 2 (EL2), and firmware with the secure monitor at exception level 3 (EL3), the most privileged level, which is always in Secure state and acts as the gatekeeper between the two security states (Arm, AArch64 Exception Model guide). Normal-world software asks the monitor for secure services with a Secure Monitor Call (SMC) instruction (Arm, 2013). Arm TrustZone splits the levels below EL3 into a normal world and a secure world. A trusted operating system, which provides the TEE, runs at secure EL1 with trusted applications at secure EL0 (Arm, 2013), and newer cores add a secure EL2 that isolates secure partitions from one another and from the normal world (Mann, 2018). Software in the secure world can reach both worlds’ memory, while the normal world can reach only its own.
What Runs at Each Level#
Every level in the two figures is home to specific, nameable software, and naming it makes the hierarchy concrete. On x86 the picture looks like this.
Level |
What runs there |
Real examples |
|---|---|---|
Ring 3, user mode |
Applications, services, and some drivers |
A web browser or word processor; Windows services and Linux daemons; drivers written for Microsoft’s User-Mode Driver Framework, which run inside an ordinary host process; an Intel SGX enclave, which is ring 3 code inside an application |
Rings 2 and 1 |
Operating-system services, in Intel’s original design |
Unused by mainstream operating systems; the Xen hypervisor once ran 32-bit guest kernels in ring 1 |
Ring 0, kernel mode |
The kernel and kernel-mode drivers |
The Linux kernel and its loadable modules; the Windows kernel and its .sys drivers, including file system filter drivers and endpoint security sensors; every virtual machine’s own guest kernel |
Ring -1, hypervisor |
The virtual machine monitor |
VMware ESXi, Microsoft Hyper-V (which also hosts Windows virtualization-based security), the Kernel-based Virtual Machine (KVM) in Linux, and Xen; on Intel TDX systems the TDX module runs beside the hypervisor in a mode of its own |
Ring -2, System Management Mode |
Firmware handlers for system management interrupts |
Code that the platform firmware installs for power management, hardware configuration, and thermal monitoring |
Ring -3, security processor |
Firmware on a separate embedded processor |
Intel CSME, whose version 11 runs a modified MINIX and which hosts the PTT firmware TPM; the AMD Secure Processor, an Arm Cortex-A5 core that boots first, hosts AMD’s firmware TPM, and manages the keys for AMD’s confidential virtual machines; Microsoft Pluton, built into recent AMD, Intel, and Qualcomm processors |
Outside the rings |
A discrete TPM on the motherboard |
TPM chips from Infineon, Nuvoton, and STMicroelectronics, such as the ST33 that the TPM-Fail researchers attacked (Moghimi et al., 2019) |
Arm splits most exception levels between the normal and secure worlds, so its table has two columns of software (Trusted Firmware-A, Firmware Design; Hafnium; Android, Virtualization Framework architecture).
Level |
Normal world |
Secure world |
|---|---|---|
EL0 |
Applications, such as Android apps |
Trusted applications, such as code that checks a personal identification number (PIN), matches a fingerprint, or holds media decryption keys |
EL1 |
A rich operating system kernel, such as Linux, which also underlies Android |
A trusted operating system such as OP-TEE or Android’s Trusty; Trusted Firmware-A calls this slot the secure EL1 payload |
EL2 |
A hypervisor such as KVM, or Android’s protected KVM (pKVM), which keeps even the Android kernel out of a protected virtual machine’s memory |
On newer cores, a secure partition manager such as Hafnium |
EL3 |
No normal-world software |
The secure monitor, such as the |
Apple silicon has its own counterpart to ring -3: the Secure Enclave, a dedicated subsystem isolated from the main processor that boots a signed operating system of its own, sepOS, and holds the roots of the device’s data encryption keys along with Face ID, Touch ID, and Optic ID data (Apple, Secure Enclave).
Why Rings 1 and 2 Were Meant for Device Drivers#
Intel’s Software Developer’s Manual (SDM) states why the rings exist: privilege levels improve the reliability of operating systems. Its protection-ring figure gives ring 0 to the operating-system kernel, ring 3 to applications, and the two middle rings to operating-system services, with device drivers as the named example (Intel SDM, Vol. 1, Sec. 6.4.5). The idea is graded trust. Drivers come from many hardware vendors rather than from the kernel’s own developers, yet they need more power than an application, so the design gives them rings of their own between the two.
Two middle rings allow two grades of driver. The processor’s flags register holds a two-bit I/O
privilege level (IOPL), and code may execute the port input and output instructions (IN, OUT, and their
relatives) only when its current privilege level (CPL) is at least as privileged as the IOPL, unless an
I/O permission bitmap kept in the task state segment grants it particular ports. Intel’s manual describes
the typical arrangement: I/O is restricted to rings 0 and 1, so the kernel and the device drivers trusted
with hardware may perform I/O, while less privileged device drivers, the natural tenants of ring 2, and
applications in ring 3 are denied the I/O address space (Intel SDM, Vol. 1, Sec. 20.5.1). A ring 2
service could be trusted with operating-system work but not with the hardware itself. Segment protection
kept each ring out of the memory of the rings inside it, and outer code could call inward only through
gates that the inner ring defined (Intel SDM, Vol. 1, Sec. 6.4.5; Vol. 3A, Sec. 6.5). In principle, then, a
crash or compromise in a ring 2 service could reach neither the hardware nor the kernel’s memory, and a
faulty ring 1 driver could misprogram a device but could not write the kernel’s memory directly.
Almost no mainstream operating system adopted the scheme. The designers of Xen observed in 2003 that, to their knowledge, no well-known x86 operating system had used rings 1 and 2 since OS/2, and Intel’s manual itself advises systems that use only two levels to choose 0 and 3 (Barham et al., 2003; Intel SDM, Vol. 3A, Sec. 6.5). Three reasons stand out.
Paging cannot tell the middle rings from the kernel. When the processor checks a page, every access made at rings 0, 1, or 2 counts as a supervisor access and only ring 3 counts as a user access (Intel SDM, Vol. 3A, Sec. 5.6). Modern operating systems protect memory with paging, so a ring 1 driver could read and write every kernel page unless the system also used segmentation to fence it in.
64-bit mode removed the fence. In 64-bit mode the processor no longer checks the limits of code and data segments, so segmentation cannot confine a middle-ring driver at all (Intel SDM, Vol. 3A, Sec. 6.3.1).
Portability. An operating system that runs on several processor families is built on the user and kernel levels that every family provides; Arm, for example, gives applications EL0 and the kernel EL1.
Ring 1 found a second life in virtualization. Xen ran 32-bit guest kernels in ring 1 so that the hypervisor could keep ring 0 for itself (Barham et al., 2003), until hardware virtualization gave every guest a full set of rings in an operating mode of its own, with the hypervisor beneath them (Intel SDM, Vol. 3C, Sec. 26.3).
The goal behind rings 1 and 2, keeping a faulty driver from bringing down the whole system, never went away. Microsoft’s driver documentation states the problem plainly: all kernel-mode code shares one virtual address space, so a kernel-mode driver is not isolated from other drivers or from the operating system, and if it crashes, the entire operating system crashes (Microsoft, User mode and kernel mode). In July 2024 a faulty update from the security vendor CrowdStrike triggered an out-of-bounds read in its kernel driver, csagent.sys, and crashed an estimated 8.5 million Windows devices (Weston, 2024a; Weston, 2024b). Today’s answers isolate drivers with stronger walls instead of middle rings:
User-mode drivers. A driver written for Microsoft’s User-Mode Driver Framework (UMDF) runs in a host process in ring 3. If it fails, the framework completes the driver’s pending requests with an error code and the operating system can restart the driver, while the rest of the system keeps running (Microsoft, How UMDF Handles Driver Failures).
Security software out of the kernel. After the 2024 outage Microsoft urged vendors to keep their kernel code minimal and to move work such as content parsing into user mode. In June 2025 it said that a private preview of a Windows endpoint security platform, on which antivirus and endpoint protection products can run in user mode just as other applications do, would reach a set of security vendors the following month (Weston, 2024b; Microsoft, 2025).
The hypervisor guarding the kernel. Windows virtualization-based security (VBS) uses the hypervisor to create an isolated environment that becomes the operating system’s root of trust and assumes the kernel itself may be compromised. Its memory integrity feature checks kernel-mode code before it runs and keeps executable kernel pages from ever being writable (Microsoft, VBS).
Fences for devices. An input/output memory management unit (IOMMU) translates and checks the addresses that devices use for direct memory access (DMA), so a device can reach only the memory mapped for it. Windows Kernel DMA Protection uses the IOMMU against drive-by DMA attacks: a hot-plugged Thunderbolt, USB4, or CFexpress peripheral whose driver does not support DMA remapping is blocked from DMA until an authorized user signs in (Microsoft, Kernel DMA Protection).
Beneath Ring 0: The Hypervisor, System Management Mode, and the Security Processor#
The hypervisor (ring -1). Hardware virtualization gives the processor two kinds of operation. In Intel’s terms, the hypervisor runs in Virtual Machine Extensions (VMX) root operation and each guest runs in VMX non-root operation with a complete set of rings of its own, so a guest kernel keeps ring 0 while the hypervisor sits underneath it (Cheng et al., 2023; Intel SDM, Vol. 3C, Sec. 26.3). The hypervisor controls which physical memory each guest can reach through a second level of page tables and can intercept a guest’s sensitive operations. Windows turns this power to defense with the virtualization-based security described above, which places the root of trust in an environment that the hypervisor protects rather than in the kernel (Microsoft, VBS).
System Management Mode (ring -2). SMM was introduced with the Intel386 SL and became a standard feature
with the Pentium processor family. Intel describes it as a special-purpose mode for system-wide functions
such as power management and hardware control, intended for use only by system firmware (Intel SDM, Vol.
1, Sec. 3.1; Vol. 3C, Sec. 34.1). The
only way in is a system management interrupt (SMI). On an SMI the processor saves its state, switches to
a separate address space, disables the interrupts the operating system normally handles, and runs the SMI
handler from system management RAM (SMRAM), a region that can be made inaccessible from every other mode;
the RSM instruction, which works only in SMM, then resumes whatever was interrupted (Intel SDM, Vol. 3C,
Sec. 34.1). Microsoft lists power management, hardware configuration, and thermal monitoring among SMM’s jobs
and notes that SMM code is invisible to the operating system (Microsoft, System Guard). That invisibility is
the danger. SMM runs at a higher effective privilege than the hypervisor, and SMM code can potentially read
and change the hypervisor’s memory, so a flaw in an SMI handler undoes every protection built above it
(Microsoft, Silicon assisted security; Microsoft, System Guard).
Attacks take two routes. Kernel code can hand an SMI handler a buffer or pointer that tricks the handler into overwriting protected memory on the attacker’s behalf, a confused-deputy attack, in which a privileged component misuses its authority for a less privileged caller. Historically, much firmware treated all ring 0 code as trusted. Microsoft’s Windows SMM Security Mitigations Table (WSMT) specification tells SMM to treat ring 0 code as potentially hostile and lets firmware declare that its handlers check that every buffer and pointer they receive lies within fixed, expected memory regions (Microsoft, 2016). Alternatively, a design flaw can defeat the protection of SMRAM itself: Domas showed in 2015 that kernel code could overlay the processor’s local interrupt-controller registers on SMRAM, intercept SMM’s own memory accesses, and so take control of SMM (Domas, 2015). Defenses put the handlers themselves under supervision. Intel’s dual-monitor treatment lets a second virtual machine monitor, the SMM-transfer monitor (STM), run inside SMM and share control of how SMIs are serviced (Intel SDM, Vol. 3C, Sec. 34.1.1). Windows 11 Secured-core PCs must either isolate SMM under System Guard Secure Launch or run firmware whose SMM code operates under a supervisor (Microsoft, Windows 11 Secured-core PCs).
The security processor (ring -3). Ring -3 is a separate computer inside the computer. In version 11 of Intel’s management engine, the CSME runs a modified version of the MINIX operating system (Tanenbaum), and the CSME serves as the trusted execution environment for Intel’s firmware TPM (Jacob et al., 2023). The AMD Secure Processor is a 32-bit Arm Cortex-A5 microcontroller built into AMD’s processors (Cheng et al., 2023). It starts before the x86 cores, loads the firmware that boots them and then starts them, provides a trusted execution environment in which AMD’s firmware TPM runs as one application, and manages the memory-encryption keys of AMD’s confidential virtual machines (Jacob et al., 2023; Cheng et al., 2023). Microsoft Pluton is a security processor built into the processor itself on recent AMD, Intel, and Qualcomm chips; Microsoft delivers its firmware updates through Windows Update, and it is built on technology proven in the Xbox and Azure Sphere (Microsoft, Pluton). Because these processors sit beneath everything else, a flaw in one undermines every protection built on top of it, as the TPM attacks below show.
The Trusted Platform Module Up Close#
A TPM is the platform’s anchor for keys and measurements (Microsoft, TPM overview; TPM fundamentals).
Keys. It generates keys whose private halves can stay inside the chip, and it limits how they are used. Each TPM holds an endorsement key whose private half never leaves the TPM and a storage root key that wraps the other keys it creates. After a limited number of failed authorization attempts, such as wrong PINs, its anti-hammering logic locks out further attempts.
Measurements. During boot, each stage of firmware and operating-system code can be measured, that is hashed, and recorded in the TPM’s platform configuration registers (PCRs) before it runs, leaving a record of exactly how the machine started.
Sealing. Data can be sealed to platform measurements so that the TPM releases it only if the platform booted the same way. By default BitLocker relies on the PCR 7 measurement to tie its key to Secure Boot, so that unauthorized firmware or a modified boot loader cannot obtain the key (Microsoft, BitLocker countermeasures).
Attestation. The TPM can sign its measurements so that a remote verifier, such as a device management service, can decide whether to trust the machine (Microsoft, System Guard).
With Windows 11, both new and upgraded devices must have TPM 2.0, and features such as Windows Hello, BitLocker, and System Guard rely on it (Microsoft, Hardware root-of-trust). Microsoft Pluton can also act as the TPM, but beginning with 2026 silicon it no longer does so on AMD and Qualcomm platforms, which instead provide TPM 2.0 through the vendor’s firmware TPM or a discrete chip (Microsoft, Pluton as TPM).
A TPM is only as strong as what surrounds it, and three lines of research show where the edges are.
Sniffing the bus. The bus between a discrete TPM and the processor is not protected, and passive sniffing of it with reasonably inexpensive equipment can defeat disk encryption that relies on the TPM alone; Microsoft’s advice against this is a TPM-plus-PIN protector, so that the key is not released without the PIN (Jacob et al., 2023, summarizing earlier work).
Timing. In TPM-Fail, signing times that depended on secret values let researchers recover 256-bit elliptic-curve private keys from Intel’s firmware TPM after about 1,300 signatures, collected within minutes, and from a Common Criteria certified STMicroelectronics chip after fewer than 40,000. They even recovered a server’s private key remotely, by timing about 45,000 handshakes with a VPN server that used the firmware TPM to sign its authentication messages (Moghimi et al., 2019).
Fault injection. In faulTPM, carefully timed voltage glitches against the AMD Secure Processor exposed the entire internal state of AMD’s firmware TPM on Zen 2 and Zen 3 processors. That defeated BitLocker’s TPM-only protection with two to three hours of physical access and under 200 dollars of equipment. Against a TPM-plus-PIN protector, the attack left BitLocker only as strong as the PIN. By the authors’ estimates, a numeric PIN added almost nothing, since even ten digits could be brute-forced in about half a minute, while a well-chosen passphrase still gave adequate protection (Jacob et al., 2023).
The practical lesson for a laptop that holds valuable data is a long alphanumeric pre-boot PIN, which Windows calls an enhanced PIN, so that unlocking the disk always requires something the thief does not have and cannot quickly guess (Microsoft, BitLocker countermeasures; Jacob et al., 2023).
Trusted Execution Environments: Enclaves, Secure Worlds, and Confidential Virtual Machines#
A TEE protects data in use. Code and data inside it stay confidential and unmodified even when more privileged software is hostile, and the TEE can prove what it is running to a remote party through attestation (Cheng et al., 2023). TEEs come in three shapes.
An enclave inside a process. An Intel SGX enclave is a protected region of an ordinary application that runs as ring 3 code, yet keeps its memory sealed from the kernel and the hypervisor. A special enclave signed by Intel, the quoting enclave, turns an enclave’s report into a quote that a remote party can verify (Costan and Devadas, 2016; Cheng et al., 2023). Enclaves have proved vulnerable to side channels, including controlled-channel, cache, branch-prediction, and speculative-execution attacks (Cheng et al., 2023).
A secure world. On Arm, TrustZone runs a trusted operating system beside the normal one: OP-TEE is designed as a companion to a normal-world Linux kernel, and Android’s Trusty runs on the same processor as Android but is isolated from it by hardware, handling tasks such as PIN and fingerprint processing and the device keys that decrypt protected media (OP-TEE; Android, Trusty).
A confidential virtual machine. A whole virtual machine is protected from the hypervisor and the cloud operator. AMD’s Secure Encrypted Virtualization (SEV) gives each virtual machine its own memory encryption key managed by the AMD Secure Processor, and its later extension, SEV-SNP (Secure Nested Paging), adds integrity protection through a table that records who owns each page. Intel’s answer is TDX. Arm’s Confidential Compute Architecture (CCA) adds a Realm world for confidential virtual machines and a Root world, home to the EL3 monitor, which controls which world owns each page of memory (Cheng et al., 2023).
TDX does not add a numbered ring, and the x86 figure is drawn to show this. Intel extended VMX with a new Secure-Arbitration Mode (SEAM). The hypervisor keeps running in ordinary VMX root operation; an Intel-signed software component, the TDX module, runs in SEAM’s own root mode from a memory range that the firmware reserves for it; and each confidential virtual machine, called a trust domain (TD), runs in SEAM’s non-root mode with its own ring 0 kernel and ring 3 applications (Cheng et al., 2023; Intel SDM, Vol. 3C, Sec. 26.3). The hypervisor is no longer allowed to manage a trust domain directly. It must call the TDX module, which carries out each management operation and takes over the address translation for the trust domain’s private memory (Cheng et al., 2023). Applications need no changes (Microsoft, About Azure confidential VMs), but the guest kernel must support TDX, as Linux has since version 5.19 (Kernel Newbies, 2022). TDX first appeared on select 4th Generation Xeon Scalable processors and continues in the 5th generation and in Xeon 6 (Cheng et al., 2023; Canonical, TDX on Ubuntu). Microsoft Azure and Google Cloud both offer confidential virtual machines on TDX processors, and Azure gives each confidential virtual machine a dedicated virtual TPM that runs in a secure environment outside the reach of any virtual machine (Microsoft, About Azure confidential VMs; Google Cloud, Confidential VM supported configurations). The protection has an operational price: Azure’s confidential virtual machines do not support live migration, and Google Cloud live-migrates some of its AMD SEV machines but none of its TDX machines (Microsoft, About Azure confidential VMs; Google Cloud, Confidential VM supported configurations).
Going Deeper (graduate/research): inside an Intel TDX trust domain
The hypervisor calls the TDX module with the SEAMCALL instruction, and the module returns with SEAMRET.
A trust domain enters the module either deliberately, with the TDCALL instruction, or through a TD exit.
When the guest does something that needs the hypervisor, such as port input and output, access to an
emulated device register, or certain CPUID queries, the module does not hand the guest’s state to the
hypervisor. It injects a virtualization exception into the guest instead, and the guest kernel’s handler
prepares a minimal set of parameters and issues a TDCALL to the TDG.VP.VMCALL function, the guest’s
hypercall, which the Linux source code calls TDVMCALL. Only then does the module ask the hypervisor to handle
the request (Cheng et al., 2023; Linux kernel documentation, Intel TDX).
Memory protection combines access control with cryptography. Through Multi-Key Total Memory Encryption (MKTME), each trust domain’s private memory is encrypted with AES-128 in XTS mode under a key of its own, which the processor generates and the encryption engine never exposes. Software outside SEAM that reads a trust domain’s private memory receives zeros. An ownership bit kept with each 64-byte cache line records any write from outside SEAM, so the trust domain is stopped before it can consume tampered data, and an optional mode adds a 28-bit message authentication code per cache line that also catches physical tampering such as Rowhammer bit flips (Cheng et al., 2023).
Input and output still have to cross the boundary. The guest marks pages as shared by setting a bit in the guest physical address; shared pages are not protected, so the guest must protect the data itself and treat everything that arrives there as untrusted. That is why the guest kernel needs changes and why Linux allows only a small set of hardened drivers inside a trust domain (Cheng et al., 2023).
Attestation works like a TPM’s measured boot. A build-time register, the measurement of trust domain (MRTD), records the trust domain’s initial contents, and four runtime measurement registers (RTMRs) record what loads afterward, extended with SHA-384 just as PCRs are. The TDX module produces a report protected by a key that only the processor holds, and the SGX quoting enclave on the same host signs it into a quote whose certificate chain leads to Intel. A verifier checks the chain and compares the measurements with expected values before releasing any secret (Cheng et al., 2023).
The Trusted Computing Base and the Reference Monitor#
Two further concepts formalize these ideas. The trusted computing base (TCB) is the complete set of hardware, firmware, and software components that are critical to enforcing the system’s security policy. Everything inside the TCB must be trusted, because a flaw anywhere within it can undermine the whole system; a central design goal is therefore to keep the TCB as small and as carefully verified as possible. The reference monitor is the abstract concept of a component that mediates every access by a subject (a user or process) to an object (a file, device, or memory region), checking each against the security policy. To be effective a reference monitor must be tamper-proof, always invoked (non-bypassable), and small enough to be thoroughly analyzed and verified. The concrete implementation of the reference monitor is called the security kernel. These principles, defense built into the lowest layers, a minimal trusted base, and complete mediation, recur throughout secure system design, from operating-system kernels to the trusted execution environments discussed in the chapter on emerging topics.
1.7 The NIST Cybersecurity Framework#
We have now covered the building blocks, properties, attacks, adversaries, controls, and hardware foundations. Organizations need a way to assemble these into a coherent program, and that is exactly what a framework provides; the most widely used one is described next.
Frameworks give organizations a shared vocabulary and a structured way to organize their security efforts. The most widely adopted in the United States, and increasingly internationally, is the NIST Cybersecurity Framework (CSF). Originally published in 2014 for critical-infrastructure operators, the framework was substantially revised as CSF 2.0 in 2024 and is now intended for organizations of every size and sector. Its core organizes all cybersecurity activity into a small number of high-level functions, each broken down into categories and subcategories of outcomes.
The original framework defined five functions. CSF 2.0 added a sixth, Govern, which now sits at the center and informs all the others:
Govern (GV): establish and monitor the organization’s cybersecurity risk-management strategy, expectations, policy, roles, and oversight. This function, new in 2.0, recognizes that cybersecurity is an enterprise risk to be managed at the leadership level, not merely a technical concern.
Identify (ID): develop an understanding of the organization’s assets, data, systems, suppliers, and the risks to them. You cannot protect what you do not know you have.
Protect (PR): implement safeguards to ensure delivery of critical services, access control, data security, awareness training, and maintenance.
Detect (DE): implement activities to identify the occurrence of a cybersecurity event in a timely manner, through continuous monitoring and detection processes.
Respond (RS): take action once an incident is detected, including response planning, analysis, containment, and communication.
Recover (RC): restore capabilities and services impaired by an incident, and incorporate lessons learned into future resilience.
Read in sequence, the functions trace the natural life of risk management: you govern the program, identify what matters and what threatens it, protect it, detect attacks that slip through, respond to contain them, and recover to normal operation while improving. This book is organized so that each function is developed in depth: identification and risk in Chapters 1 and 5, protection in Chapters 2, 3, and 11, detection in Chapter 12, response in Chapter 14, recovery in Chapters 13 and 14, and governance in Chapters 5 and 19. Other frameworks, including ISO/IEC 27001, COBIT, and the CIS Critical Security Controls, serve similar organizing roles and are discussed in the governance chapter.
1.8 Quantifying Risk in Monetary Terms#
A framework tells us what activities to perform, but leadership still must decide where to spend limited money. To make that case we have to express risk in dollars, which is the purpose of the quantitative model in this section.
Because security competes with every other organizational priority for finite budget, professionals must be able to express risk in the language executives understand: money. The classic quantitative risk model does exactly this with a small set of formulas.
Everyone already does risk math before leaving the house: the chance of rain weighed against how bad getting wet would be. The vocabulary below simply names the parts of that judgment. Single loss expectancy is the cost of one soaking. Annualized rate of occurrence is how often it happens in a year. Annualized loss expectancy is their product, and its purpose is to be compared against the price of the umbrella, since a control that costs more than the loss it prevents is not a control but a preference. The analogy also shows its own limit, and the limit governs how much weight these figures can carry. Rain is frequent, and the estimate improves because you get feedback every week. Rare high-impact events give almost no feedback, so the annualized figures for them are estimates resting on estimates, which is the standing objection to quantitative risk methods and the reason the qualitative scales of Chapter 5 survive alongside them.
The starting point is the asset value (AV), the worth of the asset at risk. The exposure factor (EF) is the percentage of that value expected to be lost in a single incident, expressed as a fraction between 0 and 1. Their product is the single loss expectancy (SLE), the money lost from one occurrence:
The annualized rate of occurrence (ARO) is the expected number of incidents per year (which may be a fraction, such as 0.3 for an event expected once every three-plus years). Multiplying SLE by ARO gives the annualized loss expectancy (ALE), the expected yearly cost of the risk:
The ALE is the single most useful number in risk economics, because it can be compared directly against the annual cost of a control. If a safeguard reduces the ALE by more than it costs to operate, it is financially justified. This is captured by the return on security investment (ROSI):
A positive ROSI means the control saves more than it costs; a negative ROSI means the organization would, on average, spend more on the safeguard than it expects to lose without it. These figures are estimates built on uncertain inputs, and they should inform judgment rather than replace it, but they impose valuable discipline on security spending. The worked example below computes these values for a realistic scenario and visualizes the effect of a control.
# Chapter 1 -- Worked Example: quantitative risk (SLE, ARO, ALE, ROSI)
import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
# --- Scenario: a customer database faces a breach risk ---
asset_value = 500_000 # value of the customer database, USD
exposure_factor = 0.40 # 40% of value lost in a typical breach
aro = 0.30 # expected 0.30 breaches per year (~once every 3+ years)
sle = asset_value * exposure_factor
ale_before = sle * aro
# A monitoring + encryption + patching programme
control_cost = 20_000 # annual operating cost
residual_factor = 0.15 # control cuts expected loss to 15% of original
ale_after = ale_before * residual_factor
benefit = ale_before - ale_after
rosi = (benefit - control_cost) / control_cost * 100
print("=== Quantitative Risk Assessment ===")
print(f" Asset value (AV) : ${asset_value:>12,.0f}")
print(f" Exposure factor (EF) : {exposure_factor:>12.0%}")
print(f" Single loss expect (SLE): ${sle:>12,.0f}")
print(f" Annual rate (ARO) : {aro:>12.2f}")
print(f" ALE before control : ${ale_before:>12,.0f}")
print(f" ALE after control : ${ale_after:>12,.0f}")
print(f" Annual control cost : ${control_cost:>12,.0f}")
print(f" Annual net benefit : ${benefit - control_cost:>12,.0f}")
print(f" ROSI : {rosi:>11.1f}%")
print(f" Decision : {'JUSTIFIED' if rosi > 0 else 'NOT justified'}")
fig, ax = plt.subplots(figsize=(7, 4))
bars = ax.bar(["ALE before", "ALE after", "Control cost"],
[ale_before, ale_after, control_cost],
color=["#c0392b", "#27ae60", "#2980b9"])
ax.set_ylabel("Annual cost (USD)")
ax.set_title("Effect of a Security Control on Annualized Loss Expectancy")
for b in bars:
ax.text(b.get_x() + b.get_width()/2, b.get_height(),
f"${b.get_height():,.0f}", ha="center", va="bottom", fontsize=9)
plt.tight_layout()
plt.savefig("ch01_risk.png", dpi=200)
print("\\nFigure saved: ch01_risk.png")
# Chapter 1 -- Visualizing defense in depth as concentric layers
import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
from matplotlib.patches import Circle
layers = [
("Data (encryption, DLP)", 1.0, "#1a5276"),
("Application (hardening, SAST)", 2.0, "#1f6f8b"),
("Host (EDR, patching)", 3.0, "#2980b9"),
("Internal network (segmentation)",4.0, "#5499c7"),
("Perimeter (firewall, IDS/IPS)", 5.0, "#7fb3d5"),
("Physical (locks, guards)", 6.0, "#aed6f1"),
("Policies & people (training)", 7.0, "#d6eaf8"),
]
fig, ax = plt.subplots(figsize=(7, 7))
for label, r, color in reversed(layers):
ax.add_patch(Circle((0, 0), r, color=color, ec="white", lw=1.5))
# centre the label in its band and back it with the band colour, so the white
# ring edge cannot be drawn through the text where the label is wider than the band
ax.text(0, r - 0.5, label, ha="center", va="center", fontsize=8.5, zorder=5,
color="white" if r <= 4 else "#1a1a1a",
bbox=dict(boxstyle="round,pad=0.22", facecolor=color, edgecolor="none"))
ax.text(0, 0, "ASSET", ha="center", va="center", fontsize=11, fontweight="bold", color="white",
zorder=6, bbox=dict(boxstyle="round,pad=0.18", facecolor="#1a5276", edgecolor="none"))
ax.set_xlim(-7.5, 7.5); ax.set_ylim(-7.5, 7.5)
ax.set_aspect("equal"); ax.axis("off")
ax.set_title("Defense in Depth: Overlapping Layers of Control", fontsize=12)
plt.tight_layout()
plt.savefig("ch01_defense_in_depth.png", dpi=110)
print("Figure saved: ch01_defense_in_depth.png")
1.9 The Saltzer and Schroeder Design Principles#
Frameworks and risk math operate at the level of programs. Underneath them sit timeless engineering principles for building individual systems securely, articulated decades ago and still authoritative.
In 1975, Jerome Saltzer and Michael Schroeder articulated a set of design principles for secure systems that remain remarkably current half a century later. They are tested directly on professional examinations and, more importantly, they provide a checklist against which any design decision can be evaluated.
Economy of mechanism. Keep the design as simple and small as possible. Complexity is the enemy of security because every additional feature, option, and line of code is another place for a flaw to hide and another thing a defender must understand. Simple systems can be reviewed and reasoned about; sprawling ones cannot. This principle motivates keeping the trusted computing base minimal.
Fail-safe defaults. Base access decisions on permission rather than exclusion: the default should be to deny, and access should be granted only by explicit allowance. A system that fails closed denies service when something goes wrong, which is annoying but safe; a system that fails open grants access on error, which is convenient but catastrophic. Default-deny firewall rules embody this principle.
Complete mediation. Every access to every object must be checked against the access-control policy, every time. Systems that check permission once and then cache the result, or that allow some paths to bypass the check, invite abuse. This is precisely the property required of the reference monitor.
Open design. The security of a system should not depend on the secrecy of its design or implementation, only on the secrecy of keys. This is the security analog of Kerckhoffs’s principle in cryptography, which holds that a cryptosystem should remain secure even if everything about it except the key is public knowledge. Security through obscurity, hiding how a system works and hoping attackers never find out, is brittle: secrets leak, and a defense that collapses once understood was never strong. Open designs can be scrutinized by many eyes and earn justified confidence.
Separation of privilege. Where practical, require more than one condition or party to authorize an important action. Requiring two officers to launch a missile, or two signatures to release a large payment, means that no single compromised credential or corrupt individual is sufficient. This is the basis of separation of duties, which splits a sensitive task so that no one person controls it end to end, and of multi-factor authentication, which requires more than one kind of evidence of identity.
Least privilege. Every user, process, and program should operate with the minimum set of privileges necessary to perform its function, and no more. If a web server only needs to read certain files, it should not run as an administrator. Least privilege limits the damage that a compromised component or a careless user can do, because the attacker inherits only the narrow rights the victim held. It is one of the most powerful and most frequently violated principles in practice.
Least common mechanism. Minimize the mechanisms that are shared by, and depended on by, more than one user or process. Shared mechanisms are potential channels for unintended information flow and single points of failure; isolating users from one another reduces the blast radius of a compromise.
Psychological acceptability. Security mechanisms must be easy enough to use that people actually use them correctly. A control that is cumbersome will be bypassed, written on a sticky note, or worked around, defeating its purpose. Usable security is not a luxury; it is a precondition for real-world effectiveness, and it explains why poorly designed password policies often make security worse.
Together these principles encode hard-won wisdom: prefer simplicity, deny by default, check everything, do not rely on secrecy, divide power, grant the least authority needed, share as little as possible, and make the secure path the easy path.
The Principle of Least Privilege (PoLP)#
Of the Saltzer and Schroeder principles above, one deserves to be singled out because it does more to limit the damage of an attack than almost any other: the principle of least privilege (PoLP). It states that every user, process, and component should be granted only the minimum privileges needed to perform its function, and no more, for only as long as needed. Least privilege does not prevent compromise; it contains it. If a web server runs as an unprivileged service account rather than as root, a remote-code-execution bug yields only that account’s limited rights, not the whole machine, which is precisely why the buffer-overflow example in Chapter 9 that prints “root privileges given to the user” is so dangerous, and why granting root by default is the original sin it punishes.
In practice PoLP shows up everywhere in this book: role-based access control (RBAC) and fine-grained cloud IAM policies (Chapters 11 and 17) that grant scoped permissions; just-in-time and time-boxed elevation instead of standing administrator rights; separation of privilege so that sensitive actions need more than one condition; dropping privileges after startup; running risky code in sandboxes, containers, and least-privileged trusted execution environments (TEEs) (Chapter 1, Chapter 17); and network micro-segmentation (Chapter 11) that is least privilege applied to traffic. The same idea underpins zero-trust architecture: never grant broad, implicit trust. Least privilege is the control that turns a total compromise into a contained incident, so it should be the default posture for accounts, services, and code alike.
1.10 The Security Mindset, Ethics, and the Law#
Principles and mechanisms describe how to build secure systems. But the same knowledge can attack as easily as defend, so we close the conceptual core by addressing the mindset, ethics, and law that govern its use.
Beyond specific techniques, cybersecurity demands a particular way of thinking that the cryptographer Bruce Schneier calls the security mindset: the habit of looking at any system and asking not “how does this work?” but “how can this be made to fail?” Where a typical engineer asks how to make a feature function, the security professional asks how an adversary could abuse it, what assumptions it silently depends on, and what happens when those assumptions are violated. This adversarial perspective can be learned, and cultivating it is one of the central aims of this book.
The same knowledge that lets a defender anticipate attacks would let an attacker carry them out, and this dual-use character makes ethics and law inseparable from technical skill. The defining distinction is authorization. Probing, scanning, or exploiting a system you do not own and have not been given explicit, documented permission to test is, in most jurisdictions, a crime, regardless of your intentions or whether you cause harm. In the United States the principal statute is the Computer Fraud and Abuse Act; many other countries have analogous laws such as the United Kingdom’s Computer Misuse Act. Penetration testers operate under written contracts and carefully scoped rules of engagement, a topic developed in the chapter on penetration-testing methodology, precisely because authorization is what separates a professional service from a felony.
Ethical practice also includes responsible disclosure: when a researcher discovers a vulnerability, the accepted norm is to report it privately to the vendor and allow reasonable time for a fix before any public discussion, balancing the public’s right to know against the risk of arming attackers. Professional bodies reinforce these expectations through codes of conduct; the (ISC)2 Code of Ethics, for instance, obliges members to protect society and the common good and to act honorably and legally. Throughout this book, every offensive technique is presented for the purpose of building better defenses, and the reader is expected to apply it only within the bounds of explicit authorization and applicable law.
1.11 A Taxonomy of Threats and a Roadmap to This Book#
With principles, economics, and ethics established, it helps to step back and survey the full range of threats this knowledge must address, which doubles as a roadmap to the chapters ahead.
The threats a modern organization faces are numerous, but they fall into a manageable number of families. Surveying them now provides both a mental filing system and a map of the chapters ahead.
Malware is malicious software in all its forms: viruses that attach to files, worms that self-propagate across networks, trojans that masquerade as legitimate programs, ransomware that encrypts data for extortion, spyware and keyloggers that steal information, rootkits that hide deep in the system, and botnets that conscript machines into attacker-controlled networks. Malware is examined in depth in Chapter 15.
Social-engineering attacks target people rather than machines, exploiting trust, authority, fear, and urgency. Phishing emails, voice-based vishing, SMS-based smishing, pretexting, baiting, and business email compromise all manipulate human psychology to extract credentials, money, or access. Because humans are involved in nearly every system, social engineering bypasses technical controls and is consistently among the most effective attack categories; it is the subject of Chapter 4.
Network attacks abuse the protocols and infrastructure that connect systems: sniffing and eavesdropping, man-in-the-middle interception, spoofing of addresses and identities, denial-of-service and distributed denial-of-service floods, and session hijacking. The networking foundations are laid in Chapter 3 and the offensive techniques developed in Chapters 7 through 9, with defenses in Chapters 11 and 12.
Application and web attacks exploit flaws in software, especially the web applications and APIs that expose organizations to the internet. Injection (including SQL injection), cross-site scripting, broken authentication, insecure deserialization, and server-side request forgery are perennial problems cataloged by the OWASP Top Ten. These are the focus of Chapter 10, with the underlying exploitation mechanics, including memory-corruption bugs and return-oriented programming, in Chapter 9.
Cryptographic attacks target the algorithms and protocols meant to protect data, exploiting weak ciphers, poor key management, flawed randomness, or implementation mistakes and side channels. Cryptography and its failure modes occupy Chapter 2, with forward-looking concerns such as the quantum threat and homomorphic and functional encryption in Chapters 2 and 17.
Physical and supply-chain attacks sidestep digital defenses entirely. Physical access to hardware, theft of devices, tampering with equipment, and the insertion of malicious components or compromised software updates upstream in the supply chain can defeat otherwise strong systems. The high-profile software-supply-chain compromises of recent years show how a single trusted vendor can become a vector to thousands of victims; these concerns thread through the governance and emerging-topics chapters.
Threats to specialized environments round out the landscape. Cloud platforms introduce shared responsibility and misconfiguration risks; mobile devices, the Internet of Things, and operational technology each expand the attack surface in distinctive ways. Industrial control systems that run critical infrastructure, examined in Chapter 20, raise the stakes from data loss to physical safety.
No single book chapter, and no single control, addresses all of these. That is exactly why the risk-based, defense-in-depth, framework-driven approach introduced in this chapter matters: it gives the practitioner a way to reason about an open-ended and shifting set of threats without being overwhelmed by their variety. With this foundation in place, the next chapter turns to cryptography, the mathematical machinery on which so much of modern security ultimately rests.
1.12 Classic Security Models#
Security models are formal frameworks that state, precisely, the rules a system must follow to enforce confidentiality, integrity, or both. They underpin the access-control mechanisms used throughout this book and appear in the CISSP and other certification bodies of knowledge. The unifying abstraction beneath most of them is the access-control matrix: a table whose rows are subjects, columns are objects, and cells list the rights a subject holds on an object. Each model below adds rules about how those rights may be read, written, granted, or changed, and each maps to a real class of system.
Confidentiality: Bell-LaPadula#
The Bell-LaPadula (BLP) model is the foundational multilevel-security model for preventing unauthorized disclosure. Subjects and objects carry classification levels (for example Unclassified, Secret, Top Secret), and the model defines the following properties (the first two are its core rules):
Simple Security Property (“no read up”): a subject cannot read data above its clearance.
Star (*) Property (“no write down”): a subject cannot write data to a lower level, which would leak classified content downward.
Strong Star Property: a stricter variant in which a subject may read and write only at its own exact level, neither up nor down, used where even a controlled write-down is unacceptable.
Discretionary Security Property: clearance alone is not enough. Access must also be allowed by the discretionary access-control matrix (for example an access-control list), so a subject needs both the right level and an explicit grant to the specific object.
BLP also assumes a tranquility property, meaning security labels do not change during operation in a way that would break the policy. Strong tranquility means labels never change; weak tranquility allows changes only when they preserve the rules.
In practice BLP describes military and government systems and anywhere leakage is the primary fear. Its limitation is that it says nothing about integrity: a low-level user can still “write up” and corrupt high-level data, which is exactly what the next models address.
Integrity: Biba and Clark-Wilson#
The Biba model is the mirror image of Bell-LaPadula, protecting integrity rather than confidentiality:
Simple Integrity Property (“no read down”): a subject cannot read lower-integrity (less trusted) data.
Star Integrity Property (“no write up”): a subject cannot write to higher-integrity data.
Invocation Property (no invoke up): a lower-integrity subject cannot invoke, that is call or request services from, a higher-integrity subject, which stops a low-trust process from driving a high-trust one.
Biba fits systems where corruption is the main risk, such as keeping untrusted input from contaminating a trusted database.
The Clark-Wilson model targets commercial integrity rather than military secrecy. Instead of levels, it requires that data be changed only through well-formed transactions: users (subjects) may touch Constrained Data Items (CDIs) only through certified Transformation Procedures (TPs), forming an access triple of (subject, TP, CDI). Integrity-verification procedures confirm that CDIs are valid, and the model enforces separation of duties so that no single person can both make and approve a change. This is the model behind real accounting and banking controls. Clark-Wilson states its requirements as two sets of rules. Certification rules, which administrators must verify, require that integrity-verification procedures confirm CDIs are valid, that every TP turns a valid CDI into another valid CDI, that the assignment of users to TPs preserves separation of duties, that all TPs append to a reconstruction log, and that any TP accepting an unconstrained (untrusted) data item either rejects it or converts it into a valid CDI. Enforcement rules, which the system itself imposes, require that only certified TPs touch CDIs, that each authorized (user, TP, CDI) triple is maintained and honored, that every user is authenticated before running a TP, and that only the agent who certifies an entity may change its associated lists, so that the certifier of a procedure cannot also execute it.
Hybrid and Specialized Models#
Brewer-Nash (the “Chinese Wall”) prevents conflicts of interest by making access depend on history: once a consultant accesses Client A’s data, the model dynamically blocks access to Client A’s competitor. It is used in finance, law, and consulting. Its simple security rule lets a subject read an object only if that object is in a company dataset the subject has already accessed or in an entirely different conflict-of-interest class, and its star property lets a subject write only when no object readable to it belongs to a different company dataset in the same conflict-of-interest class, which stops data from flowing between competitors.
Graham-Denning defines the secure creation and deletion of subjects and objects and the granting, transfer, and revocation of access rights through a set of primitive protection rules.
Harrison-Ruzzo-Ullman (HRU) extends Graham-Denning with a formal access matrix and commands, and famously shows that the general safety problem (will a subject ever obtain a given right?) is undecidable, which is why real systems rely on constrained, analyzable policies rather than arbitrary ones.
Foundational System Models#
State Machine model: treats the system as a set of states and proves it is secure in its initial state and after every permitted transition, so it can never reach an insecure state. Most of the models above build on this idea.
Noninterference model: requires that actions by high-level subjects produce no observable effect for low-level subjects, closing the covert-channel and inference leaks that level-based rules alone can miss.
Several recurring properties appear across these and related mandatory-access-control systems and are worth knowing by name: tranquility (labels stay stable, in the strong or weak form above), need-to-know (access requires both clearance and a legitimate need), least privilege (subjects get the minimum rights required), separation of privilege (more than one condition or approval is required to act), and separation of duties (a critical action is split across multiple people so no individual controls it end to end).
Together these models give designers a precise vocabulary for stating what “secure” means for a system before choosing the mechanisms to enforce it, which connects directly to the design principles of Section 1.9 and the access-control mechanisms applied throughout the book.
Security Models versus Cryptographic Security Definitions#
The models above are information-security (access-control) models: in terms of subjects, objects, and rules they define what it means for a system to be secure and which operations are allowed. They are policy models, shown correct by proving that no permitted sequence of operations can reach a disallowed state, and they say nothing about the strength of any cipher. A Bell-LaPadula system can still leak if its encryption is weak.
Cryptographic security models answer a different question: how hard is it for an adversary to break a specific scheme. They are stated as games between a challenger and an adversary and are judged by computational hardness rather than by a state machine. Examples include indistinguishability under chosen-plaintext attack (IND-CPA) and under chosen-ciphertext attack (IND-CCA) for encryption, and existential unforgeability under chosen-message attack (EUF-CMA) for signatures. A proof here is a reduction showing that any adversary who breaks the scheme could also solve a problem believed to be hard, such as integer factoring or a lattice problem.
The two are complementary layers. An information-security model decides who may access what; a cryptographic model decides whether the mechanism enforcing that access actually resists attack. A secure system needs both, the right policy and primitives that provably uphold it. Chapter 2 develops the cryptographic side, including the IND-CPA and related definitions and the provable-security reductions behind them.
1.13 Security versus Resilience#
Most of this chapter has framed the goal of cybersecurity as preventing the loss of confidentiality, integrity, and availability. Resilience is a related but distinct goal: the ability of a system to keep delivering its essential function while under attack, and to recover quickly after a compromise that prevention did not stop. Security asks how to stop bad outcomes; resilience assumes that some bad outcomes are inevitable and asks how to limit their blast radius and bounce back.
The two reinforce each other. Strong preventive controls reduce how often incidents occur, while resilience controls reduce how much each incident costs. A purely preventive posture fails badly the first time an attacker gets through, because nothing is designed to contain or absorb the damage. The DIE model introduced earlier (distributed, immutable, ephemeral) is a resilience idea: components that are replaceable and short-lived are easier to restore than ones that must be protected forever. NIST CSF 2.0 captures the same balance by pairing preventive functions (Identify, Protect) with functions that assume failure (Detect, Respond, Recover), all under Govern. Designing for resilience means planning for failure explicitly: segmentation to contain spread, redundancy and backups to preserve availability, graceful degradation so a partial failure does not become total, and tested recovery procedures so restoration is fast and predictable.
Chapter Summary#
This chapter established the conceptual foundation for everything that follows. Cybersecurity is the practice of managing risk to digital systems and data; it is a continuous process rather than a product, and perfect security is neither achievable nor the goal. The CIA triad, confidentiality, integrity, and availability, defines the properties we protect, with the DAD triad, AAA model, and Parkerian hexad extending the picture. An attack is best analyzed through five linked elements, asset, threat, vulnerability, attack surface, and exploitation, tied together by risk. Adversaries range from low-skill script kiddies to patient, well-funded advanced persistent threats, and calibrating defenses to the relevant adversary is essential. Defense in depth layers diverse, overlapping controls, which we classify by type (administrative, technical, physical) and by function (preventive, detective, corrective, deterrent, compensating, directive). Security rests on hardware foundations, CPU protection rings, the user/kernel boundary, the trusted computing base, and the reference monitor, and on enduring design principles from Saltzer and Schroeder such as least privilege, fail-safe defaults, complete mediation, and open design. Beneath ring 0 sit the hypervisor, System Management Mode, and the platform security processor, each more dangerous when compromised. Rings 1 and 2, designed for device drivers, went unused, so drivers are now isolated in user mode, by the hypervisor, and by the IOMMU instead, while TPMs and trusted execution environments, from SGX enclaves to Intel TDX trust domains, protect keys and data even from privileged software. The NIST Cybersecurity Framework 2.0 organizes all of this into six functions, and quantitative risk analysis (SLE, ARO, ALE, ROSI) lets us justify security spending in monetary terms. Finally, the security mindset and a firm grounding in ethics and law, above all the requirement of authorization, are what make this knowledge a profession rather than a hazard. The chapters ahead apply these ideas to cryptography, networking, offensive and defensive techniques, and governance.
Why This Matters#
The concepts in this chapter are not academic abstractions; they are the lens through which every later topic is viewed. When you study cryptography, you are learning mechanisms that enforce confidentiality and integrity. When you study penetration testing, you are learning to think like the threat actors described here and to map an organization’s attack surface. When you study incident response, you are operating the Detect, Respond, and Recover functions of the NIST framework. A security professional who internalizes the CIA triad, the risk equation, the control taxonomy, and the defense-in-depth principle can reason about an unfamiliar system, technology, or threat that did not even exist when they were trained. That transferable judgment, not memorized facts, is what distinguishes a practitioner from a technician, and it is what every major certification ultimately tests.
News in Focus: The Colonial Pipeline Ransomware Incident (2021)#
In May 2021, Colonial Pipeline, which supplies a large share of the fuel consumed on the United States East Coast, halted operations for several days after a ransomware attack. The intrusion has been widely attributed to the DarkSide ransomware-as-a-service operation, and public reporting indicated that the initial access was gained through a single compromised virtual private network (VPN) account that was no longer in active use but remained enabled and was not protected by multi-factor authentication.
Viewed through this chapter’s vocabulary, the incident is instructive. The asset was the company’s ability to operate the pipeline and bill customers. The vulnerability was a dormant remote-access account with a reused password and no multi-factor authentication, part of an avoidable attack surface. The threat actor was a financially motivated cybercriminal group. The attack primarily struck availability, the pipeline stopped, with secondary confidentiality impact from data theft used for extortion. Several inexpensive preventive controls, disabling unused accounts and enforcing multi-factor authentication, would likely have blocked the initial access, illustrating both attack-surface reduction and the outsized return that basic controls can deliver. The episode also showed how a digital event cascades into the physical world, triggering fuel shortages and emergency government action. The technical and reporting details here are drawn from public accounts and may be revised as investigations conclude.
A Second Case: The SolarWinds Supply-Chain Compromise (2020)#
A contrasting example shows the opposite end of the adversary spectrum. In late 2020 it emerged that attackers had inserted malicious code into a software build of SolarWinds Orion, a widely used network management product. Because the tampered update was signed and distributed through the vendor’s legitimate channel, it was trusted and installed by thousands of organizations, including government agencies and major enterprises. The operation has been publicly attributed by the United States government to a nation-state intelligence service, the hallmark of an advanced persistent threat.
Through this chapter’s lens, the contrast with Colonial Pipeline is stark. The threat actor was not a profit-seeking criminal but a patient, well-resourced APT pursuing espionage. The attack vector was the software supply chain: rather than attacking each target directly, the adversary compromised a single trusted vendor and let normal update mechanisms carry the implant to victims. The primary property at risk was confidentiality, the covert exfiltration of sensitive information, and the campaign maintained stealthy, persistent access for months before discovery. No firewall rule or password policy at the victims would have blocked an update they had every reason to trust, which is precisely why supply-chain attacks are so insidious and why defenses such as software bills of materials, build-system integrity, and assume-breach detection have risen in prominence. As with the previous case, these details derive from public reporting and official statements and may be refined as analysis continues. Taken together, the two incidents illustrate the full range of the adversary model: an opportunistic criminal exploiting basic hygiene failures, and a strategic state actor subverting the chain of trust itself.
News in Focus: Cyber Warfare and the US-Iran Cyber Conflict#
Nation-state activity, introduced in the adversary model above, reaches its sharpest form in cyber warfare, and the long confrontation between the United States and Iran is the canonical example. The opening act was Operation Olympic Games, a covert US and Israeli sabotage campaign reportedly begun around 2006 under President George W. Bush and accelerated under President Obama, which produced Stuxnet, widely regarded as the first true cyberweapon. Disclosed in 2010, Stuxnet targeted the industrial control systems at Iran’s Natanz uranium-enrichment facility: it spread to an air-gapped network (one deliberately isolated from the internet, so the malware had to be introduced physically, likely via USB), then manipulated the programmable logic controllers driving the centrifuges, subtly varying their speed to destroy an estimated thousand of them while feeding operators normal readings. Stuxnet proved that code could cause physical, kinetic destruction, and it is examined in depth as an operational-technology attack in Chapter 20.
The conflict did not end there. Public reporting (notably the documentary Zero Days) describes a much broader US contingency plan against Iran code-named Nitro Zeus, said to include the capability to disable Iranian air defenses, communications, and critical infrastructure. Iran, in turn, is widely associated with retaliatory operations, including the Shamoon wiper that crippled tens of thousands of Saudi Aramco workstations in 2012 and a campaign of distributed denial-of-service attacks against US banks around 2012 and 2013. Reporting also describes a US cyber strike on Iranian missile-control systems in June 2019 following the downing of a US drone. Together these episodes illustrate the themes of this chapter, patient and well-resourced nation-state actors, attacks that cross from the digital into the physical world, and the blurring of the line between espionage, sabotage, and armed conflict.
The arc reached a new threshold in 2026. According to U.S. government statements and extensive reporting, on February 28, 2026 the United States and Israel launched Operation Epic Fury (Israel’s coordinated effort was referred to as Operation Roaring Lion), a campaign described in early public reporting as among the first major cyber-first conflicts, in which digital and electronic operations preceded conventional strikes. The Chairman of the Joint Chiefs of Staff stated that U.S. Cyber Command, alongside U.S. Space Command, acted as a “first mover,” layering non-kinetic effects, disrupting Iranian communications, sensor networks, and air-defense command centers before kinetic operations began; reporting describes more than a thousand strategic digital nodes targeted, extensive use of artificial intelligence for targeting and intelligence processing, and a collapse of Iranian internet connectivity through attacks on Border Gateway Protocol routing, the Domain Name System, and industrial control systems. Security firms subsequently warned of Iranian-aligned cyber counteroffensives against global critical infrastructure. Epic Fury thus extends the lineage that began with Stuxnet: from a single covert cyberweapon sabotaging centrifuges to an integrated, AI-assisted, cyber-electronic offensive opening a state-on-state conflict.
Note
A note on sourcing: the operations above (Olympic Games/Stuxnet, Nitro Zeus, Shamoon, the 2019 strike, and Operation Epic Fury of February 2026) are documented in public reporting and official U.S. government statements, though many details remain classified, contested, or still emerging, so they should be read as the best available public account rather than settled fact, and this box should be updated as reporting and declassification evolve.
Review Questions (MCQ)#
Q1. Which CIA property is primarily violated when ransomware encrypts a hospital’s patient files? A. Confidentiality only B. Integrity only C. Availability (and potentially integrity) D. None
Q2. An employee accidentally emails a customer list to the wrong recipient. Which property fails? A. Availability B. Confidentiality C. Integrity D. Non-repudiation
Q3. The formula ALE = SLE × ARO produces a value measured in: A. Risk units B. Dollars per year C. Probability D. Number of patches
Q4. The function added to the NIST Cybersecurity Framework in the 2.0 (2024) revision is: A. Identify B. Detect C. Govern D. Protect
Q5. Defense in depth is best described as: A. Buying the most expensive control available B. Multiple overlapping controls so a single failure does not cause a breach C. Patching all systems within 24 hours D. Encrypting all data at rest
Q6. A visible surveillance camera in a data center is best classified as which control functions? A. Preventive only B. Corrective only C. Detective and deterrent D. Compensating only
Q7. A script kiddie differs from an APT actor primarily in: A. Motivation only B. Technical sophistication and resources C. Use of phishing D. Choice of operating system
Q8. The attack surface of an application is reduced by: A. Buying a faster server B. Disabling unused services and applying least privilege C. Adding more verbose logging D. Increasing the encryption key size
Q9. If SLE = $80,000 and ARO = 0.25, the ALE is: A. $80,000 B. $320,000 C. $20,000 D. $100,000
Q10. On the x86 ring model, ordinary user applications normally execute in: A. Ring 0 (kernel mode) B. Ring 1 C. Ring 2 D. Ring 3 (user mode)
Q11. The three required properties of a reference monitor are that it be: A. Fast, cheap, and encrypted B. Tamper-proof, always invoked, and small enough to be verified C. Cloud-based, redundant, and logged D. Open-source, audited, and signed
Q12. A control that provides an alternative when a primary control cannot be implemented (for example isolating an unpatchable legacy system) is called: A. Deterrent B. Corrective C. Compensating D. Directive
Q13. Intel’s manual assigns rings 1 and 2 to operating-system services such as device drivers, yet mainstream operating systems leave them unused. Which reason applies? A. Paging treats every access from rings 0, 1, and 2 as a supervisor access, and 64-bit mode stopped checking segment limits, so a middle ring cannot be fenced off from the kernel B. Code in rings 1 and 2 can never execute the port input and output instructions C. Drivers in rings 1 and 2 crash the processor whenever they call the kernel D. Rings 1 and 2 exist only on Arm processors
Q14. Where does the Intel TDX module run? A. In a new ring numbered -4, beneath System Management Mode B. In ring 0 of each confidential virtual machine, as part of the guest kernel C. Inside the discrete TPM chip on the motherboard D. In Secure-Arbitration Mode (SEAM), a processor mode beside the hypervisor’s VMX root operation
Q15. Researchers extracted the entire state of AMD’s firmware TPM by voltage glitching (faulTPM). Which BitLocker configuration still protected the disk key? A. A TPM-plus-PIN protector with a long, passphrase-like PIN B. The default TPM-only protector C. A TPM-only protector with Secure Boot enabled D. A TPM-plus-PIN protector with a four-digit numeric PIN
Answer Key#
1: C 2: B 3: B 4: C 5: B 6: C 7: B 8: B 9: C 10: D 11: B 12: C 13: A 14: D 15: A
Q9 worked: ALE = SLE × ARO = $80,000 × 0.25 = $20,000 per year.
Lab Assignment#
Lab 1.1 - Asset and risk register. Choose a small organization you know (a club, a family business, or a hypothetical startup). List at least eight assets, and for each one identify a threat, a vulnerability, and one control. Estimate AV, EF, and ARO for two assets and compute their ALE. Present your results in a table and write a short paragraph recommending which risk to address first and why.
Lab 1.2 - Control classification. Walk through your own home or workplace and identify ten security controls. Classify each on both axes (type: administrative/technical/physical; function: preventive/detective/corrective/deterrent/compensating/directive). Note any control that fills more than one role, and identify any function that is missing entirely from your environment.
Lab 1.3 - Mapping an incident. Find a publicly reported breach from the past year using reputable sources. Write a one-page analysis identifying the asset, threat actor, vulnerability, attack vector, which CIA properties were violated, and at least two controls that could have prevented or limited the incident. Map the defenders’ likely response to the six NIST CSF functions.
Lab 1.4 - Privilege boundaries (optional, technical). On a Linux system, run a non-privileged
command and then the same operation requiring root, observing the permission error and the role of the
kernel boundary. Use strace on a simple program (for example cat) to observe the system calls it
makes, and identify three calls that transition from user mode to kernel mode. Write a short note
explaining what the ring boundary is protecting against.
References#
Spafford, E. H. Widely quoted remark on the impossibility of perfect security.
National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, 2024.
National Institute of Standards and Technology. Guide for Conducting Risk Assessments, NIST Special Publication 800-30 Revision 1, 2012.
Parker, D. B. Fighting Computer Crime: A New Framework for Protecting Information. Wiley, 1998.
Lockheed Martin. Cyber Kill Chain. Intrusion Kill Chain framework white paper, 2011.
MITRE. MITRE ATT&CK Knowledge Base. https://attack.mitre.org
Saltzer, J. H., and Schroeder, M. D. “The Protection of Information in Computer Systems.” Proceedings of the IEEE, 63(9), 1975.
Cybersecurity and Infrastructure Security Agency (CISA). Public advisories on the 2021 Colonial Pipeline incident.
Tereshkin, A., and Wojtczuk, R. (2009). Introducing Ring -3 Rootkits. Black Hat USA, Las Vegas, July 29, 2009. https://invisiblethingslab.com/resources/bh09usa/Ring -3 Rootkits.pdf
Domas, C. (2015). The Memory Sinkhole: Unleashing an x86 Design Flaw Allowing Universal Privilege Escalation. Black Hat USA 2015. https://www.blackhat.com/docs/us-15/materials/us-15-Domas-The-Memory-Sinkhole-Unleashing-An-x86-Design-Flaw-Allowing-Universal-Privilege-Escalation.pdf
Buhren, R., and Eichner, A. (2020). All You Ever Wanted to Know About the AMD Platform Security Processor and Were Afraid to Emulate. Black Hat USA 2020. https://i.blackhat.com/USA-20/Wednesday/us-20-Buhren-All-You-Ever-Wanted-To-Know-About-The-AMD-Platform-Security-Processor-And-Were-Afraid-To-Emulate.pdf
Intel (2022, January 4). Choose the Right TPM Type for your Use Case. Intel Community blog. https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/Choose-the-Right-TPM-Type-for-your-Use-Case/post/1346882
Trusted Computing Group. Trusted Platform Module (TPM) Summary. https://trustedcomputinggroup.org/resource/trusted-platform-module-tpm-summary/
Costan, V., and Devadas, S. (2016). Intel SGX Explained. IACR Cryptology ePrint Archive, Report 2016/086. https://eprint.iacr.org/2016/086
Cheng, P.-C., Ozga, W., Valdez, E., Ahmed, S., Gu, Z., Jamjoom, H., Franke, H., and Bottomley, J. (2023). Intel TDX Demystified: A Top-Down Approach. arXiv:2303.15540. https://arxiv.org/abs/2303.15540
Arm. Learn the architecture: AArch64 Exception Model, document 102412, version 1.3. https://documentation-service.arm.com/static/63a065c41d698c4dc521cb1c
Arm (2013). SMC Calling Convention: System Software on ARM Platforms, issue A. https://documentation-service.arm.com/static/5f8ea482f86e16515cdbe3c6
Mann, B. (2018, August 6). Architecting More Secure World with Isolation and Virtualization. Arm Community blog. https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/architecting-more-secure-world-with-isolation-and-virtualization
Intel (2026). Intel 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4 (the Intel SDM), Order Number 325462-093US, September 2026. Cited sections: Vol. 1, Sec. 3.1, 6.4.5, and 20.5.1; Vol. 3A, Sec. 5.6, 6.3.1, and 6.5; Vol. 3C, Sec. 26.3, 34.1, and 34.1.1. https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., and Warfield, A. (2003). Xen and the Art of Virtualization. Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), 164-177. https://doi.org/10.1145/945445.945462
Microsoft. User mode and kernel mode. Microsoft Learn, Windows drivers. https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode
Microsoft. How UMDF Handles Driver Failures. Microsoft Learn, Windows drivers. https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/how-umdf-handles-driver-failures
Weston, D. (2024a, July 20). Helping our customers through the CrowdStrike outage. The Official Microsoft Blog. https://blogs.microsoft.com/blog/2024/07/20/helping-our-customers-through-the-crowdstrike-outage/
Weston, D. (2024b, July 27). Windows Security best practices for integrating and managing security tools. Microsoft Security Blog. https://www.microsoft.com/en-us/security/blog/2024/07/27/windows-security-best-practices-for-integrating-and-managing-security-tools/
Microsoft (2025, June 26). The Windows Resiliency Initiative: Building resilience for a future-ready enterprise. Windows Experience Blog. https://blogs.windows.com/windowsexperience/2025/06/26/the-windows-resiliency-initiative-building-resilience-for-a-future-ready-enterprise/
Microsoft. Virtualization-based Security (VBS). Microsoft Learn. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
Microsoft. Kernel DMA Protection. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/hardware-security/kernel-dma-protection-for-thunderbolt
Microsoft. System Guard: How a hardware-based root of trust helps protect Windows. Microsoft Learn, section System Management Mode (SMM) protection. https://learn.microsoft.com/en-us/windows/security/hardware-security/how-hardware-based-root-of-trust-helps-protect-windows
Microsoft. Silicon assisted security. Windows 11 security book, Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/book/hardware-security-silicon-assisted-security
Microsoft (2016). Windows SMM Security Mitigations Table, version 1.0, April 18, 2016. https://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx
Microsoft. Windows 11 Secured-core PCs. Microsoft Learn. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure-11
Tanenbaum, A. S. An Open Letter to Intel. https://www.cs.vu.nl/~ast/intel/
Jacob, H. N., Werling, C., Buhren, R., and Seifert, J.-P. (2023). faulTPM: Exposing AMD fTPMs’ Deepest Secrets. arXiv:2304.14717. https://arxiv.org/abs/2304.14717
Moghimi, D., Sunar, B., Eisenbarth, T., and Heninger, N. (2019). TPM-FAIL: TPM meets Timing and Lattice Attacks. arXiv:1911.05673. https://arxiv.org/abs/1911.05673
Microsoft. Trusted Platform Module Technology Overview. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-overview
Microsoft. Trusted Platform Module (TPM) fundamentals. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/tpm-fundamentals
Microsoft. BitLocker countermeasures. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/countermeasures
Microsoft. Hardware root-of-trust. Windows 11 security book, Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/book/hardware-security-hardware-root-of-trust
Microsoft. Microsoft Pluton security processor. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/hardware-security/pluton/microsoft-pluton-security-processor
Microsoft. Microsoft Pluton as Trusted Platform Module. Microsoft Learn. https://learn.microsoft.com/en-us/windows/security/hardware-security/pluton/pluton-as-tpm
OP-TEE. About OP-TEE. OP-TEE documentation. https://optee.readthedocs.io/en/latest/general/about.html
Android Open Source Project. Trusty TEE. https://source.android.com/docs/security/features/trusty
Trusted Firmware-A. Firmware Design. Trusted Firmware-A documentation. https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html
Hafnium. Hafnium Documentation. https://hafnium.readthedocs.io/en/latest/
Android Open Source Project. Android Virtualization Framework (AVF) documentation, page AVF architecture, covering protected KVM (pKVM). https://source.android.com/docs/core/virtualization/architecture
Apple. The Secure Enclave. Apple Platform Security guide. https://support.apple.com/guide/security/the-secure-enclave-sec59b0b31ff/web
Kernel Newbies (2022). Linux 5.19, released July 31, 2022. https://kernelnewbies.org/Linux_5.19
Canonical. Intel Trust Domain Extensions (TDX) on Ubuntu. README of the canonical/tdx GitHub repository, Supported Hardware table. canonical/tdx
Microsoft. About Azure confidential VMs. Microsoft Learn. https://learn.microsoft.com/en-us/azure/confidential-computing/confidential-vm-overview
Google Cloud. Supported configurations. Confidential VM documentation. https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations
The Linux Kernel documentation. Intel Trust Domain Extensions (TDX). https://docs.kernel.org/arch/x86/tdx.html; the kernel source file arch/x86/include/asm/shared/tdx.h names the
TDG.VP.VMCALLfunction and itsTDVMCALLrequests.
Related work by the author (see Appendix E):
Trivedi, D. (2021). Cybersecurity 101: A Practical Approach to Attacking the CIA Triad. (see Appendix E)
Trivedi, D. (2021). Digital Systems. (see Appendix E)