4.5.2. Information Security Architecture Frameworks and Principles
💡 First Principle: A control can only be justified if you can trace it back to a business need it serves — security architecture is the discipline of keeping that thread unbroken from business requirement to deployed mechanism, so that nothing is built without a reason and no business need is left without a control.
Information security architecture is the structured description of how security services (identity, access control, monitoring, encryption, resilience) are arranged across the enterprise architecture. It is driven by the business, not by the product catalog. SABSA (Sherwood Applied Business Security Architecture) is the framework built around that idea. It mirrors Zachman's stakeholder views with six layers, each answering the question for a different audience:
| SABSA Layer | Perspective | Example Output |
|---|---|---|
| Contextual | Business | Business drivers and risks ("customers must trust online payments") |
| Conceptual | Architect | Business attributes profile — what "secure" means for this business (e.g. available, confidential, auditable) |
| Logical | Designer | Security services and policies (authentication service, audit service) |
| Physical | Builder | Mechanisms (MFA, log collection platform) |
| Component | Tradesperson | Specific products, standards and configurations |
| Operational | Service manager | How security is run, monitored and maintained in operation |
SABSA's distinctive contribution is two-way traceability: every component can be traced up to the business requirement it satisfies, and every business requirement can be traced down to the components that deliver it. That traceability is what lets a security manager answer a board member's "why are we paying for this?" — and what exposes a control nobody can justify, or a business requirement nothing actually protects.
Beyond frameworks, a small set of architecture principles recur in exam scenarios:
- Defense in depth — multiple independent layers of control (identity, network, host, application, data) so the failure of one layer does not expose the asset. The layers must be genuinely independent; three controls that all rely on the same directory service fail together.
- Segmentation and security zones — grouping systems by trust level and sensitivity, and controlling traffic between zones. Segmentation limits the blast radius of a compromise and is a classic compensating control for systems that can't be patched (4.3.1).
- Least privilege and separation of duties applied structurally — designing roles, administrative paths and service accounts so excessive access is not possible by default, rather than relying on people to decline it.
- Secure by design and secure by default — security requirements are built into the design from the start, and systems ship in their most secure reasonable configuration, so safety does not depend on every administrator remembering to harden them.
- Reference architectures and patterns — pre-approved designs for recurring needs (a public web application, a remote-access service, a cloud landing zone). They let projects move faster and more consistently, because the security analysis was done once and is reused.
- Fail secure — when a control fails, it defaults to the state that protects the asset, balanced against life safety (an evacuation door fails open; see 4.3.1).
⚠️ Exam Trap: Defense in depth is sometimes read as "buy more security products." The principle is about independent layers that address different failure modes; adding a second tool that duplicates an existing layer's function adds cost and complexity without adding depth. When a scenario offers "add another product in the same layer" versus "close the uncovered layer," the uncovered layer is the better answer.
Reflection Question: A security architecture document lists forty deployed tools but cannot say which business requirement each one serves. What two risks does this lack of traceability create, one financial and one about protection?
