CROWN JEWEL REGISTER AND LOSS SCENARIO LIBRARY

What Would End Us, and Who Defends Each Chain End-to-End

Table of Contents

1. Purpose and Scope
2. Relationship to Bottom-Up Risk
3. The Crown Jewel Register
4. The Loss Scenario Library
5. Scenario Pressure-Test Process
6. Integration Points
7. Roles and Responsibilities
8. Document Control

1. Purpose and Scope

CERG’s operational pipeline is bottom-up. A scanner, a penetration test, an audit, or a review produces an observation; Risk validates its reachability, scores it, and tracks it to closure through CERG-PRC-VM-001 and the risk register in CERG-GOV-RMF-001 Section 9. This pipeline is disciplined and measurable, and it is necessary. It is not sufficient.

A program can be green on every finding metric and still have an undefended path to a catastrophic loss, because nothing in the bottom-up pipeline asks the top-down question: what is the small set of events that would actually end this organization, and is anyone defending each of those chains end-to-end? A bottom-up pipeline sees individual findings. It does not see a chain that crosses four assets and three control families, where each link looks acceptable in isolation but the chain as a whole is fatal.

This document adds the top-down layer. It does two things:

1. Establishes the Crown Jewel Register as the authoritative inventory of the assets whose loss would be catastrophic or severe, and defines the minimum control profile those assets must carry, verified rather than assumed.
2. Establishes the Loss Scenario Library, a curated set of named loss scenarios that are pressure-tested against the program’s actual control coverage, so that catastrophic gaps are discovered by deliberate exercise rather than by an incident or an auditor.

This document is scoped to CERG-managed assets and controls. It does not replace the System Categorization Register maintained under RMF-001 Section 3; it is a view over that register plus the scenario reasoning the register does not contain.

The Adaptive Test

An assessor asks: “Show me your crown jewels and the scenarios you test against them.” A Repeatable program answers with a control list. An Adaptive program answers with a named-scenario library, the control families that should break each chain, the detections that should fire, the recovery path, and the dated record of the last time each scenario was walked end-to-end. The difference is whether the program waits to be surprised.

2. Relationship to Bottom-Up Risk

The two layers are complementary and must reconcile. Neither replaces the other.

Reconciliation rules:

1. Every crown jewel in the register (Section 3) must exist as a categorized system in the RMF-001 Section 3 System Categorization Register. The register here does not invent assets; it flags and enriches the most consequential ones.
2. Every chain-breaking control named in a scenario (Section 4) must trace to a control in CERG-GOV-CB-001. Scenarios do not invent controls; they assert which existing controls must hold.
3. Every gap surfaced by a pressure-test becomes a bottom-up artifact: a Finding Record per CERG-GOV-FLOW-001 F-04. This is the bridge that returns top-down discoveries to the disciplined bottom-up pipeline for tracked closure.

3. The Crown Jewel Register

3.1 Criticality Tiers

The register classifies assets by the consequence of their loss. Tier 0 and Tier 1 assets are crown jewels and carry the minimum control profile in Section 3.3. Tiers 2 through 4 are governed by the standard baseline and overlays in CB-001. The tier definitions are the authoritative markdown form of the criticality tiers in machine-readable/cerg-crown-jewel-schema.yaml; where the two differ, this document wins and the schema is regenerated.

3.2 Register Field Set

Each crown-jewel entry records the following fields. These are the authoritative form of the crown_jewel_fields in the machine-readable schema:

3.3 Minimum Control Profile for Crown Jewels

A crown jewel does not merely inherit a NIST baseline overlay. It carries a minimum control profile that must be verified, not assumed. Each line is additive on top of the asset’s standard baseline and regulatory overlays per CB-001 (consistent with the CB-001 design principle that overlays add and never relax). A crown jewel that cannot evidence each line below generates a Finding Record per FLOW-001 F-04.

Verified, Not Assumed

“We back it up” is not tested recovery. “MFA is on” is not phishing-resistant identity enforced with legacy auth disabled. “It’s in its own VLAN” is not enumerated, minimized reachability. The crown-jewel profile is satisfied only by the named evidence, current within its freshness window. An assumed control on a crown jewel is the most expensive kind of optimism.

3.4 Relationship to the System Categorization Register

The crown-jewel register is a view over the RMF-001 Section 3 System Categorization Register, not a parallel inventory. The Tier 0 / Tier 1 flag lives on the categorization register; Governance maintains both records together. This document surfaces and operates the crown-jewel subset and attaches the minimum control profile and scenario linkage that the categorization register does not carry. There is exactly one authoritative list of systems, and it is the categorization register.

4. The Loss Scenario Library

4.1 Scenario Structure

A loss scenario is a named, narrated kill chain against one or more crown jewels. Each scenario is recorded with the following structure:

• Scenario ID and Name
• Narrative: one paragraph describing the loss event in business terms.
• Crown jewels in blast radius: the register entries the scenario threatens.
• Kill chain: the high-level adversary steps.
• Chain-breaking controls: the CB-001 control families that should stop the chain, with the specific control intent at each link.
• Detections that should fire: the ATT&CK techniques and LM-001 detections that should surface the activity.
• Recovery path: the BC-001 / RES-001 path that restores the service if prevention and detection both fail.
• Owner: the role accountable for keeping this scenario current and walking it.

Scenario-specific financial or impact figures are recorded as preliminary defaults requiring organizational calibration, following the RMF-001 Section 12 calibration pattern. They are not approved loss values until Finance and the CISO sign.

4.2 Starter Scenario Set

The following scenarios are the starting library. Each organization tailors the set to its own crown jewels and sector; the utility/OT and CUI flavor below reflects CERG’s reference environment. The library should hold roughly ten to fifteen live scenarios at any time.

Each scenario above is maintained as a fuller record (narrative, kill-chain steps, owner, preliminary impact) in the scenario library operated by the Risk Pillar Leader. The table is the index; the records carry the detail.

5. Scenario Pressure-Test Process

5.1 What a Pressure-Test Is

A scenario pressure-test is a deliberate desk exercise in which the Risk pillar walks a named scenario’s kill chain link by link and asks, at each link:

1. Does the chain-breaking control exist for the crown jewels in the blast radius?
2. Is it Implemented per CB-001 (not Planned, not assumed)?
3. Is it Effective per CERG-GOV-CEF-001 (the effectiveness metric is green, not merely the implementation metric)?
4. Would the detection fire, and would someone investigate it within SLA?
5. Does the recovery path work, and is it tested?

Any answer of “no” or “unknown” is a gap.

5.2 What a Pressure-Test Is Not

This is a control-coverage validation, not an incident drill. Full incident-response tabletops are owned by the standing IR team and documented in the IR plan. A scenario pressure-test may be combined with an IR tabletop, but its purpose is distinct: the tabletop rehearses the response; the pressure-test verifies that the controls which should prevent, detect, and recover from the scenario actually exist and work. The pressure-test does not require an active incident or a live exercise; it is a structured walk of the chain against documented control state.

5.3 From Gap to Tracked Closure

Every gap a pressure-test surfaces is logged as a Finding Record per FLOW-001 F-04, entering the disciplined bottom-up pipeline for owned, dated closure. Where a gap materially changes the residual risk of an asset, it also triggers the RMF-001 Section 9 re-score (Section 6 below). This is how a top-down discovery becomes bottom-up tracked work rather than a slide that is forgotten after the meeting.

5.4 Cadence

Scenario pressure-tests are scheduled in CERG-GOV-CAL-001. The recommended cadence is semi-annual for the full library, with any individual scenario re-walked when the threat landscape, the crown-jewel population, or a material control change warrants it. Each pressure-test produces a Scenario Pressure-Test Report and the associated Finding Records.

6. Integration Points

This document is connective tissue. Its value is in the cross-references below; each is wired in the named document.

7. Roles and Responsibilities

8. Document Control

Revision History

Review Triggers

• Annual scheduled review.
• Material change to the crown-jewel population (new Tier 0/1 asset, decommission, ownership change).
• Material threat-landscape shift that introduces or retires a scenario.
• A scenario pressure-test or incident that proves a scenario or control assumption wrong.

Related Documents

• CERG-GOV-RMF-001 - Risk Management Framework (categorization, re-score triggers)
• CERG-GOV-CB-001 - Unified Control Baseline (chain-breaking controls, Crown-Jewel Overlay)
• CERG-GOV-FLOW-001 - Cross-Pillar Operational Flows (F-02, F-03, F-04)
• CERG-GOV-CEF-001 - Control Effectiveness Framework (effectiveness test in pressure-test)
• CERG-GOV-MTR-001 - Metrics and Reporting (EM-006, RM-007)
• CERG-PLN-BC-001 - Business Continuity and DR (recovery paths)
• CERG-GOV-EDG-001 - Edge Register (vendor and SaaS edges in scenarios)

Source: governance/CERG-GOV-CJ-001_Crown_Jewel_Register_and_Scenario_Library.md · Download .md · View on GitHub