Chapter 22 — Security architecture and engineering: system and data models
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Component and interface model"]
N2["22.2 Boundaries and classifications"]
N3["22.3 Keeping models true"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Component and interface model"]
N2["22.2 Boundaries and classifications"]
N3["22.3 Keeping models true"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Component and interface model]
|
v
[22.2 Boundaries and classifications]
|
v
[22.3 Keeping models true]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) model the back office with components, interfaces and data flows; (2) mark trust boundaries and data classifications on the model; (3) keep models consistent with the system.
22.1 Component and interface model
Sofia models the fare back office as components: tap ingestion, journey construction, fare calculation, refunds, reporting and an integration layer to the payment provider. Each component has defined interfaces with message formats and authentication requirements. Modelling interfaces explicitly helps find places where data enters without validation or where a component trusts another more than it should. She notices that reporting reads directly from the journey database rather than through an interface, bypassing access controls, and records this as a design issue for review.
22.2 Boundaries and classifications
On the data-flow version of the model, Sofia marks trust boundaries: between validators and ingestion, between the back office and the payment provider, and between the back office and staff workstations. She labels each data flow with its classification from chapter 13. Flows that carry personal data across boundaries need encryption and authentication; flows carrying public data need integrity. The labelled model becomes the basis for threat modelling in the next chapter. It also makes it easy to answer an auditor's question about where personal data travels.
22.3 Keeping models true
Models drift from reality as systems change. Sofia proposes three practices: store the model in version control beside the code, review it in every design review and compare it quarterly with observed network flows and access logs. When the comparison finds a flow not in the model, either the model or the system is wrong, and both possibilities are worth knowing. Daniel notes that outdated diagrams are worse than none, because they give false confidence, so the model must have an owner responsible for keeping it accurate.
Worked example
Sofia models six back-office components, finds reporting bypassing access controls, labels flows by classification and sets up quarterly model-to-reality checks.
Synthetic case. Components and flows are synthetic.
Errors and limits
Models abstract away details where flaws can hide. Observed flows may miss rare paths used only during incidents.
Exercises
- EX064 — Bypass issue. What design issue did the component model reveal? Rubric: 3 = reporting reading the journey database directly, bypassing access controls;; 2 = bypass;; 1 = vague;; 0 = none.
- EX065 — Personal data flows. What do flows carrying personal data across boundaries need? Rubric: 3 = encryption and authentication;; 2 = both;; 1 = vague;; 0 = none.
- EX066 — Drift response. What does it mean when observed flows include one not in the model? Rubric: 3 = either the model or the system is wrong; investigate both;; 2 = investigate;; 1 = ignore;; 0 = none.
Synthesis
Accurate system and data models, with boundaries and classifications, are the foundation of threat analysis and audit answers.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →