Chapter 18 — Security architecture
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Frameworks for architecture"]
N2["18.2 Layered view of Corvia"]
N3["18.3 Attributes to controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Frameworks for architecture"]
N2["18.2 Layered view of Corvia"]
N3["18.3 Attributes to controls"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Frameworks for architecture]
|
v
[18.2 Layered view of Corvia]
|
v
[18.3 Attributes to controls]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) describe enterprise security architecture frameworks; (2) build a layered architecture view for Corvia; (3) link business attributes to technical controls.
18.1 Frameworks for architecture
Security architecture organises controls into a coherent design rather than a collection of products. SABSA, described by Sherwood, Clark and Lynas (2005), starts from business requirements expressed as attributes, such as available, private or auditable, and traces them through layers down to physical components and operations. The Open Group's guide on integrating risk and security within TOGAF shows how to bring security into each phase of enterprise architecture development. Sofia learns that frameworks provide vocabulary and structure; their value lies in making assumptions and dependencies visible across teams.
18.2 Layered view of Corvia
Sofia builds a simple layered view of the fare system. At the business layer: collect fares accurately, protect passenger privacy, keep services running. At the logical layer: identity services, payment tokenisation, logging and key management. At the physical layer: secure elements in validators, hardware security modules for keys, segmented networks. At the operational layer: monitoring, incident response and patch management. Each control appears in one layer and links to the attribute it supports. The view exposes gaps, such as no operational owner for the key management service.
18.3 Attributes to controls
Daniel asks Sofia to trace the attribute passenger privacy downward. At the logical layer it requires minimised data and access control; at the physical layer encrypted storage and segmented networks; at the operational layer access reviews and breach response. Each link is a design claim that can be verified. When a proposed change removes a control, the trace shows which business attribute is weakened. This top-down link is SABSA's central contribution: it keeps security spending tied to what the organisation values rather than to fashionable technologies.
Worked example
Sofia builds a four-layer architecture view of Corvia's fare system, traces passenger privacy from attribute to operation and finds a missing owner for key management.
Synthetic case. The architecture view and gap are synthetic; SABSA and TOGAF G152 are real.
Errors and limits
Layered views simplify cross-cutting concerns. Attribute traces can become paperwork if not kept current.
Exercises
- EX052 — SABSA starting point. Where does SABSA start an architecture? Rubric: 3 = business requirements expressed as attributes;; 2 = attributes;; 1 = technology;; 0 = none.
- EX053 — Gap found. What gap did Sofia's layered view expose? Rubric: 3 = no operational owner for key management;; 2 = owner;; 1 = vague;; 0 = none.
- EX054 — Removing a control. What does the attribute trace show when a change removes a control? Rubric: 3 = which business attribute is weakened;; 2 = attribute;; 1 = vague;; 0 = none.
Synthesis
Security architecture links business attributes to controls across layers so gaps and trade-offs become visible.
Continue studying — chapter 18 of 50
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →