Chapter 37 — Security architecture and engineering: operations
Lesson map
Lesson 37 published. Map, example, EX109.
flowchart TD
N0["Learning outcomes"]
N1["37.1 Operations by design"]
N2["37.2 Detection from threats"]
N3["37.3 Patching and change"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX109"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["37.1 Operations by design"]
N2["37.2 Detection from threats"]
N3["37.3 Patching and change"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX109"]
[Learning outcomes]
|
v
[37.1 Operations by design]
|
v
[37.2 Detection from threats]
|
v
[37.3 Patching and change]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX109]
Learning outcomes
You will (1) design security operations for the new architecture; (2) define detection use cases from the threat model; (3) plan patching and change management that preserve security properties.
37.1 Operations by design
An architecture is only as good as its operation. Sofia works with Corvia's operations centre to plan how the new back office will be run securely: who monitors which alerts, who can change configurations, how incidents are escalated and how access is reviewed. She uses NIST CSF 2.0, whose functions are govern, identify, protect, detect, respond and recover, to check that each function has owners and procedures for the new system. Operations planning during design avoids building systems that nobody can monitor or maintain properly after the project team leaves.
37.2 Detection from threats
Sofia turns threats from chapter 23 into detection use cases. For replayed tap records: alert when replay rejections from one validator exceed a threshold. For malicious tariff tables: alert on any unpublished version. For insider export of journey data: alert when exports exceed normal volume or occur outside working hours. Each use case lists the data source, the logic, expected false positives and the response playbook. Deriving detection from the threat model ensures monitoring focuses on what matters to this system rather than on generic alerts copied from vendor templates.
37.3 Patching and change
Changes can break security properties. Sofia defines a change process where any change touching authentication, cryptography, network rules or logging needs security review and re-running of relevant verification tests from chapters 30 and 40. Routine patches follow a schedule with emergency paths for critical vulnerabilities. She also requires that the architecture model be updated when a change alters flows or components. Daniel notes that most organisations struggle not with designing secure systems but with keeping them secure through years of small, well-intended changes.
Worked example
Sofia maps the back office to CSF 2.0 functions, derives three detection use cases from the threat model and defines a change process with security re-verification.
Synthetic case. Use cases and processes are synthetic; NIST CSF 2.0 is real.
Errors and limits
Detection thresholds need tuning after launch. Change processes can become bottlenecks if every change needs full review.
Exercises
- EX109 — CSF functions. List the six CSF 2.0 functions. Rubric: 3 = govern, identify, protect, detect, respond, recover;; 2 = five;; 1 = three;; 0 = none.
- EX110 — Insider export detection. How is insider export of journey data detected? Rubric: 3 = alert on unusual export volume or out-of-hours exports;; 2 = volume or time;; 1 = vague;; 0 = none.
- EX111 — Review trigger. Which changes need security review and re-verification? Rubric: 3 = those touching authentication, cryptography, network rules or logging;; 2 = three;; 1 = all trivial;; 0 = none.
Synthesis
Operational security is designed alongside the architecture, with detection derived from threats and change control that protects security properties.
Continue studying — chapter 37 of 50
← Chapter 36 (draft) · Course chapter index · Chapter 38 (draft) →