4.1.2. Zero Trust, Privacy by Design, and SASE
💡 First Principle: The Trusted Computing Base is the set of hardware, software, and firmware components that are critical to enforcing the system's security policy — everything outside the TCB is untrusted by definition. Minimizing the TCB minimizes the attack surface; a smaller TCB is easier to verify, audit, and certify as correct.
Trusted Computing Base (TCB) — the totality of protection mechanisms within a computer system, including hardware, firmware, and software, responsible for enforcing the security policy.
TCB components typically include: Operating system kernel, security kernel (the core that enforces access controls), reference monitor, security-relevant kernel modules, hardware memory protection mechanisms, trusted boot components.
TCB properties required for certification:
- Completeness — every access must go through the TCB; no bypass paths
- Isolation — the TCB must be protected from modification by untrusted processes
- Verifiability — the TCB must be small enough to be formally verified correct
Reference Monitor — an abstract concept describing an access control mechanism that: (1) is always invoked for every access attempt, (2) is tamperproof, and (3) is small enough to be analyzed. The security kernel is the hardware/software implementation of the reference monitor concept.
Security perimeter — the boundary between the TCB and untrusted components. Processes outside the perimeter cannot directly modify TCB behavior; all communication crosses the perimeter through controlled interfaces.
Trust levels and rings:
| Protection Ring | Content | Trust Level | Access |
|---|---|---|---|
| Ring 0 | OS kernel | Highest | Direct hardware access |
| Ring 1 | OS services (device drivers) | High | Privileged instructions with limits |
| Ring 2 | System utilities | Medium | Ring 1 services via system calls |
| Ring 3 | User applications | Lowest | Ring 0 only via syscall interface |
Modern x86 processors use Ring 0 (kernel) and Ring 3 (user space) primarily; Ring 1 and 2 are used by hypervisors in virtualization contexts. Ring separation enforces TCB isolation — a user-space process crashing cannot corrupt the kernel.
Virtualization and the TCB:
In virtualized environments, the hypervisor (VMM — Virtual Machine Monitor) becomes part of the TCB:
VM escape is the critical hypervisor vulnerability — an attacker in one guest VM exploits a hypervisor vulnerability to gain access outside their VM, potentially to the hypervisor itself or other VMs. Because the hypervisor is in the TCB, a compromised hypervisor compromises every VM running on it.
⚠️ Exam Trap: Type 1 hypervisors (VMware ESXi, Microsoft Hyper-V bare metal, Xen) run directly on hardware — the hypervisor IS the OS. Type 2 hypervisors (VMware Workstation, VirtualBox) run as applications on a host OS. Type 1 has a smaller TCB (no host OS between hypervisor and hardware) and is preferred for production security-sensitive deployments.
Reflection Question: A cloud provider runs customer workloads on shared physical hosts using a Type 1 hypervisor. Customer A is a defense contractor; Customer B is a general commercial company. What security boundaries depend on the hypervisor being part of the TCB, and what would VM escape mean for both customers?
