D3 — Security Architecture Depth: TCB, Evaluation Criteria, Physical Security
What a Trusted Computing Base actually is and why it must stay minimal, the security-mode vocabulary for systems handling mixed classification levels, Common Criteria evaluation assurance levels as a trust signal, and the physical-security layering that protects everything else in this domain.
Learning Objectives
- → Define the Trusted Computing Base and explain why minimizing its size is itself a security control
- → Distinguish the four security operating modes by what range of clearance and data sensitivity they permit simultaneously
- → Explain what a Common Criteria Evaluation Assurance Level actually certifies, and what it does not
- → Apply the CISSP mindset to a physical security control decision, in layered-defense terms
Lesson 10 covered cryptography; lesson 3 gave a light pass on Bell-LaPadula/Biba/Clark-Wilson. This lesson fills in the architectural vocabulary those models assume: what actually enforces them in a real system, how systems handling mixed sensitivity levels are formally classified, how outside evaluators certify a product's trustworthiness, and the physical layer every other control in this domain ultimately depends on.
The Trusted Computing Base (TCB) and the reference monitor
The Trusted Computing Base is the totality of a system's protection mechanisms — hardware, firmware, and software — that are relied upon to enforce the security policy. Critically, TCB does not mean "the whole operating system"; it means specifically the parts that must be correct for the security policy to hold.
The reference monitor is the abstract concept of the component that mediates every single access between a subject and an object, enforcing the security policy consistently. A real implementation of this concept is called a security kernel.
Why minimizing the TCB is itself a control: every additional line of code inside the TCB is additional attack surface for something the entire system's security depends on. A large, sprawling TCB means more code that must be perfectly correct; a small, minimal TCB is easier to formally verify, audit, and reason about. This is the architectural reason "least functionality" and minimal attack surface are treated as security principles, not just tidiness — they directly reduce the TCB's size and therefore the system's exposure to a flaw in security-critical code.
Security operating modes
When a system handles subjects with varying clearance levels and data of varying classification simultaneously, it operates in one of four formally defined modes:
| Mode | Clearance requirement | What subjects can access |
|---|---|---|
| Dedicated | All subjects cleared for the highest data level present | All data on the system (uniform clearance = uniform access) |
| System High | All subjects cleared for the highest data level present | Only data they have a specific need-to-know for (clearance alone isn't sufficient) |
| Compartmented | All subjects cleared for the highest level, AND formally authorized for the specific compartment | Only their specifically authorized compartment(s) |
| Multilevel | Subjects hold varying clearance levels | The system itself enforces access per subject's individual clearance (e.g. via Bell-LaPadula) |
The key distinction worth internalizing: Dedicated and System High both require every subject to hold the highest clearance present on the system — the difference between them is whether need-to-know is additionally enforced. Multilevel is the only mode where subjects with genuinely different clearance levels coexist on the same system, which is exactly why it's the mode that most directly depends on a correctly implemented Bell-LaPadula-style enforcement mechanism (Lesson 3) to keep the levels properly separated.
Common Criteria and Evaluation Assurance Levels
Common Criteria (ISO/IEC 15408) is an internationally recognized framework for independently evaluating a security product's claims. A vendor defines a Security Target (what the product claims to protect against), and an accredited evaluator assesses the product against it, assigning an Evaluation Assurance Level (EAL), typically ranging from EAL1 (functionally tested) to EAL7 (formally verified design and tested).
The critical distinction the exam tests precisely: a higher EAL does not mean "more secure" in an absolute sense — it means more rigorously and formally verified that the product does what its Security Target claims. A product with a narrow, modest Security Target evaluated at EAL7 has been extremely rigorously verified to do exactly what it claims — which might still be less functionally protective than a product with a broader, more ambitious Security Target evaluated at only EAL3. EAL measures assurance of the claim, not the absolute strength of the claim itself.
Physical security: the layer everything else depends on
No logical control — encryption, access control model, or TCB integrity — survives an attacker with unsupervised physical access to the hardware itself. Physical security is typically organized in concentric layers: deterrence (visible cameras, lighting, signage), detection (motion sensors, intrusion alarms), delay (locks, mantraps, reinforced barriers — slowing an attacker long enough for a response), and response (guards, law enforcement actually arriving). Each layer buys time or discourages the attempt; none is expected to be sufficient alone, which is the same layered-defense logic (defense in depth) that governs every other domain in this roadmap.
The CISSP mindset: manager vs technician
A vendor pitches a security appliance, emphasizing that it holds "EAL6+ certification — one of the highest levels available."
The technician answer: an EAL6+ rating sounds like strong evidence of security, so weight it heavily in the purchasing decision — a high number should mean a better product.
The manager (CISSP) answer: ask what the product's Security Target actually claims before treating the EAL rating as meaningful. If the certified claim is narrow (e.g. "this specific cryptographic module correctly implements a specific algorithm") and the organization's actual requirement is much broader (full endpoint protection against a wide range of attack techniques), a high EAL on a narrow claim provides less real assurance for the actual need than a lower EAL evaluated against a broader, more relevant Security Target. Treating "EAL6+" as a headline number, without reading what it was actually rigorously verified to do, is the same category of mistake as trusting a clean vulnerability scan (Lesson 9) as proof of something it was never designed to prove.
A vendor proposes adding a convenience feature directly into a system's security kernel to save an extra network call, rather than implementing it as a separate, less-privileged service outside the TCB. Explain, in architectural terms, what specific risk this introduces regardless of how well-tested the new feature is.
What specific risk does adding this feature to the TCB introduce, regardless of testing quality?
A government system hosts data at multiple classification levels. Analysts with SECRET clearance can access SECRET and CONFIDENTIAL data, while analysts with TOP SECRET clearance can access all three levels — the system itself enforces exactly what each individual analyst is permitted to see, based on their specific clearance. Which security mode is this, and why is it NOT System High?
Which security mode is this, and why isn't it System High?
Two products are being compared: Product A has an EAL7 rating but its Security Target only claims to correctly implement one narrow cryptographic function. Product B has an EAL3 rating but its Security Target claims broad protection against a wide range of attack techniques across an entire application. An evaluator naively recommends Product A because 'EAL7 is higher than EAL3.' What's wrong with this reasoning?
What's wrong with recommending Product A purely because its EAL is higher?