Chapter 21 — Security architecture and engineering: system models
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Building the model"]
N2["21.2 Boundaries and assets"]
N3["21.3 STRIDE review"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Building the model"]
N2["21.2 Boundaries and assets"]
N3["21.3 STRIDE review"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Building the model]
|
v
[21.2 Boundaries and assets]
|
v
[21.3 STRIDE review]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) build a model of Fernway's order system; (2) identify trust boundaries and assets; (3) use the model in a STRIDE review.
21.1 Building the model
Lucas draws a data-flow diagram of Fernway's order system: the customer's browser, the web shop, the payment provider, the stock database, the warehouse picking app and the delivery partner. He marks processes, data stores, external entities and flows, and he labels what each flow carries. He validates the diagram with the developer and the warehouse manager, who correct two flows he had missed: a nightly price import from a supplier and a manual spreadsheet upload. Models are only useful if the people who run the system agree they are accurate.
21.2 Boundaries and assets
Lucas marks trust boundaries where data crosses between parties or privilege levels: between browser and shop, shop and payment provider, Fernway and the delivery partner, and between the office network and the cloud. He lists assets: customer details, order history, prices and stock levels. The manual spreadsheet upload crosses a boundary without any validation, which means a mistaken or malicious file could change prices across the shop. Marking boundaries makes such gaps visible because every crossing should have a defined check.
21.3 STRIDE review
Using Shostack's (2014) STRIDE categories, Lucas examines each element. Spoofing: the delivery partner's webhooks are signed. Tampering: the spreadsheet upload lacks validation. Repudiation: price changes are not logged with the user who made them. Information disclosure: order history is accessible to all staff accounts. Denial of service: the shop relies on one hosting region. Elevation of privilege: the picking app runs with database owner rights. He records seven threats with proposed mitigations and owners, and Fernway schedules the top three for the next quarter.
Worked example
Lucas builds and validates a data-flow model, marks four trust boundaries and runs a STRIDE review producing seven threats with owners.
Synthetic case. The order system is synthetic; Shostack (2014) is real.
Errors and limits
Models age as systems change. STRIDE finds categories of threat, not every attack.
Exercises
- EX061 — Validating the model. What did the developer and warehouse manager add? Rubric: 3 = a nightly supplier price import and a manual spreadsheet upload;; 2 = one flow;; 1 = vague;; 0 = none.
- EX062 — Unvalidated crossing. Why is the spreadsheet upload a concern? Rubric: 3 = it crosses a boundary unvalidated and could change prices;; 2 = validation;; 1 = vague;; 0 = none.
- EX063 — Repudiation finding. What repudiation gap did STRIDE find? Rubric: 3 = price changes are not logged with the user;; 2 = logging;; 1 = vague;; 0 = none.
Synthesis
A validated model with marked boundaries turns STRIDE into a concrete, owned list of threats.
Continue studying — chapter 21 of 40
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →