Chapter 20 — Security architecture and engineering: foundational cases

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Learning from cases"]
  N2["20.2 Mapping to Fernway"]
  N3["20.3 Writing a case analysis"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 Learning from cases"]
  N2["20.2 Mapping to Fernway"]
  N3["20.3 Writing a case analysis"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Learning from cases]
    |
    v
[20.2 Mapping to Fernway]
    |
    v
[20.3 Writing a case analysis]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) analyse published incidents for architectural lessons; (2) map lessons to Fernway; (3) write a short case analysis.

20.1 Learning from cases

Dr Bellini assigns three well-documented public incident patterns rather than specific company stories: compromise through a supplier with network access, theft of data from an exposed cloud storage bucket, and ransomware that spread because backups were reachable from the same network. Lucas analyses each for architectural causes rather than individual blame. The supplier case shows excessive trust; the storage case shows weak defaults and missing monitoring; the ransomware case shows a single failure domain. Each points to a design principle that could have limited damage.

20.2 Mapping to Fernway

Lucas checks Fernway against each pattern. The shopfitting contractor has a permanent VPN account with broad access, matching the supplier pattern; he recommends time-limited access approved per job. Fernway's product images sit in a cloud bucket, correctly public, but an export folder in the same bucket holds a stock file; he recommends a separate private bucket. Backups are already offline from chapter 11. The mapping turns abstract cases into three concrete actions, ranked by the size of the gap and the ease of fixing it.

20.3 Writing a case analysis

Lucas writes each analysis in a fixed structure: what happened, architectural causes, what would have limited impact, and relevance to Fernway. He keeps blame out and cites published guidance where it applies, such as SP 800-207 for limiting supplier trust. Each analysis is under a page. Hannah shares them with Fernway's managers, who find short structured cases more persuasive than general warnings. Lucas learns that the value of a case lies in the transferable design lesson, not in the drama of the incident.

Worked example

Lucas analyses three incident patterns for architectural causes, maps them to Fernway and produces three ranked actions in one-page analyses.

Synthetic case. The incident patterns are generic and synthetic; SP 800-207 is real.

Errors and limits

Generic patterns may miss local detail. Case lessons need checking against current configurations.

Exercises

• EX058 — Supplier pattern. Which Fernway arrangement matched the supplier pattern?
  Show marking criteria

  Rubric: 3 = the shopfitter's permanent broad VPN account;; 2 = contractor;; 1 = vague;; 0 = none.
• EX059 — Bucket fix. What did Lucas recommend for the cloud bucket?
  Show marking criteria

  Rubric: 3 = move the export folder to a separate private bucket;; 2 = separate;; 1 = delete images;; 0 = none.
• EX060 — Value of a case. Where does a case's value lie?
  Show marking criteria

  Rubric: 3 = in the transferable design lesson;; 2 = lesson;; 1 = drama;; 0 = none.

Synthesis

Analysing cases for architectural causes turns other organisations' incidents into specific local improvements.

Continue studying — chapter 20 of 40

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →