Chapter 18 — Security architecture | Engineering Incident response and cyber resilience

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX035.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["18.1 Trust zones and boundaries"]
  N2["18.2 Planes"]
  N3["18.3 Logging and recovery paths"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX035"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["18.1 Trust zones and boundaries"]
  N2["18.2 Planes"]
  N3["18.3 Logging and recovery paths"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX035"]

[Learning outcomes and connection]
    |
    v
[18.1 Trust zones and boundaries]
    |
    v
[18.2 Planes]
    |
    v
[18.3 Logging and recovery paths]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX035]

Learning outcomes and connection

After this chapter you can (1) draw trust zones and boundaries for a response system; (2) separate the control plane, data plane and evidence plane; (3) place logging and recovery paths so that compromise of one zone does not silently corrupt evidence or disable response; and (4) choose between architectures under explicit threat and availability constraints. It builds on Chapter 15 and prepares Chapters 23, 26 and 44.

18.1 Trust zones and boundaries

A trust zone groups components that share a security posture and administrators; a boundary is where data or control crosses between zones and must be mediated. Saltzer and Schroeder (1975) named principles that still guide placement: economy of mechanism, fail-safe defaults, complete mediation, separation of privilege, least privilege, least common mechanism. NIST SP 800-207 adds the zero-trust view: no implicit trust from network location; each request is authenticated and authorised. In Architecture A, the corporate IdP is an implicit trust anchor for all three planes.

18.2 Planes

A response system has three planes. The data plane carries telemetry and case data. The control plane issues actions — isolate, disable, block — and holds the highest privilege. The evidence plane stores raw records, manifests and audit logs and must be writable by producers but not alterable by them. Separating the planes means separate identities, separate administrators where possible, and one-way flows into the evidence plane.

Architecture B in the worked example applies this separation of planes to the HVSS case service. Its evidence store sits in a separate account with write-only ingest roles, and its containment orchestrator holds credentials scoped per action. Its break-glass case access also avoids the corporate IdP, so compromising that provider does not give the attacker every plane at once.

18.3 Logging and recovery paths

Logs must leave the zone they describe quickly, to a store the zone's administrators cannot modify. A recovery path — how responders work if the main platform or the corporate identity provider is compromised — must exist before the incident: out-of-band communication, break-glass accounts stored offline, and a minimal case log that does not depend on the main platform.

For HVSS, the recovery path matters because identity compromise is the most common route in its past cases. If the corporate IdP is the system under attack, responders who sign in through it lose access exactly when they need the case service. The break-glass path in Architecture B exists for that situation.

18.4 Worked example (synthetic): two architectures for the HVSS case service

Architecture A places the case service, evidence store and containment orchestrator in the corporate cloud tenant, all administered by the cloud team and authenticated through the corporate identity provider (IdP). Architecture B places the evidence store in a separate account with write-only ingest roles and an independent administrator group; the containment orchestrator in its own account with credentials scoped per action; and break-glass access to the case service that does not depend on the corporate IdP.

Criterion	A	B
Compromise of corporate IdP	attacker can reach evidence and controls	evidence and break-glass unaffected
Cloud admin insider	can alter evidence and audit logs	needs collusion with evidence admins
Availability during IdP outage	responders locked out	break-glass path works
Cost and complexity	lower	higher: two more accounts, separate admins, key custody

Threat constraint: the scenario of highest concern is identity compromise — the most common path in HVSS's past cases. Availability constraint: responders must work when the IdP is down. B satisfies both; A satisfies neither. The decision record lists B's added costs and its residual risk: break-glass credentials themselves are a target, mitigated by offline storage, dual control and alerting on use.

18.5 Errors and limits

Evidence stored where the investigated administrators can alter it.
Response tooling dependent on the system under attack.
Break-glass accounts never tested.
Architecture chosen without stating the threat it addresses.

Architecture A commits the first two errors, since the cloud administrators who may be under investigation can alter the evidence store, and an IdP outage locks responders out. Architecture B avoids both of those errors but takes on the third risk instead. Its offline, dual-controlled break-glass credentials must be exercised on a schedule, or the first real use may fail.

Exercises — chapter 18

EX035 — Zone diagram. Objective: draw zones and flows. Inputs: Architecture B. Steps: draw (text or ASCII) the zones, every cross-boundary flow with direction and the identity used; mark one-way flows. Expected evidence: diagram and flow list. Rubric: 3 = all planes separated, ingest write-only, audit flow one-way, break-glass shown; 2 = minor omissions; 1 = single zone; 0 = none.

EX036 — Choose under constraints. Objective: decide with explicit criteria. Inputs: a small HVSS client with two IT staff and no separate administrator group. Steps: adapt B to their constraint; state the residual risk. Expected evidence: design and risk. Rubric: 3 = e.g., evidence store with object lock / external managed service, break-glass with dual control from outside staff, residual insider risk acknowledged; 2 = partial; 1 = adopts A uncritically; 0 = none.

Chapter synthesis

Security architecture for response systems separates data, control and evidence planes, moves logs out of reach of those they describe, provides recovery paths independent of the attacked systems and chooses designs against stated threats and availability needs.

Continue studying — chapter 18 of 50

← Chapter 17 · Course chapter index · Chapter 19 →

Continue to the next authored lesson.