Chapter 16 — Security architecture
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 What an architecture contains"]
N2["16.2 Attributes for Fernway"]
N3["16.3 An overview document"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 What an architecture contains"]
N2["16.2 Attributes for Fernway"]
N3["16.3 An overview document"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 What an architecture contains]
|
v
[16.2 Attributes for Fernway]
|
v
[16.3 An overview document]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) describe what a security architecture contains; (2) apply SABSA-style attribute thinking to Fernway; (3) produce an architecture overview for a small organisation.
16.1 What an architecture contains
Lucas learns that a security architecture is a structured description of how security is achieved across an organisation: principles, the business attributes security must support, the main components and services, how they connect and who owns them. It is not a product list. Dr Bellini introduces SABSA, described by Sherwood, Clark and Lynas (2005), which starts from business attributes, and the Open Group's guide on integrating risk and security into TOGAF. Both emphasise that architecture links what the business values to what is built and operated.
16.2 Attributes for Fernway
Lucas works with Hannah to define Fernway's key attributes: available, so the shop sells during peak seasons; trustworthy, so members trust Fernway with their data; accurate, so stock and prices are correct; and compliant, so card and privacy obligations are met. For each attribute he lists the services that support it. Availability depends on cloud hosting and incident response; trustworthiness depends on identity, privacy and checkout protection. When someone proposes cutting a service, the attribute map shows which business value would weaken, turning technical debates into business ones.
16.3 An overview document
Lucas writes a ten-page architecture overview: principles such as deny by default and least privilege; attributes; a diagram of zones and services; key security services including identity, logging, backup and payment integration; owners; and known gaps with plans. He keeps it short so it is read. Hannah presents it to Fernway's board, who for the first time see security as a coherent design rather than a series of purchases. The overview becomes the reference for future project reviews. It is reviewed each spring.
Worked example
Lucas defines four business attributes for Fernway, maps supporting services and writes a ten-page architecture overview presented to the board.
Synthetic case. Attributes and overview are synthetic; SABSA and TOGAF G152 are real.
Errors and limits
Overviews simplify; details live in supporting documents. Attributes need revisiting when the business changes.
Exercises
- EX046 — Not a product list. Why is a security architecture not a product list? Rubric: 3 = it describes principles, attributes, services, connections and owners;; 2 = structure;; 1 = it is;; 0 = none.
- EX047 — Attribute use. How does the attribute map help when someone proposes cutting a service? Rubric: 3 = it shows which business value would weaken;; 2 = value;; 1 = vague;; 0 = none.
- EX048 — Board effect. What did the overview change for Fernway's board? Rubric: 3 = they saw security as a coherent design rather than purchases;; 2 = coherent;; 1 = vague;; 0 = none.
Synthesis
A security architecture links business attributes to services and owners in a short document people actually use.
Continue studying — chapter 16 of 40
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →