Chapter 31 — Security architecture and engineering: advanced cases
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Zero trust for a co-operative"]
N2["31.2 Resilience for peak season"]
N3["31.3 Weighing trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Zero trust for a co-operative"]
N2["31.2 Resilience for peak season"]
N3["31.3 Weighing trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Zero trust for a co-operative]
|
v
[31.2 Resilience for peak season]
|
v
[31.3 Weighing trade-offs]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) analyse a zero trust migration for Fernway; (2) weigh resilience design for peak seasons; (3) evaluate trade-offs in advanced designs.
31.1 Zero trust for a co-operative
Hannah wonders whether zero trust applies to Fernway. Lucas reads NIST SP 800-207 and explains its core idea: no implicit trust based on network location; every access request is evaluated using identity, device state and context. For Fernway this means retiring the office VPN for most uses and putting the stock system and staff apps behind an identity-aware access proxy. He plans a phased move starting with the finance app, which has few users and high value, so lessons are learned before the busy stores are included.
31.2 Resilience for peak season
Fernway earns a third of its online revenue in six weeks before winter. Lucas uses ideas from NIST SP 800-160 Vol. 2 Rev. 1 on cyber resilience: anticipate, withstand, recover and adapt. He proposes a pre-season freeze on non-essential changes, a tested failover for the shop to a second hosting region, a rehearsed manual order process if payment fails, and extra monitoring during peak. Each measure is sized to the risk: the failover costs money all year, so he checks it against the revenue lost in a peak-day outage before recommending it.
31.3 Weighing trade-offs
Advanced designs bring costs. The access proxy adds a dependency on the identity provider, already a single point of failure from chapter 22. The change freeze delays features marketing wants. Lucas presents each trade-off openly: what is gained, what is lost and who carries the cost. The board approves the proxy for finance and the freeze, but defers the second hosting region until next year's budget, accepting the risk for one season with the manual order process as a fallback. Lucas records the decision and its review date.
Worked example
Lucas plans a phased zero trust move starting with finance, applies resilience goals to peak season and presents trade-offs leading to a recorded board decision.
Synthetic case. Plans and costs are synthetic; SP 800-207 and SP 800-160 Vol. 2 Rev. 1 are real.
Errors and limits
Zero trust is a direction, not a product. Deferred resilience leaves the season exposed.
Exercises
- EX091 — Why finance first. Why start zero trust with the finance app? Rubric: 3 = few users and high value, so lessons are learned safely;; 2 = pilot;; 1 = stores first;; 0 = none.
- EX092 — Four resilience goals. What four resilience goals did Lucas use? Rubric: 3 = anticipate, withstand, recover and adapt;; 2 = three;; 1 = vague;; 0 = none.
- EX093 — Deferred item. What did the board defer and with what fallback? Rubric: 3 = the second hosting region; manual order process;; 2 = deferred;; 1 = vague;; 0 = none.
Synthesis
Advanced designs such as zero trust and resilience planning are phased and justified by explicit trade-offs.
Continue studying — chapter 31 of 40
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →