Chapter 12 — Security architecture and engineering: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Drawing the flows"]
N2["12.2 Trust boundaries"]
N3["12.3 Unprotected flows"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Drawing the flows"]
N2["12.2 Trust boundaries"]
N3["12.3 Unprotected flows"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Drawing the flows]
|
v
[12.2 Trust boundaries]
|
v
[12.3 Unprotected flows]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) draw data flows for parcel handling; (2) mark trust boundaries; (3) find unprotected flows.
12.1 Drawing the flows
Tomás draws how parcel data moves: a retailer sends a manifest to the tracking service; depots scan parcels; the tracking service sends routes to drivers' handhelds; drivers capture delivery photos; customers receive text updates through a messaging provider. He labels each arrow with the data it carries. Sam corrects him on one point: manifests from small retailers arrive by email as spreadsheets and are uploaded by hand. Diagrams must match reality, not the official process description. He redraws the diagram twice before Sam and the developer agree it matches what actually happens at the depots.
12.2 Trust boundaries
Tomás marks boundaries where data crosses between organisations or privilege levels: retailer to Brightwater, Brightwater to the messaging provider, depot network to cloud, and the email inbox where manifests arrive. Each crossing should have checks: authentication of the sender, encryption in transit and validation of content. Shostack (2014) recommends looking carefully at every crossing because attackers exploit the places where one party assumes the other has already checked. He numbers each boundary on the diagram and lists, for each one, which of the three checks is already present and which is missing, so the gaps are easy to see at a glance.
12.3 Unprotected flows
The emailed spreadsheet flow has no sender verification and no content validation, and anyone with access to the shared inbox can upload it. A criminal could send a fake manifest to redirect parcels. Tomás recommends moving small retailers to a simple upload portal with accounts, and validating manifests for unusual changes such as many address updates at once. The messaging provider flow is encrypted and authenticated, so no change is needed there. Data flow diagrams turn vague worries into specific fixes.
Worked example
Tomás draws parcel data flows, corrected by Sam, marks four trust boundaries and finds an unprotected emailed manifest flow.
Synthetic case. Flows and providers are synthetic; Shostack (2014) is real.
Errors and limits
Diagrams age quickly. Portals add work for small retailers.
Exercises
- EX034 — Sam's correction. What did Sam correct in the diagram? Rubric: 3 = small retailers email spreadsheets uploaded by hand;; 2 = email manifests;; 1 = vague;; 0 = none.
- EX035 — Boundary checks. What checks should each boundary crossing have? Rubric: 3 = sender authentication, encryption and content validation;; 2 = two;; 1 = vague;; 0 = none.
- EX036 — Fake manifest. What could a criminal do with the emailed flow? Rubric: 3 = send a fake manifest to redirect parcels;; 2 = redirect;; 1 = vague;; 0 = none.
Synthesis
Data flow diagrams with marked trust boundaries expose specific unprotected crossings.
Continue studying — chapter 12 of 30
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →