Chapter 26 — Alternative containment and recovery architectures

Lesson map

Lesson 26 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["26.1 Dimensions of a containment architecture"]
  N2["26.2 Identity-service compromise: the hard case"]
  N3["26.4 Modelling failure modes"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["26.1 Dimensions of a containment architecture"]
  N2["26.2 Identity-service compromise: the hard case"]
  N3["26.4 Modelling failure modes"]
  N4["Chapter synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX051"]

[Learning outcomes and connection]
    |
    v
[26.1 Dimensions of a containment architecture]
    |
    v
[26.2 Identity-service compromise: the hard case]
    |
    v
[26.4 Modelling failure modes]
    |
    v
[Chapter synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes and connection

After this chapter you can (1) describe containment architectures by isolation boundary, blast radius and restore path; (2) model their failure modes; (3) compare them against service objectives and residual risk; and (4) defend a choice in a decision record. It builds on Chapters 18 and 23 and prepares Chapters 27, 33, 35 and 38.

26.1 Dimensions of a containment architecture

• Isolation boundary: where the cut is made — credential, session, host, network segment, application, tenant, whole identity provider.
• Speed: time from decision to effective containment.
• Blast radius: what else stops working when the boundary is applied.
• Evidence effect: whether containment preserves or destroys volatile evidence and attacker visibility.
• Restore path: how service returns, and how long that takes.
• Residual risk: what attacker capability survives (persistent tokens, other footholds).

NIST SP 800-160 Vol. 2 Rev. 1 frames cyber resiliency techniques — segmentation, non-persistence, privilege restriction, redundancy, diversity — that map onto these dimensions.

26.2 Identity-service compromise: the hard case

When the identity provider (IdP) itself is suspect, every service that trusts it is exposed, and the response team's own access probably depends on it. Containment options range from narrow (revoke specific sessions and tokens, rotate signing keys) to broad (fail over to a clean standby IdP, or cut federation to all relying services).

At HVSS this is the scenario of the worked example below: an attacker with administrative access to the cloud IdP tenant who may have added a federated trust. Revoking sessions cannot remove a trust the attacker created, and responders who sign in through the same tenant may be locked out midway.

26.3 Worked example (synthetic): two designs at HVSS

Scenario: evidence suggests an attacker obtained administrative access to HVSS's cloud IdP tenant and may have added a federated trust or credentials to an application identity.

Design 1 — in-place containment. Disable suspicious administrator accounts, remove unknown federation trusts and application credentials, rotate token-signing keys, revoke all sessions. Speed: about 1–2 h for an experienced team. Blast radius: all users re-authenticate; some integrations break until re-consented. Evidence: audit logs remain in place, but an attacker with admin access may have altered log settings. Restore: immediate after verification. Residual risk: unknown persistence inside the tenant not found by enumeration.

Design 2 — clean-standby failover. A pre-built standby IdP tenant, configured from version-controlled definitions, takes over federation for critical applications; the suspect tenant is frozen for investigation. Speed: 4–8 h, mostly re-pointing applications. Blast radius: larger initially (all applications re-pointed), but bounded and rehearsed. Evidence: suspect tenant preserved intact. Restore path: back to a rebuilt primary later. Residual risk: configuration drift between definitions and reality; standby credentials must not share custody with the primary.

26.4 Modelling failure modes

Lesson table; scroll horizontally to read all columns →

Against HVSS objectives — critical applications restored within 8 h and no return of attacker access — Design 2 meets the persistence objective with higher confidence, at the cost of building and rehearsing the standby (Chapter 35). HVSS chose a hybrid: Design 1 for confirmed narrow compromise (single application credential), Design 2 when tenant-level administrative compromise is confirmed or cannot be excluded within 2 h. The decision rule itself is part of the architecture.

26.5 Errors and limits

• One containment pattern for all compromise depths.
• Response access dependent on the compromised system.
• Standby environments that are never exercised.
• Choosing by speed alone.

HVSS's hybrid rule addresses the first and last errors together. A confirmed single application credential gets the faster in-place Design 1. Tenant-level administrative compromise, or doubt that cannot be cleared within 2 h, gets the slower clean-standby Design 2. Picking Design 1 every time because it takes 1–2 h would leave hidden persistence in the tenant. Design 2 is only safe if the standby is rehearsed, as the failure-mode table warns.

Exercises — chapter 26

EX051 — Compare. Objective: model alternatives. Inputs: a compromised endpoint-management server that can push software to all workstations. Steps: describe two containment designs (e.g., disable push service vs network-isolate the server) by the six dimensions; choose under the objective "no further software pushed by the attacker, payroll workstations available by 08:00". Expected evidence: table and decision. Rubric: 3 = all dimensions, failure modes, decision justified; 2 = partial; 1 = one design; 0 = none.

EX052 — Decision rule. Objective: encode escalation. Inputs: the HVSS hybrid. Steps: write the decision rule as a short flowchart or pseudo-code with observable criteria and time limits. Expected evidence: rule. Rubric: 3 = observable criteria (admin role changes, federation changes, inability to exclude within 2 h), owner, time limits; 2 = partial; 1 = vague; 0 = none.

Chapter synthesis

Containment architectures differ by boundary, speed, blast radius, evidence effect, restore path and residual risk. Model failure modes, compare against objectives, and make the rule that selects between architectures part of the design.