{ "framework": "ASOM-Fed", "version": "6.1", "inherits": "NIST SP 800-53 Rev. 5", "classification": "Unclassified / Illustrative — a recommended reference for U.S. federal agencies", "generated_note": "Generated from the ASOM-Fed source package by scripts/asom-publish.mjs. Not hand-maintained: the catalog, the Word documents, the CSV and JSON exports and the framework website are all derived from one source, so they cannot disagree about what the framework contains.", "controls_total": 78, "families": [ { "id": "TM", "name": "Terrain Management", "description": "Inventory, classification, weighting, zones, connections, currency, ownership" }, { "id": "KT", "name": "Key Terrain and Decisive Points", "description": "What must not be lost, and whether an adversary can reach it" }, { "id": "ID", "name": "Identity Terrain", "description": "The identity plane as ground: planes, credentials, assurance, assertions, authorization integrity" }, { "id": "DV", "name": "Devices Terrain", "description": "The entry fords: device identification, posture as an access precondition, sensor liveness, execution control, lifecycle and sanitization" }, { "id": "SM", "name": "Scheme of Maneuver", "description": "Choosing moves, assigning them to ground, honest implementation states, deception emplacement" }, { "id": "TA", "name": "Tempo and Temporal Advantage", "description": "Making speed of decision measurable, governed and pre-authorized" }, { "id": "EN", "name": "Engagement and Pursuit", "description": "Declaration, triage, reconstruction, evidence, escalation, eradication, communication" }, { "id": "CE", "name": "Cycle Execution and Assurance", "description": "Cadence, intelligence requirements, posture computation, the evidentiary record" }, { "id": "CG", "name": "Command and Governance", "description": "Intent, phase, rules of engagement, findings disposition, inheritance" }, { "id": "RC", "name": "Reconstitution and Recovery", "description": "Recovery held outside the blast radius and proven by exercise" }, { "id": "FO", "name": "Federal Obligations", "description": "Terrain that exists because the organization is a federal one" }, { "id": "WF", "name": "Workforce Terrain", "description": "The people who operate the estate, held as ground" }, { "id": "FC", "name": "Facilities Terrain", "description": "Buildings, zones, and the maintenance paths reaching through them" }, { "id": "LC", "name": "Lines of Communication", "description": "Suppliers, components, and the routes they reach the estate on" } ], "controls": [ { "id": "TM-1", "family": "TM", "title": "Terrain Inventory and Overlay", "control_statement": "The organization shall maintain a current graphical overlay of all systems, data stores, and external actors within the authorization boundary, including the trust zones in which they reside.", "purpose": "To establish one authoritative positional picture of the estate, so that every later judgment about priority, reachability and risk is made against the same ground.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the defense is arrayed on ground we actually hold. *This control* — that ground is recorded positionally and kept current.", "discussion": "A register in a spreadsheet is not terrain. Terrain is positional: it records where an element sits relative to boundaries and to other elements, because position determines how an adversary moves. The overlay is the single artifact from which every other ASOM product is derived, which means an error introduced here propagates to reachability, coverage, backlog ranking and the Brief without being independently detectable in any of them.", "activities": [ { "n": 1, "capability": 2, "text": "Establish the authorization boundary as the overlay's outer edge, and record what was deliberately excluded and on whose authority." }, { "n": 2, "capability": 2, "text": "Populate the overlay from the authoritative asset inventory." }, { "n": 3, "capability": 2, "text": "Represent external actors — public users, partner agencies, suppliers, unauthenticated internet — as first-class elements rather than as an arrow at the boundary." }, { "n": 4, "capability": 3, "text": "Reconcile count and identity against the inventory rather than transcribing a subset, so completeness is a property of the method." }, { "n": 5, "capability": 3, "text": "Group every element into the trust zone that actually contains it, taken from enforced configuration rather than architectural intent." }, { "n": 6, "capability": 3, "text": "Record the derivation of each element: system of record, date, and who confirmed it." }, { "n": 7, "capability": 3, "text": "Publish the overlay in a form readable without the tool that produced it, so the artifact survives a change of platform." }, { "n": 8, "capability": 4, "text": "Measure reconciliation variance between overlay and inventory each cycle and set a threshold above which the overlay is not fit to plan from." }, { "n": 9, "capability": 4, "text": "Trend the age of the overlay at the moment it is used for a decision, not at the moment it was refreshed." }, { "n": 10, "capability": 5, "text": "Feed elements discovered during engagements — which the inventory did not contain — back into the inventory process, not only onto the overlay." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI", "SOC" ], "informed": [ "HT", "GOV" ] }, "information_flows": "*Inputs* — authoritative asset inventory; configuration management database;\nnetwork and identity configuration; supplier register (LC-1).\n*Outputs* — Cyber Terrain Overlay; derivation record; input to every other ASOM\ncontrol and to the Brief.", "people_skills": "Architectural reasoning across identity, network, application and physical\nestate. Reconciliation discipline. Ability to represent an estate positionally\nrather than as a list.", "policies": "Boundary definition and exclusion approval. Reconciliation procedure and cadence.\nOverlay publication and retention standard.", "culture": "", "services": "Diagram surface capable of holding zones, elements and external actors.\nExport to a tool-independent format. Linkage to the inventory system of record.", "metric_outcome": "percentage of inventory elements present on the overlay.", "metric_performance": "median age of the overlay at time of use.", "evidence": "Cyber Terrain Overlay (Figure 1 of the Brief); exported diagram source; derivation and reconciliation record.", "assessment": "Examine the overlay; interview the architecture owner; compare against the authoritative asset inventory for completeness.", "nist_800_53": [ "CM-8", "PM-5", "RA-9" ], "csf_2_0": [ "ID.AM-01", "ID.AM-03" ], "ztmm": "all pillars", "d3fend": "Model tactic", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth. Retrofitted from the 4.1 Control Practices pilot: numbered practices became capability-leveled activities; value and risk drivers absorbed into purpose, discussion and the culture component." } ] }, { "id": "TM-2", "family": "TM", "title": "Defensive Layer Classification", "control_statement": "Every element on the terrain shall be classified to exactly one defensive layer: identity, devices, networks, applications and workloads, data, operational technology, workforce, facilities, or supply chain. Elements that enable maneuver across layers rather than constituting ground — visibility and analytics, automation and orchestration, governance — shall be classified to the cross-cutting domain.", "purpose": "To make posture summable and comparable by layer, and to force an explicit ownership decision for every element.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — every part of the estate is somebody's ground. *This control* — each element sits on exactly one layer, and the layers sum.", "discussion": "Classification is what allows posture to be rolled up and compared. The one-layer rule is what keeps the matrix partitionable: coverage summed across layers must equal total coverage, and an element counted twice inflates both. The failure this correction addresses is structural — a framework that added four terrain layers in v2.0 and v3.0 while leaving the classification control at five made those layers doctrinally present and practically unscoreable.", "activities": [ { "n": 1, "capability": 2, "text": "Classify every element to exactly one of the nine terrain layers, or to the cross-cutting domain where the element enables movement rather than being ground." }, { "n": 2, "capability": 2, "text": "Flag unclassified elements automatically rather than relying on review." }, { "n": 3, "capability": 2, "text": "Record the classification against the element in the register." }, { "n": 4, "capability": 3, "text": "Where an element plausibly spans layers, assign it to the layer whose loss would defeat it, and cross-reference from the others rather than duplicating." }, { "n": 5, "capability": 3, "text": "Treat unclassified elements as findings with an owner and a due date." }, { "n": 6, "capability": 3, "text": "Reconcile layer totals to the full inventory each cycle; a shortfall means elements are unclassified, an excess means one is double-counted." }, { "n": 7, "capability": 3, "text": "Record rationale for any classification a reviewer would find surprising, so the decision survives its author." }, { "n": 8, "capability": 4, "text": "Trend reclassification rate; a layer with high churn indicates the criteria are ambiguous rather than that the estate is changing." }, { "n": 9, "capability": 4, "text": "Measure the population of each of T6–T9 and escalate where a declared terrain layer holds no classified elements at all." }, { "n": 10, "capability": 5, "text": "Refine the layer criteria where reclassification patterns show a boundary that practitioners cannot apply consistently." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI" ], "informed": [ "SOC", "HT", "GOV" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); element function and hosting records.\n*Outputs* — classified asset register; reconciliation record; input to TM-3\nweighting, CE-4 posture computation and all layer-scoped reporting.", "people_skills": "Ability to reason about which layer's loss defeats an element. Familiarity with\noperational technology, workforce and supplier terrain, not only IT estate.", "policies": "Layer criteria definitions including the cross-cutting test. Reconciliation\nprocedure. Finding disposition for unclassified elements.", "culture": "", "services": "Register with a single-valued layer field covering all ten values. Automatic\nflagging of unclassified elements. Reconciliation computation.", "metric_outcome": "percentage of elements carrying exactly one layer.", "metric_performance": "reconciliation variance between layer totals and inventory count.", "evidence": "Asset Register, \"Defensive layer\" column; reconciliation record.", "assessment": "Examine the register for unclassified elements; test that layer totals reconcile to the full inventory; test that at least one element on each of T6, T7, T8 and T9 is classified and scored.", "nist_800_53": [ "CM-8(1)", "RA-2", "PM-5" ], "csf_2_0": [ "ID.AM-05", "ID.AM-01" ], "ztmm": "five pillars mapped to T1–T5", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MAJOR-adjacent scope correction. v3.0 statement enumerated five defensive layers, making every element on T6-T9 and TX unclassifiable under the control mandating classification, while FO-4, WF-1, FC-1 and LC-1 all require that classification. Statement now carries the full v3.0 ten-layer model. Added L4 activity requiring escalation where a declared terrain layer holds no classified elements. Added PM-5 to inheritance and ID.AM-01 to CSF mapping." } ] }, { "id": "TM-3", "family": "TM", "title": "Asset Weighting", "control_statement": "Each element shall carry a defensive weight derived from its criticality to the mission and its exposure to untrusted actors, on a defined and consistently applied scale.", "purpose": "To convert an undifferentiated inventory into a priority order, so that coverage figures carry meaning and investment can be argued from mission consequence.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — effort concentrates where loss matters. *This control* — consequence and exposure are scored on a defined scale.", "discussion": "Without weighting, coverage percentages are misleading: protecting fifty low-value assets and leaving one crown jewel exposed can still report high compliance. The scale's integrity depends on calibration rather than on definition — two assessors applying a well-written scale will still diverge until they have scored a reference set together and reconciled the disagreement.", "activities": [ { "n": 1, "capability": 2, "text": "Score every element on criticality and on exposure." }, { "n": 2, "capability": 2, "text": "Compute weight as the product of the two scores." }, { "n": 3, "capability": 2, "text": "Record the scores against the element." }, { "n": 4, "capability": 3, "text": "Define both scales, including what distinguishes adjacent points, before any element is scored." }, { "n": 5, "capability": 3, "text": "Derive criticality from the mission the element serves, obtained from the mission owner rather than assigned by the security function." }, { "n": 6, "capability": 3, "text": "Derive exposure from reachability on permitted paths, not from network location alone." }, { "n": 7, "capability": 3, "text": "Calibrate by scoring a reference set collectively and reconciling divergence before scoring at scale." }, { "n": 8, "capability": 3, "text": "Re-score on mission change, on architectural change, and at cadence regardless of either." }, { "n": 9, "capability": 4, "text": "Measure inter-assessor variance on the calibration set and set a threshold above which the scale is not fit for trend use." }, { "n": 10, "capability": 5, "text": "Re-base the scales from observed incident consequence, so criticality reflects what loss actually cost rather than what it was assumed to cost." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI", "GOV" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — classified register (TM-2); mission service register; reachability\nresults (KT-4); permitted path register (TM-5).\n*Outputs* — weighted asset register; total defensive weight; input to KT-1\ndesignation, CE-4 posture and CE-5 backlog ranking.", "people_skills": "Consequence reasoning at mission level. Calibration discipline. Ability to hold a\nscoring line against an owner advocating for their own system.", "policies": "Criticality and exposure scale definitions. Calibration procedure. Re-scoring\ntriggers.", "culture": "", "services": "Register fields for both dimensions with computed weight. Calibration record.\nWeight distribution reporting.", "metric_outcome": "share of total defensive weight held by designated key terrain.", "metric_performance": "inter-assessor variance on the calibration set.", "evidence": "Asset Register weight column; total defensive weight in the Brief; calibration record.", "assessment": "Examine the weighting scale definition; interview owners on two high-weight and two low-weight assets to confirm consistent application.", "nist_800_53": [ "RA-2", "RA-3" ], "csf_2_0": [ "ID.AM-05", "ID.RA-05" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "TM-4", "family": "TM", "title": "Trust Zone Definition", "control_statement": "Trust zones shall be defined with explicit boundaries, and every element shall reside within a declared zone.", "purpose": "To establish boundaries that something enforces, so that reachability and denied-path analysis rest on configuration rather than on design intent.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — movement is constrained by boundaries that hold. *This control* — zones are declared, enforced and tested.", "discussion": "A zone that exists only on a diagram is a description of intent. Everything downstream — KT-3 avenues, KT-4 reachability, M4 canalization — computes over zone boundaries, so an unenforced zone does not merely fail to protect: it produces confident false negatives in the analysis that depends on it.", "activities": [ { "n": 1, "capability": 2, "text": "Draw zones on the overlay and place every element inside one." }, { "n": 2, "capability": 2, "text": "Raise a finding for any element sitting outside every declared zone." }, { "n": 3, "capability": 2, "text": "Identify, for each zone, the mechanism intended to enforce its boundary." }, { "n": 4, "capability": 3, "text": "Define each zone by the trust assumption that holds inside it, and state what must be true for an element to belong." }, { "n": 5, "capability": 3, "text": "Name the owner of each enforcing mechanism." }, { "n": 6, "capability": 3, "text": "Test a sample of boundaries against enforcing configuration each cycle rather than accepting the design." }, { "n": 7, "capability": 3, "text": "Record zones enforced by convention rather than configuration, and treat each as an open finding." }, { "n": 8, "capability": 3, "text": "Review zone membership when an element changes function or hosting." }, { "n": 9, "capability": 4, "text": "Trend boundary test pass rate and the count of convention-enforced zones, driving the latter toward zero." }, { "n": 10, "capability": 5, "text": "Revise zone design where repeated membership exceptions show the boundary is drawn in the wrong place." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC" ], "informed": [ "CTI", "HT", "GOV" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); network, identity and policy configuration.\n*Outputs* — zone declaration with enforcement record; input to TM-5 denied paths,\nKT-3 avenues and KT-4 reachability.", "people_skills": "Configuration-level verification across network and identity platforms. Ability\nto distinguish enforced segmentation from documented segmentation.", "policies": "Zone definition standard. Boundary testing procedure and sampling rate.\nMembership review triggers.", "culture": "", "services": "Zone rendering on the overlay. Configuration access sufficient to test\nboundaries. Membership containment tooling.", "metric_outcome": "percentage of elements inside a declared zone.", "metric_performance": "boundary sample test pass rate.", "evidence": "Terrain overlay showing zone membership; boundary enforcement record.", "assessment": "Examine the overlay for elements outside declared zones; test boundary enforcement against network configuration.", "nist_800_53": [ "SC-7", "AC-4" ], "csf_2_0": [ "PR.IR-01" ], "ztmm": "Networks", "d3fend": "Isolate tactic", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "TM-5", "family": "TM", "title": "Connection and Denied-Path Register", "control_statement": "All permitted connections between elements shall be recorded, and paths that are deliberately blocked shall be recorded distinctly as denied paths.", "purpose": "To record connectivity as three distinct states — permitted, denied, unknown — so that reachability conclusions rest on tested denials rather than on absence of evidence.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the adversary cannot reach what matters. *This control* — every path is known, and every denial is recorded and enforced.", "discussion": "Denied paths are the load-bearing entries. KT-4 concludes that a decisive point is unreachable precisely because certain paths are blocked; if those denials are not recorded and enforced, the conclusion is unfounded. The three-state distinction matters as much as the recording: treating unknown connectivity as absent is how a reachability model becomes confidently wrong.", "activities": [ { "n": 1, "capability": 2, "text": "Record every permitted connection with direction and protocol." }, { "n": 2, "capability": 2, "text": "Record deliberately blocked paths as first-class entries, distinguishable from paths that simply have no entry." }, { "n": 3, "capability": 2, "text": "Record observation-only paths separately from permitted flows." }, { "n": 4, "capability": 3, "text": "Record the business reason each permitted connection exists, so the register doubles as a rationale record." }, { "n": 5, "capability": 3, "text": "Represent unknown connectivity as a third state visible as such, rather than collapsing it into absence." }, { "n": 6, "capability": 3, "text": "Bind each denied path to the configuration enforcing it and the owner of that configuration." }, { "n": 7, "capability": 3, "text": "Test a sample of denied paths each cycle against firewall or policy configuration." }, { "n": 8, "capability": 3, "text": "Place change detection on the configurations enforcing denied paths." }, { "n": 9, "capability": 4, "text": "Trend denied-path test pass rate and measure mean time to detect an unauthorized change to a denied path." }, { "n": 10, "capability": 5, "text": "Feed paths discovered during engagements — which the register did not contain — back into the enumeration method, not only into the register." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "CTI" ], "informed": [ "HT", "GOV" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); zones (TM-4); firewall, policy and identity\nconfiguration; change management record.\n*Outputs* — connection register with three-state paths; denied-path enforcement\nrecord; input to KT-3, KT-4 and KT-5.", "people_skills": "Network and policy configuration fluency. Discipline to record unknown as\nunknown. Change management literacy sufficient to wire detection.", "policies": "Register schema including the three states. Denied-path testing procedure.\nChange detection coverage standard.", "culture": "", "services": "Connection register supporting three path states. Distinct rendering of denied\npaths on the overlay. Configuration change detection.", "metric_outcome": "percentage of denied paths with verified enforcement.", "metric_performance": "mean time to detect an unauthorized change to a denied path.", "evidence": "Connection register; denied paths rendered distinctly on the overlay; change-detection coverage record.", "assessment": "Examine the register; test a sample of denied paths against firewall or policy configuration to confirm they are enforced.", "nist_800_53": [ "AC-4", "SC-7(5)", "CA-3" ], "csf_2_0": [ "PR.IR-01", "ID.AM-03" ], "ztmm": "Networks", "d3fend": "Isolate, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added an explicit third connectivity state (unknown), distinguished from absence. v3.0 recorded permitted and denied only, which caused unknown connectivity to be treated as absent and produced confidently wrong reachability results downstream in KT-4." } ] }, { "id": "TM-6", "family": "TM", "title": "Terrain Currency", "control_statement": "The terrain overlay shall be refreshed at a defined cadence and upon any material architectural change.", "purpose": "To keep the overlay current against both the clock and the change, so that planning is conducted against ground as it currently is.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the defense is planned against real ground. *This control* — the map does not silently diverge from the estate.", "discussion": "A stale overlay is more dangerous than no overlay, because it is trusted. Currency has two triggers, and a program honoring only the cadence will plan from a map that a deployment invalidated the week after it was drawn. Wiring the change trigger into change management is what stops the second trigger depending on someone remembering.", "activities": [ { "n": 1, "capability": 2, "text": "Refresh the overlay at a stated interval." }, { "n": 2, "capability": 2, "text": "Record each refresh with its date and trigger." }, { "n": 3, "capability": 2, "text": "Retain superseded overlays rather than overwriting them." }, { "n": 4, "capability": 3, "text": "Define the refresh cadence and the rationale for its interval." }, { "n": 5, "capability": 3, "text": "Define what counts as a material architectural change, specifically enough for a change board to apply without judgment calls." }, { "n": 6, "capability": 3, "text": "Wire the change-triggered refresh into the change management process so it fires without depending on memory." }, { "n": 7, "capability": 3, "text": "Record a lapse in cadence as a finding with justification rather than allowing silent slippage." }, { "n": 8, "capability": 4, "text": "Trend overlay age at time of use and the elapsed time from material change to refresh." }, { "n": 9, "capability": 4, "text": "Measure drift per cycle as the delta between successive overlays, and escalate where drift exceeds the interval's assumption." }, { "n": 10, "capability": 5, "text": "Adjust the cadence from measured drift, shortening it where the estate moves faster than the interval assumed." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV" ], "informed": [ "CTI", "SOC", "HT" ] }, "information_flows": "*Inputs* — change management record; deployment pipeline events; cycle calendar.\n*Outputs* — refreshed overlay; cycle history with dates and triggers; retained\nsnapshot series; input to CE-1 cadence and CE-6 trend.", "people_skills": "Change management integration. Ability to specify a material-change threshold\nthat a non-security change board can apply.", "policies": "Cadence definition with rationale. Material change definition. Lapse\njustification procedure. Snapshot retention standard.", "culture": "", "services": "Snapshot retention with dated versions. Change management hook. Diff capability\nbetween successive overlays.", "metric_outcome": "percentage of cycles meeting the defined cadence.", "metric_performance": "median elapsed time from material change to overlay refresh.", "evidence": "Cycle history with dates; snapshot series; change-trigger record.", "assessment": "Examine cycle dates against the defined cadence; interview on the change-triggered refresh process; test that a recent material change produced a refresh.", "nist_800_53": [ "CM-8(1)", "CA-7" ], "csf_2_0": [ "ID.AM-08", "ID.IM-03" ], "ztmm": "cross-cutting Automation", "d3fend": "Model tactic", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "TM-7", "family": "TM", "title": "Terrain Ownership", "control_statement": "Every element shall have a named accountable owner recorded against it.", "purpose": "To attach every element to a person who can be asked to act, so that findings convert into work rather than accumulating.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — every part of the estate is defended by someone. *This control* — accountability is named, accepted and current.", "discussion": "Ownership is what converts a finding into work. An unowned element cannot be remediated, re-scored or defended, because there is nobody the requirement attaches to. The acceptance requirement distinguishes this control from an org chart lookup: ownership assigned silently is routinely discovered, at the worst moment, to have been news to its holder.", "activities": [ { "n": 1, "capability": 2, "text": "Record a named individual — not a team, distribution list or vacant post — as accountable for each element." }, { "n": 2, "capability": 2, "text": "Flag unowned elements automatically." }, { "n": 3, "capability": 2, "text": "Raise a finding for each unowned element." }, { "n": 4, "capability": 3, "text": "Obtain explicit acceptance of accountability from each named owner rather than assigning it silently." }, { "n": 5, "capability": 3, "text": "Confirm owners hold the authority and budget to act on findings against their elements, and escalate where they do not." }, { "n": 6, "capability": 3, "text": "Reconcile ownership against the personnel record each cycle so departures surface as unowned elements." }, { "n": 7, "capability": 3, "text": "Define the interim owner for an element whose owner has departed, so accountability never falls to nobody." }, { "n": 8, "capability": 4, "text": "Trend ownership gap duration and set a disposition period beyond which gaps escalate." }, { "n": 9, "capability": 4, "text": "Measure remediation velocity per owner, since an owner with no closures is a different problem from an element with no owner." }, { "n": 10, "capability": 5, "text": "Adjust ownership assignment where velocity data shows accountability sitting persistently away from the authority to act." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO" ], "informed": [ "CTI", "SOC", "HT" ] }, "information_flows": "*Inputs* — asset register (TM-1); personnel and organizational records.\n*Outputs* — ownership register with acceptance record; open findings list; input\nto CG-4 findings disposition and CE-5 backlog assignment.", "people_skills": "Organizational navigation sufficient to find the real owner rather than the\nnominal one. Willingness to escalate an owner without authority.", "policies": "Ownership acceptance procedure. Personnel reconciliation cadence. Interim owner\nrule. Disposition period for ownership gaps.", "culture": "", "services": "Register owner field with acceptance flag and date. Personnel record integration.\nAutomatic flagging on departure.", "metric_outcome": "percentage of elements with an accepted named owner.", "metric_performance": "median duration of an ownership gap.", "evidence": "Asset Register owner column; open findings list; acceptance record.", "assessment": "Examine the register for unowned elements; interview a sample of named owners to confirm they accept accountability.", "nist_800_53": [ "CM-8(4)", "PM-5" ], "csf_2_0": [ "GV.RR-02" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "KT-1", "family": "KT", "title": "Decisive Point Identification", "control_statement": "The organization shall identify and designate the elements whose compromise would unhinge the wider defense, and shall justify each designation.", "purpose": "To concentrate defensive effort on the small number of elements whose loss is decisive, so that priority is a stated judgment rather than an emergent property of the asset register.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — no single compromise unhinges the defense. *This control* — the elements capable of unhinging it are named and justified.", "discussion": "A decisive point is not the same as a high-weight asset. Weight measures consequence of loss; decisiveness measures whether losing it collapses everything else. An identity policy decision point may carry moderate weight and still be decisive, because holding it confers control of movement everywhere. The justification requirement exists because the designation is a judgment, and an unjustified judgment cannot be argued with or inherited by a successor.", "activities": [ { "n": 1, "capability": 2, "text": "Identify candidate decisive points from the terrain overlay, considering elements that control movement, control authorization, or control recovery." }, { "n": 2, "capability": 2, "text": "Designate each decisive point on the overlay so it is visually distinct from surrounding terrain." }, { "n": 3, "capability": 2, "text": "Record a justification for each designation stating what its compromise would unhinge." }, { "n": 4, "capability": 3, "text": "Define the designation criteria in advance and derive them from the defensive intent (CG-1), so a candidate is tested against stated purpose rather than assessed on instinct." }, { "n": 5, "capability": 3, "text": "Record, for each high-weight element *not* designated, why it was excluded — the exclusions carry as much information as the designations." }, { "n": 6, "capability": 3, "text": "Obtain the accountable authority's approval of the designated set as a whole, not element by element." }, { "n": 7, "capability": 3, "text": "Re-run designation on material architectural change and at defined cadence." }, { "n": 8, "capability": 4, "text": "Measure the concentration of defensive weight held by the designated set and set a threshold above which the set is too large to be meaningful." }, { "n": 9, "capability": 4, "text": "Test designations against incident and exercise evidence: an element whose compromise did *not* unhinge the defense is a designation to revisit." }, { "n": 10, "capability": 5, "text": "Re-derive the designation criteria from observed engagements, so what counts as decisive is learned from contact rather than assumed at the outset." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "TO", "SOC" ], "informed": [ "HT", "GOV" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); layer classification (TM-2); asset weighting\n(TM-3); mission service register; threat courses of action.\n*Outputs* — designated decisive point set with justifications; exclusion record;\ninput to KT-2 protection floor, KT-3 avenue analysis and SM-4 main effort.", "people_skills": "Ability to reason about second-order consequence rather than asset value.\nFamiliarity with the estate's authorization and recovery paths. Willingness to\nrecord a judgment that a successor will challenge.", "policies": "Designation criteria document. Approval procedure naming the accountable\nauthority. Review trigger definition covering both cadence and change.", "culture": "", "services": "Terrain overlay capable of flagging and rendering designated elements distinctly.\nRegister capable of holding justification and exclusion text against elements.", "metric_outcome": "share of total defensive weight held by the designated set.", "metric_performance": "percentage of designations carrying a recorded, current justification.", "evidence": "Key Terrain section of the Brief with justification per element; exclusion record; approval record.", "assessment": "Examine designations and justifications; interview the CISO on why non-designated high-weight assets were excluded; test whether the designated set has grown beyond the stated threshold.", "nist_800_53": [ "RA-9", "CP-2(8)", "PM-11" ], "csf_2_0": [ "ID.AM-05", "ID.RA-04" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "4.0.1", "changes": [ { "v": "4.0.1", "note": "PATCH. Backfill after CG authoring: designation criteria now derived from the defensive intent (CG-1) rather than from an unsourced standard. Decisiveness is a judgment about purpose, and CG-1 is where purpose is stated." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "KT-2", "family": "KT", "title": "Decisive Point Protection Floor", "control_statement": "Every designated decisive point shall have at least one defensive move assigned and operational, and shall meet a defined minimum effective coverage.", "purpose": "To ensure designation produces protection, so that identifying a decisive point is an act with consequences rather than an annotation.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — decisive points are held. *This control* — every one of them carries operational defense above a stated floor.", "discussion": "The gap between designation and protection is where most programs fail. An element can be starred on the overlay for four consecutive cycles with a planned maneuver against it and never receive one. The *operational* qualifier is doing the work here: a move recorded as planned or partial does not satisfy the floor, because an adversary is not slowed by intent.", "activities": [ { "n": 1, "capability": 2, "text": "Assign at least one defensive maneuver to each designated decisive point." }, { "n": 2, "capability": 2, "text": "Record the implementation state of each assignment as planned, partial or operational." }, { "n": 3, "capability": 2, "text": "Raise a finding where a decisive point carries no operational move." }, { "n": 4, "capability": 3, "text": "Define the minimum effective coverage floor and the basis on which it was set, and obtain the accountable authority's approval recording the date relative to first measurement (GA4)." }, { "n": 5, "capability": 3, "text": "Compute effective coverage per decisive point, weighting by implementation state so that partial assignments do not count in full, and excluding moves recorded as constrained under FO-4 so that a decisive point on operational technology is scored against achievable coverage rather than against a floor it cannot reach." }, { "n": 6, "capability": 3, "text": "Assign an owner and a target date to each decisive point below the floor." }, { "n": 7, "capability": 3, "text": "Verify by sampling that moves recorded as operational are present and functioning in production, not merely licensed." }, { "n": 8, "capability": 4, "text": "Trend the number of decisive points below the floor across cycles and escalate where the count fails to fall." }, { "n": 9, "capability": 4, "text": "Measure the elapsed time from designation to first operational move, since that interval is the window in which designation was decorative." }, { "n": 10, "capability": 5, "text": "Re-base the floor from exercise and incident evidence rather than leaving it at the value first chosen." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — designated decisive point set (KT-1); maneuver assignments (SM-2);\nimplementation states (SM-3); effectiveness weightings (SM-6).\n*Outputs* — per-point coverage result; findings list; input to CE-4 posture\ncomputation and CE-5 backlog ranking.", "people_skills": "Ability to distinguish a control that is licensed from one that is operating.\nSufficient independence to record an uncomfortable implementation state.", "policies": "Coverage floor definition with its rationale. Finding disposition procedure.\nSampling procedure for verifying operational status.", "culture": "", "services": "Assignment register linking moves to elements. Coverage computation weighted by\nimplementation state. Findings engine capable of raising on absence.", "metric_outcome": "percentage of decisive points meeting the coverage floor.", "metric_performance": "median elapsed time from designation to first operational move.", "evidence": "Findings list; per-asset maneuver assignment in the Register; sampling record.", "assessment": "Test each decisive point for assigned and operational moves; examine effective coverage against the defined floor; test a sample of \"operational\" states against production reality.", "nist_800_53": [ "SC-7", "AC-6", "SI-4" ], "csf_2_0": [ "PR.AA-05", "PR.PS-01" ], "ztmm": "all pillars", "d3fend": "Harden, Isolate tactics", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after FO-4 and SM-3: constrained moves are excluded from the effective coverage denominator, so a decisive point on operational technology is scored against achievable coverage rather than against a floor it cannot reach." }, { "v": "4.1.0", "note": "MINOR. Backfill after TA-3 and GA4: the coverage floor now requires accountable-authority approval with the date recorded relative to first measurement. Without this, the floor is set wherever the program already passes and can never report a deficit." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "KT-3", "family": "KT", "title": "Avenue of Approach Analysis", "control_statement": "The routes by which an adversary could approach designated decisive points shall be enumerated and assessed.", "purpose": "To convert the estate's connectivity into a set of named approach routes, so that defense can be emplaced on the routes that exist rather than distributed evenly across ground.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the adversary is met on ground of our choosing. *This control* — the routes to decisive points are known before contact.", "discussion": "An avenue of approach is a property of the architecture, not of any particular adversary, which is what makes it enumerable in advance. The assessment step matters more than the enumeration: a route with neither a barrier nor a compensating detection is an open approach, and knowing about it without acting is worse than not knowing, because it converts a gap into an accepted one without anyone accepting it.", "activities": [ { "n": 1, "capability": 2, "text": "Trace permitted paths from each external actor and each lower-trust zone to each designated decisive point." }, { "n": 2, "capability": 2, "text": "Record each distinct route as a named avenue with its origin, its path, and its terminus." }, { "n": 3, "capability": 2, "text": "Identify, for each avenue, whether a barrier or a detection currently covers it." }, { "n": 4, "capability": 3, "text": "Enumerate avenues systematically from the connection register rather than from analyst recall, so completeness is a property of the method." }, { "n": 5, "capability": 3, "text": "Include approach routes through workforce, facility and supplier terrain, not only network paths — three of the most-used federal intrusion paths are not network routes." }, { "n": 6, "capability": 3, "text": "Assess each avenue for whether its coverage is a barrier, a detection, or neither, and record the result distinctly." }, { "n": 7, "capability": 3, "text": "Raise a finding for every avenue with neither, with an owner and a date." }, { "n": 8, "capability": 4, "text": "Measure the count of uncovered avenues per decisive point and trend it." }, { "n": 9, "capability": 4, "text": "Test a sample of avenues by attempting traversal, rather than accepting the register's account of coverage." }, { "n": 10, "capability": 5, "text": "Update the enumeration method from routes observed in real engagements that the method had not predicted." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "HT", "TO" ], "informed": [ "SOC", "GOV" ] }, "information_flows": "*Inputs* — connection and denied-path register (TM-5); trust zones (TM-4);\ndecisive points (KT-1); supplier register (LC-1); workforce terrain (WF-1).\n*Outputs* — enumerated avenue set with coverage assessment; findings; input to\nKT-4 reachability and M4 canalization planning.", "people_skills": "Path-tracing across heterogeneous terrain. Ability to think about approach\nthrough people and suppliers, not only through networks. Red-team perspective\nsufficient to see a route the architecture did not intend.", "policies": "Enumeration method document. Coverage classification definitions. Finding\ndisposition procedure for uncovered avenues.", "culture": "", "services": "Route tracer operating over the connection register. Ability to render traced\nroutes on the overlay. Register fields for coverage classification.", "metric_outcome": "percentage of enumerated avenues carrying a barrier or a detection.", "metric_performance": "percentage of avenues verified by traversal test rather than by record.", "evidence": "Adversary reach analysis; traced route figures; coverage classification per avenue.", "assessment": "Examine enumerated avenues; test that each has either a barrier or a compensating detection; test whether non-network approach routes were enumerated at all.", "nist_800_53": [ "RA-3", "CA-8", "RA-5" ], "csf_2_0": [ "ID.RA-01" ], "ztmm": "Networks, Identity", "d3fend": "Model, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR, scope-widening. Activity 5 now requires enumeration of approach routes through workforce, facility and supplier terrain, not only network paths. v3.0 read as network path analysis while declaring T7-T9 as terrain; those are three of the most-used federal intrusion paths." } ] }, { "id": "KT-4", "family": "KT", "title": "Adversary Reachability Assessment", "control_statement": "The organization shall determine, on permitted paths only, whether any threat actor position can reach any designated decisive point, and shall record the result each cycle.", "purpose": "To produce a computed, repeatable answer to the question a control catalog cannot ask — can they get there from here — and to record the answer as a trend rather than a one-time finding.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — decisive points are unreachable from adversary positions. *This control* — reachability is computed, not assumed, every cycle.", "discussion": "This is one of the framework's genuinely net-new controls: no federal catalog requires a computed reachability result. Its integrity depends entirely on the denied-path register under TM-5. A negative result — no route exists — is a claim about configuration that holds only while the barriers holding the line remain enforced, which is why KT-5 exists and why the two controls should never be assessed apart.", "activities": [ { "n": 1, "capability": 2, "text": "Define the threat actor start positions to be assessed, at minimum the unauthenticated internet and any compromised-user position." }, { "n": 2, "capability": 2, "text": "Compute, over permitted paths only, whether a route exists from each start position to each decisive point." }, { "n": 3, "capability": 2, "text": "Record the result for the cycle, including the routes found and the points proven unreachable." }, { "n": 4, "capability": 3, "text": "Derive start positions from current threat courses of action rather than from a fixed list, so the assessment tracks the threat." }, { "n": 5, "capability": 3, "text": "Report, for each negative result, the specific denied paths holding the line, and hand them to KT-5." }, { "n": 6, "capability": 3, "text": "Re-compute on material architectural change as well as at cycle cadence." }, { "n": 7, "capability": 3, "text": "Validate the computation against the connection register so that a route the register permits cannot be absent from the result." }, { "n": 8, "capability": 4, "text": "Trend reachability results across cycles; a point that becomes reachable between cycles is a reportable condition, not a backlog item." }, { "n": 9, "capability": 4, "text": "Measure the interval between a permitting change and its appearance in a reachability result." }, { "n": 10, "capability": 5, "text": "Reconcile computed reachability against routes actually used in engagements, and correct the model where contact disagrees with it." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "TO", "SOC" ], "informed": [ "HT", "GOV" ] }, "information_flows": "*Inputs* — connection and denied-path register (TM-5); trust zones (TM-4);\ndecisive points (KT-1); avenues (KT-3); threat courses of action.\n*Outputs* — per-cycle reachability result; barrier list to KT-5; input to CE-4\nposture and CE-6 trend.", "people_skills": "Graph reasoning over connectivity. Ability to state a negative result with its\ndependencies rather than as an unqualified assurance.", "policies": "Start position definition. Computation method documented sufficiently for an\nassessor to reproduce it. Escalation procedure for a point becoming reachable.", "culture": "", "services": "Route tracer with a documented algorithm. Cycle history capable of holding\nresults as a series. Change detection feeding re-computation.", "metric_outcome": "number of decisive points reachable from any assessed start position.", "metric_performance": "elapsed time from a permitting configuration change to its reflection in a reachability result.", "evidence": "Adversary Reach section of the Brief; per-cycle result series; barrier dependency list.", "assessment": "Test the reachability computation against the connection register; examine the result trend across cycles; test that a recent permitting change appeared in the subsequent result. **Assess jointly with KT-5:** a negative reachability result is a claim about configuration that holds only while the barriers under KT-5 remain enforced, so KT-4 assessed alone can certify a conclusion that a subsequent barrier change has already invalidated.", "nist_800_53": [ "RA-3(4)", "CA-8" ], "csf_2_0": [ "ID.RA-05", "DE.AE-07" ], "ztmm": "Networks, Identity", "d3fend": "Model tactic", "version": "4.0.1", "changes": [ { "v": "4.0.1", "note": "PATCH. Added mandatory joint assessment with KT-5. A negative reachability result holds only while KT-5 barriers remain enforced, so KT-4 assessed alone can certify a conclusion a later barrier change has already invalidated." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "KT-5", "family": "KT", "title": "Barrier Sufficiency", "control_statement": "Where reachability is prevented by denied paths, those barriers shall be identified, enforced technically, and monitored for change.", "purpose": "To make the barriers on which negative reachability results depend into named, owned, monitored controls, so that the assurance KT-4 provides cannot be silently withdrawn.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — decisive points stay unreachable. *This control* — the barriers making them unreachable are enforced and watched.", "discussion": "This control exists because of a specific failure sequence: a reachability assessment returns negative, the result is briefed, a firewall rule is changed six weeks later for an unrelated reason, and nobody recomputes. The assurance persists in the record long after the configuration that justified it has gone. Change monitoring on the barrier set is the only thing that closes that window.", "activities": [ { "n": 1, "capability": 2, "text": "Extract from each negative reachability result the specific denied paths that held the line." }, { "n": 2, "capability": 2, "text": "Record each as a control with a named owner rather than leaving it as a register entry." }, { "n": 3, "capability": 2, "text": "Identify the technical configuration enforcing each barrier." }, { "n": 4, "capability": 3, "text": "Verify by test that each barrier is enforced by configuration and not by convention, documentation or expectation." }, { "n": 5, "capability": 3, "text": "Place change detection on every enforcing configuration, with an alert path that reaches someone able to act." }, { "n": 6, "capability": 3, "text": "Define the response to a detected barrier change, including re-running KT-4 before the change is accepted." }, { "n": 7, "capability": 3, "text": "Review barrier ownership when the underlying platform or its owner changes." }, { "n": 8, "capability": 4, "text": "Trend barrier test pass rate and the count of convention-enforced barriers, driving the latter toward zero." }, { "n": 9, "capability": 4, "text": "Measure mean time to detect an unauthorized change to a barrier." }, { "n": 10, "capability": 5, "text": "Feed every barrier failure back into the enumeration method, so the class of barrier that failed is looked for elsewhere in the estate." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "CTI" ], "informed": [ "HT", "GOV" ] }, "information_flows": "*Inputs* — reachability results and barrier dependencies (KT-4); denied-path\nregister (TM-5); change management record.\n*Outputs* — barrier control list with owners; change detection coverage record;\ntrigger for KT-4 re-computation.", "people_skills": "Configuration-level verification skill. Ability to distinguish an enforced denial\nfrom a documented one. Change management fluency sufficient to wire a trigger.", "policies": "Barrier verification procedure. Change detection coverage standard. Response\nprocedure on detected barrier change, including mandatory KT-4 re-run.", "culture": "", "services": "Configuration change detection across firewall, policy and identity platforms.\nAlerting into a monitored path. Linkage from barrier to enforcing configuration.", "metric_outcome": "percentage of load-bearing barriers with verified technical enforcement and active change detection.", "metric_performance": "mean time to detect an unauthorized barrier change.", "evidence": "Barrier list from route analysis; supporting configuration evidence; change-detection coverage record.", "assessment": "Test each barrier against enforcing configuration; examine change-detection coverage on those barriers; test the response path by introducing a monitored change. **Assess jointly with KT-4:** this control exists to sustain KT-4's negative results, and its findings invalidate them directly.", "nist_800_53": [ "SC-7(5)", "AC-4", "CM-3" ], "csf_2_0": [ "PR.IR-01", "DE.CM-01" ], "ztmm": "Networks", "d3fend": "Isolate, Detect tactics", "version": "4.0.1", "changes": [ { "v": "4.0.1", "note": "PATCH. Mirror of the KT-4 joint assessment requirement." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "SM-1", "family": "SM", "title": "Maneuver Catalog Adoption", "control_statement": "The organization shall adopt a defined catalog of defensive moves expressed as intent and mechanism rather than as product names.", "purpose": "To fix a shared vocabulary of defensive moves stated as intent, so the plan survives replacement of the tools that implement it.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — leadership can direct a defense without being engineers. *This control* — a durable, intent-first move catalog is in force.", "discussion": "Products are replaced every few years; intent is durable. Expressing the catalog as intent means the framework survives procurement cycles and lets leaders direct without technical fluency. The adoption test is not whether the catalog exists but whether leadership can actually issue direction in its terms — a catalog nobody commands with is a glossary.", "activities": [ { "n": 1, "capability": 2, "text": "Adopt the eleven-move catalog as issued, or extend it with locally defined moves in the same form." }, { "n": 2, "capability": 2, "text": "Record each move's intent, mechanism and effectiveness weighting." }, { "n": 3, "capability": 2, "text": "Publish the catalog where those who must use it can reach it." }, { "n": 4, "capability": 3, "text": "State every move as intent and mechanism, and reject any candidate that names a product category rather than a defensive effect." }, { "n": 5, "capability": 3, "text": "Require any locally defined move to meet the same admission criteria as an issued one: durable, expressible as intent, distinct in effect, supported by at least five techniques, and capable of being absent." }, { "n": 6, "capability": 3, "text": "Confirm by interview that leadership can direct using the catalog's terms without translation by an engineer." }, { "n": 7, "capability": 3, "text": "Review the catalog when the framework issues a version, and record which local extensions were superseded." }, { "n": 8, "capability": 4, "text": "Measure how often direction is actually issued in catalog terms versus in product terms, since the second indicates adoption has not occurred." }, { "n": 9, "capability": 5, "text": "Contribute locally defined moves that met the admission criteria back to the framework steward, so the catalog improves from field use." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI", "SOC" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — issued ASOM-Fed maneuver catalog; local defensive practice; framework\nversion notices.\n*Outputs* — adopted catalog with weightings; local extension record; input to\nSM-2 assignment and SM-4 main effort.", "people_skills": "Ability to state a defensive effect without naming a product. Doctrinal literacy\nsufficient to apply the admission criteria to a candidate move.", "policies": "Adopted catalog document. Local extension admission procedure. Version review\nprocedure.", "culture": "", "services": "Catalog accessible to planners and operators. Linkage from moves to the\ntechniques that realize them.", "metric_outcome": "percentage of defensive direction issued in catalog terms.", "metric_performance": "percentage of local extensions meeting the admission criteria.", "evidence": "Adopted catalog with intent, mechanism and effectiveness weighting per move; local extension record.", "assessment": "Examine the adopted catalog; interview leadership on their ability to direct using it.", "nist_800_53": [ "PL-2", "PM-7" ], "csf_2_0": [ "GV.PO-01" ], "ztmm": "cross-cutting Governance", "d3fend": "taxonomy alignment", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Corrects the published CSV, which recorded 'the ten-move catalog' against a v3.0 framework carrying eleven forms; the DOCX was already correct. Added the five admission criteria for locally defined moves, which v3.0 referenced only implicitly." } ] }, { "id": "SM-2", "family": "SM", "title": "Maneuver Assignment", "control_statement": "Defensive moves shall be assigned to specific elements of terrain rather than declared at program level.", "purpose": "To bind defensive intent to specific ground, so that coverage reflects what protects which element rather than what the program has bought.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — every element that matters is covered by a named move. *This control* — moves are assigned per element, not declared in aggregate.", "discussion": "Program-level declaration is the single largest source of coverage inflation. \"We do microsegmentation\" is true of an organization and false of most of its elements, and the gap between those two statements is invisible until an assignment register forces the question element by element. This control is what makes an unprotected-asset report possible at all.", "activities": [ { "n": 1, "capability": 2, "text": "Assign moves to specific elements rather than declaring them at program level." }, { "n": 2, "capability": 2, "text": "Produce a report of elements carrying no assigned move." }, { "n": 3, "capability": 2, "text": "Record assignments in the register against the element." }, { "n": 4, "capability": 3, "text": "Derive assignment priority from asset weight (TM-3) and decisive point designation (KT-1) rather than from ease of assignment." }, { "n": 5, "capability": 3, "text": "Verify by sampling that a move recorded as assigned is genuinely present on that element, not present somewhere in the estate." }, { "n": 6, "capability": 3, "text": "Use bulk assignment for genuinely common patterns, but require the same sampling verification as individually assigned moves." }, { "n": 7, "capability": 3, "text": "Reconcile assignments after architectural change, since an element rebuilt on a new platform rarely retains its moves." }, { "n": 8, "capability": 4, "text": "Trend the count and weight of unprotected elements, and set a threshold on weight rather than on count." }, { "n": 9, "capability": 4, "text": "Measure the divergence between program-level claims and element-level assignment, which is the inflation figure." }, { "n": 10, "capability": 5, "text": "Revise assignment patterns where sampling repeatedly finds a class of move recorded but absent, since that indicates a systemic rather than a local gap." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — adopted catalog (SM-1); classified and weighted register (TM-2,\nTM-3); decisive points (KT-1).\n*Outputs* — per-element assignment register; unprotected-asset report; input to\nSM-3 state tracking, KT-2 protection floor and CE-4 posture.", "people_skills": "Knowledge of what is actually deployed on specific elements, as distinct from\nwhat is licensed. Sampling discipline.", "policies": "Assignment procedure with priority derivation. Sampling verification standard.\nPost-change reconciliation trigger.", "culture": "", "services": "Assignment register linking moves to elements. Bulk assignment with audit trail.\nUnprotected-asset reporting.", "metric_outcome": "percentage of defensive weight carried by elements with at least one assigned move.", "metric_performance": "sampling pass rate on assignments verified present.", "evidence": "Per-asset maneuver assignment; unprotected-asset report; sampling record.", "assessment": "Examine assignments against the register; test that a sample of assigned moves is genuinely present on that element.", "nist_800_53": [ "PL-2", "CA-2" ], "csf_2_0": [ "PR.PS-01", "ID.IM-01" ], "ztmm": "all pillars", "d3fend": "Harden, Detect, Isolate tactics", "version": "4.0.0", "changes": [ { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "SM-3", "family": "SM", "title": "Implementation State Tracking", "control_statement": "Each assigned move shall carry an implementation state of planned, partial, or operational, and only operational moves shall count in full toward risk reduction.", "purpose": "To make the coverage figure reflect what is defending the estate rather than what is intended to, by weighting mitigation by implementation state.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — posture claims are true. *This control* — intent and operation are distinguished, and only operation counts in full.", "discussion": "This is the honesty control, and the entire posture computation rests on it. An adversary is not slowed by a planned maneuver, so a framework that counts one is producing a number about ambition rather than about defense. The control is also the framework's most fragile, because it can be defeated without any technical failure: if \"operational\" becomes the state recorded to avoid a finding, no assessment procedure downstream can recover. That is why the assessment tests production reality rather than the field.", "activities": [ { "n": 1, "capability": 2, "text": "Record an implementation state of planned, partial or operational against every assigned move." }, { "n": 2, "capability": 2, "text": "Weight mitigation by state so that planned and partial do not count in full." }, { "n": 3, "capability": 2, "text": "Report coverage separately at full weight and at state-weighted value." }, { "n": 4, "capability": 3, "text": "Define each state against an observable condition, so the distinction between partial and operational is testable rather than a matter of judgment. Record a fourth state, **constrained**, where a terrain constraint recorded under FO-4 makes the move genuinely unavailable, and exclude constrained assignments from the coverage denominator rather than carrying them indefinitely as planned." }, { "n": 5, "capability": 3, "text": "Require evidence for any transition to operational, rather than allowing the state to be self-declared." }, { "n": 6, "capability": 3, "text": "Sample states each cycle and test against production, prioritizing moves on decisive points." }, { "n": 7, "capability": 3, "text": "Record the date of each state transition, so the age of an operational claim is visible." }, { "n": 8, "capability": 4, "text": "Measure the false-operational rate found by sampling, and treat a rising rate as a governance finding rather than a data quality one." }, { "n": 9, "capability": 4, "text": "Trend the duration moves spend in planned and partial, since a move that has been planned for four cycles is not a plan." }, { "n": 10, "capability": 5, "text": "Automate state derivation from telemetry where the observable condition permits, replacing declaration with detection." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — assignment register (SM-2); production telemetry; change and\ndeployment records.\n*Outputs* — state-weighted coverage; effective coverage computation; input to\nKT-2 protection floor, CE-4 posture and CE-5 backlog.", "people_skills": "Ability to verify operation rather than presence. Independence sufficient to\nrecord an uncomfortable state against one's own element.", "policies": "State definitions tied to observable conditions. Evidence requirement for\ntransition to operational. Sampling procedure and rate.", "culture": "", "services": "State field with transition dates. Weighted coverage computation. Telemetry\nintegration where automated derivation is feasible.", "metric_outcome": "state-weighted effective coverage against full-weight coverage.", "metric_performance": "false-operational rate found by sampling.", "evidence": "Implementation state per assignment with transition dates; effective coverage computation; sampling record.", "assessment": "Test a sample of moves recorded as operational to confirm they are in production and effective; examine the false-operational rate trend.", "nist_800_53": [ "CA-5", "PM-4" ], "csf_2_0": [ "ID.IM-02" ], "ztmm": "maturity staging", "d3fend": "N/A (assessment layer — no countermeasure equivalent)", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after FO-4: adds a fourth implementation state, constrained, for moves made genuinely unavailable by a recorded terrain constraint. Without it an OT element that cannot be patched or restarted on the defender's schedule sits permanently as planned and depresses coverage forever, which trains OT owners to disengage from the program." }, { "v": "4.1.0", "note": "MINOR. Added state definitions tied to observable conditions, an evidence requirement for transition to operational, and a false-operational rate metric derived from sampling. SM-3 carries the entire posture computation and was the framework's most fragile control: defeasible by optimistic self-declaration with no downstream detection." } ] }, { "id": "SM-4", "family": "SM", "title": "Main Effort Designation", "control_statement": "For each phase, the organization shall designate where defensive priority is concentrated.", "purpose": "To concentrate defensive priority at a declared point, so that subordinate decisions follow from it without referral.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — priority is stated, not emergent. *This control* — a main effort is designated per phase and resourcing follows it.", "discussion": "Main effort is the concept a control catalog structurally cannot hold, because a catalog has no way to say that one requirement matters more this quarter. The designation is only real if resourcing moved: a main effort that changed no budget line, no staffing allocation and no queue priority is a label applied after the fact. The assessment procedure therefore examines resourcing rather than the declaration.", "activities": [ { "n": 1, "capability": 2, "text": "Declare the current campaign phase." }, { "n": 2, "capability": 2, "text": "Designate where defensive priority is concentrated for that phase." }, { "n": 3, "capability": 2, "text": "Record the designation in the Brief." }, { "n": 4, "capability": 3, "text": "Derive the designation from the phase's dominant forms and from current threat courses of action, rather than from standing organizational preference." }, { "n": 5, "capability": 3, "text": "State what is being accepted as lower priority, since a main effort that subordinates nothing is not a main effort." }, { "n": 6, "capability": 3, "text": "Align resourcing — budget, staffing, queue priority — to the designation, and record the specific allocations that moved." }, { "n": 7, "capability": 3, "text": "Re-designate on phase transition and on material change in the threat picture." }, { "n": 8, "capability": 4, "text": "Measure the proportion of defensive effort actually expended on the designated main effort, and compare it against the designation." }, { "n": 9, "capability": 4, "text": "Trend the interval between phase transition and resourcing realignment." }, { "n": 10, "capability": 5, "text": "Review past designations against engagement outcomes, and adjust the derivation where the main effort was repeatedly designated away from where contact occurred." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "AO" ], "consulted": [ "CTI", "SOC", "GOV" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — declared phase (CG-2); threat courses of action; decisive points\n(KT-1); adopted catalog (SM-1).\n*Outputs* — main effort statement with subordinated priorities; resourcing\nallocation record; input to CE-5 backlog and the Brief.", "people_skills": "Command judgment. Willingness to state what is being given up. Budget authority\nsufficient to make the designation consequential.", "policies": "Designation procedure tied to phase. Resourcing alignment requirement.\nRe-designation triggers.", "culture": "", "services": "Phase declaration surface. Main-effort marking across the overlay. Linkage from\ndesignation to resourcing records.", "metric_outcome": "proportion of defensive effort expended on the designated main effort.", "metric_performance": "elapsed time from phase transition to resourcing realignment.", "evidence": "Phase declaration and main-effort statement in the Brief; subordination record; resourcing allocation record.", "assessment": "Examine the designation; interview on how resourcing followed it; test that at least one allocation demonstrably moved.", "nist_800_53": [ "PM-11", "RA-2" ], "csf_2_0": [ "GV.RM-01" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (planning layer — no countermeasure equivalent)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added an explicit subordination requirement (state what is deprioritized) and a resourcing evidence test. A main effort that subordinates nothing and moved no allocation is a label, and the v3.0 assessment could not distinguish the two." } ] }, { "id": "SM-5", "family": "SM", "title": "Branches and Sequels", "control_statement": "Pre-planned contingency maneuvers shall be defined for the most likely and most dangerous adversary courses of action.", "purpose": "To decide contingency responses before contact, so that the decision loop under pressure is a selection rather than a design exercise.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the response is chosen in advance. *This control* — branches exist for both the likely and the dangerous case, and have been exercised.", "discussion": "The distinction between most likely and most dangerous is the whole value of the control. Planning only against the likely course produces a program that is efficient until the day it is not; planning only against the dangerous one produces a program that cannot afford its own contingencies. Holding both, and knowing which cells both demand, is where a single investment answers two threats.", "activities": [ { "n": 1, "capability": 2, "text": "Define contingency moves against the most likely adversary course of action." }, { "n": 2, "capability": 2, "text": "Define contingency moves against the most dangerous course of action." }, { "n": 3, "capability": 2, "text": "Link each to the response procedure that executes it." }, { "n": 4, "capability": 3, "text": "Derive both courses of action from current intelligence rather than from a standing scenario library." }, { "n": 5, "capability": 3, "text": "Identify the moves demanded by both courses, since those are where one investment answers two threats." }, { "n": 6, "capability": 3, "text": "State the trigger condition for each branch, specifically enough that an operator can recognize it without escalating to ask." }, { "n": 7, "capability": 3, "text": "Exercise at least one branch per cycle through tabletop or live test." }, { "n": 8, "capability": 4, "text": "Measure the elapsed time from trigger condition to branch execution in exercise, and compare it against the tempo the branch assumes." }, { "n": 9, "capability": 4, "text": "Trend branch currency against the threat picture; a branch built for a course of action no longer assessed is a maintenance liability." }, { "n": 10, "capability": 5, "text": "Re-derive branches from engagements, replacing assumed adversary behavior with observed behavior." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "SOC", "HT" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — threat courses of action; adopted catalog (SM-1); rules of\nengagement (CG-3); decisive points (KT-1).\n*Outputs* — branch and sequel register with triggers; linked response procedures;\nexercise records; input to TA-4 pre-authorization.", "people_skills": "Course-of-action development. Ability to write a trigger an operator can apply\nunder pressure. Exercise design.", "policies": "Branch register schema including triggers. Exercise cadence. Currency review\nagainst the threat picture.", "culture": "", "services": "Branch register linked to response playbooks. Exercise recording. Linkage from\ntrigger to the telemetry that would show it.", "metric_outcome": "percentage of assessed courses of action carrying a current branch.", "metric_performance": "elapsed time from trigger to execution in exercise.", "evidence": "Branch and sequel register with triggers; linked response procedures; exercise records.", "assessment": "Examine defined branches; test one through a tabletop exercise; examine currency against the current threat assessment.", "nist_800_53": [ "IR-4", "CP-2" ], "csf_2_0": [ "RS.MA-01", "ID.IM-02", "ID.IM-04" ], "ztmm": "cross-cutting Automation", "d3fend": "Isolate, Evict tactics", "version": "4.0.1", "changes": [ { "v": "4.0.1", "note": "PATCH. CSF recovery: adds ID.IM-04 (incident response plans established) — branches and sequels with linked response procedures constitute the plan." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "SM-6", "family": "SM", "title": "Maneuver Effectiveness Validation", "control_statement": "The assumed effectiveness of each move shall be validated through exercise, testing, or observed incident performance, and adjusted where evidence contradicts assumption.", "purpose": "To replace assumed effectiveness with demonstrated effectiveness, so the coverage figure reflects what controls do rather than what was assumed of them.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — posture reflects reality. *This control* — effectiveness weightings are corrected by evidence.", "discussion": "The framework's own design documentation concedes that the `riskReduction` weightings are an allocation model for prioritization rather than an empirical finding, and states that they should be re-based against an agency's own incident history. SM-6 is the control that discharges that obligation. An agency running the framework for several cycles without adjusting a single weighting has not validated anything — it has confirmed its priors, and its coverage figure remains a statement about doctrine rather than about its estate.", "activities": [ { "n": 1, "capability": 2, "text": "Test or exercise assigned moves and record the result." }, { "n": 2, "capability": 2, "text": "Record the basis on which each effectiveness weighting currently rests." }, { "n": 3, "capability": 2, "text": "Adjust weightings where evidence contradicts assumption." }, { "n": 4, "capability": 3, "text": "Define what constitutes validating evidence for each move, distinguishing exercise, red-team test and observed incident performance." }, { "n": 5, "capability": 3, "text": "Use each technique's success indicator as the pass/fail condition, so validation tests the framework's own stated observable." }, { "n": 6, "capability": 3, "text": "Record every adjustment with its justification and the evidence that drove it." }, { "n": 7, "capability": 3, "text": "Propagate adjusted weightings into the posture computation rather than holding them as a separate finding." }, { "n": 8, "capability": 4, "text": "Measure the proportion of weightings resting on evidence rather than on issued default, and trend it upward." }, { "n": 9, "capability": 4, "text": "Measure the divergence between assumed and demonstrated effectiveness, since a consistently positive divergence indicates the defaults are optimistic." }, { "n": 10, "capability": 5, "text": "Re-base the full weighting distribution against accumulated agency incident history, and contribute the finding to the framework steward." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "HT" ], "consulted": [ "SOC", "CTI", "GOV" ], "informed": [ "TO" ] }, "information_flows": "*Inputs* — assignment register (SM-2); implementation states (SM-3); technique\nsuccess indicators; exercise and incident records.\n*Outputs* — validation results; adjusted weightings with justification; input to\nCE-4 posture computation and M10 doctrine update.", "people_skills": "Red-team capability. Statistical caution about small samples. Independence from\nthe party that implemented the move.", "policies": "Validation evidence definitions. Adjustment justification requirement.\nPropagation procedure into posture computation.", "culture": "", "services": "Weighting fields editable with audit trail. Exercise and test recording. Linkage\nfrom technique indicator to test result.", "metric_outcome": "percentage of effectiveness weightings resting on agency evidence rather than issued default.", "metric_performance": "divergence between assumed and demonstrated effectiveness.", "evidence": "Validation results; adjusted weightings with justification and supporting evidence.", "assessment": "Examine validation evidence; test that adjustments were reflected in the posture computation; examine whether any weighting has ever been reduced.", "nist_800_53": [ "CA-2", "CA-8", "IR-3" ], "csf_2_0": [ "ID.IM-02", "ID.IM-03" ], "ztmm": "cross-cutting Visibility", "d3fend": "all tactics (as test targets)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. RACI responsibility assigned to the hunt team rather than terrain owners, on independence grounds: the party that emplaced a move is the wrong party to certify it. Added an assessment step examining whether any effectiveness weighting has ever been reduced." } ] }, { "id": "SM-7", "family": "SM", "title": "Deception Emplacement", "control_statement": "Deception shall be emplaced across designated terrain, and every interaction with a deception element shall raise an alert that reaches a human within a defined period.", "purpose": "To obtain detection with no false-positive budget, and to ensure that signal is acted on rather than queued.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the adversary is heard early and pays to move. *This control* — deception is emplaced, monitored, and alerts reach a human fast.", "discussion": "A deception element has a property no other detection has: nothing legitimate touches it, so an interaction is an incident with no triage burden and no false-positive budget. That property is destroyed by routing the alert into a queue triaged tomorrow, which is the ordinary failure and the reason the alert path is written into the control rather than left to detection engineering. The second requirement is placement: deception emplaced where an adversary would not look is decoration, and placement should follow the avenues enumerated under `KT-3` rather than convenience.", "activities": [ { "n": 1, "capability": 2, "text": "Emplace deception elements across designated terrain." }, { "n": 2, "capability": 2, "text": "Monitor every deception element for interaction." }, { "n": 3, "capability": 2, "text": "Raise an alert on interaction." }, { "n": 4, "capability": 3, "text": "Place deception along the avenues of approach enumerated under `KT-3` and adjacent to designated decisive points, rather than where placement is easiest." }, { "n": 5, "capability": 3, "text": "Define the period within which a deception alert must reach a human, derived from the decide segment measured under `TA-1`, with provenance per `GA4`." }, { "n": 6, "capability": 3, "text": "Ensure deception elements are indistinguishable from real ones to an adversary and identifiable to defenders, and record how each property is achieved." }, { "n": 7, "capability": 3, "text": "Ensure no legitimate process, scanner or inventory tool interacts with deception elements, so the no-false-positive property holds in practice." }, { "n": 8, "capability": 3, "text": "Extend deception across terrain layers — identity, data, network, endpoint — rather than a single layer, so it is present wherever movement occurs." }, { "n": 9, "capability": 4, "text": "Measure elapsed time from deception interaction to human response, against the defined period." }, { "n": 10, "capability": 4, "text": "Test emplacement by exercise: a red team given an objective should encounter deception, and an exercise in which none is encountered is a placement finding." }, { "n": 11, "capability": 5, "text": "Re-place deception from observed adversary movement and from engagements, rather than leaving an initial layout in place indefinitely." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "HT", "CTI" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — avenues of approach (`KT-3`); decisive points (`KT-1`); terrain\nclassification (`TM-2`); decide segment measurement (`TA-1`); threat courses of action.\n*Outputs* — deception emplacement record by terrain layer; interaction alerts and\nresponse times; placement findings from exercise; input to `TA-1` detect segment\nand `M5` technique evidencing.", "people_skills": "Deception design credible to an adversary. Alert path engineering. Coordination\nwith inventory and scanning owners to preserve the no-false-positive property.", "policies": "Emplacement standard by terrain layer. Alert path and response period with\nprovenance. Exclusion rules for legitimate tooling.", "culture": "", "services": "Deception elements across identity, data, network and endpoint terrain. Alerting\ninto a monitored path with defined response. Exclusion configuration for\nlegitimate tooling.", "metric_outcome": "elapsed time from deception interaction to human response.", "metric_performance": "terrain layers carrying emplaced deception, against those designated.", "evidence": "Emplacement record by terrain layer; interaction alerts with response times; exclusion configuration; exercise encounter records.", "assessment": "Examine emplacement against enumerated avenues; test that an interaction reaches a human within the defined period; test that no legitimate tooling interacts with deception elements; examine whether a recent exercise encountered deception.", "nist_800_53": [ "SC-26", "SC-30", "SI-4" ], "csf_2_0": [ "DE.CM-01", "DE.AE-02" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Deceive tactic", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Closes the Deceive tactic, which reverse coverage found at zero of D3FEND's seven despite M5 Ambush carrying thirteen techniques and being the dominant effort of Phase I. Alert-to-human period derived from the TA-1 decide segment: a deception alert routed to a queue triaged tomorrow discards the no-false-positive property that made it worth emplacing." } ] }, { "id": "TA-1", "family": "TA", "title": "Decision Loop Measurement", "control_statement": "The organization shall measure the elapsed time from detection through decision to containment, and shall record it each cycle.", "purpose": "To make the defender's tempo a measured quantity rather than an impression, so that the numerator of temporal advantage exists at all.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — our own speed is measured and recorded per cycle.", "discussion": "The loop has three segments and they fail differently. Detection latency is a tooling and coverage problem; decision latency is an authority problem; containment latency is an execution problem. Reporting only the total hides which one is binding, and in most programs the binding constraint is the middle segment — which no amount of detection investment will shorten. Measuring the segments separately is what makes the metric actionable rather than merely honest.", "activities": [ { "n": 1, "capability": 2, "text": "Record, for each incident, the timestamps of detection, decision and containment." }, { "n": 2, "capability": 2, "text": "Compute elapsed time across the full loop and record it for the cycle." }, { "n": 3, "capability": 2, "text": "Report the cycle figure into the Brief." }, { "n": 4, "capability": 3, "text": "Define each timestamp against an observable event, so \"decision\" means a recorded authorization rather than the moment someone formed a view." }, { "n": 5, "capability": 3, "text": "Measure and report the three segments separately — detect, decide, contain — so the binding constraint is visible. The decide segment is constituted by `EN-1` triage and `EN-4` escalation; attribute time between them, since a slow triage and an unreachable authority are different problems." }, { "n": 6, "capability": 3, "text": "Derive the cycle figure from a stated statistic (median, or a named percentile) rather than from a mean, which a single outlier distorts." }, { "n": 7, "capability": 3, "text": "Exclude no incident from the population without a recorded justification." }, { "n": 8, "capability": 4, "text": "Trend each segment independently across cycles and set a threshold on the segment that is binding rather than on the total." }, { "n": 9, "capability": 4, "text": "Measure the spread as well as the central figure; a stable median with a widening tail is a degrading capability that the median conceals." }, { "n": 10, "capability": 5, "text": "Attribute segment improvement to the specific change that produced it, so tempo investment is directed by evidence rather than by assumption." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "CTI", "HT" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — incident records; SOC case management timestamps; authorization\nrecords; containment action logs.\n*Outputs* — per-cycle loop measurement by segment; input to TA-3 threshold\ncomparison, TA-5 degradation assessment and CE-6 trend.", "people_skills": "Incident timeline reconstruction. Statistical literacy sufficient to choose and\ndefend a summary statistic. Willingness to publish an unflattering number.", "policies": "Timestamp definitions tied to observable events. Population inclusion rule and\nexclusion justification procedure. Statistic definition.", "culture": "", "services": "Case management with reliable timestamps at all three points. Authorization\nrecording. Reporting capable of segment-level breakdown.", "metric_outcome": "median detect-to-contain elapsed time for the cycle.", "metric_performance": "percentage of incidents with all three timestamps recorded.", "evidence": "Temporal advantage assessment; supporting incident timing records; segment breakdown.", "assessment": "Examine the derivation from incident data; test against a sample of recorded incidents; examine whether timestamp definitions have changed between cycles being compared.", "nist_800_53": [ "IR-4", "SI-4", "AU-6" ], "csf_2_0": [ "DE.AE-06", "RS.MA-01" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Detect, Evict tactics", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after EN: the decide segment is constituted by EN-1 triage and EN-4 escalation, and time should be attributed between them — a slow triage and an unreachable authority are different problems with different remedies." }, { "v": "4.1.0", "note": "MINOR. Requires segment-level measurement (detect / decide / contain) reported separately. The segments fail for different reasons and the binding constraint is usually decide latency, which no detection investment shortens. v3.0 reported the total only." } ] }, { "id": "TA-2", "family": "TA", "title": "Adversary Dwell Estimation", "control_statement": "The organization shall maintain a documented estimate of adversary dwell time relevant to its threat profile, with a stated basis.", "purpose": "To establish the denominator of temporal advantage with an explicit, challengeable basis, so the comparison the framework rests on can be argued with.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — the adversary's speed is estimated, sourced and current.", "discussion": "This is the framework's most epistemically exposed control, and it should be stated plainly rather than buried. An agency can measure its own decision loop directly; it almost never measures adversary dwell against itself, because dwell is observable only in the intrusions that were eventually found — which is a biased sample by construction, and biased toward the slow adversaries. The estimate is therefore imported from external reporting and adjusted, and the signature metric consequently rests half on measurement and half on a cited assumption. The *stated basis* requirement exists so that this is visible to anyone reading the result rather than concealed inside a ratio.", "activities": [ { "n": 1, "capability": 2, "text": "Record a dwell time estimate applicable to the agency's threat profile." }, { "n": 2, "capability": 2, "text": "Record the source of the estimate." }, { "n": 3, "capability": 2, "text": "Carry the estimate into the temporal advantage computation." }, { "n": 4, "capability": 3, "text": "Select sources matched to the agency's sector, size and adversary set rather than adopting a global industry median." }, { "n": 5, "capability": 3, "text": "State the known bias in the estimate explicitly — that dwell is observed only in discovered intrusions — so the figure is read as a bound rather than a fact." }, { "n": 6, "capability": 3, "text": "Adjust the imported figure against any locally observed dwell from the agency's own incidents, and record the adjustment." }, { "n": 7, "capability": 3, "text": "Review the estimate each cycle and on material change to the threat assessment." }, { "n": 8, "capability": 4, "text": "Record a confidence level against the estimate, consistent with CE-3, and carry that confidence through to the temporal advantage result." }, { "n": 9, "capability": 4, "text": "Track divergence between the imported estimate and locally observed dwell as evidence about which is wrong." }, { "n": 10, "capability": 5, "text": "Build a local dwell series from the reconstructions required by `EN-2`, and transition the estimate from imported to measured as the series matures." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "HT" ], "informed": [ "SOC", "TO", "GOV" ] }, "information_flows": "*Inputs* — sector and government threat reporting; information-sharing group\nproducts; locally reconstructed incident dwell (M10).\n*Outputs* — dwell estimate with basis and confidence; input to TA-3 threshold\ncomparison and to the Brief.", "people_skills": "Source evaluation. Ability to state a bias in one's own input. Confidence\nassignment consistent with the analytic standard in CE-3.", "policies": "Source selection criteria. Bias statement requirement. Adjustment and review\nprocedure.", "culture": "", "services": "Intelligence intake with source retention. Field for basis and confidence\nalongside the figure. Linkage into the advantage computation.", "metric_outcome": "currency of the dwell estimate in cycles since last review.", "metric_performance": "divergence between imported estimate and locally observed dwell.", "evidence": "Dwell estimate with cited basis, stated bias and confidence level.", "assessment": "Examine the source; interview the intelligence function on its applicability; test whether the estimate has been adjusted against local observation where local observation exists.", "nist_800_53": [ "RA-3", "PM-16" ], "csf_2_0": [ "ID.RA-02", "ID.RA-03" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Model tactic", "version": "4.1.1", "changes": [ { "v": "4.1.1", "note": "PATCH. Backfill after EN: the local dwell series is built from EN-2 reconstructions, which is now a control rather than an M10 intention." }, { "v": "4.1.0", "note": "MINOR. Requires explicit statement of the estimate's known bias: dwell is observable only in discovered intrusions, biasing the sample toward slow adversaries. The signature metric rests half on an imported figure and that should be visible in the result rather than concealed in the ratio." } ] }, { "id": "TA-3", "family": "TA", "title": "Temporal Advantage Threshold", "control_statement": "The organization shall define the minimum acceptable ratio of adversary dwell to defender decision loop, and shall treat a deficit as a reportable condition.", "purpose": "To convert the temporal advantage figure into a governed condition with an escalation consequence, so that being behind is a decision the organization has to make rather than a number it can note.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — a minimum ratio is approved in advance and a deficit escalates.", "discussion": "The sequencing requirement is what makes this control real. A threshold set after the first measurement will be set wherever the organization already passes, which produces a governed-looking metric that has never once reported a problem. Approving the threshold before the figure is known — or at minimum recording that it was approved after, and by whom — is the difference between a risk appetite and a post-hoc justification.", "activities": [ { "n": 1, "capability": 2, "text": "Define the minimum acceptable ratio of adversary dwell to defender loop." }, { "n": 2, "capability": 2, "text": "Compare the measured result to the threshold each cycle." }, { "n": 3, "capability": 2, "text": "Report the result as advantage or deficit." }, { "n": 4, "capability": 3, "text": "Obtain the accountable authority's approval of the threshold, recording the date of approval relative to the date of first measurement." }, { "n": 5, "capability": 3, "text": "Define the escalation path a deficit triggers, including who is informed and within what period." }, { "n": 6, "capability": 3, "text": "Carry the confidence level from TA-2 into the reported result, so a deficit at low confidence is distinguishable from one at high confidence." }, { "n": 7, "capability": 3, "text": "Re-approve the threshold on material change to the mission or threat picture, rather than treating it as permanent." }, { "n": 8, "capability": 4, "text": "Trend the result against the threshold across cycles and measure the duration of any sustained deficit." }, { "n": 9, "capability": 4, "text": "Test the escalation path on a recorded deficit rather than assuming it fires." }, { "n": 10, "capability": 5, "text": "Re-base the threshold against demonstrated containment outcomes — whether incidents at a given ratio were in fact contained before loss." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI", "SOC" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — loop measurement (TA-1); dwell estimate and confidence (TA-2);\nrisk appetite statement; defensive intent (CG-1).\n*Outputs* — approved threshold; per-cycle advantage or deficit result with\nconfidence; escalation record; input to CE-6 trend and the Brief.", "people_skills": "Risk appetite articulation. Ability to hold a threshold that the program\ncurrently fails.", "policies": "Threshold definition with approval record and date. Escalation procedure and\nperiod. Re-approval triggers.", "culture": "", "services": "Scoreboard computing the ratio with confidence. Threshold stored with approval\nmetadata. Escalation routing.", "metric_outcome": "measured ratio against approved threshold, with confidence.", "metric_performance": "elapsed time from recorded deficit to escalation.", "evidence": "Declared threshold with approval date; scoreboard result per cycle; escalation records.", "assessment": "Examine the threshold and its approval; test the escalation path on a recorded deficit; examine whether the threshold was approved before or after the first measurement.", "nist_800_53": [ "IR-4", "PM-6" ], "csf_2_0": [ "GV.RM-02", "GV.OV-03" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Records threshold approval date relative to first measurement, closing the post-hoc threshold problem. Generalised framework-wide as GA4." } ] }, { "id": "TA-4", "family": "TA", "title": "Pre-authorized Response", "control_statement": "Defensive actions that may be executed without escalation shall be defined in advance and approved by the accountable authority.", "purpose": "To remove authority latency from the decision loop, so that the segment most programs cannot shorten with tooling is shortened by governance.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — the actions that need no permission are settled before contact.", "discussion": "This is the highest-leverage control in the family and the cheapest to implement, because it costs no technology. TA-1's segment breakdown usually shows the decide segment dominating the loop, and decide latency is almost entirely the time spent locating someone with authority. Pre-authorization converts that from an incident-time search into a design-time decision. The constraint is that it must be genuinely bounded: an authority so broad that it permits degrading a public service without reference will not survive its first use, and one so narrow that every real action falls outside it changes nothing.", "activities": [ { "n": 1, "capability": 2, "text": "Define which defensive actions may be executed without escalation." }, { "n": 2, "capability": 2, "text": "Obtain the accountable authority's approval of that set." }, { "n": 3, "capability": 2, "text": "Link each pre-authorized action to the maneuvers it enables." }, { "n": 4, "capability": 3, "text": "Bound each authorization by condition, scope and duration, rather than by action type alone — \"revoke sessions for a confirmed compromised account\" is bounded; \"revoke sessions\" is not." }, { "n": 5, "capability": 3, "text": "Define the escalation matrix for actions outside the pre-authorized set, naming the authority and the reachable path to it at any hour." }, { "n": 6, "capability": 3, "text": "Key the pre-authorized set to campaign phase, so a declared Phase III widens what may be executed without reference." }, { "n": 7, "capability": 3, "text": "Rehearse the authority in exercise, confirming operators can state what they may do unaided." }, { "n": 8, "capability": 4, "text": "Measure the proportion of executed actions that fell inside the pre-authorized set, since a low proportion means the set is drawn in the wrong place." }, { "n": 9, "capability": 4, "text": "Measure decide-segment latency for pre-authorized versus escalated actions, so the control's contribution is quantified rather than assumed." }, { "n": 10, "capability": 5, "text": "Widen or narrow the set from observed use — actions repeatedly escalated and always approved are candidates for pre-authorization; actions pre-authorized and never used are candidates for removal." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "AO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT", "TO" ] }, "information_flows": "*Inputs* — maneuver catalog (SM-1); branches and sequels (SM-5); declared phase\n(CG-2); rules of engagement (CG-3); statutory availability floor (FO-5).\n*Outputs* — approved pre-authorization set with bounds; escalation matrix;\ninput to TA-1 decide-segment performance and to incident execution.", "people_skills": "Authority scoping. Legal and mission literacy sufficient to know which actions\ncarry statutory consequence. Exercise design.", "policies": "Approved rules of engagement. Escalation matrix with out-of-hours path.\nPhase-keyed authorization table. Rehearsal cadence.", "culture": "", "services": "Authorization record accessible at incident time. Phase-aware presentation of the\ncurrent set. Action logging against authorization.", "metric_outcome": "proportion of executed defensive actions falling inside the pre-authorized set.", "metric_performance": "decide-segment latency for pre-authorized versus escalated actions.", "evidence": "Approved rules of engagement with bounds; escalation matrix; rehearsal records; action logs referencing authorization.", "assessment": "Examine the approval; test that operators executed within authority during a recorded incident; interview operators on whether they believe the authority will be honored.", "nist_800_53": [ "IR-4(2)", "AC-2(13)", "IR-9" ], "csf_2_0": [ "RS.MA-01", "RS.MI-01", "GV.RR-01" ], "ztmm": "cross-cutting Automation and Orchestration", "d3fend": "Isolate, Evict tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added RS.MI-01 to the CSF mapping; pre-authorized containment genuinely supports the Respond/Mitigate outcome. First deliberate step against the Detect/Respond thinness identified in the v3.0 catalog analysis. Authorizations now bounded by condition, scope and duration, and keyed to campaign phase." } ] }, { "id": "TA-5", "family": "TA", "title": "Tempo Degradation Trigger", "control_statement": "Conditions under which the defender decision loop is expected to degrade shall be identified, with compensating measures defined.", "purpose": "To plan for the periods in which tempo predictably falls, so that the measured advantage is not a statement about the organization's best hours only.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — predictable tempo loss is anticipated and compensated.", "discussion": "Tempo is not a constant, and its degradation is not random. Nights, weekends, federal holidays, shift handovers, key-person absence, hiring gaps, contract transitions and major change windows all reduce the loop — and adversaries select those windows deliberately. A temporal advantage figure computed across a cycle averages over these conditions and therefore overstates the position at exactly the moments contact is most likely. This control exists so the average is not mistaken for the floor.", "activities": [ { "n": 1, "capability": 2, "text": "Identify the conditions under which the decision loop is expected to degrade." }, { "n": 2, "capability": 2, "text": "Define a compensating measure for each condition." }, { "n": 3, "capability": 2, "text": "Record both alongside the tempo measurement." }, { "n": 4, "capability": 3, "text": "Include organizational conditions as well as operational ones — contract transition, key-person absence, hiring gaps and handover windows, not only nights and weekends." }, { "n": 5, "capability": 3, "text": "Estimate the expected degradation per condition, so compensation can be sized rather than gestured at." }, { "n": 6, "capability": 3, "text": "Assign an owner to each compensating measure and confirm it is available during the condition it compensates for." }, { "n": 7, "capability": 3, "text": "Report tempo at the degraded condition as well as in aggregate, so the floor is visible next to the average." }, { "n": 8, "capability": 4, "text": "Measure actual loop performance during degraded conditions against the estimate, and correct the estimate where it was optimistic." }, { "n": 9, "capability": 4, "text": "Correlate incident timing against degraded windows, since adversary selection of those windows is itself a measurable finding." }, { "n": 10, "capability": 5, "text": "Redesign staffing, automation or authority scope to remove the degradation condition rather than compensating for it indefinitely." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "GOV", "TO" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — loop measurement by segment (TA-1); staffing and roster records;\nchange calendar; contract and personnel transition schedule.\n*Outputs* — degradation register with compensating measures and owners; degraded\ntempo figure; input to TA-3 threshold assessment and CP continuity planning.", "people_skills": "Workforce and roster planning. Ability to estimate capability loss rather than\nmerely note absence. Correlation analysis across incident and calendar data.", "policies": "Degradation register schema. Compensating measure standard with ownership.\nReporting requirement for degraded-condition tempo.", "culture": "", "services": "Roster and calendar integration. Tempo measurement segmentable by condition.\nAutomation available specifically during degraded windows.", "metric_outcome": "measured loop performance during degraded conditions against the aggregate figure.", "metric_performance": "percentage of identified conditions with an owned, available compensating measure.", "evidence": "Degradation register with compensating measures and owners; degraded-condition tempo figures; incident-timing correlation.", "assessment": "Examine the register; interview operations on a recent period of degraded capacity; test whether the compensating measure was in fact available during it.", "nist_800_53": [ "IR-4", "CP-2", "PS-2" ], "csf_2_0": [ "RS.MA-01", "ID.IM-01" ], "ztmm": "cross-cutting Automation and Orchestration", "d3fend": "N/A (operational layer — no countermeasure equivalent)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Degradation conditions widened to organizational causes: contract transition, key-person absence, hiring gaps, handover windows. v3.0 read as out-of-hours coverage only. Added incident-timing correlation against degraded windows." } ] }, { "id": "CE-1", "family": "CE", "title": "Cycle Cadence", "control_statement": "The organization shall execute the full analytic cycle at a defined cadence and shall not allow the interval to lapse without recorded justification.", "purpose": "To keep the loop turning, so that defensive posture is a maintained position rather than a periodic assessment.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the loop turns faster than the adversary adapts. *This control* — the cycle runs at cadence and lapses are visible.", "discussion": "The cycle is the first thing sacrificed when the SOC is busy, and the SOC is busy precisely when the cycle would be most valuable. That inversion is the failure mode this control exists to catch. A lapse is also invisible by default — nothing alerts when a cadence quietly stretches from monthly to quarterly, and a program can discover it only by looking at dates it has no reason to look at. Requiring a recorded justification makes the lapse an event rather than an absence.", "activities": [ { "n": 1, "capability": 2, "text": "Execute the full analytic cycle and record its date and phase." }, { "n": 2, "capability": 2, "text": "Define the cadence at which the cycle is expected to run." }, { "n": 3, "capability": 2, "text": "Maintain a cycle history from which the interval can be read." }, { "n": 4, "capability": 3, "text": "State the rationale for the interval, so it can be challenged rather than inherited." }, { "n": 5, "capability": 3, "text": "Record a justification for any interval that exceeds the cadence, naming who accepted the lapse." }, { "n": 6, "capability": 3, "text": "Define which steps of the cycle may be abbreviated under load and which may not, so pressure produces a known degradation rather than an ad hoc one." }, { "n": 7, "capability": 3, "text": "Separate cycle execution ownership from incident response ownership where staffing permits, so the two do not compete for the same people." }, { "n": 8, "capability": 4, "text": "Trend the actual interval against the defined cadence and escalate a sustained overrun rather than a single one." }, { "n": 9, "capability": 4, "text": "Correlate lapses against incident load, since a cadence that holds only in quiet periods is not a cadence." }, { "n": 10, "capability": 5, "text": "Adjust the cadence from measured estimate drift — if the terrain and threat picture move faster than the interval assumes, the interval is wrong." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "SOC", "GOV" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — cycle calendar; prior cycle record; incident load data; terrain\ncurrency status (TM-6).\n*Outputs* — cycle history with dates, phases and justified lapses; input to CE-6\ntrend and CE-7 Brief.", "people_skills": "Analytic process discipline. Ability to run a cycle to completion under\ncompeting operational demand.", "policies": "Cadence definition with rationale. Lapse justification procedure. Abbreviation\nrules under load.", "culture": "", "services": "Cycle recording with dates and phase. History view exposing intervals. Alerting\non cadence overrun.", "metric_outcome": "percentage of intervals meeting the defined cadence.", "metric_performance": "median interval between completed cycles.", "evidence": "Cycle history with dates and phase; lapse justifications with named acceptor.", "assessment": "Examine cycle records against the defined cadence; examine whether lapses cluster against periods of high incident load.", "nist_800_53": [ "CA-7", "PM-31" ], "csf_2_0": [ "ID.IM-03", "GV.OV-01" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added definition of which cycle steps may be abbreviated under load, and correlation of lapses against incident volume. The cycle is sacrificed exactly when it is most needed, and a cadence holding only in quiet periods is not a cadence." } ] }, { "id": "CE-2", "family": "CE", "title": "Priority Intelligence Requirements", "control_statement": "Each cycle shall begin with a defined set of priority intelligence requirements that drive collection and hunting.", "purpose": "To direct analytic effort at named questions, so that collection and hunting answer what the accountable authority needs rather than processing what arrives.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — analysis is directed, not reactive. *This control* — the cycle's questions are stated in advance and tracked to answer.", "discussion": "Hunting without a requirement is sampling, and sampling an estate of federal scale returns whatever the analyst already expected to find. The tracking requirement is what separates this from a wish list: requirements that are recorded, never answered, and silently carried forward for four cycles describe an intelligence function that is busy rather than one that is directed. A requirement should close — as answered, as no longer relevant, or as unanswerable with current collection, which is itself a finding about visibility.", "activities": [ { "n": 1, "capability": 2, "text": "Define the priority intelligence requirements for the cycle before collection begins." }, { "n": 2, "capability": 2, "text": "Record each requirement with a status of open, watching or answered." }, { "n": 3, "capability": 2, "text": "Direct collection and hunting activity against the open requirements." }, { "n": 4, "capability": 3, "text": "Derive requirements from the defensive intent (CG-1), the declared phase (CG-2) and the current threat courses of action, rather than from analyst preference." }, { "n": 5, "capability": 3, "text": "State for each requirement what an answer would look like, so it can be recognized when obtained." }, { "n": 6, "capability": 3, "text": "Close requirements explicitly, including closure as unanswerable with current collection — which is raised as a visibility finding rather than dropped." }, { "n": 7, "capability": 3, "text": "Carry unanswered requirements forward with a recorded reason rather than by default." }, { "n": 8, "capability": 4, "text": "Measure the proportion of requirements answered per cycle and the age of the oldest open requirement." }, { "n": 9, "capability": 4, "text": "Measure the proportion of hunting effort attributable to a named requirement, since unattributed effort is sampling." }, { "n": 10, "capability": 5, "text": "Revise the requirement-setting method where answered requirements repeatedly fail to change any decision, since a requirement that changes nothing was the wrong question." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "HT", "SOC" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — defensive intent (CG-1); declared phase (CG-2); threat courses of\naction; prior cycle open requirements; visibility gaps.\n*Outputs* — requirement register with status; collection and hunting direction;\nvisibility findings; input to M10 requirement revision and CE-7 Brief.", "people_skills": "Requirement formulation. Ability to state an answerable question. Discipline to\nclose a requirement as unanswerable rather than leaving it open indefinitely.", "policies": "Requirement derivation procedure. Status definitions and closure rules. Escalation\nof unanswerable requirements as visibility findings.", "culture": "", "services": "Requirement register with status tracking. Linkage from requirement to the\ncollection and hunting activity addressing it.", "metric_outcome": "percentage of cycle requirements closed with a recorded disposition.", "metric_performance": "percentage of hunting effort attributable to a named requirement.", "evidence": "Intelligence requirement register with status and closure dispositions; visibility findings raised from unanswerable requirements.", "assessment": "Examine the register; test that collection or hunting activity addressed a sample of open requirements; examine the age of the oldest open item.", "nist_800_53": [ "PM-16", "RA-10", "SI-5" ], "csf_2_0": [ "ID.RA-02", "DE.AE-07" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Model, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added closure as 'unanswerable with current collection', raised as a visibility finding. Converts a perpetually open requirement into a finding about collection rather than an item carried forward indefinitely." } ] }, { "id": "CE-3", "family": "CE", "title": "Fusion and Confidence", "control_statement": "Analytic conclusions shall be recorded with an explicit confidence level and the basis for that confidence.", "purpose": "To distinguish assessment from assertion, so that decisions taken on analytic conclusions carry the uncertainty of those conclusions with them.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — decisions reflect what is actually known. *This control* — every conclusion states how sure it is and why.", "discussion": "Confidence is what makes an analytic product falsifiable. A conclusion offered without it cannot be wrong in any useful sense, because it never committed to a degree of belief. The scale also has to be usable in both directions: if every product is issued at high confidence, the scale conveys no information and the field is decorative. An analytic function that has never published a low-confidence assessment on a significant question is not being careful, it is being unfalsifiable.", "activities": [ { "n": 1, "capability": 2, "text": "Record a confidence level against each analytic conclusion." }, { "n": 2, "capability": 2, "text": "Record the basis on which that confidence rests." }, { "n": 3, "capability": 2, "text": "Carry confidence into the products the conclusion feeds." }, { "n": 4, "capability": 3, "text": "Define the confidence scale and what distinguishes adjacent levels, so it is applied consistently between analysts." }, { "n": 5, "capability": 3, "text": "Apply structured analytic techniques to significant conclusions and record which were used." }, { "n": 6, "capability": 3, "text": "State the key assumptions a conclusion depends on, so a change in assumption can be traced to the conclusions it invalidates." }, { "n": 7, "capability": 3, "text": "Carry confidence through to derived figures — notably the temporal advantage result (TA-3) — rather than dropping it at the first computation." }, { "n": 8, "capability": 4, "text": "Measure the distribution of confidence levels issued; a distribution concentrated at high confidence indicates the scale is not being used." }, { "n": 9, "capability": 4, "text": "Review past conclusions against subsequent evidence and measure calibration — whether high-confidence assessments were in fact more often right." }, { "n": 10, "capability": 5, "text": "Adjust analytic practice from measured calibration error rather than from reviewer preference." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "HT" ], "informed": [ "SOC", "TO", "GOV" ] }, "information_flows": "*Inputs* — collection results; hunting output; incident findings; threat\nreporting.\n*Outputs* — conclusions with confidence and basis; key assumption register;\ninput to TA-2, TA-3, CE-4 and the Brief.", "people_skills": "Structured analytic technique proficiency. Calibration awareness. Willingness to\npublish low confidence on a question leadership wants settled.", "policies": "Confidence scale definition. Structured technique requirement for significant\nconclusions. Key assumption recording.", "culture": "", "services": "Product templates carrying confidence and basis fields. Assumption register.\nCalibration review record.", "metric_outcome": "percentage of conclusions carrying an explicit confidence and basis.", "metric_performance": "calibration error measured against subsequent evidence.", "evidence": "Findings with stated confidence and basis; structured technique records; assumption register.", "assessment": "Examine a sample of conclusions for stated confidence and basis; interview analysts on the scale used; examine the distribution of confidence levels issued across recent cycles.", "nist_800_53": [ "RA-3", "SI-4(16)", "PM-16" ], "csf_2_0": [ "DE.AE-02", "DE.AE-03", "ID.RA-05" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Detect, Model tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Added measurement of the distribution of issued confidence levels and calibration review against subsequent evidence. A function that never publishes low confidence is unfalsifiable rather than careful." } ] }, { "id": "CE-4", "family": "CE", "title": "Coverage and Residual Risk Computation", "control_statement": "Defensive coverage and residual risk shall be computed from asset weighting, layer maturity, and operational move mitigation, using a documented method.", "purpose": "To produce a posture figure that can be reproduced and challenged rather than asserted, so that the number carries authority beyond the tool that generated it.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — posture claims are true. *This control* — the figure is computed by a stated method from recorded inputs.", "discussion": "The denominator determines the answer, and the choice of denominator is a judgment that must be published rather than embedded. Counting techniques evidenced rewards tagging a crowded intersection over a sparse one for identical effort; counting ground held — terrain × form cells occupied — does not, which is why the framework scores that way. But the reasoning is only defensible if it is stated where the figure appears. A coverage percentage whose denominator is undisclosed is not a measurement, and an adopter who cannot reproduce it cannot argue with it.", "activities": [ { "n": 1, "capability": 2, "text": "Compute defensive coverage from asset weighting, layer maturity and operational move mitigation." }, { "n": 2, "capability": 2, "text": "Compute residual risk from the same inputs." }, { "n": 3, "capability": 2, "text": "Report both figures for the cycle." }, { "n": 4, "capability": 3, "text": "Document the method in sufficient detail that an assessor can recompute the figure from the recorded inputs without access to the tool." }, { "n": 5, "capability": 3, "text": "State the denominator explicitly wherever the figure is published, including the choice between ground held and techniques evidenced and the reason for it." }, { "n": 6, "capability": 3, "text": "Weight mitigation by implementation state (SM-3), so planned and partial moves do not count in full." }, { "n": 7, "capability": 3, "text": "Record the framework version against every computed figure, since a change in the framework's shape changes the denominator." }, { "n": 8, "capability": 4, "text": "Recompute at least one prior cycle's figure from its recorded inputs each cycle, confirming the method is stable and the inputs were preserved." }, { "n": 9, "capability": 4, "text": "Measure the sensitivity of the figure to its most uncertain input, so the reported precision does not exceed the underlying certainty." }, { "n": 10, "capability": 5, "text": "Revise the method where sensitivity analysis shows the figure is dominated by an input the organization cannot measure well." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI", "TO" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — asset weighting (TM-3); layer classification (TM-2); implementation\nstates (SM-3); validated effectiveness weightings (SM-6); framework version.\n*Outputs* — coverage and residual risk figures with method and denominator;\nsensitivity result; input to CE-5 backlog, CE-6 trend and the Brief.", "people_skills": "Quantitative method documentation. Sensitivity analysis. Ability to state a\nfigure's limits alongside the figure.", "policies": "Documented computation method. Denominator disclosure requirement. Version\nrecording rule. Recomputation procedure.", "culture": "", "services": "Posture computation with retained inputs. Version stamping. Recomputation\ncapability against historical inputs.", "metric_outcome": "coverage and residual risk for the cycle, with denominator stated.", "metric_performance": "percentage of prior-cycle figures reproducible from retained inputs.", "evidence": "Posture computation in the Brief; documented method with denominator; retained inputs; recomputation record.", "assessment": "Examine the method; test the computation by recomputing from source inputs; examine whether the framework version is recorded against each figure.", "nist_800_53": [ "RA-3", "CA-2", "PM-9" ], "csf_2_0": [ "ID.RA-05", "GV.RM-02" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires the denominator to be stated wherever the figure is published, including the ground-held versus techniques-evidenced choice and its rationale; requires framework version recorded against every computed figure; adds sensitivity analysis against the most uncertain input." } ] }, { "id": "CE-5", "family": "CE", "title": "Remediation Backlog Prioritization", "control_statement": "Identified gaps shall be ranked by the residual risk they retire per unit of effort, and shall be assigned owners and target dates.", "purpose": "To make the backlog answer where the next hour of work goes, rather than enumerate everything wrong.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — effort is spent where it retires most risk. *This control* — the backlog is ranked by risk retired per unit effort and owned.", "discussion": "Ranking by risk alone produces a backlog headed by items nobody can afford; ranking by effort alone produces a quarter of completed busywork with the risk position unchanged. The ratio is the whole point, and it is also the part most often dropped in implementation, because effort estimates are uncomfortable to produce and easy to omit. A backlog with risk scores and no effort estimates has not implemented this control.", "activities": [ { "n": 1, "capability": 2, "text": "Record identified gaps as a backlog." }, { "n": 2, "capability": 2, "text": "Estimate the residual risk each gap retires if closed." }, { "n": 3, "capability": 2, "text": "Assign an owner and a target date to each item." }, { "n": 4, "capability": 3, "text": "Estimate the effort each item requires, on a defined scale, so the ratio can be computed rather than intuited." }, { "n": 5, "capability": 3, "text": "Rank by risk retired per unit of effort and publish the ranking basis." }, { "n": 6, "capability": 3, "text": "Reconcile ownership against terrain ownership (TM-7), so backlog items land on people who already hold the ground." }, { "n": 7, "capability": 3, "text": "Re-rank each cycle from current figures rather than preserving a stale order." }, { "n": 8, "capability": 4, "text": "Measure realized risk retirement against estimate for completed items, and correct the estimation method where it is systematically optimistic." }, { "n": 9, "capability": 4, "text": "Trend backlog age by rank band; high-ranked items ageing indicates the ranking is not driving allocation." }, { "n": 10, "capability": 5, "text": "Feed completion data back into effort estimation, so the ratio improves in accuracy as the program accumulates history." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — findings from all controls; posture computation (CE-4); asset\nweighting (TM-3); ownership register (TM-7); main effort (SM-4).\n*Outputs* — ranked backlog with owners, target dates and ranking basis; input to\nCG-4 disposition and the Brief.", "people_skills": "Effort estimation. Risk quantification consistent with CE-4. Negotiation with\nowners over target dates.", "policies": "Effort scale definition. Ranking basis documentation. Re-ranking cadence.\nOwnership reconciliation rule.", "culture": "", "services": "Backlog with risk and effort fields and computed ratio. Automatic ranking.\nOwnership linkage.", "metric_outcome": "residual risk retired per cycle.", "metric_performance": "median age of items in the top rank band.", "evidence": "Ranked backlog with owners, target dates, effort estimates and ranking basis.", "assessment": "Examine the ranking basis; test progress against target dates; examine whether effort estimates exist at all for the top-ranked items.", "nist_800_53": [ "CA-5", "RA-7", "PM-4" ], "csf_2_0": [ "ID.RA-06", "ID.IM-02", "GV.RM-06" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (planning layer — no countermeasure equivalent)", "version": "4.1.1", "changes": [ { "v": "4.1.1", "note": "PATCH. CSF recovery: adds GV.RM-06 (risk response prioritization) — CE-5 ranks by risk retired per unit effort." }, { "v": "4.1.0", "note": "MINOR. Requires effort estimates on a defined scale so the risk-per-effort ratio can be computed rather than intuited. A backlog with risk scores and no effort estimates has not implemented this control." } ] }, { "id": "CE-6", "family": "CE", "title": "Cycle Record and Trend", "control_statement": "Each cycle shall be recorded with its posture result, and the trend across cycles shall be reported.", "purpose": "To answer whether the program is improving — a question no point-in-time assessment can address.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the position improves over time. *This control* — the series exists, is preserved and is interpretable.", "discussion": "A trend is only interpretable if the denominator did not change between its points, and the framework's own versioning rules make this concrete: a structural change adds or removes a form, a terrain layer or a phase, and every coverage score computed against the prior version becomes incomparable. A series that silently spans a version boundary is not a trend, it is two trends drawn as one — and it will show improvement or decline that is an artifact of the denominator rather than of the estate. Recording the framework version against each point is what makes the series honest.", "activities": [ { "n": 1, "capability": 2, "text": "Record each cycle's posture result." }, { "n": 2, "capability": 2, "text": "Report the change since the prior cycle." }, { "n": 3, "capability": 2, "text": "Preserve the series rather than overwriting the current position." }, { "n": 4, "capability": 3, "text": "Record the framework version against every point in the series." }, { "n": 5, "capability": 3, "text": "Break the trend line visibly at any version boundary that changed the denominator, rather than plotting across it." }, { "n": 6, "capability": 3, "text": "Preserve the inputs to each figure, not only the figure, so a point can be recomputed under CE-4." }, { "n": 7, "capability": 3, "text": "Record alongside each point the material events of that cycle — incidents, architectural changes, staffing changes — so a movement can be attributed." }, { "n": 8, "capability": 4, "text": "Distinguish movement caused by estate change from movement caused by measurement change, and report the two separately." }, { "n": 9, "capability": 4, "text": "Measure the proportion of cycle-over-cycle movement that can be attributed to a recorded cause." }, { "n": 10, "capability": 5, "text": "Use the series to test the framework's own assumptions — a weighting that never moves the aggregate is a weighting carrying no information." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI" ], "informed": [ "SOC", "TO", "HT" ] }, "information_flows": "*Inputs* — posture computation per cycle (CE-4); cycle history (CE-1); framework\nversion; material event log.\n*Outputs* — preserved posture series with version stamps and attribution; trend\nreport; input to CE-7 Brief and to external assurance.", "people_skills": "Time-series interpretation. Discipline to preserve inputs rather than results\nalone. Ability to distinguish measurement artifact from real movement.", "policies": "Series retention standard. Version boundary rule. Attribution recording\nrequirement.", "culture": "", "services": "Cycle history with retained inputs and version stamps. Trend rendering with\nversion-boundary breaks. Event log linkage.", "metric_outcome": "direction and magnitude of posture movement across the current series.", "metric_performance": "percentage of movement attributable to a recorded cause.", "evidence": "Cycle history table; movement-over-time section of the Brief; version stamps; attribution records.", "assessment": "Examine the series for completeness; test two entries against their source computations; examine whether any version boundary is plotted across without a break.", "nist_800_53": [ "CA-7(3)", "AU-6", "PM-31" ], "csf_2_0": [ "ID.IM-03", "GV.OV-01" ], "ztmm": "maturity vector per pillar per quarter", "d3fend": "N/A (assurance layer — no countermeasure equivalent)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR, correctness-critical. Requires the framework version against every point and a visible break in the trend line at any version boundary. The framework's own versioning rules make cross-version coverage scores incomparable; a series plotted across a boundary shows movement that is a denominator artifact. Two structural releases have already occurred, so existing multi-cycle series in the field are likely affected." } ] }, { "id": "CE-7", "family": "CE", "title": "Brief Generation and Distribution", "control_statement": "Each cycle shall produce a brief recording terrain, decisive points, scheme of maneuver, posture, findings, and trend, distributed to the accountable authority.", "purpose": "To produce one document per cycle that an Authorizing Official can decide from, rather than a dashboard nobody decides from.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the accountable authority can direct from what they are given. *This control* — a decision-grade cycle record is produced and reaches them.", "discussion": "Generation and distribution are the easy halves; use is the control's actual object. A Brief that is produced, distributed and never decided from satisfies every literal reading of the requirement and delivers nothing, which is why the assessment interviews recipients rather than examining distribution lists. The Brief is also the framework's compliance exhaust: because each section cites the controls it evidences, a retained series of Briefs is the FISMA continuous-monitoring record, produced as a by-product of defending.", "activities": [ { "n": 1, "capability": 2, "text": "Generate a Brief each cycle covering terrain, decisive points, scheme of maneuver, posture, findings and trend." }, { "n": 2, "capability": 2, "text": "Distribute it to the accountable authority." }, { "n": 3, "capability": 2, "text": "Retain it as the cycle record." }, { "n": 4, "capability": 3, "text": "Cite in each section the controls it evidences, so the Brief serves as assessment evidence without separate authoring." }, { "n": 5, "capability": 3, "text": "Head the Brief with the defensive intent (CG-1) and the declared phase (CG-2), so posture is read against stated purpose." }, { "n": 6, "capability": 3, "text": "State confidence on assessments carried into the Brief, consistent with CE-3." }, { "n": 7, "capability": 3, "text": "Record the decisions taken from each Brief, so use is evidenced rather than assumed." }, { "n": 8, "capability": 4, "text": "Measure the proportion of Briefs from which a recorded decision followed." }, { "n": 9, "capability": 4, "text": "Measure elapsed time from cycle completion to distribution, since a Brief arriving after the situation has moved is a historical document." }, { "n": 10, "capability": 5, "text": "Revise Brief content from what recipients actually decided from, removing sections that have never informed a decision." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "CTI" ], "consulted": [ "GOV", "SOC" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — every preceding control's output; defensive intent (CG-1); phase\n(CG-2); posture (CE-4); backlog (CE-5); trend (CE-6).\n*Outputs* — dated, retained Brief with control citations; decision record; input\nto FISMA continuous monitoring evidence and to the next cycle's FRAME step.", "people_skills": "Executive written communication. Ability to compress a cycle into a decision\ndocument. Judgment about what a accountable authority needs versus what is available.", "policies": "Brief template with required sections and control citations. Distribution list\nand retention standard. Decision recording procedure.", "culture": "", "services": "Brief generation from the cycle record. Control citation linkage. Retention with\ndating. Decision log.", "metric_outcome": "percentage of Briefs from which a recorded decision followed.", "metric_performance": "elapsed time from cycle completion to distribution.", "evidence": "Generated Briefs, dated and retained, with control citations; decision records.", "assessment": "Examine retained briefs; interview recipients on receipt and use; test whether a decision is recorded against a sample of Briefs.", "nist_800_53": [ "CA-7", "PM-31", "PL-2" ], "csf_2_0": [ "GV.OV-01", "ID.IM-03" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (assurance layer — no countermeasure equivalent)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires decisions taken from each Brief to be recorded, so use is evidenced rather than assumed. Generation and distribution satisfy the literal requirement while delivering nothing." } ] }, { "id": "CG-1", "family": "CG", "title": "Defensive Intent", "control_statement": "The accountable authority shall issue a defensive intent stating the end-state to be protected and the risk that is acceptable, expressed in plain language.", "purpose": "To give subordinate decisions a reference point, so that people can act correctly without referring upward.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the accountable authority's purpose is known to those executing it. *This control* — that purpose is stated, approved and usable unaided.", "discussion": "The test of an intent is operational, not literary: can someone two levels down, at three in the morning, make a decision from it without calling? Most published intents fail that test because they state aspiration rather than acceptable risk. \"Protect mission-transaction integrity and sensitive records; degrade gracefully, never fail open\" tells an operator what to trade when they must trade something. A statement that lists everything as important tells them nothing, and they will escalate — which is the decide-segment latency TA-1 measures.", "activities": [ { "n": 1, "capability": 2, "text": "Issue a defensive intent stating the end-state to be protected." }, { "n": 2, "capability": 2, "text": "State the risk that is acceptable in pursuit of it." }, { "n": 3, "capability": 2, "text": "Publish the intent where those executing it can reach it." }, { "n": 4, "capability": 3, "text": "Express the intent in plain language, without technology or product terms, so it survives re-tooling and is legible to mission staff." }, { "n": 5, "capability": 3, "text": "State explicitly what may be traded and in what order, since an intent that subordinates nothing cannot resolve a conflict." }, { "n": 6, "capability": 3, "text": "Obtain the accountable authority's signature and record the date." }, { "n": 7, "capability": 3, "text": "Head every generated Brief with the current intent, so posture is always read against purpose." }, { "n": 8, "capability": 4, "text": "Test comprehension by interviewing operators on a decision the intent should resolve, and measure whether they resolve it consistently." }, { "n": 9, "capability": 4, "text": "Review the intent on material change to mission or threat, and record the review even where no change results." }, { "n": 10, "capability": 5, "text": "Revise the intent where recorded escalations show a recurring decision the intent does not resolve." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "AO" ], "consulted": [ "GOV", "CTI" ], "informed": [ "SOC", "TO", "HT" ] }, "information_flows": "*Inputs* — mission objectives; enterprise risk appetite; statutory obligations\n(FO-5); threat assessment.\n*Outputs* — signed defensive intent; input to CE-2 requirement derivation, SM-4\nmain effort, CG-3 rules of engagement and every Brief.", "people_skills": "Command articulation. Ability to state acceptable loss. Plain-language writing\nunder conditions where hedging is the safer instinct.", "policies": "Intent authoring and approval procedure. Publication standard. Review triggers.", "culture": "", "services": "Intent published where operators work, not only in a governance repository.\nAutomatic inclusion in the Brief header.", "metric_outcome": "consistency of operator decisions on a test case the intent should resolve.", "metric_performance": "currency of the intent in cycles since last review.", "evidence": "Signed intent statement with date; publication record; comprehension test results.", "assessment": "Examine the statement and its approval; interview operators on whether they can act on it unaided; test comprehension against a decision the intent should resolve.", "nist_800_53": [ "PM-1", "PL-1", "PM-29" ], "csf_2_0": [ "GV.OC-01", "GV.PO-01" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires the intent to state what may be traded and in what order. An intent that subordinates nothing cannot resolve the decision it exists for, and the operator escalates, which is the decide latency TA-1 measures. Added comprehension testing against a decision the intent should resolve." } ] }, { "id": "CG-2", "family": "CG", "title": "Phase Declaration", "control_statement": "The organization shall declare its current campaign phase, and shall align main effort and resourcing to it.", "purpose": "To make \"we are in Phase III\" a sentence that changes behavior, rather than a label applied to a state of affairs.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the defense is fought as a campaign. *This control* — the phase is declared and materially changes what happens.", "discussion": "Phase declaration shares a failure mode with main effort designation: both are trivially satisfiable as labels and both are meaningless unless something downstream is keyed to them. The framework's design keys real consequences to phase — pre-authorized response sets widen (TA-4), session lifetimes shorten, dominant forms change, and resourcing shifts. If none of those change on transition, the declaration is a status field. The assessment therefore tests what changed, not what was declared.", "activities": [ { "n": 1, "capability": 2, "text": "Declare the current campaign phase." }, { "n": 2, "capability": 2, "text": "Record the declaration with its date and the condition that triggered it." }, { "n": 3, "capability": 2, "text": "Score readiness against the phase's dominant forms." }, { "n": 4, "capability": 3, "text": "Define the entry and exit conditions for each phase, so transition is a recognizable event rather than a judgment call, and bind them to the declaration criteria under `EN-1` so a declared incident meeting a phase entry condition routes to the transition decision rather than being handled locally." }, { "n": 5, "capability": 3, "text": "Key at least one consequential control to phase — pre-authorized response, session lifetime, or cadence — so declaration changes behavior." }, { "n": 6, "capability": 3, "text": "Align main effort (SM-4) and resourcing to the declared phase on transition." }, { "n": 7, "capability": 3, "text": "Communicate transition to everyone whose authority or task changes as a result." }, { "n": 8, "capability": 4, "text": "Measure what actually changed on the last transition — authorizations, allocations, configurations — and treat an empty answer as a finding." }, { "n": 9, "capability": 4, "text": "Trend time spent in each phase; a program permanently in Phase 0 has not implemented phasing." }, { "n": 10, "capability": 5, "text": "Revise phase entry conditions where transitions were repeatedly declared late relative to when contact began." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "AO" ], "consulted": [ "CTI", "SOC", "GOV" ], "informed": [ "TO", "HT" ] }, "information_flows": "*Inputs* — threat assessment; incident status; defensive intent (CG-1); campaign\nmodel.\n*Outputs* — phase declaration with trigger and date; readiness score; input to\nSM-4 main effort, TA-4 authorization set and the Brief.", "people_skills": "Campaign judgment. Ability to recognize a transition condition. Communication\nreach across every function whose task changes.", "policies": "Phase entry and exit condition definitions. Transition communication procedure.\nPhase-keyed control register.", "culture": "", "services": "Phase declaration surface visible to operators. Phase-aware presentation of\nauthorizations and configurations. Readiness scoring.", "metric_outcome": "number of consequential controls whose state changed on last transition.", "metric_performance": "elapsed time from transition condition to declaration.", "evidence": "Declared phase with trigger and date; phase readiness score; record of what changed on transition.", "assessment": "Examine the declaration and readiness score; interview on resourcing alignment; test what materially changed at the last transition.", "nist_800_53": [ "PM-11", "IR-4", "CP-2" ], "csf_2_0": [ "GV.RM-01", "ID.IM-01" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (campaign layer — no countermeasure equivalent)", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after EN-1: phase entry conditions bound to declaration criteria, so a declared incident meeting a phase entry condition routes to the transition decision rather than being handled locally." }, { "v": "4.1.0", "note": "MINOR. Requires at least one consequential control to be keyed to phase, and the assessment now tests what materially changed at the last transition rather than that a declaration exists." } ] }, { "id": "CG-3", "family": "CG", "title": "Rules of Engagement", "control_statement": "The organization shall maintain approved rules of engagement defining which defensive actions may be executed at which authority level.", "purpose": "To let operators act inside a known mandate rather than guessing at one, and to make the boundaries of that mandate legally and operationally sound.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — action is taken within authority. *This control* — the mandate is written, approved, current and reachable.", "discussion": "Rules of engagement carry a constraint the rest of the framework does not: some defensive actions have statutory consequences. Degrading a public service where a statute sets a deadline, or acting on a system holding regulated records, is not purely a security decision. The ROE is where those limits are recorded, and it is also where the framework's boundary sits — nothing in ASOM-Fed contemplates action outside the agency's own terrain, and the ROE should say so explicitly rather than leaving it to inference from doctrine.", "activities": [ { "n": 1, "capability": 2, "text": "Define which defensive actions may be executed at which authority level." }, { "n": 2, "capability": 2, "text": "Obtain approval from the accountable authority." }, { "n": 3, "capability": 2, "text": "Link the rules to the maneuvers and pre-authorized actions they govern." }, { "n": 4, "capability": 3, "text": "Record the statutory and regulatory constraints bounding specific actions, referencing the availability floors under FO-5 where they apply." }, { "n": 5, "capability": 3, "text": "State explicitly that no action extends outside the agency's own boundary, so the limit is written rather than inferred." }, { "n": 6, "capability": 3, "text": "Ensure the authority named for each escalation level is reachable at any hour, and record the path." }, { "n": 7, "capability": 3, "text": "Review the rules on phase transition, on legal change, and at cadence." }, { "n": 8, "capability": 4, "text": "Measure adherence during recorded incidents — actions taken outside authority, and actions not taken because authority could not be reached." }, { "n": 9, "capability": 4, "text": "Test reachability of each named authority out of hours rather than assuming it." }, { "n": 10, "capability": 5, "text": "Revise authority levels where measured adherence shows the rules are routinely worked around rather than followed." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "SOC", "TO" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — defensive intent (CG-1); phase (CG-2); statutory availability floors\n(FO-5); legal counsel input; maneuver catalog (SM-1).\n*Outputs* — approved rules of engagement with authority levels and legal bounds;\nreachability record; input to TA-4 pre-authorization and incident execution.", "people_skills": "Legal literacy sufficient to recognize a statutory constraint. Authority mapping.\nOut-of-hours contact management.", "policies": "Approved rules of engagement document. Legal review requirement. Reachability\ntesting procedure. Review triggers.", "culture": "", "services": "Rules accessible at incident time, not only in a policy repository. Escalation\ncontact system with out-of-hours coverage. Action logging against authority level.", "metric_outcome": "percentage of recorded incident actions taken within written authority.", "metric_performance": "percentage of named authorities verified reachable out of hours.", "evidence": "Approved rules of engagement with legal bounds; reachability test records; incident action logs referencing authority.", "assessment": "Examine approval and currency; test adherence in a recorded incident; test whether a named out-of-hours authority is in fact reachable.", "nist_800_53": [ "IR-4", "AC-2", "PM-1" ], "csf_2_0": [ "GV.RR-01", "RS.MA-01" ], "ztmm": "cross-cutting Governance", "d3fend": "Isolate, Evict tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires the boundary limit (no action outside the agency's own terrain) to be written rather than inferred from doctrine; requires statutory constraints recorded with reference to FO-5 availability floors; requires out-of-hours authority reachability to be tested rather than assumed." } ] }, { "id": "CG-4", "family": "CG", "title": "Findings Disposition", "control_statement": "Findings raised by architectural review shall be dispositioned as remediated, accepted with justification, or transferred, within a defined period.", "purpose": "To ensure every finding reaches a decision, so that the open set reflects work in progress rather than accumulated neglect.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — known weaknesses are decided about. *This control* — every finding is dispositioned within a stated period.", "discussion": "Acceptance is where this control is defeated. A finding accepted permanently, by someone without the authority to accept it, disappears from view while the risk remains — and a program with a large accepted set can report a small open set indefinitely. Two requirements close that: acceptance must be by a person whose risk authority covers the exposure, and it must expire, forcing periodic re-decision rather than one-time disposal.", "activities": [ { "n": 1, "capability": 2, "text": "Record every finding with its source and date." }, { "n": 2, "capability": 2, "text": "Disposition each as remediated, accepted with justification, or transferred." }, { "n": 3, "capability": 2, "text": "Define the period within which disposition must occur." }, { "n": 4, "capability": 3, "text": "Require acceptance to be made by a person whose risk authority covers the exposure, recorded by name." }, { "n": 5, "capability": 3, "text": "Give every acceptance an expiry, after which it returns for re-decision rather than persisting." }, { "n": 6, "capability": 3, "text": "Record for transferred findings who received them and their acknowledgment." }, { "n": 7, "capability": 3, "text": "Escalate findings exceeding the disposition period rather than ageing them." }, { "n": 8, "capability": 4, "text": "Trend the accepted set alongside the open set, since a shrinking open set and a growing accepted set is not improvement." }, { "n": 9, "capability": 4, "text": "Measure re-decision outcomes on expiry — acceptances renewed without change indicate risk being deferred rather than managed." }, { "n": 10, "capability": 5, "text": "Feed recurring finding types back into the control that generates them, since a finding class that keeps recurring is a design problem rather than a remediation backlog." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO" ], "informed": [ "CTI", "SOC", "HT" ] }, "information_flows": "*Inputs* — findings from every control; ownership register (TM-7); backlog\nranking (CE-5); risk authority matrix.\n*Outputs* — findings register with dispositions, named acceptors and expiries;\ninput to CE-5 backlog and the Brief.", "people_skills": "Risk authority mapping. Ability to refuse an acceptance made at the wrong level.\nRegister discipline.", "policies": "Disposition period definition. Acceptance authority matrix. Expiry rule.\nTransfer acknowledgment requirement.", "culture": "", "services": "Findings register with disposition, acceptor identity and expiry date. Automatic\nreturn on expiry. Trend reporting on open versus accepted.", "metric_outcome": "percentage of findings dispositioned within the defined period.", "metric_performance": "ratio of accepted to remediated dispositions, trended.", "evidence": "Findings register with disposition, dates, named acceptors and expiries; transfer acknowledgments.", "assessment": "Examine open findings against the defined period; test the justification recorded for accepted risks; test whether acceptors held authority covering the exposure.", "nist_800_53": [ "CA-5", "CA-7", "RA-7" ], "csf_2_0": [ "ID.IM-02", "GV.RM-03" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires acceptance by a named person whose risk authority covers the exposure, and an expiry forcing re-decision. Adds trending of accepted alongside open. Closes the route by which a program reports a shrinking open set while the accepted set grows without limit." } ] }, { "id": "CG-5", "family": "CG", "title": "Control Inheritance Mapping", "control_statement": "The organization shall maintain the mapping between these controls and its existing control baseline, and shall assess inherited controls once rather than twice.", "purpose": "To keep the framework additive, so that adopting it adds assessment effort only where it adds assessable content.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — defending well produces the compliance evidence. *This control* — inheritance is mapped and duplicate assessment does not occur.", "discussion": "This is the control adoption depends on. A framework layered onto SP 800-53 that re-assesses what 800-53 already covers doubles the assessment burden and will be declined regardless of merit — and the decline will be correct. The mapping has to be maintained rather than published once: control baselines are tailored, overlays change, and an inheritance claim citing an assessment that no longer covers the requirement is worse than no claim, because it retires a requirement that nothing is actually testing. FO-3 applies the same discipline at a different scope: CG-5 verifies inheritance from a control baseline, FO-3 verifies it from a service provider, and a requirement can fall between the two if neither is checked.", "activities": [ { "n": 1, "capability": 2, "text": "Maintain the mapping between ASOM-Fed controls and the existing baseline." }, { "n": 2, "capability": 2, "text": "Declare for each control whether it is inherited, extended, or net new." }, { "n": 3, "capability": 2, "text": "Cite existing assessment results as evidence where inheritance applies." }, { "n": 4, "capability": 3, "text": "Verify that each cited assessment actually covers the requirement claimed, rather than covering the control family it belongs to." }, { "n": 5, "capability": 3, "text": "Assess only the delta for extended controls, and state what that delta is." }, { "n": 6, "capability": 3, "text": "Re-verify inheritance claims when the baseline is tailored, an overlay is applied, or a cited assessment expires." }, { "n": 7, "capability": 3, "text": "Record where an inheritance claim fails verification, since that requirement is then unassessed by anything." }, { "n": 8, "capability": 4, "text": "Measure the assessment effort attributable to ASOM-Fed over and above the existing baseline, which is the framework's true marginal cost." }, { "n": 9, "capability": 4, "text": "Measure the proportion of inheritance claims that survive verification, since a low rate means the mapping is aspirational." }, { "n": 10, "capability": 5, "text": "Feed verification failures back to the framework steward, since a claim that fails at multiple agencies is a defect in the published crosswalk rather than in the adopter." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "CTI" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — ASOM-Fed crosswalk; agency 800-53 baseline and tailoring; existing\nassessment results; overlay and authorization package.\n*Outputs* — maintained inheritance mapping with verification status; marginal\neffort measure; unassessed-requirement findings; input to the assessment plan.", "people_skills": "RMF and 800-53A fluency. Ability to read an assessment result and judge what it\nactually covered. Crosswalk maintenance discipline.", "policies": "Inheritance declaration procedure. Verification standard. Re-verification\ntriggers on baseline change.", "culture": "", "services": "Crosswalk maintained as data rather than as a document. Linkage from claim to the\nspecific assessment result cited. Expiry tracking on cited results.", "metric_outcome": "percentage of inheritance claims verified against a current assessment result.", "metric_performance": "assessment effort attributable to ASOM-Fed beyond the baseline.", "evidence": "Maintained crosswalk with inheritance decisions and verification status; cited assessment results; unassessed-requirement findings.", "assessment": "Examine the crosswalk; test two inherited controls to confirm the cited assessment covers the requirement; examine whether any claim has ever failed verification.", "nist_800_53": [ "PM-10", "CA-2", "SA-4" ], "csf_2_0": [ "GV.SC-07", "GV.OV-02" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "4.1.1", "changes": [ { "v": "4.1.1", "note": "PATCH. Backfill after FO-3: names FO-3 as the provider-scope sibling. CG-5 verifies inheritance from a control baseline, FO-3 from a service provider, and a requirement can fall between the two if neither is checked." }, { "v": "4.1.0", "note": "MINOR. Requires inheritance claims to be verified against the specific assessment result cited rather than asserted at family level, and a failed verification to be recorded as an unassessed requirement. Adds measurement of ASOM-Fed's true marginal assessment cost over the existing baseline." } ] }, { "id": "RC-1", "family": "RC", "title": "Recovery Objectives", "control_statement": "Every mission service shall have a declared recovery time objective and recovery point objective, approved by the service owner, recorded on the terrain overlay before an incident occurs.", "purpose": "To establish what recovery must achieve, so that restoration can succeed or fail rather than simply take however long it takes.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the mission comes back on evidence, not on hope. *This control* — every service carries a mission judgment about acceptable loss.", "discussion": "Without a stated time and a stated tolerable data loss, recovery has no success condition. The approval requirement matters as much as the numbers: an objective set by the security or infrastructure function is a capability estimate, whereas one set by the service owner is a mission judgment about what the agency can survive. Those are different claims, and only the second can justify the investment the first implies. A declared objective is also not a demonstrated one — that distinction is RC-5's object, and an agency holding objectives it has never tested holds aspirations.", "activities": [ { "n": 1, "capability": 2, "text": "Declare a recovery time objective and a recovery point objective for every mission service." }, { "n": 2, "capability": 2, "text": "Record both on the terrain overlay against the service." }, { "n": 3, "capability": 2, "text": "Flag mission services carrying no declared objective." }, { "n": 4, "capability": 3, "text": "Obtain the service owner's approval of both figures, recorded by name and date, so the objective is a mission judgment rather than a capability estimate." }, { "n": 5, "capability": 3, "text": "Verify that each objective satisfies any statutory or regulatory availability floor applying to that service (FO-5), and raise a finding where it does not." }, { "n": 6, "capability": 3, "text": "State the dependency chain for each service, since a service cannot recover faster than the identity, network and data services it depends on." }, { "n": 7, "capability": 3, "text": "Record objectives with approval provenance per GA4." }, { "n": 8, "capability": 4, "text": "Compare declared objectives against demonstrated recovery times from RC-5, and flag every objective whose demonstrated time exceeds it." }, { "n": 9, "capability": 4, "text": "Measure the proportion of mission services whose objectives have been demonstrated at all, distinguishing declared from proven." }, { "n": 10, "capability": 5, "text": "Re-base objectives from demonstrated capability and mission consequence together, rather than allowing the declared figure to persist unchallenged against repeated failure to meet it." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — mission service register; terrain overlay (TM-1); statutory\navailability floors (FO-5); dependency mapping; demonstrated times (RC-5).\n*Outputs* — recovery objectives table with owner approval and provenance;\ndependency chains; input to RC-3 rebuild paths, RC-5 exercise scope and the Brief.", "people_skills": "Mission consequence reasoning. Dependency analysis across services. Ability to\nelicit a real tolerance figure from a service owner rather than an aspiration.", "policies": "Objective declaration and approval procedure. Statutory floor verification.\nDependency chain recording standard.", "culture": "", "services": "Overlay fields for both objectives with owner and approval date. Dependency\nrepresentation. Linkage to demonstrated times.", "metric_outcome": "percentage of mission services with an owner-approved objective.", "metric_performance": "percentage of objectives demonstrated within their stated period.", "evidence": "Recovery objectives table with owner approval and dates; statutory floor verification; dependency chains.", "assessment": "Examine the objectives table for completeness against the mission service list; interview service owners on whether the stated figures reflect a mission judgment they made; test that no objective is weaker than its statutory floor.", "nist_800_53": [ "CP-2", "CP-2(3)", "PM-11" ], "csf_2_0": [ "RC.RP-01", "GV.OC-04", "GV.OC-05" ], "ztmm": "cross-cutting Governance", "d3fend": "Restore tactic", "version": "4.1.1", "changes": [ { "v": "4.1.1", "note": "PATCH. CSF recovery: adds GV.OC-05 (dependencies determined) — RC-1 already requires the dependency chain per mission service." }, { "v": "4.1.0", "note": "MINOR. Requires objectives to satisfy any statutory availability floor under FO-5, and to be approved by the service owner with provenance per GA4. Adds the distinction between a declared objective and a demonstrated one, which is RC-5's object." } ] }, { "id": "RC-2", "family": "RC", "title": "Isolated Recovery Capability", "control_statement": "The means of recovery shall be held outside the trust boundary of the production identity plane, such that compromise of production credentials cannot reach, alter, or destroy them.", "purpose": "To ensure the recovery capability survives the compromise it exists to recover from.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the means of recovery are preserved. *This control* — production credential compromise cannot reach them.", "discussion": "This is the ransomware lesson stated as a control. Backups that authenticate against the production identity provider are reachable by anyone who holds production administrative credentials, which is precisely the position an adversary occupies at the moment recovery becomes necessary. The operative test is narrower and more useful than \"held outside the boundary\": can a production administrator credential, used adversarially, reach the recovery store? That question has a demonstrable answer, and a great many recovery architectures that satisfy the general statement fail the specific test.", "activities": [ { "n": 1, "capability": 2, "text": "Place the recovery store in a trust zone separate from production." }, { "n": 2, "capability": 2, "text": "Record the authentication path by which the recovery store is reached." }, { "n": 3, "capability": 2, "text": "Raise a finding where the recovery store shares an identity provider with production." }, { "n": 4, "capability": 3, "text": "Test whether a production administrator credential can reach, alter or delete the recovery store, rather than inferring independence from architecture." }, { "n": 5, "capability": 3, "text": "Verify that the credentials governing the recovery store are issued, held and rotated independently of production." }, { "n": 6, "capability": 3, "text": "Apply the same independence test to the recovery store's own management plane, including its console, its orchestration and its monitoring." }, { "n": 7, "capability": 3, "text": "Verify immutability or retention locking where the platform supports it, and record where it does not." }, { "n": 8, "capability": 4, "text": "Test independence on a defined cadence and after any change to either identity plane, and trend the pass rate." }, { "n": 9, "capability": 4, "text": "Measure the elapsed time between an identity-plane change and the next independence test, since that interval is the exposure window." }, { "n": 10, "capability": 5, "text": "Re-derive the independence test from adversary tradecraft observed in engagements and in sector reporting, rather than testing only the paths the original design anticipated." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — terrain overlay and zones (TM-1, TM-4); identity plane configuration;\nrecovery platform configuration; credential inventory.\n*Outputs* — independence test results; credential separation record; findings;\ninput to RC-3 rebuild path and RC-5 exercise scenario.", "people_skills": "Identity architecture. Adversarial testing of authentication paths. Ability to\ndistinguish network separation from credential separation.", "policies": "Independence test procedure. Credential separation standard. Retention and\nimmutability configuration standard.", "culture": "", "services": "Recovery store with independent authentication. Separate management plane.\nImmutability or retention locking where available.", "metric_outcome": "result of the production-credential reachability test against the recovery store.", "metric_performance": "currency of the last independence test relative to the last identity-plane change.", "evidence": "Terrain overlay showing the recovery zone and its trust boundary; credential separation record; independence test results.", "assessment": "Test whether a production administrator credential can reach the recovery store; examine the authentication path for independence; test the recovery store's management plane by the same method.", "nist_800_53": [ "CP-6", "CP-9(3)", "SC-28" ], "csf_2_0": [ "RC.RP-01", "PR.DS-11", "PR.IR-03" ], "ztmm": "Identity, Data", "d3fend": "Isolate, Restore tactics", "version": "4.1.1", "changes": [ { "v": "4.1.1", "note": "PATCH. CSF recovery: adds PR.IR-03 (resilience mechanisms) — isolated recovery capability is a resilience mechanism in the CSF sense." }, { "v": "4.1.0", "note": "MINOR. Adds explicit authentication-path independence testing. v3.0 required the recovery store to sit outside the production trust boundary; the operative test is whether a production administrator credential can reach it, which is narrower and testable." } ] }, { "id": "RC-3", "family": "RC", "title": "Trusted Rebuild Path", "control_statement": "For every decisive point, the organization shall maintain a documented and tested path to rebuild the element from trusted media within its declared recovery time objective.", "purpose": "To ensure that what must not be lost can be rebuilt, from a source the adversary did not touch, inside the time the mission requires.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — decisive points can be reconstituted. *This control* — a tested rebuild path exists for each, within its objective.", "discussion": "Most rebuild procedures assume a working identity plane — they begin with authenticating to something. Where identity is itself the decisive point that was compromised, the procedure contains a circular dependency, and it surfaces at the worst possible moment. The identity plane's own rebuild path therefore has to be tested independently and first, because every other path in the estate depends on it. The trusted-media requirement carries the second half of the problem: media stored, indexed or validated by the compromised environment is not trusted media regardless of where it physically sits.", "activities": [ { "n": 1, "capability": 2, "text": "Document a rebuild path for every designated decisive point." }, { "n": 2, "capability": 2, "text": "Identify the media source each path rebuilds from." }, { "n": 3, "capability": 2, "text": "Record the most recent rebuild test and its elapsed time." }, { "n": 4, "capability": 3, "text": "Verify that each media source is independently trusted — not stored, indexed or validated by the environment being rebuilt." }, { "n": 5, "capability": 3, "text": "Test the rebuild path for the identity plane itself, and sequence it first, since every other path depends on a working identity service." }, { "n": 6, "capability": 3, "text": "Record the dependency order across rebuild paths, so reconstitution can be sequenced rather than attempted in parallel." }, { "n": 7, "capability": 3, "text": "Compare each tested elapsed time against the element's declared recovery time objective (RC-1) and raise a finding where it exceeds." }, { "n": 8, "capability": 4, "text": "Test each decisive point's rebuild path on a defined cadence and trend the elapsed times, since procedures decay as platforms change." }, { "n": 9, "capability": 4, "text": "Measure the proportion of decisive points whose rebuild path has been tested at all, distinguishing documented from tested." }, { "n": 10, "capability": 5, "text": "Re-engineer paths whose tested time persistently exceeds the objective, rather than repeatedly recording the same finding." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — decisive points (KT-1); recovery objectives and dependency chains\n(RC-1); isolated recovery capability (RC-2); build and configuration sources.\n*Outputs* — rebuild procedures with tested elapsed times; dependency-ordered\nsequence; findings against objectives; input to RC-5 exercise scope.", "people_skills": "Platform rebuild engineering. Identity plane reconstruction specifically.\nDependency sequencing. Media provenance verification.", "policies": "Rebuild procedure standard including media provenance. Test cadence. Dependency\nsequence documentation.", "culture": "", "services": "Trusted media source independent of production. Build automation reproducible\nwithout the compromised environment. Test environment capable of hosting a\nrebuild.", "metric_outcome": "percentage of decisive points with a tested rebuild path meeting their objective.", "metric_performance": "median age of the most recent rebuild test per decisive point.", "evidence": "Rebuild procedure per decisive point; record of the most recent rebuild test and its elapsed time; media provenance verification; dependency sequence.", "assessment": "Examine the procedures for currency; test one rebuild against its stated recovery time objective; verify the media source is independently trusted; test whether the identity plane's own rebuild path has been exercised.", "nist_800_53": [ "CP-10", "SI-7", "CM-2" ], "csf_2_0": [ "RC.RP-04", "PR.PS-02" ], "ztmm": "Identity, Applications and Workloads", "d3fend": "Restore tactic", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after LC-2: trusted rebuild media must also carry verified component provenance. Media independent of the compromised environment but built from a compromised supply chain reconstitutes the intrusion with the system, which media-source independence alone does not catch." }, { "v": "4.1.0", "note": "MINOR. Requires the rebuild path for the identity plane itself to be tested. Most rebuild plans assume a working identity plane; where identity is what was compromised, the plan carries a circular dependency that only surfaces during recovery." } ] }, { "id": "RC-4", "family": "RC", "title": "Recovery Integrity Verification", "control_statement": "Restored data and rebuilt systems shall be verified against an integrity record maintained independently of the system being restored, before the service is returned to use.", "purpose": "To ensure restoration returns the mission to a known-good state rather than reinstating the compromise.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — recovery is on evidence, not hope. *This control* — what is restored is verified before it is trusted.", "discussion": "Recovery has a failure mode that looks exactly like success: restoring from a point after the intrusion began returns the service, the data and the adversary together. The integrity record therefore has to satisfy two conditions rather than one — it must be maintained independently of the system being restored, *and* it must predate the earliest plausible compromise. The second condition is what connects this control to dwell estimation: if adversary dwell may have been ninety days, an integrity baseline taken thirty days ago verifies nothing useful, and the restore point has to be chosen against the dwell estimate rather than against the last known-good backup.", "activities": [ { "n": 1, "capability": 2, "text": "Record the integrity source used to verify each recovery store." }, { "n": 2, "capability": 2, "text": "Verify restored data and rebuilt systems against that source before returning the service to use." }, { "n": 3, "capability": 2, "text": "Record the verification result." }, { "n": 4, "capability": 3, "text": "Verify that the integrity record is maintained independently of the system being restored, including independently of its identity plane." }, { "n": 5, "capability": 3, "text": "Verify that the record predates the earliest plausible compromise, selecting the restore point against the engagement reconstruction (`EN-2`) where one exists and against the dwell estimate (TA-2) otherwise, rather than against the most recent backup." }, { "n": 6, "capability": 3, "text": "Define what happens when verification fails, including the authority to refuse return to service." }, { "n": 7, "capability": 3, "text": "Retain verification results as evidence rather than as a transient check." }, { "n": 8, "capability": 4, "text": "Measure the interval covered by retained integrity records against the current dwell estimate, and raise a finding where retention is shorter than plausible dwell." }, { "n": 9, "capability": 4, "text": "Trend verification failure rates from exercise, since a rate of zero usually means verification is not discriminating." }, { "n": 10, "capability": 5, "text": "Extend integrity record retention and granularity where dwell estimates or observed engagements show the current window is insufficient." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI", "HT" ], "informed": [ "SOC", "GOV" ] }, "information_flows": "*Inputs* — recovery stores (RC-2); rebuild outputs (RC-3); dwell estimate (TA-2);\nintegrity baselines; incident timeline reconstruction.\n*Outputs* — verification results with restore point rationale; retention adequacy\nfinding; input to RC-5 exercise and to return-to-service authorization.", "people_skills": "Integrity verification method. Incident timeline reasoning sufficient to choose a\nrestore point. Authority to hold a service out of use pending verification.", "policies": "Integrity source independence standard. Restore point selection rule referencing\ndwell. Verification failure procedure with refusal authority.", "culture": "", "services": "Integrity records maintained independently with retention covering plausible\ndwell. Verification tooling. Retained results.", "metric_outcome": "percentage of restorations verified before return to service.", "metric_performance": "integrity record retention window against the current dwell estimate.", "evidence": "Integrity verification results for the most recent restoration or exercise; restore point rationale; retention window record.", "assessment": "Examine the verification method and its independence; test a restoration for verification before return to service; test whether the integrity record retention exceeds the current dwell estimate.", "nist_800_53": [ "CP-9(1)", "SI-7(1)", "AU-9" ], "csf_2_0": [ "RC.RP-05", "RC.RP-03" ], "ztmm": "Data", "d3fend": "Restore, Detect tactics", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after EN-2: restore point selected against the engagement reconstruction where one exists, falling back to the TA-2 dwell estimate otherwise. A reconstruction gives the actual entry time; the estimate is only a bound." }, { "v": "4.1.0", "note": "MINOR. Requires the integrity record to predate the earliest plausible compromise, not merely to be independently maintained. Restoring from a point after intrusion reinstates the adversary with the data." } ] }, { "id": "RC-5", "family": "RC", "title": "Reconstitution Exercise", "control_statement": "The organization shall exercise reconstitution against a stated failure scenario on a defined cadence, and every declared recovery objective shall have been demonstrated within its stated period.", "purpose": "To convert declared recovery capability into demonstrated capability, so that objectives are proven before they are needed.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — recovery is proven, not asserted. *This control* — every objective has been demonstrated within its stated period.", "discussion": "This is the control that makes the rest of the family real, and it is the one the framework's own analysis identifies as most often asserted rather than demonstrated. The scenario is where exercises usually fall short: an exercise that restores a single application from a clean environment demonstrates a procedure, not a reconstitution. The scenarios that test what RC-2 and RC-3 actually claim are the uncomfortable ones — loss of the identity plane, loss of the management plane, recovery under an assumption that production credentials are held by the adversary. An exercise program that has never run those has not tested the family's central dependency.", "activities": [ { "n": 1, "capability": 2, "text": "Exercise reconstitution against a stated failure scenario." }, { "n": 2, "capability": 2, "text": "Record the scenario, participants, measured elapsed times and findings raised." }, { "n": 3, "capability": 2, "text": "Compare measured times against declared objectives." }, { "n": 4, "capability": 3, "text": "Define the exercise cadence with provenance per GA4, and flag objectives overdue for demonstration." }, { "n": 5, "capability": 3, "text": "Include at least one scenario per period in which the identity plane is unavailable and production credentials are assumed adversary-held." }, { "n": 6, "capability": 3, "text": "Exercise the dependency sequence across services (RC-3) rather than single services in isolation." }, { "n": 7, "capability": 3, "text": "Disposition findings raised by exercise through CG-4 rather than closing them with the exercise report." }, { "n": 8, "capability": 4, "text": "Measure the proportion of declared objectives demonstrated within their stated period, and treat a shortfall as a reportable condition." }, { "n": 9, "capability": 4, "text": "Trend measured recovery times across exercises, since drift upward indicates decay in procedures that still pass." }, { "n": 10, "capability": 5, "text": "Derive scenarios from observed adversary tradecraft and from engagements under M10, rather than repeating a scenario library that the estate has learned to pass." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "TO", "HT", "GOV" ], "informed": [ "CTI" ] }, "information_flows": "*Inputs* — recovery objectives (RC-1); isolation test results (RC-2); rebuild\npaths and dependency sequence (RC-3); verification method (RC-4); threat courses\nof action.\n*Outputs* — exercise records with measured times and findings; demonstration\nstatus per objective; input to RC-1 re-basing, CG-4 disposition and the Brief.", "people_skills": "Exercise design and facilitation. Scenario realism. Measurement under exercise\nconditions. Willingness to design a scenario the organization may fail.", "policies": "Exercise cadence with provenance. Scenario standard including the identity-loss\ncase. Finding disposition routing to CG-4.", "culture": "", "services": "Exercise environment capable of representing identity-plane loss. Timing\ninstrumentation. Exercise record retention.", "metric_outcome": "percentage of declared objectives demonstrated within their stated period.", "metric_performance": "trend in measured recovery times across successive exercises.", "evidence": "Exercise record: scenario, participants, measured recovery times, findings raised and their disposition.", "assessment": "Examine the exercise records for cadence and scenario realism; compare measured times against declared objectives; test that findings were dispositioned; examine whether any scenario has assumed loss of the identity plane.", "nist_800_53": [ "CP-4", "CP-4(1)", "IR-3" ], "csf_2_0": [ "RC.RP-06", "ID.IM-02" ], "ztmm": "cross-cutting Automation and Orchestration", "d3fend": "Restore tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires every declared objective to have been demonstrated within its stated period, and scenario realism to include loss of the identity plane. Adds exercise cadence provenance per GA4." } ] }, { "id": "FO-1", "family": "FO", "title": "Privacy Terrain Identification", "control_statement": "Elements holding personally identifiable information shall be identified on the terrain overlay, with the authority under which the information is held recorded against each.", "purpose": "To make privacy exposure positional, so that the elements holding personal information can be defended, minimized and accounted for as terrain.", "goals_cascade": "*Mission outcome* — the mission survives contact without betraying the public. *Defensive intent* — personal information is held only where it must be, and defended there. *This control* — those elements are known, marked and legally accounted for.", "discussion": "Privacy terrain is the only ground in the framework where holding *more* of it is itself the risk. Everywhere else, an element on the overlay is an asset to be defended; here, an element holding personal information without a recorded authority is an exposure that should be removed rather than protected. The authority requirement is therefore doing double duty — it satisfies the federal obligation, and it surfaces holdings that no authority covers, which are the ones a defense should not be built around in the first place.", "activities": [ { "n": 1, "capability": 2, "text": "Mark elements holding personally identifiable information on the terrain overlay." }, { "n": 2, "capability": 2, "text": "Record against each the authority under which the information is held." }, { "n": 3, "capability": 2, "text": "Flag marked elements carrying no recorded authority." }, { "n": 4, "capability": 3, "text": "Reconcile the marked set against the agency's privacy impact assessments and systems of records notices, in both directions — unmarked elements that appear in a notice, and marked elements that appear in none." }, { "n": 5, "capability": 3, "text": "Record the categories held, so that exposure can be assessed by sensitivity rather than by presence alone." }, { "n": 6, "capability": 3, "text": "Raise a finding for any holding with no covering authority, dispositioned as removal rather than as protection wherever the mission permits." }, { "n": 7, "capability": 3, "text": "Include derived and incidental holdings — logs, caches, analytics stores, backups — which are the holdings least likely to appear in a notice." }, { "n": 8, "capability": 4, "text": "Trend the count and weight of privacy terrain, since a defensible program should see it fall rather than grow." }, { "n": 9, "capability": 4, "text": "Measure the interval between a new holding appearing and its authority being recorded." }, { "n": 10, "capability": 5, "text": "Feed recurring unauthorized holdings back into system design and data retention practice, rather than remediating the same class each cycle." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "CTI" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); privacy impact assessments; systems of records\nnotices; data inventory; retention schedules.\n*Outputs* — overlay with privacy terrain marked and authorities recorded;\nunauthorized-holding findings; input to TM-3 weighting and CG-4 disposition.", "people_skills": "Privacy program literacy. Ability to recognize derived and incidental holdings.\nReconciliation across legal and technical records.", "policies": "Marking standard and category definitions. Authority recording requirement.\nReconciliation procedure against assessments and notices.", "culture": "", "services": "Overlay marking and shading for privacy terrain. Category and authority fields.\nDiscovery across derived stores.", "metric_outcome": "percentage of privacy terrain elements with a recorded covering authority.", "metric_performance": "trend in the count and weight of privacy terrain across cycles.", "evidence": "Terrain overlay with privacy elements marked; authority recorded per element; reconciliation record against assessments and notices.", "assessment": "Examine the overlay against the privacy impact assessments and systems of records notices; test for elements holding such information that are unmarked, including logs, caches and backups.", "nist_800_53": [ "PT-2", "PT-3", "RA-8" ], "csf_2_0": [ "GV.OC-03", "ID.AM-07" ], "ztmm": "Data", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires derived and incidental holdings (logs, caches, analytics stores, backups) to be included, and unauthorized holdings to be dispositioned as removal rather than protection where the mission permits. Adds two-way reconciliation against privacy impact assessments and systems of records notices. Adds trending on the count and weight of privacy terrain, which a defensible program should see fall." } ] }, { "id": "FO-2", "family": "FO", "title": "Controlled Unclassified Information Handling", "control_statement": "Elements processing, storing, or transmitting controlled unclassified information shall be identified on the terrain overlay, and the boundaries across which that information may move shall be declared.", "purpose": "To make CUI movement declarable and therefore detectable, so that handling obligations attach to information rather than to systems.", "goals_cascade": "*Mission outcome* — the mission survives contact without uncontrolled disclosure. *Defensive intent* — regulated information moves only where it is permitted to. *This control* — the elements holding it and the flows between them are declared.", "discussion": "CUI is defined by the information, not by the system, which means it moves — into a spreadsheet, an email, a ticketing system, a contractor's environment — and each move takes the obligation with it. Marking elements is therefore only half the control; declaring permitted flows is what makes an undeclared movement a detectable event rather than an invisible one. The failure mode is a correctly marked estate with no declared flows, in which every element is compliant and the information is nonetheless everywhere.", "activities": [ { "n": 1, "capability": 2, "text": "Mark elements processing, storing or transmitting controlled unclassified information on the overlay." }, { "n": 2, "capability": 2, "text": "Declare the boundaries across which that information may move." }, { "n": 3, "capability": 2, "text": "Raise a finding for observed flows that were not declared." }, { "n": 4, "capability": 3, "text": "Reconcile marked elements against the agency's CUI categorization record." }, { "n": 5, "capability": 3, "text": "Declare flows by category where categories carry different handling requirements, rather than treating CUI as a single class." }, { "n": 6, "capability": 3, "text": "Extend declaration to flows leaving the authorization boundary — to contractors, to shared services, to other agencies — since those are where handling obligations most often lapse." }, { "n": 7, "capability": 3, "text": "Instrument the declared boundaries sufficiently that an undeclared flow can be observed rather than only prohibited." }, { "n": 8, "capability": 4, "text": "Measure observed flows against declared flows and trend the divergence." }, { "n": 9, "capability": 4, "text": "Measure the proportion of declared boundaries carrying detection, since an undeclared flow across an uninstrumented boundary is not a finding, it is an absence." }, { "n": 10, "capability": 5, "text": "Revise the declared flow set from observed legitimate movement, so the declaration reflects how the mission actually works rather than how it was designed to." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); CUI categorization record; connection register\n(TM-5); contract and sharing agreements.\n*Outputs* — overlay with CUI elements marked and flows declared; divergence\nfindings; input to TM-5, KT-3 avenue analysis and CG-4 disposition.", "people_skills": "CUI categorization literacy. Data flow analysis. Ability to instrument a boundary\nfor content rather than only for connectivity.", "policies": "Marking and categorization standard. Flow declaration procedure including\nexternal flows. Detection coverage standard.", "culture": "", "services": "Overlay marking by category. Flow declaration register. Boundary instrumentation\ncapable of observing content movement.", "metric_outcome": "percentage of observed CUI flows that were declared.", "metric_performance": "percentage of declared boundaries carrying detection.", "evidence": "Terrain overlay with marked elements and declared flows; the flow declaration itself; divergence findings.", "assessment": "Examine the marked elements against the categorization record; test observed flows against the declared set; test whether declared boundaries are instrumented.", "nist_800_53": [ "MP-4", "SC-28", "AC-21" ], "csf_2_0": [ "PR.DS-01", "GV.OC-03" ], "ztmm": "Data, Networks", "d3fend": "Isolate, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires declared boundaries to be instrumented, not only prohibited: an undeclared flow across an uninstrumented boundary is an absence rather than a finding. Extends flow declaration to flows leaving the authorization boundary, and requires declaration by CUI category where handling requirements differ." } ] }, { "id": "FO-3", "family": "FO", "title": "Tenancy and Inheritance Boundary", "control_statement": "For every element hosted in a shared or authorized service, the overlay shall record which controls are inherited from the provider and which remain the organization's responsibility.", "purpose": "To ensure that the customer half of a shared responsibility model is owned by someone, so that inherited controls do not become nobody's job.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — every control has an owner, including in hosted terrain. *This control* — the inheritance split is recorded and the customer half assigned.", "discussion": "The customer responsibility matrix is the most reliably unread document in federal cloud adoption. The provider states that a control is the customer's responsibility; the customer assumes that a FedRAMP-authorized service handles it; and the control is implemented by neither while appearing satisfied to both. That gap is invisible on any inventory and visible on this overlay, because an unassigned customer responsibility appears as an element with an inheritance claim and no owner. This control and CG-5 are the same discipline applied at different scopes — CG-5 verifies inheritance from a control baseline, FO-3 verifies it from a service provider.", "activities": [ { "n": 1, "capability": 2, "text": "Record the hosting provider for every element in a shared or authorized service." }, { "n": 2, "capability": 2, "text": "Record which controls are inherited and which remain the organization's responsibility." }, { "n": 3, "capability": 2, "text": "Report unassigned customer responsibilities as gaps." }, { "n": 4, "capability": 3, "text": "Derive the split from the provider's authorization package and customer responsibility matrix rather than from assumption." }, { "n": 5, "capability": 3, "text": "Assign an owner and an implementing maneuver to each customer responsibility, reconciled against terrain ownership (TM-7)." }, { "n": 6, "capability": 3, "text": "Re-verify the split when the provider changes its offering, its authorization status, or its responsibility matrix." }, { "n": 7, "capability": 3, "text": "Record where a provider's authorization does not extend to the way the agency is actually using the service, since inheritance does not apply outside the authorized scope." }, { "n": 8, "capability": 4, "text": "Measure the proportion of customer responsibilities carrying both an owner and an operational move, since an owned but unimplemented responsibility is a gap that reports as assigned." }, { "n": 9, "capability": 4, "text": "Trend the count of unassigned responsibilities across cycles." }, { "n": 10, "capability": 5, "text": "Feed recurring inheritance gaps into acquisition, so that the responsibility split is evaluated before a service is adopted rather than after." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); provider authorization packages and customer\nresponsibility matrices; ownership register (TM-7); acquisition records.\n*Outputs* — inheritance record per hosted element; customer responsibility matrix\nreconciled to assigned maneuvers; gap findings; input to CG-5 and CE-5.", "people_skills": "FedRAMP and shared-responsibility literacy. Ability to read an authorization\npackage for scope rather than for status. Reconciliation discipline.", "policies": "Inheritance recording standard. Responsibility assignment procedure.\nRe-verification triggers on provider change.", "culture": "", "services": "Overlay fields for provider and inheritance split. Linkage from responsibility to\nassigned maneuver and owner. Gap reporting.", "metric_outcome": "percentage of customer responsibilities with an owner and an operational move.", "metric_performance": "currency of the inheritance record against the provider's current responsibility matrix.", "evidence": "Inheritance record per hosted element; customer responsibility matrix reconciled to assigned maneuvers; scope exceptions recorded.", "assessment": "Examine the inheritance record against the provider's authorization package; test that each customer responsibility has an owner and an assigned move; test whether agency usage falls within the authorized scope.", "nist_800_53": [ "SA-9", "SC-7(21)", "PM-10" ], "csf_2_0": [ "GV.SC-07", "ID.AM-04" ], "ztmm": "Applications and Workloads", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires each customer responsibility to carry both an owner and an operational move, since an owned but unimplemented responsibility reports as assigned. Adds recording of cases where agency usage falls outside the provider's authorized scope, in which inheritance does not apply." } ] }, { "id": "FO-4", "family": "FO", "title": "Operational Technology Terrain", "control_statement": "Operational technology, industrial control, and physical-effect systems shall be represented on the terrain overlay as a distinct defensive layer, with their connections to enterprise terrain declared.", "purpose": "To stop operational technology being scored as though it were a server estate, and to make the connections between the two declarable.", "goals_cascade": "*Mission outcome* — the mission survives contact without physical consequence. *Defensive intent* — ground we cannot maneuver freely on is defended accordingly. *This control* — OT is a distinct layer with declared connections to enterprise terrain.", "discussion": "Operational technology is ground you cannot maneuver freely on. Systems that cannot be patched or restarted on the defender's schedule remove whole classes of move from availability, and the consequence of loss is physical rather than informational. Scoring OT against enterprise expectations produces findings the agency cannot action and obscures the ones it can. The connections are where the real risk sits: engineering workstations, vendor remote access, historian replication and shared identity are the paths by which enterprise compromise becomes physical consequence, and they are routinely absent from network diagrams that show an air gap.", "activities": [ { "n": 1, "capability": 2, "text": "Classify operational technology, industrial control and physical-effect systems to the OT terrain layer." }, { "n": 2, "capability": 2, "text": "Declare every connection between OT elements and enterprise zones." }, { "n": 3, "capability": 2, "text": "Highlight cross-layer connections on the overlay." }, { "n": 4, "capability": 3, "text": "Reconcile the OT layer against the operational inventory held by the engineering or facilities function, not against the IT asset inventory." }, { "n": 5, "capability": 3, "text": "Enumerate connections exhaustively, including engineering workstations, vendor remote access, historian and data-diode paths, and shared identity — the paths most often omitted from a claimed air gap." }, { "n": 6, "capability": 3, "text": "Record for each OT element which defensive moves are unavailable and why — patching windows, restart constraints, vendor certification, safety interlocks — so coverage is scored against what is achievable." }, { "n": 7, "capability": 3, "text": "Record the physical consequence of loss, so weighting under TM-3 reflects consequence rather than data value." }, { "n": 8, "capability": 4, "text": "Test declared connections against observed traffic, since an undeclared path into OT is the finding that matters most in this layer." }, { "n": 9, "capability": 4, "text": "Measure the proportion of OT elements whose unavailable-move set has been recorded, since an unrecorded constraint reads as an unremediated gap." }, { "n": 10, "capability": 5, "text": "Work with engineering and vendors to remove constraints that force moves to be unavailable, rather than accepting the constraint set as fixed." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — operational inventory from engineering or facilities; terrain overlay\n(TM-1); connection register (TM-5); safety and certification constraints.\n*Outputs* — OT layer with declared connections and constraint record; physical\nconsequence weighting input to TM-3; input to KT-3 avenue analysis.", "people_skills": "OT and control-systems literacy. Working relationship with engineering and safety\nfunctions. Ability to recognize a connection that a network diagram omits.", "policies": "OT classification standard. Connection declaration procedure. Constraint recording\nstandard. Reconciliation against the operational inventory.", "culture": "", "services": "Overlay support for a distinct OT layer with cross-layer highlighting. Constraint\nfields per element. Traffic observation at the OT boundary.", "metric_outcome": "percentage of OT elements with declared connections and recorded constraints.", "metric_performance": "number of observed OT connections that were undeclared.", "evidence": "Terrain overlay showing the OT layer and its declared connections; constraint record per element; reconciliation against the operational inventory.", "assessment": "Examine the layer against the operational inventory; test the declared connections for completeness, including engineering workstations and remote access paths; test declared connections against observed traffic.", "nist_800_53": [ "PM-5", "SC-7(21)", "SI-4(20)" ], "csf_2_0": [ "ID.AM-01", "PR.IR-01" ], "ztmm": "no equivalent pillar — T6 is ASOM-Fed's own", "d3fend": "Isolate, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires the unavailable-move set to be recorded per OT element with its cause (patch window, restart constraint, vendor certification, safety interlock), so coverage is scored against what is achievable rather than carrying permanent unactionable findings. Requires reconciliation against the engineering or facilities operational inventory rather than the IT asset inventory, and testing of declared connections against observed traffic." } ] }, { "id": "FO-5", "family": "FO", "title": "Statutory Availability Floor", "control_statement": "Where statute, regulation, or an authorizing instrument sets a deadline the mission must meet, the affected services shall be identified and their recovery objectives shall be set no weaker than that deadline requires.", "purpose": "To identify the point at which a defensive action becomes a legal one, so that degradation decisions are bounded before they are needed.", "goals_cascade": "*Mission outcome* — the mission survives contact and meets its statutory duties. *Defensive intent* — we degrade gracefully, within what the law permits. *This control* — the floors are known and recovery objectives satisfy them.", "discussion": "This is the control that tells the SOC when it must *not* degrade. Isolation and retrograde under M8 trade availability for containment, and that trade is ordinarily the accountable authority's to make — except where a statute sets a deadline the agency must meet, at which point the trade has a legal boundary that no security judgment overrides. Recording the floors in advance is what allows that boundary to be respected at three in the morning by someone who is not a lawyer, and it is why FO-5 feeds directly into the rules of engagement under CG-3.", "activities": [ { "n": 1, "capability": 2, "text": "Identify services subject to a statutory, regulatory or instrument-set deadline." }, { "n": 2, "capability": 2, "text": "Record the governing instrument and its deadline against each." }, { "n": 3, "capability": 2, "text": "Raise a finding where a recovery objective is weaker than its floor." }, { "n": 4, "capability": 3, "text": "Obtain legal confirmation of each floor rather than deriving it from operational understanding." }, { "n": 5, "capability": 3, "text": "Set recovery objectives (RC-1) no weaker than the floor requires, accounting for the dependency chain rather than the service alone." }, { "n": 6, "capability": 3, "text": "Carry the floors into the rules of engagement (CG-3) and the pre-authorized response set (TA-4), so an operator knows which degradations are unavailable." }, { "n": 7, "capability": 3, "text": "Record seasonal or cyclical floors distinctly, since many federal deadlines bind only in defined periods and the constraint differs by date." }, { "n": 8, "capability": 4, "text": "Test operator awareness of the floors applying during the current period." }, { "n": 9, "capability": 4, "text": "Measure the interval between a change in governing instrument and its reflection in the register and the rules of engagement." }, { "n": 10, "capability": 5, "text": "Use the floors to argue for resilience investment, since a statutory deadline is the one availability requirement that does not need to be justified on risk terms." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — authorizing instruments; legal counsel determination; mission service\nregister; recovery objectives (RC-1); dependency chains.\n*Outputs* — statutory availability register with instrument, deadline and derived\nobjective; input to RC-1, CG-3 rules of engagement and TA-4 pre-authorization.", "people_skills": "Statutory literacy or reliable access to it. Ability to translate a legal deadline\ninto a recovery objective. Awareness of cyclical binding periods.", "policies": "Floor identification and legal confirmation procedure. Objective derivation rule.\nPropagation into rules of engagement.", "culture": "", "services": "Availability register with instrument, deadline and period. Presentation of\ncurrently binding floors at incident time. Linkage to recovery objectives.", "metric_outcome": "percentage of affected services whose recovery objective satisfies its statutory floor.", "metric_performance": "operator awareness of currently binding floors, tested.", "evidence": "Statutory availability register: service, instrument, deadline, resulting recovery objective; legal confirmation records.", "assessment": "Examine the register against the authorizing instruments; test that each affected service's recovery objective satisfies its floor; test operator awareness of currently binding floors.", "nist_800_53": [ "CP-2(8)", "SC-5", "PM-11" ], "csf_2_0": [ "GV.OC-04", "RC.RP-01" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires floors to be carried into the rules of engagement (CG-3) and the pre-authorized response set (TA-4), so an operator knows at incident time which degradations are legally unavailable. Requires seasonal and cyclical floors to be recorded distinctly, since many federal deadlines bind only in defined periods. Requires legal confirmation rather than operational derivation." } ] }, { "id": "FO-6", "family": "FO", "title": "Supply Chain Obligation", "control_statement": "The organization shall maintain a supply chain risk management program meeting its federal obligations, and shall record which acquisitions fall within its scope.", "purpose": "To discharge the statutory supply chain risk obligation, and to make the boundary of its scope explicit rather than assumed.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the routes by which the estate is resupplied are governed. *This control* — the SCRM obligation is met and its scope is recorded.", "discussion": "The distinction between this control and `LC-1` is the difference between an obligation and an operation. `LC-1` asks who has a path into the estate and what it reaches — a terrain question, answered on the overlay. `FO-6` asks whether the agency runs the program it is required to run, and to which acquisitions that program applies. Scope is where this control does its work: supply chain obligations rarely apply to every acquisition, and an agency that has never recorded the boundary cannot demonstrate either compliance inside it or a considered position outside it.", "activities": [ { "n": 1, "capability": 2, "text": "Maintain a supply chain risk management program meeting the agency's federal obligations." }, { "n": 2, "capability": 2, "text": "Record which acquisitions fall within its scope." }, { "n": 3, "capability": 2, "text": "Record the basis on which acquisitions are excluded." }, { "n": 4, "capability": 3, "text": "Derive scope from the governing obligations rather than from acquisition value thresholds alone." }, { "n": 5, "capability": 3, "text": "Integrate the program's determinations into acquisition decisions before award rather than after." }, { "n": 6, "capability": 3, "text": "Reconcile in-scope acquisitions against the supplier terrain register (LC-1), so a supplier with estate access that fell outside SCRM scope is visible as a deliberate position rather than an oversight." }, { "n": 7, "capability": 3, "text": "Record prohibited-source and exclusion determinations and the action taken." }, { "n": 8, "capability": 4, "text": "Measure the proportion of in-scope acquisitions assessed before award." }, { "n": 9, "capability": 4, "text": "Measure the gap between suppliers holding estate access (LC-1) and suppliers within SCRM scope, and treat a large gap as a finding about scope." }, { "n": 10, "capability": 5, "text": "Revise scope where the reconciliation with LC-1 repeatedly shows access-holding suppliers falling outside it." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO" ], "informed": [ "CTI", "SOC", "HT" ] }, "information_flows": "*Inputs* — governing supply chain obligations; acquisition record; supplier\nterrain register (LC-1); prohibited source determinations.\n*Outputs* — SCRM program record with scope and exclusions; pre-award\nassessments; scope reconciliation findings; input to LC-2 provenance and CG-4.", "people_skills": "Acquisition process literacy. Supply chain risk assessment. Ability to state and\ndefend a scope boundary.", "policies": "SCRM program documentation. Scope determination rule. Pre-award integration\nprocedure. Exclusion recording standard.", "culture": "", "services": "Program record with scope and exclusion fields. Acquisition system integration\nfor pre-award assessment. Reconciliation against the supplier register.", "metric_outcome": "percentage of in-scope acquisitions assessed before award.", "metric_performance": "count of access-holding suppliers falling outside SCRM scope.", "evidence": "SCRM program record with scope and recorded exclusions; pre-award assessments; reconciliation against the supplier terrain register.", "assessment": "Examine the program against the governing obligations; test that in-scope acquisitions were assessed before award; test the reconciliation against LC-1 for access-holding suppliers outside scope.", "nist_800_53": [ "SR-3", "SR-6", "SA-9" ], "csf_2_0": [ "GV.SC-01", "GV.SC-04", "GV.SC-06", "GV.SC-09", "ID.RA-09", "ID.RA-10" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "5.1.0", "changes": [ { "v": "5.1.0", "note": "MINOR. CSF recovery: adds GV.SC-01 (SCRM program established), GV.SC-06 (pre-contract due diligence) and ID.RA-10 (critical supplier assessment). FO-6 is the SCRM program control and requires pre-award assessment, so these were excluded in error rather than by scope." }, { "v": "5.0.0", "note": "MAJOR, scope change. The v3.0 statement duplicated LC-1 Supplier Terrain Register: both required suppliers with a path into the estate to be represented on the overlay with access recorded. Duplicate controls double-count supply chain coverage in every scored estate, which the framework's own design rules identify as the failure mode degrading a catalog fastest. FO-6 is narrowed to the federal SCRM obligation and its recorded scope; LC-1 retains the operational terrain register. Retitled from 'Supply Chain Terrain' to 'Supply Chain Obligation'. Requires framework owner ratification before publication." }, { "v": "4.0.0", "note": "First authoring at 2019 depth, prior to the duplication being identified." } ] }, { "id": "FO-7", "family": "FO", "title": "Obligation Profile Declaration", "control_statement": "The organization shall declare which federal obligations it stands on, with the basis for each inclusion and exclusion, approved by the accountable authority; obligations outside the declared profile shall be scored out of scope rather than as gaps.", "purpose": "To make the scope of the `FO` family an approved position, so that coverage figures are comparable and exclusions are decisions rather than silences.", "goals_cascade": "*Mission outcome* — the mission survives contact and meets its statutory duties. *Defensive intent* — we know which obligations bind us. *This control* — the profile is declared, justified and approved.", "discussion": "This control exists because a denominator that is never written down cannot be compared or challenged. Two agencies reporting `FO` coverage of sixty percent may have scored against entirely different obligation sets, and neither figure means anything without the profile behind it. The exclusion basis carries more weight than the inclusion basis: including an obligation that does not apply is merely wasteful, while excluding one that does is a compliance failure concealed inside a scoping decision that nobody recorded.", "activities": [ { "n": 1, "capability": 2, "text": "Declare which federal obligations the organization stands on." }, { "n": 2, "capability": 2, "text": "Record the basis for each inclusion." }, { "n": 3, "capability": 2, "text": "Record the basis for each exclusion." }, { "n": 4, "capability": 3, "text": "Obtain the accountable authority's approval of the profile as a whole, recorded with date, rather than obligation by obligation." }, { "n": 5, "capability": 3, "text": "Obtain legal confirmation for exclusions, since an exclusion is a determination that a governing instrument does not apply." }, { "n": 6, "capability": 3, "text": "Publish the profile alongside any `FO` coverage figure, so the denominator travels with the number." }, { "n": 7, "capability": 3, "text": "Score obligations outside the profile as out of scope rather than as gaps, and ensure the posture computation under `CE-4` reflects the profile denominator." }, { "n": 8, "capability": 4, "text": "Review the profile on change of mission, authority or governing instrument, and measure the interval between such a change and the profile's revision." }, { "n": 9, "capability": 4, "text": "Measure the proportion of exclusions carrying legal confirmation rather than operational judgment." }, { "n": 10, "capability": 5, "text": "Reconcile the profile against obligations that arose in practice — an obligation encountered operationally but absent from the profile indicates the derivation method is incomplete rather than the instance exceptional." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO" ], "informed": [ "CTI", "SOC", "HT" ] }, "information_flows": "*Inputs* — governing instruments and authorizing legislation; mission and\nauthority records; legal determinations; statutory floors (`FO-5`).\n*Outputs* — approved obligation profile with inclusion and exclusion bases;\nscoped `FO` denominator; input to `CE-4` posture computation and `CG-5` inheritance.", "people_skills": "Statutory and regulatory literacy or reliable access to it. Ability to record a\nscoping determination that will be examined by an auditor.", "policies": "Profile declaration and approval procedure. Exclusion confirmation requirement.\nPublication rule tying the profile to every coverage figure. Review triggers.", "culture": "", "services": "Profile held as data rather than as a document, consumed by the posture\ncomputation so the denominator is enforced rather than described.", "metric_outcome": "percentage of `FO` obligations with a recorded, approved inclusion or exclusion basis.", "metric_performance": "currency of the profile against the most recent change of governing instrument.", "evidence": "Approved obligation profile with inclusion and exclusion bases and approval date; legal confirmations for exclusions; published denominator.", "assessment": "Examine the profile and its approval; test that exclusions carry legal confirmation; test that `FO` coverage figures are computed against the declared profile rather than the full family.", "nist_800_53": [ "PM-1", "PM-9", "PL-1" ], "csf_2_0": [ "GV.OC-03", "GV.OV-02" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Declares the per-agency obligation profile the v2.0 design assumed but never required. Makes the FO denominator an approved, published position so coverage figures are comparable between agencies and exclusions are recorded decisions rather than silences." } ] }, { "id": "WF-1", "family": "WF", "title": "Workforce Terrain Identification", "control_statement": "The organization shall identify on the terrain overlay the roles whose compromise would materially advance an adversary, and record the population holding each.", "purpose": "To make the workforce positional, so that defensive effort concentrates on the roles an adversary would actually target.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the people who hold the estate are defended as ground. *This control* — the roles that matter are identified, with their populations.", "discussion": "Identifying roles rather than individuals is what makes this terrain defensible without becoming personnel monitoring. A role is a standing property of the estate; the people in it change, and defending the role survives that change. Population size is the second half of the picture and is routinely omitted: a privileged role held by three named engineers can be defended by measures that are absurd for a role held by four hundred caseworkers, and a program that records only the role list will apply the wrong move to one or the other.", "activities": [ { "n": 1, "capability": 2, "text": "Mark on the terrain overlay the roles whose compromise would materially advance an adversary." }, { "n": 2, "capability": 2, "text": "Record the population currently holding each marked role." }, { "n": 3, "capability": 2, "text": "Flag privileged roles that are unmarked." }, { "n": 4, "capability": 3, "text": "Define the marking criterion in terms of what an adversary gains, not in terms of seniority or job title." }, { "n": 5, "capability": 3, "text": "Include roles whose access is indirect — helpdesk, delegated administration, approval authorities, and contractor roles with equivalent reach." }, { "n": 6, "capability": 3, "text": "Record the accountable owner for each marked role, reconciled against terrain ownership (TM-7)." }, { "n": 7, "capability": 3, "text": "Justify the exclusion of privileged roles that were considered and not marked, so the boundary is a recorded judgment." }, { "n": 8, "capability": 4, "text": "Trend population size per marked role; growth in a high-value role's population is an expansion of terrain that no asset inventory will report." }, { "n": 9, "capability": 4, "text": "Measure the interval between a role's creation or reclassification and its appearance on the overlay." }, { "n": 10, "capability": 5, "text": "Re-derive the marking criterion from roles actually targeted in engagements and in sector reporting, rather than from assumed adversary preference." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI", "GOV" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); privileged access record; role and\nentitlement catalog; human resources role data; threat reporting on targeted roles.\n*Outputs* — workforce terrain on the overlay with populations and owners;\nexclusion justifications; input to WF-2, WF-3 and TM-3 weighting.", "people_skills": "Entitlement analysis. Ability to reason about indirect access. Working\nrelationship with human resources sufficient to obtain role population data\nwithout obtaining more than is needed.", "policies": "Marking criterion definition. Population recording standard with minimization.\nExclusion justification procedure.", "culture": "", "services": "Overlay support for role elements with population counts. Entitlement data source.\nLinkage from role to the individuals holding it, held under WF-2 rather than here.", "metric_outcome": "percentage of privileged roles marked or explicitly excluded with justification.", "metric_performance": "trend in population size across marked high-value roles.", "evidence": "Workforce terrain section of the Brief; role-to-population record; exclusion justifications; ownership record.", "assessment": "Examine the marked roles against the privileged-access record; interview the accountable owner on why unmarked roles were excluded; test whether indirect-access roles were considered.", "nist_800_53": [ "AT-2", "PS-2", "PM-12" ], "csf_2_0": [ "GV.RR-04", "ID.AM-03" ], "ztmm": "Identity", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires roles with indirect access to be included (helpdesk, delegated administration, approval authorities, equivalent-reach contractor roles), exclusion justifications to be recorded, and population size to be trended. Population growth in a high-value role is an expansion of terrain no asset inventory reports." } ] }, { "id": "WF-2", "family": "WF", "title": "Privileged Human Register", "control_statement": "Every privileged account shall resolve to a named, currently employed, appropriately vetted individual, and the register shall be reconciled on a defined cadence.", "purpose": "To ensure privilege is held by accountable people, so that every privileged action has a person behind it.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — privilege is held accountably. *This control* — every privileged account resolves to a vetted, current person.", "discussion": "Three failure classes hide behind an apparently clean privileged account list: accounts bound to departed staff, accounts bound to nobody at all — shared, service, or legacy — and accounts bound to people whose vetting no longer covers the access they hold. The reconciliation cadence catches the first, the resolution requirement catches the second, and the vetting check catches the third, which is the one most often missed because it fails silently as access accumulates around a person who was correctly cleared for their original role.", "activities": [ { "n": 1, "capability": 2, "text": "Bind every privileged account to a named individual." }, { "n": 2, "capability": 2, "text": "Raise a finding for privileged accounts that resolve to no named holder." }, { "n": 3, "capability": 2, "text": "Reconcile the register against the identity provider on a defined cadence." }, { "n": 4, "capability": 3, "text": "Verify that each named holder is currently employed or under current contract, reconciled against the personnel record." }, { "n": 5, "capability": 3, "text": "Verify that each holder's vetting covers the access currently held, not the access held when they were vetted." }, { "n": 6, "capability": 3, "text": "Record shared, service and non-human accounts distinctly, each with a named accountable human owner, rather than treating them as exceptions to the register." }, { "n": 7, "capability": 3, "text": "Record and time-bound justified exceptions rather than allowing them to persist unmarked." }, { "n": 8, "capability": 4, "text": "Measure accumulated privilege per holder over time, since the common failure is entitlement growth around a correctly vetted person rather than an improperly granted account." }, { "n": 9, "capability": 4, "text": "Trend the count of unresolved and exception accounts, driving both toward zero." }, { "n": 10, "capability": 5, "text": "Drive privilege toward just-in-time issuance where the platform supports it, so the register shrinks rather than being reconciled more often." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — identity provider account data; personnel and contract records;\nvetting status; entitlement catalog; workforce terrain (WF-1).\n*Outputs* — privileged human register with reconciliation dates; exception list\nwith justification and expiry; input to WF-5 revocation and KT-1 designation.", "people_skills": "Identity and entitlement administration. Personnel record reconciliation within\nprivacy limits. Ability to assess whether vetting covers current access.", "policies": "Register schema including non-human accounts. Reconciliation cadence. Vetting\nadequacy standard. Exception time-bounding rule.", "culture": "", "services": "Identity provider with attributable accounts. Personnel record integration.\nEntitlement growth reporting. Just-in-time privilege where available.", "metric_outcome": "percentage of privileged accounts resolving to a current, adequately vetted named individual.", "metric_performance": "accumulated privilege per holder, trended.", "evidence": "Privileged human register with reconciliation dates; exception list with justification and expiry; vetting adequacy records.", "assessment": "Examine the register against the identity provider; test a sample of privileged accounts for a current, vetted holder; test whether vetting covers the access currently held rather than the access originally granted.", "nist_800_53": [ "PS-3", "AC-2(7)", "IA-2(1)" ], "csf_2_0": [ "PR.AA-05", "GV.RR-02" ], "ztmm": "Identity", "d3fend": "Harden tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires vetting to be verified against access currently held rather than access held when vetted; requires shared, service and non-human accounts to be recorded distinctly with a named accountable human rather than treated as register exceptions; adds measurement of accumulated privilege per holder, entitlement growth around a correctly vetted person being the common failure." } ] }, { "id": "WF-3", "family": "WF", "title": "Role-Based Readiness", "control_statement": "Personnel in identified workforce terrain shall receive preparation specific to how their role is actually attacked, and their readiness shall be measured rather than attested.", "purpose": "To prepare people for the attacks their role attracts, and to know whether the preparation worked.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the force can hold its own ground. *This control* — preparation is role-specific and readiness is measured.", "discussion": "Completion is attestation; performance is measurement, and the gap between them is where most awareness programs live. A hundred percent completion rate across generic annual training tells you about administration, not about readiness. Role specificity is the other half: the attacks aimed at a finance approver, a systems administrator and a public-facing caseworker are different, and generic content prepares none of them well. The design constraint worth stating is that measurement here is of a *role's* readiness, and results should be used to direct preparation rather than to identify individuals for sanction — a program that punishes failure gets under-reporting, which is the opposite of what it needs.", "activities": [ { "n": 1, "capability": 2, "text": "Provide preparation to personnel in identified workforce terrain." }, { "n": 2, "capability": 2, "text": "Measure readiness by test or exercise rather than by completion." }, { "n": 3, "capability": 2, "text": "Record results against the role." }, { "n": 4, "capability": 3, "text": "Derive content per role from current reporting on how that role is actually attacked, rather than from a generic curriculum." }, { "n": 5, "capability": 3, "text": "Define the readiness threshold per role and its provenance per GA4." }, { "n": 6, "capability": 3, "text": "Use results to direct further preparation at the role, and define explicitly how individual results may and may not be used." }, { "n": 7, "capability": 3, "text": "Refresh content when the attack pattern against a role changes, not on an annual calendar alone." }, { "n": 8, "capability": 4, "text": "Trend measured readiness per role against its threshold and escalate roles that remain below it across cycles." }, { "n": 9, "capability": 4, "text": "Correlate readiness against real incidents involving those roles, since a readiness measure that does not predict incident involvement is measuring the wrong thing." }, { "n": 10, "capability": 5, "text": "Redesign the role or its controls where readiness cannot be brought to threshold, on the basis that a role people cannot reliably hold is a design problem rather than a training problem." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "TO", "CTI" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — workforce terrain and populations (WF-1); threat reporting by role;\nincident records involving personnel; exercise results.\n*Outputs* — readiness results by role against threshold; content-to-threat\nmapping; input to CE-5 backlog and WF-1 criterion revision.", "people_skills": "Instructional design. Threat translation into role-specific scenarios.\nMeasurement design that tests behavior rather than recall.", "policies": "Role content standard mapped to threat. Readiness threshold definitions with\nprovenance. Explicit rules on permitted use of individual results.", "culture": "", "services": "Role-targeted delivery. Simulation and exercise capability. Result recording at\nrole level with individual data minimized.", "metric_outcome": "measured readiness per marked role against its threshold.", "metric_performance": "currency of role content against current attack reporting.", "evidence": "Exercise results by role; content mapped to the campaigns it prepares for; threshold definitions with provenance.", "assessment": "Examine content against current threat reporting for those roles; test measured results against the stated readiness threshold; examine whether individual results are used within the stated limits.", "nist_800_53": [ "AT-3", "AT-2(1)", "PS-7" ], "csf_2_0": [ "PR.AT-01", "PR.AT-02" ], "ztmm": "Identity", "d3fend": "Harden tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires explicit rules on how individual results may and may not be used, and correlation of measured readiness against real incidents involving those roles. A program that sanctions individuals for simulation failure trains concealment of real incidents. Adds threshold provenance per GA4." } ] }, { "id": "WF-4", "family": "WF", "title": "Insider Risk Position", "control_statement": "The organization shall define, and be able to execute, a rights-respecting process for resolving an indication of insider risk, with a stated disposition period.", "purpose": "To be able to resolve an indication proportionately and lawfully, so that the organization is neither unable to act nor acting without safeguards.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — risk from within is resolved, fairly and within the law. *This control* — a rights-respecting resolution process exists and is executable.", "discussion": "This control is written around resolving an *indication*, not around monitoring a population, and the distinction is the whole design. A process that begins with an indication and proceeds under defined safeguards is insider risk management; a capability that continuously scores individuals for propensity is workforce surveillance, and it corrodes exactly the cooperation that makes the rest of this family work. The rights safeguards are therefore assessed as part of the control rather than treated as an external constraint: legal and privacy review of the process, defined authority to initiate, minimum-necessary access to personal information, a disposition period that prevents indefinite open suspicion, and a route by which a closed indication leaves no residue against the person.", "activities": [ { "n": 1, "capability": 2, "text": "Define the process for resolving an indication of insider risk." }, { "n": 2, "capability": 2, "text": "Name the process owner and the authority required to initiate." }, { "n": 3, "capability": 2, "text": "State the disposition period within which an indication must be resolved." }, { "n": 4, "capability": 3, "text": "Obtain legal and privacy review of the process before it is used, and record the review." }, { "n": 5, "capability": 3, "text": "Define the minimum information the process may access at each stage, so escalation of access follows escalation of evidence rather than preceding it." }, { "n": 6, "capability": 3, "text": "Define how a closed indication is recorded, including that an unsubstantiated indication leaves no adverse residue against the individual." }, { "n": 7, "capability": 3, "text": "Define the route for referral to human resources, counsel or law enforcement, and the point at which the security function ceases to lead." }, { "n": 8, "capability": 3, "text": "Flag open indications exceeding the disposition period." }, { "n": 9, "capability": 4, "text": "Measure disposition times against the stated period, and the proportion of indications closed as unsubstantiated — a rate near zero suggests the threshold to initiate is set too high, and a rate near one that it is too low." }, { "n": 10, "capability": 4, "text": "Test the process against a documented scenario rather than waiting for a real indication to discover it does not work." }, { "n": 11, "capability": 5, "text": "Review closed indications for the conditions that produced them and address those conditions, since most substantiated insider events have precursors that were organizational rather than individual." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI", "HT" ], "informed": [ "SOC", "TO" ] }, "information_flows": "*Inputs* — indications from detection, reporting or referral; legal and privacy\ndeterminations; workforce terrain (WF-1); privileged register (WF-2).\n*Outputs* — documented process with safeguards; disposition record for closed\nindications; referral records; input to CG-4 disposition and WF-1 criterion review.", "people_skills": "Investigative discipline under constraint. Privacy and employment law literacy or\nreliable access to it. Judgment about when to stop.", "policies": "Documented process with legal and privacy review. Initiation authority. Staged\naccess rules. Disposition period and residue rules. Referral routes.", "culture": "", "services": "Case handling with staged access controls and its own audit trail. Retention\naligned to the residue rules. Access to the case system itself restricted and logged.", "metric_outcome": "percentage of indications dispositioned within the stated period.", "metric_performance": "proportion of indications closed as unsubstantiated, trended.", "evidence": "Documented process with legal and privacy review; disposition record for closed indications; scenario test record.", "assessment": "Examine the process for rights safeguards and approval; test that closed indications met the stated period; test whether access escalation followed evidence escalation; examine whether unsubstantiated closures left residue.", "nist_800_53": [ "PM-12", "AU-6(9)", "PS-8" ], "csf_2_0": [ "DE.CM-03", "GV.RR-04" ], "ztmm": "cross-cutting Governance", "d3fend": "Detect tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Rights safeguards made assessable rather than advisory: legal and privacy review recorded before use, staged access rules so escalation of access follows escalation of evidence, explicit residue rules for unsubstantiated closures, and defined handoff to HR, counsel or law enforcement. Adds measurement of the unsubstantiated closure rate as a two-sided indicator of whether the initiation threshold is set correctly. RACI responsibility assigned to governance rather than the SOC." } ] }, { "id": "WF-5", "family": "WF", "title": "Separation and Revocation Tempo", "control_statement": "All access held by a departing or suspended individual shall be removable in a single action, within a period measured against the tempo at which that access could be misused.", "purpose": "To close the window between a person ceasing to be trusted and their access ceasing to work.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — access ends when trust ends. *This control* — revocation is single-action and inside the misuse tempo.", "discussion": "Two properties are being required, and they fail independently. *Single action* fails when access exists outside the primary identity provider — local accounts, SaaS applications provisioned outside single sign-on, VPN credentials, API keys, shared secrets — each of which survives a correctly executed identity-provider disablement. *Within tempo* fails when the process is complete but slow: a revocation that takes four days is not a control against access that could be misused in twenty minutes. The tempo comparison is what connects this control to the TA family, and the period should be derived from what the access could do rather than from what the offboarding process currently achieves.", "activities": [ { "n": 1, "capability": 2, "text": "Define the revocation process for departing and suspended individuals." }, { "n": 2, "capability": 2, "text": "Measure the elapsed time from trigger to complete revocation." }, { "n": 3, "capability": 2, "text": "Raise a finding where measured time exceeds the stated period." }, { "n": 4, "capability": 3, "text": "Derive the required period from the tempo at which the access could be misused, not from current process capability, with provenance per GA4." }, { "n": 5, "capability": 3, "text": "Enumerate every access location outside the primary identity provider and bring each into the single revocation action or record it as an exception." }, { "n": 6, "capability": 3, "text": "Distinguish planned departure, immediate separation and suspension, since the tempo requirement differs sharply between them." }, { "n": 7, "capability": 3, "text": "Verify revocation by testing the access rather than by confirming the ticket closed." }, { "n": 8, "capability": 4, "text": "Trend measured revocation time by separation type against its required period." }, { "n": 9, "capability": 4, "text": "Measure surviving access found by post-revocation testing, which is the direct measure of the single-action property." }, { "n": 10, "capability": 5, "text": "Reduce the number of access locations outside the primary identity provider, since consolidation improves this control more durably than accelerating the process that compensates for fragmentation." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — personnel separation and suspension triggers; privileged register\n(WF-2); identity provider and application entitlement data; access inventory.\n*Outputs* — measured revocation times by separation type; surviving-access\nfindings; exception register; input to TA-5 degradation and CG-4 disposition.", "people_skills": "Identity and access administration across federated and non-federated systems.\nAbility to enumerate shadow access. Verification testing.", "policies": "Revocation procedure by separation type. Required period definition with\nprovenance. Exception register for access outside the single action.\nVerification standard.", "culture": "", "services": "Single-action revocation across federated systems. Access inventory covering\nnon-federated locations. Post-revocation verification tooling.", "metric_outcome": "measured revocation time by separation type against required period.", "metric_performance": "surviving access found by post-revocation testing.", "evidence": "Measured revocation times from exercise or real separations; exception register; post-revocation verification results.", "assessment": "Test a revocation end to end against the stated tempo; examine for access surviving in systems outside the primary identity provider; test whether verification tests access or only confirms process completion.", "nist_800_53": [ "PS-4", "PS-5", "AC-2(3)" ], "csf_2_0": [ "PR.AA-01", "GV.RR-02" ], "ztmm": "Identity", "d3fend": "Evict tactic", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Backfill after FC-2: physical access (badge and facility credentials) made explicit in the enumeration of access outside the primary identity provider. Revocation processes routinely disable the identity-provider account and leave the badge live, which satisfies the single-action property on paper while leaving the person able to enter the building." }, { "v": "4.1.0", "note": "MINOR. Requires the period to be derived from the tempo at which access could be misused rather than from current process capability; requires enumeration of access outside the primary identity provider; distinguishes planned departure, immediate separation and suspension; requires revocation verified by testing access rather than by ticket closure." } ] }, { "id": "FC-1", "family": "FC", "title": "Facility Terrain Identification", "control_statement": "Facilities housing mission systems, data, or personnel in identified workforce terrain shall be represented on the terrain overlay, with the elements each contains recorded.", "purpose": "To resolve the estate to physical locations, so that defense, recovery and continuity can be reasoned about in the place things actually are.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the ground we stand on is part of the defense. *This control* — facilities are on the overlay with their contents recorded.", "discussion": "The test that makes this control concrete is whether every designated decisive point resolves to a named facility. An agency that cannot say which building its identity provider's hardware sits in cannot defend it physically, cannot plan its rebuild under RC-3, and cannot assess whether the environmental sustain period of that building satisfies the recovery objective of everything depending on it. Cloud-hosted elements resolve to a provider region rather than an agency facility, and recording that distinction is part of the control rather than an exemption from it.", "activities": [ { "n": 1, "capability": 2, "text": "Represent on the terrain overlay every facility housing mission systems, data, or personnel in identified workforce terrain." }, { "n": 2, "capability": 2, "text": "Record the elements each facility contains." }, { "n": 3, "capability": 2, "text": "Flag mission elements whose facility is unrecorded." }, { "n": 4, "capability": 3, "text": "Reconcile the facility set against the agency's real property and lease record, including leased, shared and co-located space." }, { "n": 5, "capability": 3, "text": "Resolve every designated decisive point (KT-1) to a named facility or to a recorded provider region, and raise a finding where neither is possible." }, { "n": 6, "capability": 3, "text": "Record facilities housing operational technology and building management systems (FO-4), since those are simultaneously facility and OT terrain." }, { "n": 7, "capability": 3, "text": "Record the accountable owner for each facility, who is frequently outside the security function and must still be reconciled against TM-7." }, { "n": 8, "capability": 4, "text": "Measure the proportion of decisive points resolving to a named location, and trend it." }, { "n": 9, "capability": 4, "text": "Test the recorded contents of a sample of facilities against physical verification rather than against the asset record alone." }, { "n": 10, "capability": 5, "text": "Feed concentration findings into siting decisions — a facility holding a disproportionate share of decisive points is a single point of failure that the overlay makes visible and that procurement can address." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); real property and lease record; decisive points\n(KT-1); workforce terrain (WF-1); OT terrain (FO-4); provider region data.\n*Outputs* — facilities on the overlay with contents and owners; decisive-point\nlocation resolution; input to FC-2 zoning, FC-4 continuity and RC-3 rebuild paths.", "people_skills": "Working relationship with facilities and real property functions. Ability to\nreconcile a physical estate against a logical one. Physical verification\ndiscipline.", "policies": "Facility recording standard including leased and shared space. Decisive-point\nresolution requirement. Ownership reconciliation with TM-7.", "culture": "", "services": "Overlay support for facility elements containing other elements. Real property\ndata source. Provider region recording for hosted elements.", "metric_outcome": "percentage of decisive points resolving to a named facility or recorded provider region.", "metric_performance": "physical verification pass rate on sampled facility contents.", "evidence": "Terrain overlay showing facilities and their contents; real property reconciliation; decisive-point location resolution record.", "assessment": "Examine the overlay against the real property record; test that decisive points resolve to a named facility; verify a sample of recorded contents physically.", "nist_800_53": [ "PE-2", "PE-3", "PM-8" ], "csf_2_0": [ "ID.AM-01", "PR.IR-02" ], "ztmm": "no equivalent pillar — T8 is ASOM-Fed's own", "d3fend": "Model tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires every designated decisive point to resolve to a named facility or a recorded provider region. An agency that cannot say which building its identity provider's hardware occupies cannot defend it physically, plan its rebuild under RC-3, or compare its environmental sustain period against dependent recovery objectives. Adds physical verification of sampled facility contents and concentration findings for siting." } ] }, { "id": "FC-2", "family": "FC", "title": "Physical Zone Boundary", "control_statement": "Facilities shall be divided into zones whose boundaries are enforced and logged, and the zone containing each decisive point shall be identified.", "purpose": "To establish physical boundaries that constrain movement and produce a record of crossing, so that physical terrain can be defended in depth rather than at a perimeter.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — physical movement toward decisive points is constrained and observed. *This control* — zones are declared, enforced, logged, and mapped to decisive points.", "discussion": "These are physical zones and they are not the logical trust zones of TM-4; conflating the two produces an overlay that claims segmentation it does not have in either dimension. The word doing the work here is *enforced*, and its physical failure mode is specific: a boundary that opens for an authorized badge and admits whoever follows has controlled a door without attributing an entry. Enforcement in this control means individual attribution at the crossing, because a log that records which badge opened a door — rather than who passed through it — cannot answer the question an investigation will ask.", "activities": [ { "n": 1, "capability": 2, "text": "Divide each facility into zones and declare their boundaries." }, { "n": 2, "capability": 2, "text": "Identify the zone containing each decisive point." }, { "n": 3, "capability": 2, "text": "Log crossings at each declared boundary." }, { "n": 4, "capability": 3, "text": "Define each zone by the access assumption that holds inside it, and state what entitles a person to be there." }, { "n": 5, "capability": 3, "text": "Identify the mechanism enforcing each boundary and its owner, distinguishing boundaries enforced by construction, by mechanism, and by convention." }, { "n": 6, "capability": 3, "text": "Address unattributed entry — tailgating and piggybacking — at boundaries protecting decisive points, so a crossing resolves to a person rather than to a credential." }, { "n": 7, "capability": 3, "text": "Make crossing logs reviewable and retained for a period matched to the dwell estimate (TA-2), since an investigation reaching back further than retention finds nothing." }, { "n": 8, "capability": 4, "text": "Test a sample of boundaries by attempted traversal rather than by inspecting the access control configuration." }, { "n": 9, "capability": 4, "text": "Trend the count of convention-enforced boundaries protecting decisive points, driving it to zero." }, { "n": 10, "capability": 5, "text": "Re-zone where repeated exception grants show a boundary drawn across normal work, since a boundary routinely bypassed with permission is not a boundary." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — facility terrain (FC-1); decisive points (KT-1); access control system\ndata; dwell estimate (TA-2); workforce terrain (WF-1).\n*Outputs* — zone declaration with enforcement mechanism and owner; crossing logs;\ntraversal test results; input to WF-5 revocation scope and KT-3 avenue analysis.", "people_skills": "Physical security literacy. Adversarial traversal testing. Log retention\nreasoning tied to threat rather than to storage cost.", "policies": "Zone definition and entitlement standard. Enforcement classification. Unattributed\nentry procedure. Log retention standard referencing dwell.", "culture": "", "services": "Access control with individual attribution at decisive-point boundaries. Crossing\nlog retention and review. Traversal test capability.", "metric_outcome": "percentage of decisive points inside a boundary with enforced, attributed crossing.", "metric_performance": "traversal test pass rate on sampled boundaries.", "evidence": "Zone declaration with enforcement mechanism; access logs per boundary; traversal test records; retention configuration.", "assessment": "Examine zone boundaries and their enforcement; test that crossings are logged, attributed and reviewable; test a boundary by attempted traversal; compare log retention against the current dwell estimate.", "nist_800_53": [ "PE-3(1)", "PE-5", "SC-7" ], "csf_2_0": [ "PR.AA-06", "PR.IR-02", "DE.CM-02" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Isolate, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires individual attribution at boundaries protecting decisive points, addressing unattributed entry (tailgating): a log recording which badge opened a door rather than who passed through cannot answer an investigation's question. Requires crossing log retention matched to the dwell estimate (TA-2) rather than to a fixed period. Distinguishes physical zones from TM-4 logical trust zones explicitly." } ] }, { "id": "FC-3", "family": "FC", "title": "Maintenance Access Control", "control_statement": "Vendor and remote maintenance shall occur only within an approved, time-boxed, supervised window, and no maintenance path shall exist outside one.", "purpose": "To ensure the maintenance path — authorized, expected, and outside the normal identity plane — is bounded in time and observed while open.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — no standing path exists into the estate. *This control* — maintenance access is windowed, supervised and absent otherwise.", "discussion": "Maintenance access is the path that bypasses everything else precisely because it is legitimate. It is often granted outside the agency's own identity plane, frequently at a level of privilege the vendor specifies rather than the agency scopes, and it is renewed indefinitely because removing it risks a support contract. The requirement that no path exist *outside* a window is the whole control; a maintenance account that is disabled between windows and a maintenance account that merely goes unused between windows look identical in a register and behave completely differently under compromise.", "activities": [ { "n": 1, "capability": 2, "text": "Record every vendor and remote maintenance path into the estate." }, { "n": 2, "capability": 2, "text": "Approve each maintenance occurrence in advance, time-boxed to a defined window." }, { "n": 3, "capability": 2, "text": "Raise a finding for any standing maintenance path." }, { "n": 4, "capability": 3, "text": "Verify that maintenance access is technically absent outside its window, not merely unused, and record the mechanism achieving that." }, { "n": 5, "capability": 3, "text": "Supervise maintenance sessions with a named agency observer for access touching decisive points, and record the supervision." }, { "n": 6, "capability": 3, "text": "Scope each window to the elements the maintenance requires rather than to the privilege level the vendor requests." }, { "n": 7, "capability": 3, "text": "Log maintenance session activity to the agency's own record, not only to the vendor's, so the account survives the relationship." }, { "n": 8, "capability": 4, "text": "Test that a maintenance path is unavailable outside its window, rather than inspecting the configuration that should make it so." }, { "n": 9, "capability": 4, "text": "Measure the proportion of maintenance sessions with complete agency-side activity records." }, { "n": 10, "capability": 5, "text": "Negotiate maintenance access terms into contract renewal, so the constraint is a procurement condition rather than a recurring exception fought at each occurrence." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — facility terrain (FC-1); OT terrain and constraints (FO-4); supplier\nregister (LC-1); maintenance contracts; decisive points (KT-1).\n*Outputs* — maintenance path inventory with windows, approvals and supervision\nrecords; agency-side session logs; input to LC-3 access constraint and KT-3\navenue analysis.", "people_skills": "Vendor relationship management under constraint. Session supervision. Ability to\nscope access against the task rather than against the vendor's default request.", "policies": "Maintenance approval and windowing procedure. Supervision requirement by element\ncriticality. Agency-side logging standard. Contract term requirements.", "culture": "", "services": "Just-in-time maintenance access provisioning. Session recording to agency-held\nstorage. Window enforcement at the access mechanism.", "metric_outcome": "number of standing maintenance paths, target zero.", "metric_performance": "percentage of maintenance sessions with agency-side activity records.", "evidence": "Maintenance window record with approver and supervision evidence; agency-side session logs; path inventory.", "assessment": "Examine the maintenance path inventory for standing access; test that a path is unavailable outside its window; test whether session activity is recorded to the agency's own systems.", "nist_800_53": [ "MA-4", "MA-5", "MA-3" ], "csf_2_0": [ "PR.AA-05", "PR.PS-03" ], "ztmm": "Identity, Devices", "d3fend": "Isolate, Detect tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires maintenance access to be technically absent outside its window rather than merely unused, with the achieving mechanism recorded; requires session activity logged to agency-held storage so the record survives the vendor relationship; requires scoping to the task rather than to the privilege the vendor requests. States the boundary with LC-3 explicitly to prevent the FO-6/LC-1 duplication pattern recurring." } ] }, { "id": "FC-4", "family": "FC", "title": "Environmental Continuity", "control_statement": "For each facility carrying a mission service, the environmental conditions the service depends on shall be identified, and the period the facility can sustain the service without them shall be stated.", "purpose": "To know how long the physical ground holds without support, so that recovery objectives are not contradicted by the buildings the services sit in.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the mission degrades gracefully rather than abruptly. *This control* — environmental dependencies and sustain periods are known and tested.", "discussion": "This control's value is almost entirely in a comparison that two separate documents make impossible: the environmental sustain period of a facility against the recovery time objectives of the services housed in it. A four-hour uninterruptible supply under a twenty-four-hour recovery objective is a contradiction that is obvious once the two figures are placed side by side and invisible while they live in a facilities record and a continuity plan respectively. Putting facilities on the overlay is what makes the comparison routine.", "activities": [ { "n": 1, "capability": 2, "text": "Identify the environmental conditions each mission-carrying facility depends on — power, cooling, water, connectivity, physical access." }, { "n": 2, "capability": 2, "text": "State the period the facility can sustain the service without each." }, { "n": 3, "capability": 2, "text": "Record both against the facility on the overlay." }, { "n": 4, "capability": 3, "text": "Test the stated sustain periods rather than taking them from design specification or vendor rating." }, { "n": 5, "capability": 3, "text": "Compare each sustain period against the recovery objectives (RC-1) of the services housed there, and raise a finding on every contradiction." }, { "n": 6, "capability": 3, "text": "Include dependencies on external providers and on other facilities, since a sustain period assuming resupply is contingent on the resupply arriving." }, { "n": 7, "capability": 3, "text": "Record the degradation sequence — which services lose availability first as a condition is lost — so the loss is a plan rather than a discovery." }, { "n": 8, "capability": 4, "text": "Trend tested sustain periods, since capacity degrades with equipment age while the recorded figure does not." }, { "n": 9, "capability": 4, "text": "Measure the interval since each sustain period was last tested rather than last recorded." }, { "n": 10, "capability": 5, "text": "Feed persistent contradictions between sustain period and recovery objective into siting, investment or objective revision, rather than carrying the finding indefinitely." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — facility terrain (FC-1); recovery objectives and dependency chains\n(RC-1); environmental system records; external provider agreements.\n*Outputs* — environmental dependency record with tested sustain periods;\ncontradiction findings against recovery objectives; degradation sequence; input\nto RC-1 re-basing and RC-5 exercise scenarios.", "people_skills": "Facilities engineering literacy. Test design for environmental systems.\nAbility to reason across a facilities record and a continuity plan.", "policies": "Dependency identification standard. Sustain period testing procedure and cadence.\nComparison requirement against recovery objectives.", "culture": "", "services": "Environmental monitoring with capacity reporting. Test capability without\ndisrupting mission services. Overlay fields for dependencies and periods.", "metric_outcome": "percentage of mission-carrying facilities whose tested sustain period satisfies the recovery objectives of services housed there.", "metric_performance": "median age of the most recent sustain period test.", "evidence": "Environmental dependency record; ride-through test results; comparison against recovery objectives; degradation sequence.", "assessment": "Examine the stated periods against test evidence; compare against the recovery objectives of the services housed there; test whether periods derive from measurement or from design specification.", "nist_800_53": [ "PE-11", "PE-13", "CP-2" ], "csf_2_0": [ "PR.IR-04", "RC.RP-01" ], "ztmm": "cross-cutting Governance", "d3fend": "Restore tactic", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires sustain periods to be tested rather than taken from design specification or vendor rating, and compared against the recovery objectives (RC-1) of services housed in the facility, raising a finding on every contradiction. A four-hour supply under a twenty-four-hour objective is invisible while the two figures live in separate documents. Adds the degradation sequence so loss order is planned rather than discovered." } ] }, { "id": "LC-1", "family": "LC", "title": "Supplier Terrain Register", "control_statement": "Suppliers, integrators and managed-service providers with a path into the estate shall be registered on the terrain overlay, with the access each holds and the elements it reaches recorded.", "purpose": "To make third parties positional, so that supplier risk is assessed against what a supplier can reach rather than against what they were contracted to do.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the routes by which we are resupplied are known and defended. *This control* — every supplier with a path in is on the overlay, with its reach.", "discussion": "Procurement already holds a vendor list; this is not that. The distinguishing requirement is *the elements it reaches* — a supplier with a narrow contract and broad technical access is the case this control exists to surface, and it is invisible on any acquisition record because the contract describes intent while the entitlement describes capability. Reconciling the register against provisioned access rather than against contracts is therefore the control's operative activity, and it routinely finds access that outlived the engagement that justified it.", "activities": [ { "n": 1, "capability": 2, "text": "Register every supplier, integrator and managed-service provider holding a path into the estate as an external actor on the overlay." }, { "n": 2, "capability": 2, "text": "Record the access each holds and the elements that access reaches." }, { "n": 3, "capability": 2, "text": "Raise a finding for suppliers holding unrecorded access." }, { "n": 4, "capability": 3, "text": "Reconcile the register against provisioned access in the identity and network estate, not against the acquisition record, since contracts describe intent and entitlements describe capability." }, { "n": 5, "capability": 3, "text": "Record reach transitively where a supplier's access permits movement beyond the element it terminates on." }, { "n": 6, "capability": 3, "text": "Raise a finding for any supplier holding standing access to a decisive point (KT-1), and route it to LC-3 for constraint." }, { "n": 7, "capability": 3, "text": "Reconcile against the SCRM scope under FO-6, so an access-holding supplier outside that scope is a recorded position rather than an oversight." }, { "n": 8, "capability": 4, "text": "Trend the count of suppliers and the aggregate weight of elements they reach, since supplier reach expands quietly through renewals and scope changes." }, { "n": 9, "capability": 4, "text": "Measure the interval between engagement end and access removal, which is the window in which reach exists with no contract behind it." }, { "n": 10, "capability": 5, "text": "Feed reach findings into acquisition, so access scope is specified before award rather than discovered at the next reconciliation." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); connection register (TM-5); identity and\nnetwork entitlement data; acquisition record; SCRM scope (FO-6).\n*Outputs* — supplier terrain register with access and reach; standing-access\nfindings; input to LC-3 constraint, LC-5 severance and KT-3 avenue analysis.", "people_skills": "Entitlement analysis across federated and vendor-managed systems. Transitive\nreach reasoning. Working relationship with acquisition.", "policies": "Register schema including reach. Reconciliation against provisioned access.\nStanding-access finding procedure. FO-6 scope reconciliation.", "culture": "", "services": "Overlay support for supplier external actors with access paths. Entitlement data\nacross vendor-managed systems. Reach computation.", "metric_outcome": "percentage of suppliers whose recorded reach matches provisioned access.", "metric_performance": "median interval between engagement end and access removal.", "evidence": "Supplier terrain register reconciled to provisioned access; standing-access findings; FO-6 scope reconciliation.", "assessment": "Examine the register against contracts and against provisioned access; test for suppliers holding access not in the register; test whether reach was recorded transitively.", "nist_800_53": [ "SR-2", "SA-9", "PM-30" ], "csf_2_0": [ "GV.SC-04", "ID.AM-04" ], "ztmm": "cross-cutting Governance", "d3fend": "Model tactic", "version": "4.2.0", "changes": [ { "v": "4.2.0", "note": "MINOR. Confirmed as sole owner of the supplier terrain register following the FO-6 narrowing. Requires reconciliation against provisioned access rather than the acquisition record, since contracts describe intent and entitlements describe capability; requires transitive reach to be recorded; requires reconciliation against SCRM scope under FO-6 so an access-holding supplier outside scope is a recorded position rather than an oversight." }, { "v": "4.0.0", "note": "First authoring at 2019 depth." } ] }, { "id": "LC-2", "family": "LC", "title": "Component Provenance", "control_statement": "Software and hardware components deployed into the estate shall resolve to a verified origin, and the organization shall maintain a current inventory of what those components contain.", "purpose": "To know where deployed components came from and what is inside them, so that a compromise disclosed anywhere can be located here.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — what we deploy is what we intended to deploy. *This control* — origin is verified and contents are inventoried.", "discussion": "Provenance and contents are two different questions and both are required. Provenance answers where a component came from; the inventory answers what it carries. A correctly signed package containing a vulnerable transitive dependency has verified provenance and unknown content, and an agency holding only the first cannot answer the question that actually arrives — *are we running this?* — when a component compromise is disclosed. The practical measure of this control is time to answer that question across the whole estate, which is why that is its outcome metric rather than inventory completeness.", "activities": [ { "n": 1, "capability": 2, "text": "Record the origin of each deployed software and hardware component." }, { "n": 2, "capability": 2, "text": "Verify signatures or equivalent origin evidence before deployment." }, { "n": 3, "capability": 2, "text": "Maintain an inventory of what each deployed component contains." }, { "n": 4, "capability": 3, "text": "Extend the inventory to transitive dependencies rather than to direct components alone, since disclosure typically names a dependency." }, { "n": 5, "capability": 3, "text": "Raise a finding for artifacts whose origin cannot be verified, and define whether deployment may proceed and under whose authority." }, { "n": 6, "capability": 3, "text": "Keep the inventory current at deployment rather than reconstructing it on demand, since reconstruction under disclosure pressure is slow and incomplete." }, { "n": 7, "capability": 3, "text": "Extend provenance to firmware and hardware components, where verification is hardest and substitution is least visible." }, { "n": 8, "capability": 4, "text": "Measure time to answer \"are we running this component, and where\" across the estate, and treat that interval as the control's real capability." }, { "n": 9, "capability": 4, "text": "Measure inventory coverage against the deployed estate, distinguishing components inventoried from components merely recorded." }, { "n": 10, "capability": 5, "text": "Automate inventory generation into the deployment pipeline, so currency is a property of deploying rather than a periodic exercise." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "CTI", "GOV" ], "informed": [ "SOC", "HT" ] }, "information_flows": "*Inputs* — deployment pipeline artifacts; vendor-supplied component inventories;\nsignature and attestation infrastructure; supplier register (LC-1).\n*Outputs* — component inventory per artifact with provenance verification\nresults; unverifiable-artifact findings; input to LC-4 staging, RC-3 rebuild media\nand CE-2 requirement answering.", "people_skills": "Software supply chain literacy. Signature and attestation verification. Pipeline\nintegration.", "policies": "Provenance verification standard. Inventory currency requirement. Unverifiable\nartifact procedure with named deployment authority.", "culture": "", "services": "Artifact repository with provenance metadata. Component inventory generation in\nthe pipeline. Estate-wide component search.", "metric_outcome": "time to answer whether a named component is deployed and where.", "metric_performance": "percentage of deployed artifacts with verified provenance and a current component inventory.", "evidence": "Component inventory per artifact; signature and origin verification results; unverifiable-artifact findings with authorization.", "assessment": "Examine the inventory for currency and completeness; test verification on a sample of deployed artifacts; test the estate-wide search by naming a component and timing the answer.", "nist_800_53": [ "SR-4", "SR-11", "SA-10" ], "csf_2_0": [ "GV.SC-08", "ID.RA-09" ], "ztmm": "Applications and Workloads", "d3fend": "Model, Harden tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Separates provenance from contents explicitly: a correctly signed package containing a vulnerable transitive dependency has verified provenance and unknown content. Requires the inventory to extend to transitive dependencies and to be current at deployment rather than reconstructed under disclosure pressure. Outcome metric changed to time-to-answer whether a named component is deployed and where, which is the control's real capability." } ] }, { "id": "LC-3", "family": "LC", "title": "Supplier Access Constraint", "control_statement": "Supplier access shall be brokered through the organization's own identity plane and constrained to the elements the engagement requires, with no standing access to a decisive point.", "purpose": "To keep supplier access scoped, observable, and revocable by the agency rather than by the supplier.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — third-party reach is bounded and under our control. *This control* — access is brokered, scoped, and never standing on decisive points.", "discussion": "Brokering is the requirement that carries the rest. Where a supplier holds credentials the supplier issued, the agency can request removal but cannot perform it — which means LC-5's severance capability does not exist regardless of what the contract says. Routing access through the agency's own identity plane converts severance from a negotiation into an action. The scoping requirement addresses the second failure: supplier access is habitually provisioned at the privilege level the supplier requests, which reflects their convenience across all customers rather than this engagement's need.", "activities": [ { "n": 1, "capability": 2, "text": "Route supplier access through the organization's own identity plane." }, { "n": 2, "capability": 2, "text": "Scope each supplier's access to the elements the engagement requires." }, { "n": 3, "capability": 2, "text": "Raise a finding for standing access to any designated decisive point." }, { "n": 4, "capability": 3, "text": "Record for each supplier access grant its broker, scope and expiry, and set an expiry in every case rather than only where one is obvious." }, { "n": 5, "capability": 3, "text": "Verify that revocation is technically within the agency's control, not dependent on supplier action." }, { "n": 6, "capability": 3, "text": "Apply the constraint to supplier-managed infrastructure and vendor-operated services, where the identity plane is most often the supplier's by default." }, { "n": 7, "capability": 3, "text": "Re-scope on engagement change rather than allowing scope to accumulate across successive contracts." }, { "n": 8, "capability": 4, "text": "Measure provisioned supplier access against engagement scope and trend the divergence." }, { "n": 9, "capability": 4, "text": "Measure the proportion of supplier access grants that are agency-revocable without supplier cooperation." }, { "n": 10, "capability": 5, "text": "Move brokering requirements into contract terms at renewal, so the constraint is a condition of engagement rather than an exception negotiated per grant." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — supplier register (LC-1); decisive points (KT-1); engagement scope and\ncontracts; identity plane configuration.\n*Outputs* — supplier access records with broker, scope and expiry; revocability\nverification; input to LC-5 severance and WF-5 revocation enumeration.", "people_skills": "Federated identity administration. Contract-to-entitlement translation. Ability\nto scope against engagement need rather than vendor default request.", "policies": "Brokering requirement. Scope derivation from engagement. Expiry rule.\nRevocability verification standard. Contract term requirements.", "culture": "", "services": "Identity broker covering supplier-managed infrastructure. Scoped entitlement\nprovisioning with expiry. Agency-controlled revocation.", "metric_outcome": "percentage of supplier access grants brokered, scoped and agency-revocable.", "metric_performance": "divergence between provisioned access and engagement scope.", "evidence": "Supplier access records showing broker, scope and expiry; revocability verification results.", "assessment": "Examine provisioned supplier access against the engagement scope; test that revocation is within the agency's control; test whether supplier-managed infrastructure is brokered or exempted.", "nist_800_53": [ "SR-5", "AC-20", "SA-9(2)" ], "csf_2_0": [ "GV.SC-07", "PR.AA-05", "DE.CM-06" ], "ztmm": "Identity", "d3fend": "Isolate, Harden tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires verification that revocation is technically within the agency's control rather than dependent on supplier action, which is the precondition for LC-5 severance. Requires an expiry on every grant rather than only where obvious, and application to supplier-managed infrastructure where the identity plane is the supplier's by default. States the FC-3 boundary explicitly." } ] }, { "id": "LC-4", "family": "LC", "title": "Update Integrity and Staging", "control_statement": "Supplier-provided updates shall be integrity-verified before deployment and shall pass through a staging ring for a stated period before reaching the whole estate.", "purpose": "To limit the blast radius of a compromised trusted update, so that supply chain compromise reaches a ring rather than the estate.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — a trusted channel that turns hostile is contained. *This control* — updates are verified and soaked in a ring before general release.", "discussion": "The soak period is the control, and its length is the part most often chosen arbitrarily. A staging ring protects only if the soak exceeds the time the organization needs to notice something wrong — so the period should be derived from the measured detection segment of the decision loop under TA-1, not from a release calendar. An estate with a ten-day detect segment and a twenty-four-hour soak has implemented staging and gained almost nothing from it, and that mismatch is invisible unless the two figures are compared deliberately.", "activities": [ { "n": 1, "capability": 2, "text": "Integrity-verify supplier-provided updates before deployment." }, { "n": 2, "capability": 2, "text": "Pass updates through a staging ring before general release." }, { "n": 3, "capability": 2, "text": "Record the staging ring composition and the soak period applied." }, { "n": 4, "capability": 3, "text": "Derive the soak period from the measured detection segment under TA-1, with provenance per GA4, rather than from a release calendar." }, { "n": 5, "capability": 3, "text": "Compose the staging ring to be representative of the estate rather than of the systems most tolerant of disruption, since an unrepresentative ring detects nothing about the systems that matter." }, { "n": 6, "capability": 3, "text": "Define and record the emergency bypass path, its authority and its compensating measures, since bypass will occur and an undefined bypass is unbounded." }, { "n": 7, "capability": 3, "text": "Instrument the ring for behavioral change, not only for functional failure — a compromised update usually works correctly." }, { "n": 8, "capability": 4, "text": "Measure the proportion of updates traversing the ring against those bypassing it, and trend bypass rate." }, { "n": 9, "capability": 4, "text": "Compare the applied soak period against the current detection segment each cycle, and raise a finding where soak is shorter." }, { "n": 10, "capability": 5, "text": "Shorten the required soak by improving detection rather than by accepting more risk, since the two are the same trade viewed from opposite ends." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "CTI" ], "informed": [ "GOV", "HT" ] }, "information_flows": "*Inputs* — supplier-provided updates; component provenance (LC-2); detection\nsegment measurement (TA-1); staging ring telemetry.\n*Outputs* — staging records with soak periods; integrity verification results;\nbypass record with authority; input to LC-5 and CE-5 backlog.", "people_skills": "Release engineering. Ring composition design. Behavioral detection in a staging\nenvironment rather than functional testing alone.", "policies": "Integrity verification standard. Soak period derivation with provenance. Ring\ncomposition standard. Emergency bypass procedure with named authority.", "culture": "", "services": "Staged deployment infrastructure with representative ring. Integrity verification\nin the pipeline. Behavioral telemetry in the ring.", "metric_outcome": "percentage of updates traversing the staging ring for the full soak period.", "metric_performance": "applied soak period against the current measured detection segment.", "evidence": "Staging records with soak periods; integrity verification results per update; bypass records with authority and compensating measures.", "assessment": "Examine the declared soak period and its rationale against the measured detection segment; test that a sample of updates traversed the ring; examine the bypass rate and its authorizations.", "nist_800_53": [ "SI-2", "SR-11(1)", "CM-3" ], "csf_2_0": [ "ID.RA-01", "PR.PS-02" ], "ztmm": "Applications and Workloads", "d3fend": "Detect, Isolate tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Soak period derived from the measured detection segment under TA-1 with provenance per GA4, rather than chosen from a release calendar: a ring protects only if soak exceeds time-to-notice. Requires the ring to be representative of the estate rather than of the systems most tolerant of disruption, behavioral instrumentation rather than functional testing alone, and a defined emergency bypass path with named authority." } ] }, { "id": "LC-5", "family": "LC", "title": "Supplier Severance Capability", "control_statement": "The organization shall be able to sever a supplier's access within a stated period and continue the mission, and shall have demonstrated it.", "purpose": "To retain the option of cutting a line of communication, so that a compromised or failed supplier is a decision rather than a dependency.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — no supplier relationship is unbreakable. *This control* — severance is possible within a stated period and demonstrated.", "discussion": "Two halves, and the second is the one usually missing. Severing access is an identity and network action that LC-3's brokering makes achievable. Continuing the mission afterwards is an operational question that nobody answers until it is urgent — and for a managed-service provider or a sole-source integrator, the honest answer may be that the mission cannot continue, which is itself a finding worth having in advance rather than during. Severance without continuity is not a defensive option; it is an outage the agency chose.", "activities": [ { "n": 1, "capability": 2, "text": "Define the procedure for severing each supplier's access." }, { "n": 2, "capability": 2, "text": "State the period within which severance must be achievable." }, { "n": 3, "capability": 2, "text": "Record the authority required to initiate severance." }, { "n": 4, "capability": 3, "text": "Assess mission continuity following severance for each supplier, and record where the mission cannot continue as a finding rather than as an accepted state." }, { "n": 5, "capability": 3, "text": "Derive the required period from what the supplier's access could do if turned hostile, with provenance per GA4, rather than from contractual notice terms." }, { "n": 6, "capability": 3, "text": "Demonstrate severance for suppliers whose reach includes a decisive point, rather than for the easiest supplier to test." }, { "n": 7, "capability": 3, "text": "Distinguish severance from termination, since access must be removable without ending the commercial relationship." }, { "n": 8, "capability": 4, "text": "Measure demonstrated severance time against the stated period and trend it." }, { "n": 9, "capability": 4, "text": "Measure the proportion of decisive-point-reaching suppliers whose severance has been demonstrated at all." }, { "n": 10, "capability": 5, "text": "Reduce single-supplier dependency where continuity assessment shows the mission cannot survive severance, since that is a resilience problem that no access control resolves." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — supplier register and reach (LC-1); brokered access records (LC-3);\nmission service dependencies (RC-1); contracts and notice terms.\n*Outputs* — severance procedures with demonstrated times; continuity assessment\nper supplier; findings where continuity fails; input to RC-5 exercise scenarios\nand CG-4 disposition.", "people_skills": "Operational continuity assessment. Identity and network severance execution.\nCommercial literacy sufficient to separate access removal from contract action.", "policies": "Severance procedure per supplier. Period derivation with provenance. Continuity\nassessment requirement. Demonstration cadence and scope.", "culture": "", "services": "Agency-controlled revocation across brokered access. Alternate service capability\nwhere continuity requires it. Severance test capability.", "metric_outcome": "percentage of decisive-point-reaching suppliers with demonstrated severance within the stated period.", "metric_performance": "demonstrated severance time against stated period, trended.", "evidence": "Severance exercise record: supplier, elapsed time, mission impact observed; continuity assessment per supplier; findings where continuity fails.", "assessment": "Examine the procedure and its authorization; test severance for one supplier against the stated period; examine whether any decisive-point-reaching supplier has been tested; examine continuity findings.", "nist_800_53": [ "SR-8", "IR-4", "CP-2(7)" ], "csf_2_0": [ "GV.SC-10", "RS.MA-01" ], "ztmm": "cross-cutting Governance", "d3fend": "Isolate, Evict tactics", "version": "4.1.0", "changes": [ { "v": "4.1.0", "note": "MINOR. Requires mission continuity assessment following severance, recorded as a finding where the mission cannot continue rather than accepted silently. Requires the period derived from what the access could do if turned hostile rather than from contractual notice terms; requires demonstration for suppliers reaching decisive points rather than for the easiest supplier to test; distinguishes severance from termination." } ] }, { "id": "ID-1", "family": "ID", "title": "Identity Plane Definition", "control_statement": "The organization shall identify on the terrain overlay every authoritative identity plane, the policy decision and enforcement points it operates, and the trust relationships between planes.", "purpose": "To make identity positional, so that the plane controlling movement everywhere else is itself defensible ground rather than an assumed service.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — identity, not network location, is the decisive plane. *This control* — that plane is mapped, with its enforcement points and trust edges.", "discussion": "Most estates have more than one identity plane and have never drawn the relationships between them: a primary provider, a legacy directory, a cloud tenant, one or more federated partners, and a set of local account stores that answer to nobody. Trust edges between planes are the highest-value terrain in the estate, because compromise of a low-assurance plane that a high-assurance plane trusts confers the higher assurance. That is the identity equivalent of an unmapped mobility corridor, and it is invisible on a network diagram.", "activities": [ { "n": 1, "capability": 2, "text": "Identify every authoritative identity plane serving the estate and place it on the overlay." }, { "n": 2, "capability": 2, "text": "Record the policy decision and enforcement points each plane operates." }, { "n": 3, "capability": 2, "text": "Record which elements depend on which plane for authorization." }, { "n": 4, "capability": 3, "text": "Enumerate trust relationships between planes — federation, synchronisation, directory trust, token exchange — and record their direction and assurance." }, { "n": 5, "capability": 3, "text": "Identify local and non-federated account stores as identity planes in their own right rather than as exceptions, since an unmapped store is an unmapped plane." }, { "n": 6, "capability": 3, "text": "Designate the primary plane and any plane whose compromise would confer control of it as decisive points under `KT-1`." }, { "n": 7, "capability": 3, "text": "Record for each enforcement point whether it is consulted on every authorization decision or only at session establishment." }, { "n": 8, "capability": 4, "text": "Trend the count of identity planes and trust edges; growth is terrain expansion that no asset inventory reports." }, { "n": 9, "capability": 4, "text": "Test that enforcement points are actually consulted, rather than accepting the architecture's claim that they are." }, { "n": 10, "capability": 5, "text": "Consolidate planes and retire trust edges where the estate permits, since reducing the terrain is more durable than defending more of it." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "CTI" ], "informed": [ "GOV", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); identity provider and directory configuration;\nfederation agreements; application authorization configuration.\n*Outputs* — identity planes and trust edges on the overlay; enforcement point\nregister; input to `KT-1` designation, `KT-3` avenue analysis and `ID-5`.", "people_skills": "Federated identity architecture. Ability to recognize an implicit trust edge.\nDirectory and token protocol literacy.", "policies": "Identity plane definition standard. Trust edge recording requirement. Enforcement\npoint classification.", "culture": "", "services": "Overlay support for identity plane elements and trust edges. Configuration access\nacross directories, federation and cloud tenants.", "metric_outcome": "percentage of estate elements whose authorizing plane is recorded.", "metric_performance": "count of identity planes and trust edges, trended.", "evidence": "Overlay showing identity planes, enforcement points and trust edges; plane dependency record.", "assessment": "Examine the overlay against directory and federation configuration; test for local or non-federated stores absent from the plane list; test whether a sampled enforcement point is consulted on authorization.", "nist_800_53": [ "IA-8", "AC-3", "PM-5" ], "csf_2_0": [ "PR.AA-01", "ID.AM-01" ], "ztmm": "Identity", "d3fend": "Model tactic", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Identity plane, enforcement point and trust edge mapping. Trust edges between planes are the highest-value terrain in the estate and are invisible on a network diagram." } ] }, { "id": "ID-2", "family": "ID", "title": "Credential Strength and Binding", "control_statement": "Identities shall be proofed to a level commensurate with the access they confer, and bound to credentials whose strength matches that level.", "purpose": "To ensure the credential is as strong as the access behind it, so that proofing and authentication assurance are matched rather than assumed.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — a credential confers only what its assurance justifies. *This control* — proofing and credential strength match the access conferred.", "discussion": "The failure this addresses is drift rather than misconfiguration. A person proofed at one level and issued a credential appropriate to it accumulates access over subsequent years, and nothing re-examines whether the original proofing still justifies the current entitlement. `WF-2` catches this for privileged humans; this control generalises it to every identity including non-human ones, where the problem is worse because service identities are routinely issued long-lived secrets and then granted whatever access their consuming application later requires.", "activities": [ { "n": 1, "capability": 2, "text": "Record the proofing level applied to each identity." }, { "n": 2, "capability": 2, "text": "Record the credential type bound to each identity." }, { "n": 3, "capability": 2, "text": "Raise a finding where credential strength is below the access conferred." }, { "n": 4, "capability": 3, "text": "Define the required proofing and credential strength per access tier, with provenance per `GA4`." }, { "n": 5, "capability": 3, "text": "Apply the requirement to non-human identities — service accounts, workload identities, API credentials — where binding is to an owning system and a named accountable human rather than to a person." }, { "n": 6, "capability": 3, "text": "Require phishing-resistant credentials for identities reaching decisive points, and record exceptions with expiry." }, { "n": 7, "capability": 3, "text": "Re-examine proofing adequacy when access changes, not only when the identity is created." }, { "n": 8, "capability": 4, "text": "Measure the gap between proofing level and access conferred across the population, and trend it." }, { "n": 9, "capability": 4, "text": "Measure the count and age of long-lived non-human secrets, since these are the credentials least likely to be rotated and most likely to be exfiltrated." }, { "n": 10, "capability": 5, "text": "Move non-human identities to short-lived, workload-attested credentials where the platform permits, retiring the long-lived secret class rather than managing it." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — identity planes (`ID-1`); entitlement data; proofing records; privileged\nregister (`WF-2`); decisive points (`KT-1`).\n*Outputs* — proofing and credential record per identity; mismatch findings;\nnon-human secret inventory; input to `ID-3` and `WF-5` revocation scope.", "people_skills": "Identity proofing standards literacy. Non-human identity management. Ability to\nreason about assurance rather than about credential type alone.", "policies": "Proofing and credential strength standard per access tier. Non-human identity\nbinding rule. Exception register with expiry.", "culture": "", "services": "Credential lifecycle management covering non-human identities. Proofing record\nlinkage. Secret age reporting.", "metric_outcome": "percentage of identities whose credential strength matches conferred access.", "metric_performance": "count and median age of long-lived non-human secrets.", "evidence": "Proofing and credential record per identity; mismatch findings; non-human secret inventory with ages.", "assessment": "Examine the proofing standard and its provenance; test a sample of identities for credential strength against conferred access; test whether non-human identities are within scope in practice.", "nist_800_53": [ "IA-5", "IA-12", "IA-9" ], "csf_2_0": [ "PR.AA-02", "PR.AA-01" ], "ztmm": "Identity", "d3fend": "Harden tactic", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Proofing and credential strength matched to conferred access, extended to non-human identities where long-lived secrets are the dominant failure." } ] }, { "id": "ID-3", "family": "ID", "title": "Authentication Assurance", "control_statement": "Users, services and devices shall be authenticated at an assurance level commensurate with the terrain being accessed, and the assurance achieved shall be recorded with the authorization decision.", "purpose": "To ensure authentication strength varies with what is being reached, and that the level achieved is available to the decision that relies on it.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — a stolen credential, on its own, yields no movement. *This control* — authentication assurance matches terrain and is recorded.", "discussion": "`M3` Envelopment's stated indicator is that a stolen credential alone yields no movement, and this is the control that makes it assessable. The requirement that assurance be *recorded with the decision* is the part usually missing: an estate can enforce strong authentication at the front door and then issue a session that every downstream service accepts without knowing how it was obtained. Carrying the assurance level into the authorization decision is what allows a service holding decisive-point data to refuse a session that was established weakly, which is the difference between authenticating once and authenticating appropriately.", "activities": [ { "n": 1, "capability": 2, "text": "Authenticate users, services and devices before granting access." }, { "n": 2, "capability": 2, "text": "Define the assurance level required per terrain layer or access tier." }, { "n": 3, "capability": 2, "text": "Record the assurance level achieved at authentication." }, { "n": 4, "capability": 3, "text": "Carry the achieved assurance level into the authorization decision, so a service can refuse a session established below its requirement." }, { "n": 5, "capability": 3, "text": "Require step-up authentication on transition to higher-assurance terrain rather than only at session establishment." }, { "n": 6, "capability": 3, "text": "Apply device assurance as an input where the terrain warrants it, so authentication is not credential-only." }, { "n": 7, "capability": 3, "text": "Record and time-bound every path that bypasses the assurance requirement, including legacy protocols that cannot carry it." }, { "n": 8, "capability": 4, "text": "Measure the proportion of authorization decisions made with assurance level available, since a decision made without it is made blind." }, { "n": 9, "capability": 4, "text": "Test resistance directly: attempt authentication with a captured credential and confirm it yields no usable session for decisive-point terrain." }, { "n": 10, "capability": 5, "text": "Retire bypass paths and legacy protocols rather than compensating for them, since each is a standing exception to the form's own indicator." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — identity planes and enforcement points (`ID-1`); credential binding\n(`ID-2`); terrain classification (`TM-2`); decisive points (`KT-1`).\n*Outputs* — assurance requirement per terrain; achieved-assurance records; bypass\nregister; input to `ID-5` and `M3` technique evidencing.", "people_skills": "Authentication protocol literacy. Step-up and conditional access design.\nAdversarial credential testing.", "policies": "Assurance level standard per terrain. Step-up trigger definition. Bypass register\nwith expiry.", "culture": "", "services": "Authentication capable of emitting assurance level. Authorization able to consume\nit. Step-up capability. Device assurance signal where required.", "metric_outcome": "result of captured-credential testing against decisive-point terrain.", "metric_performance": "percentage of authorization decisions with assurance level available.", "evidence": "Assurance requirements per terrain; achieved-assurance records; bypass register; credential resistance test results.", "assessment": "Examine the assurance standard against terrain classification; test that a captured credential yields no usable session for decisive-point terrain; examine the bypass register for expiry.", "nist_800_53": [ "IA-2", "IA-2(1)", "IA-3" ], "csf_2_0": [ "PR.AA-03", "PR.AA-05" ], "ztmm": "Identity, Devices", "d3fend": "Harden, Detect tactics", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Authentication assurance carried into the authorization decision, with direct captured-credential testing. Makes M3 Envelopment's stated indicator assessable for the first time." } ] }, { "id": "ID-4", "family": "ID", "title": "Identity Assertion Protection", "control_statement": "Identity assertions, tokens and session material shall be protected against interception, replay and forgery, and their validity shall be bounded in time and scope.", "purpose": "To prevent a valid authentication from becoming a durable, portable credential in an adversary's hands.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — authentication cannot be stolen after the fact. *This control* — assertions are protected, bounded and revocable.", "discussion": "Strong authentication is routinely defeated downstream rather than at the point of authentication: the token issued after a phishing-resistant login is frequently a bearer credential with a long lifetime, broad scope and no binding to the device that obtained it. An adversary who takes it inherits the assurance without the credential. Signing key protection is the same problem one level up — an adversary holding the issuing key can forge assertions at any assurance level and will not appear in authentication logs at all.", "activities": [ { "n": 1, "capability": 2, "text": "Protect assertions and tokens in transit and at rest." }, { "n": 2, "capability": 2, "text": "Bound assertion validity in time." }, { "n": 3, "capability": 2, "text": "Bound assertion scope to the access required." }, { "n": 4, "capability": 3, "text": "Bind assertions to the device or client that obtained them where the platform permits, so a stolen token is not portable." }, { "n": 5, "capability": 3, "text": "Protect assertion signing keys at a level commensurate with the access forgeable assertions would confer, and record where they are held." }, { "n": 6, "capability": 3, "text": "Key assertion lifetime to campaign phase (`CG-2`), so a declared Phase III shortens session lifetimes without a change request." }, { "n": 7, "capability": 3, "text": "Provide estate-wide session revocation and verify it reaches every consuming service, not only the issuing plane." }, { "n": 8, "capability": 4, "text": "Measure assertion lifetime distribution against the requirement per terrain, and trend the tail rather than the median." }, { "n": 9, "capability": 4, "text": "Test estate-wide revocation end to end and measure elapsed time to effect across consuming services." }, { "n": 10, "capability": 5, "text": "Move toward continuous evaluation, so authorization is re-decided during a session rather than settled at its start." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — identity planes and enforcement points (`ID-1`); assurance records\n(`ID-3`); campaign phase (`CG-2`); key management records.\n*Outputs* — assertion protection configuration; lifetime and scope records;\nrevocation test results; input to `M8` retrograde and `TA-1` containment segment.", "people_skills": "Token and session protocol literacy. Key management. Understanding of which\nconsuming services honor revocation and which cache.", "policies": "Assertion lifetime and scope standard per terrain. Signing key protection\nstandard. Phase-keyed lifetime rules. Revocation verification procedure.", "culture": "", "services": "Token binding where supported. Hardware-protected signing keys. Estate-wide\nrevocation reaching consuming services. Phase-aware lifetime configuration.", "metric_outcome": "measured time to effect for estate-wide session revocation.", "metric_performance": "assertion lifetime distribution against requirement, tail-weighted.", "evidence": "Assertion protection configuration; lifetime and scope records; signing key protection record; revocation test results.", "assessment": "Examine lifetime and scope against terrain requirements; test estate-wide revocation reaching consuming services; examine signing key protection against the access forgeable assertions would confer.", "nist_800_53": [ "IA-5(2)", "SC-8", "SC-23" ], "csf_2_0": [ "PR.AA-04", "PR.DS-02" ], "ztmm": "Identity", "d3fend": "Harden, Evict tactics", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Assertion, token and session protection with lifetime keyed to campaign phase and verified estate-wide revocation. Strong authentication is routinely defeated downstream by long-lived bearer tokens." } ] }, { "id": "ID-5", "family": "ID", "title": "Authorization Decision Integrity", "control_statement": "Authorization policy shall be enforced at a decision point that every access path consults, and changes to that policy shall be controlled, logged and reviewable.", "purpose": "To ensure the policy that governs movement is actually consulted and cannot be altered without trace.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the adversary is surrounded by policy. *This control* — policy is enforced on every path and its change is controlled.", "discussion": "`M3` Envelopment's precondition, in the framework's own words, is a policy decision point that something actually enforces — an authorization engine no service consults is a document, and it will score well. This control makes that testable in both directions: paths that bypass the decision point, and changes to policy that leave no trace. The second is the higher-value target. An adversary who can add a policy rule does not need to defeat any control in this family; they authorize themselves, and unless policy change is logged and reviewed against an expected-change baseline, the alteration is indistinguishable from routine administration.", "activities": [ { "n": 1, "capability": 2, "text": "Enforce authorization policy at a defined decision point." }, { "n": 2, "capability": 2, "text": "Log every change to authorization policy." }, { "n": 3, "capability": 2, "text": "Record which access paths consult the decision point." }, { "n": 4, "capability": 3, "text": "Enumerate access paths that do not consult the decision point and record each as a finding with an owner, since these are where envelopment fails." }, { "n": 5, "capability": 3, "text": "Review policy changes against expected change, not merely retain the log — an unreviewed change log detects nothing." }, { "n": 6, "capability": 3, "text": "Require authorization for policy change at a level above the access the policy governs, so self-authorization requires two failures rather than one." }, { "n": 7, "capability": 3, "text": "Place change detection on the policy store itself and route it to a monitored path, consistent with `KT-5` barrier monitoring." }, { "n": 8, "capability": 4, "text": "Measure the proportion of access paths consulting the decision point, and trend it toward complete coverage." }, { "n": 9, "capability": 4, "text": "Measure time to detect an unauthorized authorization policy change, tested rather than assumed." }, { "n": 10, "capability": 5, "text": "Move toward policy as reviewed, version-controlled configuration, so change review is a property of the deployment process rather than a periodic audit." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — identity planes and enforcement points (`ID-1`); assurance level\n(`ID-3`); terrain classification (`TM-2`); change management record.\n*Outputs* — path coverage record; policy change log with review results; bypass\nfindings; input to `KT-4` reachability and `KT-5` barrier monitoring.", "people_skills": "Authorization architecture. Change review against expectation rather than against\napproval. Detection engineering on configuration stores.", "policies": "Decision point coverage standard. Policy change authorization rule. Change review\nprocedure. Detection coverage on the policy store.", "culture": "", "services": "Policy decision point consulted by every path. Policy store with change logging.\nDetection on the store. Version control where feasible.", "metric_outcome": "percentage of access paths consulting the authorization decision point.", "metric_performance": "measured time to detect an unauthorized policy change.", "evidence": "Path coverage record; policy change log with review results; bypass findings; change detection coverage on the policy store.", "assessment": "Examine paths that bypass the decision point; test whether policy changes are reviewed against expected change rather than only retained; test time to detect an introduced policy change.", "nist_800_53": [ "AC-3", "AC-6", "AU-6" ], "csf_2_0": [ "PR.AA-05", "DE.CM-09" ], "ztmm": "Identity, Applications and Workloads", "d3fend": "Isolate, Detect tactics", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Authorization decision point coverage and policy change integrity. An adversary who can add a policy rule authorizes themselves without defeating any other control in the family." } ] }, { "id": "EN-1", "family": "EN", "title": "Event Declaration and Triage", "control_statement": "Adverse events shall be declared as incidents against defined criteria, and every declared incident shall be triaged, validated, categorized and prioritized within a stated period.", "purpose": "To convert raw events into a decided position quickly, since this is the segment of the decision loop that most often binds.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — events become declared, categorized incidents inside a stated period.", "discussion": "`TA-1` measures the decide segment; this control is what the decide segment consists of. Declaration criteria matter more than they appear: an estate without them declares incidents by judgment, which means the threshold moves with analyst experience, workload and the hour of day, and the resulting tempo measurement compares populations that were selected differently in each cycle. Validation is the second half — a triage process that categorizes without validating produces confident categorizations of events that never happened, and the cost lands on the eviction path.", "activities": [ { "n": 1, "capability": 2, "text": "Declare incidents when adverse events meet defined criteria." }, { "n": 2, "capability": 2, "text": "Triage and validate each declared incident." }, { "n": 3, "capability": 2, "text": "Categorize and prioritize each validated incident." }, { "n": 4, "capability": 3, "text": "Define declaration criteria in terms an analyst can apply without escalating, so the threshold does not move with judgment or workload." }, { "n": 5, "capability": 3, "text": "Prioritize against terrain: an incident touching a designated decisive point (`KT-1`) or high-weight element (`TM-3`) outranks one that does not, and the ranking basis is recorded." }, { "n": 6, "capability": 3, "text": "State the period within which triage must complete, derived from the decide segment target under `TA-1`, with provenance per `GA4`." }, { "n": 7, "capability": 3, "text": "Route declaration to `CG-2` where the incident meets the entry condition for a campaign phase transition, since phase is how the estate changes posture." }, { "n": 8, "capability": 3, "text": "Record events considered and *not* declared, so the declaration boundary is examinable rather than invisible." }, { "n": 9, "capability": 4, "text": "Measure triage elapsed time against the stated period, and measure the false-declaration and missed-declaration rates as a two-sided check on the criteria." }, { "n": 10, "capability": 4, "text": "Correlate declaration rate against degraded tempo conditions (`TA-5`), since a falling declaration rate during a holiday weekend is a detection finding rather than a quiet period." }, { "n": 11, "capability": 5, "text": "Re-derive declaration criteria from engagements that were declared late or not at all, rather than from the criteria's original authoring assumptions." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "CTI", "HT" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — detection telemetry; deception alerts (`SM-7`); decisive points\n(`KT-1`); asset weighting (`TM-3`); decide segment target (`TA-1`); phase entry\nconditions (`CG-2`).\n*Outputs* — declared incidents with category, priority and ranking basis;\nnon-declaration record; input to `EN-2` reconstruction, `EN-4` escalation and\n`TA-1` decide segment measurement.", "people_skills": "Triage under volume. Ability to validate before categorizing. Judgment about\nwhen an incident warrants phase transition rather than local handling.", "policies": "Declaration criteria. Triage period with provenance. Prioritization basis tied to\nterrain. Non-declaration recording standard.", "culture": "", "services": "Case management with declaration, category and priority fields. Terrain linkage\nfor prioritization. Timestamping adequate for `TA-1`.", "metric_outcome": "triage elapsed time against the stated period.", "metric_performance": "false-declaration and missed-declaration rates.", "evidence": "Declaration criteria; declared incidents with category, priority and ranking basis; non-declaration record; triage timing.", "assessment": "Examine the criteria for applicability without escalation; test a sample of declarations against them; examine the non-declaration record for events that met criteria; test triage times against the stated period.", "nist_800_53": [ "IR-4", "IR-5", "SI-4" ], "csf_2_0": [ "DE.AE-08", "RS.MA-02", "RS.MA-03" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Detect tactic", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Event declaration, triage, validation, categorization and prioritization. Declaration criteria fix the threshold so it does not move with analyst judgment or workload, which is what makes cross-cycle tempo comparison valid." } ] }, { "id": "EN-2", "family": "EN", "title": "Engagement Reconstruction", "control_statement": "For every declared incident, the organization shall reconstruct what took place — the entry, the movement, the dwell interval and the scope reached — and shall record the actions taken during the investigation.", "purpose": "To establish what actually happened, since every consolidation activity depends on a reconstruction and none of them can be performed without one.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — contact becomes durable advantage rather than a closed ticket. *This control* — the engagement is reconstructed and the investigation recorded.", "discussion": "`M10`'s stated precondition is a dwell reconstruction, and the framework's own material observes that the reconstruction gets harder every day after the ticket closes. This is the control that makes it a requirement rather than an intention. The reconstruction is also load-bearing far beyond the incident it describes: `RC-4` selects a restore point against it, `TA-2` corrects the imported dwell estimate against it, `M10.02` verifies avenue closure against it, and `CE-2` revises intelligence requirements from what it showed could not be seen. An agency that closes incidents without reconstructing them has disabled four controls it believes it operates.", "activities": [ { "n": 1, "capability": 2, "text": "Reconstruct the entry point, the movement path and the scope reached for each declared incident." }, { "n": 2, "capability": 2, "text": "Estimate the dwell interval from first access to detection." }, { "n": 3, "capability": 2, "text": "Record the actions taken during the investigation, with times and actors." }, { "n": 4, "capability": 3, "text": "Estimate incident magnitude — elements affected, data reached, mission impact — and record the confidence level per `CE-3`." }, { "n": 5, "capability": 3, "text": "Record what could *not* be reconstructed and why, since a visibility gap is the most actionable output of an engagement and is otherwise lost." }, { "n": 6, "capability": 3, "text": "Reconcile the reconstructed path against the terrain overlay and record every place the map was wrong, feeding `TM-1` and `M10.03`." }, { "n": 7, "capability": 3, "text": "Complete reconstruction before the incident is closed, with closure withheld until it is recorded." }, { "n": 8, "capability": 4, "text": "Measure the proportion of declared incidents carrying a completed reconstruction, distinguishing closed from reconstructed." }, { "n": 9, "capability": 4, "text": "Compare reconstructed dwell against the imported estimate under `TA-2`, and feed the divergence back into it." }, { "n": 10, "capability": 5, "text": "Build a local dwell series from accumulated reconstructions, transitioning `TA-2` from an imported figure to a measured one." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "HT" ], "consulted": [ "CTI", "SOC" ], "informed": [ "TO", "GOV" ] }, "information_flows": "*Inputs* — declared incidents (`EN-1`); preserved evidence (`EN-3`); terrain\noverlay (`TM-1`); connection register (`TM-5`); telemetry and logs.\n*Outputs* — reconstruction with dwell, scope, magnitude and confidence;\nvisibility gap findings; overlay corrections; input to `RC-4` restore point,\n`TA-2` dwell, `CE-2` requirements and `M10` techniques.", "people_skills": "Forensic reconstruction. Timeline analysis across heterogeneous telemetry.\nDiscipline to record what could not be determined.", "policies": "Reconstruction standard and required elements. Closure gate requiring\nreconstruction. Visibility gap escalation. Confidence recording per `CE-3`.", "culture": "", "services": "Telemetry retention exceeding plausible dwell. Timeline tooling. Case management\nwith a closure gate.", "metric_outcome": "percentage of declared incidents with a completed reconstruction.", "metric_performance": "divergence between reconstructed dwell and the `TA-2` estimate.", "evidence": "Reconstruction per incident with dwell, scope, magnitude and confidence; investigation action record; visibility gap findings; overlay corrections.", "assessment": "Examine reconstructions for completeness; test that closure was withheld pending reconstruction; examine whether visibility gaps were raised as findings; compare reconstructed dwell against the estimate in use.", "nist_800_53": [ "IR-4(4)", "AU-6", "IR-4" ], "csf_2_0": [ "RS.AN-03", "RS.AN-06", "RS.AN-08", "DE.AE-04" ], "ztmm": "cross-cutting Visibility and Analytics", "d3fend": "Model, Detect tactics", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Engagement reconstruction — entry, movement, dwell, scope, magnitude and investigation record. M10's stated precondition, previously an intention with no control behind it. RC-4, TA-2, CE-2 and M10.02 all depend on it." } ] }, { "id": "EN-3", "family": "EN", "title": "Evidence Preservation", "control_statement": "Incident data and metadata shall be preserved at a fidelity and for a period sufficient to support reconstruction, legal action and subsequent analysis, under a defined chain of custody.", "purpose": "To ensure the material an engagement depends on still exists when it is needed, and is admissible where that matters.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — contact leaves us better informed. *This control* — evidence is preserved, attributable and retained long enough.", "discussion": "Retention is the failure that cannot be remediated after the fact. If telemetry retention is thirty days and plausible dwell is ninety, the reconstruction under `EN-2` cannot reach the entry point, `RC-4` cannot select a safe restore point, and no amount of subsequent investment recovers the data. Retention should therefore be set against the dwell estimate rather than against storage cost, which is the same reasoning applied by `FC-2` to physical crossing logs. Chain of custody is the second requirement and is frequently omitted until an incident turns out to involve an insider or a criminal referral, at which point it cannot be established retrospectively.", "activities": [ { "n": 1, "capability": 2, "text": "Preserve incident data and metadata on declaration." }, { "n": 2, "capability": 2, "text": "Record what was preserved, by whom and when." }, { "n": 3, "capability": 2, "text": "Define the retention period for preserved evidence." }, { "n": 4, "capability": 3, "text": "Set telemetry retention against the dwell estimate under `TA-2` rather than against storage cost, and raise a finding where retention is shorter." }, { "n": 5, "capability": 3, "text": "Define chain of custody for material that may support legal or personnel action, consistent with the safeguards in `WF-4`." }, { "n": 6, "capability": 3, "text": "Preserve material outside the environment under investigation, so evidence is not held where an adversary with access could alter it." }, { "n": 7, "capability": 3, "text": "Extend preservation to volatile material where the terrain warrants it, since it is lost by containment actions taken minutes later." }, { "n": 8, "capability": 4, "text": "Measure telemetry retention against the current dwell estimate per terrain layer, and trend the shortfall." }, { "n": 9, "capability": 4, "text": "Test evidentiary integrity by verifying preserved material against its recorded hash or equivalent on a defined cadence." }, { "n": 10, "capability": 5, "text": "Extend retention and fidelity where reconstructions repeatedly fail to reach the entry point, rather than accepting the limit as fixed." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "GOV", "HT" ], "informed": [ "CTI", "TO" ] }, "information_flows": "*Inputs* — declared incidents (`EN-1`); dwell estimate (`TA-2`); terrain\nclassification (`TM-2`); legal and privacy determinations (`WF-4`).\n*Outputs* — preserved evidence with custody record; retention adequacy findings;\ninput to `EN-2` reconstruction and `RC-4` restore point selection.", "people_skills": "Digital forensics. Chain of custody discipline. Retention economics argued against\nthreat rather than budget.", "policies": "Preservation standard by terrain and incident category. Retention derivation from\ndwell. Chain of custody procedure. Out-of-environment storage rule.", "culture": "", "services": "Telemetry retention exceeding dwell. Evidence storage outside investigated\nenvironments. Integrity verification. Custody recording.", "metric_outcome": "telemetry retention against the current dwell estimate, by terrain layer.", "metric_performance": "evidentiary integrity verification pass rate.", "evidence": "Preserved evidence inventory with custody records; retention configuration by terrain; integrity verification results.", "assessment": "Compare retention against the current dwell estimate; test chain of custody on a sample; test that preserved material is held outside the investigated environment.", "nist_800_53": [ "AU-9", "AU-11", "IR-4" ], "csf_2_0": [ "RS.AN-07" ], "ztmm": "Data", "d3fend": "Model tactic", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Evidence preservation with retention derived from the dwell estimate and chain of custody. Retention is the one failure that cannot be remediated afterwards." } ] }, { "id": "EN-4", "family": "EN", "title": "Escalation and Engagement Authority", "control_statement": "Incidents shall be escalated against defined criteria to an authority that is reachable within a stated period, and the authority exercised shall be recorded against the action taken.", "purpose": "To remove the search for a decision-maker from the decision loop, which is where the decide segment is usually spent.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we act faster than the adversary adapts. *This control* — escalation is criteria-driven and the authority is reachable.", "discussion": "`TA-4` defines what may be done without escalation; this control governs what happens when escalation is required, and the two together constitute the decide segment. The binding constraint in most programs is not deliberation but locating someone with authority, and that is an availability problem rather than a judgment problem. Recording authority against action closes the loop in the other direction: an operator who acted correctly under written authority and is later questioned needs the record more than the organization does, and without it the practical effect is that the next operator escalates instead.", "activities": [ { "n": 1, "capability": 2, "text": "Define the criteria at which an incident escalates." }, { "n": 2, "capability": 2, "text": "Define the authority level required at each escalation tier." }, { "n": 3, "capability": 2, "text": "Record the authority exercised against each action taken." }, { "n": 4, "capability": 3, "text": "State the period within which each named authority must be reachable, and maintain an out-of-hours path consistent with `CG-3`." }, { "n": 5, "capability": 3, "text": "Define escalation for the case where the named authority is unreachable, including who may act in their absence and under what constraint." }, { "n": 6, "capability": 3, "text": "Escalate on terrain rather than on severity alone — an incident touching a decisive point escalates regardless of apparent magnitude." }, { "n": 7, "capability": 3, "text": "Record escalations that were required by criteria and did not occur, so the gap between criteria and practice is visible." }, { "n": 8, "capability": 4, "text": "Measure time from escalation trigger to authority response, separately from total decide-segment time, since these fail for different reasons." }, { "n": 9, "capability": 4, "text": "Test reachability of each named authority out of hours rather than assuming it, at a defined cadence." }, { "n": 10, "capability": 5, "text": "Move recurring escalations that are always approved into the pre-authorized set under `TA-4`, since a decision made identically every time is a policy rather than a decision." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "GOV", "AO" ], "informed": [ "CTI", "HT", "TO" ] }, "information_flows": "*Inputs* — declared and prioritized incidents (`EN-1`); pre-authorized set\n(`TA-4`); rules of engagement (`CG-3`); decisive points (`KT-1`); phase (`CG-2`).\n*Outputs* — escalation records with authority exercised and response times;\nunreachability findings; input to `TA-1` decide segment and `TA-4` set revision.", "people_skills": "Escalation judgment under time pressure. Authority mapping including deputies.\nWillingness to act in an authority's absence where the constraint permits.", "policies": "Escalation criteria and tiers. Reachability period per authority. Absent-authority\nrule. Authority recording standard.", "culture": "", "services": "Escalation routing with out-of-hours coverage. Authority recording against actions.\nReachability testing.", "metric_outcome": "time from escalation trigger to authority response.", "metric_performance": "percentage of named authorities verified reachable out of hours.", "evidence": "Escalation criteria and tiers; escalation records with authority and response times; reachability test records; missed-escalation record.", "assessment": "Examine criteria against a sample of incidents; test out-of-hours reachability; examine whether authority was recorded against actions taken.", "nist_800_53": [ "IR-4", "IR-6", "IR-7" ], "csf_2_0": [ "RS.MA-04" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Escalation criteria and reachable authority. With TA-4 this constitutes the decide segment; the binding constraint is usually locating a decision-maker, which is an availability problem rather than a judgment one." } ] }, { "id": "EN-5", "family": "EN", "title": "Eradication and Transition to Recovery", "control_statement": "Incidents shall be eradicated, the eradication verified, and the transition to recovery made against defined criteria with recovery actions selected, scoped and prioritized.", "purpose": "To ensure the adversary is actually gone before the mission is restored, and that the transition is a decision rather than a drift.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — we evict, then restore on evidence. *This control* — eradication is verified and the recovery transition is decided.", "discussion": "The transition from `M8` Isolation to `M11` Reconstitution is the most consequential judgment in an engagement and is usually made informally, under pressure to restore availability, on the basis that nothing further has been observed. Absence of observation is not verification, particularly where `EN-2` found visibility gaps. The recovery-action scoping requirement addresses the other half: `RC-3` sequences rebuild paths and `RC-5` exercises them, but nothing selected which actions this particular incident requires, and restoring more than necessary extends outage while restoring less leaves the adversary a foothold.", "activities": [ { "n": 1, "capability": 2, "text": "Eradicate the adversary's presence and access." }, { "n": 2, "capability": 2, "text": "Define the criteria for transition from containment to recovery." }, { "n": 3, "capability": 2, "text": "Select and scope the recovery actions this incident requires." }, { "n": 4, "capability": 3, "text": "Verify eradication actively — by hunting against the reconstructed tradecraft from `EN-2` — rather than concluding from absence of further observation." }, { "n": 5, "capability": 3, "text": "Include identity-plane eradication explicitly: credential, token and assertion revocation across every plane identified under `ID-1`, since access persists there after endpoint eradication." }, { "n": 6, "capability": 3, "text": "Prioritize recovery actions against mission and terrain, and record the basis." }, { "n": 7, "capability": 3, "text": "Require the transition decision to be taken by the authority defined in `EN-4` and recorded, rather than occurring by default." }, { "n": 8, "capability": 3, "text": "Withhold transition where `EN-2` recorded visibility gaps material to the eradication claim, or record the residual risk acceptance under `CG-4`." }, { "n": 9, "capability": 4, "text": "Measure recurrence: an incident recurring through the same avenue within a defined window is an eradication failure and should be counted as one." }, { "n": 10, "capability": 4, "text": "Measure elapsed time from containment to verified eradication, which is a distinct interval from the containment measured under `TA-1`." }, { "n": 11, "capability": 5, "text": "Feed eradication failures into `M10` avenue closure verification and into the detection engineering backlog, since a recurrence is a detection gap as much as an eradication one." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "HT" ], "consulted": [ "SOC", "TO" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — reconstruction (`EN-2`); identity planes (`ID-1`); recovery objectives\nand rebuild paths (`RC-1`, `RC-3`); escalation authority (`EN-4`); visibility gaps.\n*Outputs* — eradication verification results; recovery action selection with\nbasis; transition decision record; recurrence findings; input to `RC-3`, `M10.02`\nand `CG-4`.", "people_skills": "Threat hunting against known tradecraft. Identity-plane eradication. Judgment\nabout sufficiency of verification under residual uncertainty.", "policies": "Eradication verification standard. Transition criteria and decision authority.\nRecovery scoping basis. Recurrence definition and window.", "culture": "", "services": "Hunt capability against reconstructed tradecraft. Estate-wide revocation\n(`ID-4`). Recovery orchestration with scoping.", "metric_outcome": "recurrence rate through previously used avenues within the defined window.", "metric_performance": "elapsed time from containment to verified eradication.", "evidence": "Eradication verification results including identity-plane revocation; recovery action selection with basis; transition decision record with authority; recurrence findings.", "assessment": "Test that eradication was verified by hunting rather than inferred from absence; examine whether identity-plane eradication occurred; test that the transition decision was taken by the defined authority and recorded.", "nist_800_53": [ "IR-4", "IR-4(4)", "CP-10" ], "csf_2_0": [ "RS.MI-02", "RS.MA-05", "RC.RP-02" ], "ztmm": "cross-cutting Automation and Orchestration", "d3fend": "Evict, Restore tactics", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Eradication verified by hunting against reconstructed tradecraft rather than inferred from absence of observation, including identity-plane eradication, plus the decided transition to recovery with scoped actions." } ] }, { "id": "EN-6", "family": "EN", "title": "Engagement Communication", "control_statement": "Incident and recovery information shall be shared with designated internal stakeholders, external partners and the public as the situation and the agency's obligations require, within stated periods.", "purpose": "To ensure the people who must know, do — inside the agency, across the federal community, and among those the mission serves.", "goals_cascade": "*Mission outcome* — the mission survives contact and keeps faith with those it serves. *Defensive intent* — our contact makes the next defender's job easier. *This control* — communication reaches designated recipients within stated periods.", "discussion": "This control covers three audiences with different clocks and is distinct from `CE-7`, which distributes the cycle Brief internally on a cadence. Internal stakeholder notification is an operational obligation; federal reporting to CISA and sector partners is frequently a statutory one with a defined window; and public communication during a recovery is where a federal agency's obligation to the people it serves becomes concrete. The framework's own material puts the community reporting case well: reporting is not altruism in a federal community — it is how the next agency's spoiling attack becomes possible, and how yours does.", "activities": [ { "n": 1, "capability": 2, "text": "Identify the internal stakeholders, external partners and public audiences to be informed." }, { "n": 2, "capability": 2, "text": "Communicate incident information to each within stated periods." }, { "n": 3, "capability": 2, "text": "Communicate recovery status and completion as the situation develops." }, { "n": 4, "capability": 3, "text": "Record the statutory or policy reporting windows applying to each recipient, with provenance per `GA4`, and treat a missed window as a finding." }, { "n": 5, "capability": 3, "text": "Define what may be shared with each audience at each stage, so operational sensitivity and the duty to inform are reconciled in advance rather than negotiated during." }, { "n": 6, "capability": 3, "text": "Share indicators and tradecraft with sector partners and CISA once eradication permits, consistent with `M10.05` and the agency's disclosure authorities." }, { "n": 7, "capability": 3, "text": "Designate the communication authority per audience, since public communication is a command decision rather than an analyst's." }, { "n": 8, "capability": 3, "text": "Provide recovery status to those affected by the mission impact, not only to internal stakeholders." }, { "n": 9, "capability": 4, "text": "Measure communication timeliness against each stated window and trend it." }, { "n": 10, "capability": 4, "text": "Measure the proportion of eradicated incidents that resulted in a community contribution, since a program that only receives from the community is not participating in it." }, { "n": 11, "capability": 5, "text": "Review communications after each engagement against what recipients actually needed, and revise the audience and content definitions." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "GOV" ], "consulted": [ "CTI", "SOC" ], "informed": [ "HT", "TO" ] }, "information_flows": "*Inputs* — declared incidents (`EN-1`); reconstruction and magnitude (`EN-2`);\neradication status (`EN-5`); statutory reporting obligations (`FO-5`, `FO-7`);\ndisclosure authorities (`CG-3`).\n*Outputs* — communication records with recipients, content and timing; community\ncontributions; missed-window findings; input to `CG-4` disposition and `M10.05`.", "people_skills": "Crisis communication. Judgment about operational sensitivity against duty to\ninform. Familiarity with federal reporting obligations and their windows.", "policies": "Audience and content definitions by stage. Reporting windows with provenance.\nCommunication authority per audience. Community sharing procedure.", "culture": "", "services": "Contact and obligation register by audience. Sharing channels to CISA and sector\npartners. Public communication capability independent of affected systems.", "metric_outcome": "percentage of required communications delivered within their stated window.", "metric_performance": "proportion of eradicated incidents resulting in a community contribution.", "evidence": "Communication records with recipients, content, authority and timing; reporting window register; community contribution records; missed-window findings.", "assessment": "Examine communications against stated windows; test that the designated authority approved public communication; examine whether recent engagements produced community contributions.", "nist_800_53": [ "IR-6", "IR-9", "PM-16" ], "csf_2_0": [ "RS.CO-02", "RS.CO-03", "RC.CO-03", "RC.CO-04" ], "ztmm": "cross-cutting Governance", "d3fend": "N/A (governance layer — D3FEND is a countermeasure ontology and holds no equivalent for governance outcomes)", "version": "5.0.0", "changes": [ { "v": "5.0.0", "note": "NEW in v5.0. Engagement communication across internal, federal community and public audiences, with statutory reporting windows and designated authority per audience." } ] }, { "id": "DV-1", "family": "DV", "title": "Device Terrain Identification", "control_statement": "Every device with a path into the estate shall be represented on the terrain overlay with its management state, its owning population, and the terrain it can reach.", "purpose": "To make devices positional, so that the crossings into the estate are known and can be defended rather than merely counted.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the ways into the estate are known and watched. *This control* — every device is on the overlay with its state and its reach.", "discussion": "The distinguishing requirement is **management state**, and the category that matters is the one most inventories omit: devices that reach the estate and are not managed by it. Contractor laptops, personal devices under a bring-your-own arrangement, vendor maintenance endpoints and unenrolled cloud workstations all cross the ford, and an inventory built from the management console will report none of them because the console can only see what it manages. Reconciling against the identity plane rather than the endpoint platform is what surfaces them.", "activities": [ { "n": 1, "capability": 2, "text": "Represent devices with a path into the estate on the terrain overlay." }, { "n": 2, "capability": 2, "text": "Record the management state of each — managed, unmanaged, or unknown." }, { "n": 3, "capability": 2, "text": "Record the population that operates each device class." }, { "n": 4, "capability": 3, "text": "Reconcile the device set against the identity plane (`ID-1`) rather than against the endpoint management console, since the console can only report devices it already manages." }, { "n": 5, "capability": 3, "text": "Record the terrain each device class can reach, so a device is scored by its reach rather than by its cost." }, { "n": 6, "capability": 3, "text": "Classify unmanaged devices as a measured population with an owner and a disposition, not as an exception to the inventory." }, { "n": 7, "capability": 3, "text": "Record the software inventory carried by each managed device class, so a component disclosure can be resolved to devices rather than to an estate." }, { "n": 8, "capability": 4, "text": "Trend the unmanaged population against the managed one, and set a threshold above which the estate is not fit to plan device defense from." }, { "n": 9, "capability": 4, "text": "Measure the interval between a device first authenticating and its appearance on the overlay." }, { "n": 10, "capability": 5, "text": "Remove the conditions that generate unmanaged reach — brokered access, virtual desktops, or enrollment requirements — rather than counting it indefinitely." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "GOV" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — terrain overlay (TM-1); identity plane and authentication records\n(`ID-1`, `ID-3`); endpoint management platform; procurement and asset records.\n*Outputs* — device terrain on the overlay with management state, population and\nreach; unmanaged-population findings; device software inventory; input to `DV-2`,\n`DV-3` and `KT-3` avenue analysis.", "people_skills": "Endpoint estate administration. Ability to reconcile across identity and\nmanagement platforms. Judgment about what constitutes a path into the estate.", "policies": "Device recording standard including management state. Reconciliation procedure\nagainst the identity plane. Unmanaged device disposition rule.", "culture": "", "services": "Overlay support for device elements with state and reach. Identity-plane\nreconciliation. Software inventory collection per device class.", "metric_outcome": "percentage of authenticating devices present on the overlay.", "metric_performance": "unmanaged population as a share of devices reaching the estate.", "evidence": "Terrain overlay showing device classes with management state, population and reach; reconciliation record; software inventory.", "assessment": "Examine the overlay against the identity plane rather than the management console; test for device classes authenticating but absent from the overlay; examine the unmanaged population's disposition.", "nist_800_53": [ "CM-8", "CM-8(1)", "PM-5" ], "csf_2_0": [ "ID.AM-01", "ID.AM-02", "ID.AM-05" ], "ztmm": "Devices", "d3fend": "Model tactic", "version": "6.0.0", "changes": [ { "v": "6.0.0", "note": "PATCH. Technique back-references added so the control is reachable from the maneuver matrix, closing the orphan condition the suite auditor now fails the build on." }, { "v": "5.2.0", "note": "NEW in v5.2. Device terrain identification with management state, population and reach, reconciled against the identity plane rather than the endpoint console — the console can only report devices it already manages. Recovers ID.AM-02 software inventory." } ] }, { "id": "DV-2", "family": "DV", "title": "Device Posture as an Access Precondition", "control_statement": "Device health shall be evaluated as a precondition of access to designated terrain, and failing posture shall deny access rather than raise a notification.", "purpose": "To ensure a compromised or non-compliant device cannot spend a valid credential, closing the gap `M3` Envelopment leaves when identity alone is enforced.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — a valid credential on a bad device yields nothing. *This control* — posture gates access and failure denies.", "discussion": "The word doing the work is **precondition**. A posture check that reports non-compliance into a ticket queue has measured device health; it has not defended anything, and the adversary holding the device proceeds unimpeded. This control is also where identity and device terrain meet: `ID-3` requires authentication assurance commensurate with terrain, and device assurance is an input to that assurance rather than a parallel track. An estate enforcing strong authentication from an unhealthy endpoint has bought half the control.", "activities": [ { "n": 1, "capability": 2, "text": "Evaluate device health signals before granting access to designated terrain." }, { "n": 2, "capability": 2, "text": "Define the posture requirement per terrain layer or access tier." }, { "n": 3, "capability": 2, "text": "Deny access on failing posture rather than recording an exception." }, { "n": 4, "capability": 3, "text": "Feed device assurance into the authorization decision under `ID-5`, so posture and identity are evaluated together rather than in sequence." }, { "n": 5, "capability": 3, "text": "Require posture for access to decisive points (`KT-1`) without exception, and record any exception with an owner and expiry." }, { "n": 6, "capability": 3, "text": "Re-evaluate posture during a session where the platform permits, not only at establishment." }, { "n": 7, "capability": 3, "text": "Define the fallback path for a device that cannot report posture, so an unreportable device is a decision rather than a bypass." }, { "n": 8, "capability": 4, "text": "Measure the proportion of access grants made with a current posture signal available, since a grant made without one is made blind." }, { "n": 9, "capability": 4, "text": "Trend the exception population and drive it toward a stated floor." }, { "n": 10, "capability": 5, "text": "Extend posture signals to the device classes that currently cannot report, rather than maintaining a permanent exception for them." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — device terrain (`DV-1`); identity planes and enforcement points\n(`ID-1`, `ID-5`); posture telemetry; decisive points (`KT-1`).\n*Outputs* — posture requirement per terrain; grant records with posture state;\nexception register; input to `ID-3` assurance and `M3` technique evidencing.", "people_skills": "Conditional access design. Endpoint telemetry engineering. Willingness to deny\naccess to a functioning device.", "policies": "Posture requirement standard per terrain. Exception register with expiry.\nUnreportable-device fallback rule.", "culture": "", "services": "Posture signal collection across device classes. Conditional access able to\nconsume it. Continuous evaluation where supported.", "metric_outcome": "percentage of access to decisive-point terrain gated on posture.", "metric_performance": "proportion of grants made with a current posture signal.", "evidence": "Posture requirements per terrain; grant records showing posture state; exception register with expiry.", "assessment": "Test that failing posture denies rather than notifies; examine whether posture reaches the authorization decision or runs beside it; examine the exception population against decisive-point terrain.", "nist_800_53": [ "CM-6", "AC-3", "IA-3" ], "csf_2_0": [ "PR.AA-05", "PR.PS-01" ], "ztmm": "Devices, Identity", "d3fend": "Harden, Isolate tactics", "version": "6.0.0", "changes": [ { "v": "6.0.0", "note": "PATCH. Technique back-references added so the control is reachable from the maneuver matrix, closing the orphan condition the suite auditor now fails the build on." }, { "v": "5.2.0", "note": "NEW in v5.2. Device posture as an access precondition, feeding device assurance into the ID-5 authorization decision. Failing posture must deny, not notify. Recovers PR.PS-01." } ] }, { "id": "DV-3", "family": "DV", "title": "Endpoint Sensor Coverage and Liveness", "control_statement": "Sensor coverage across the device estate shall be reconciled to the device inventory rather than to the sensor console, and a sensor that stops reporting shall be treated as a security event.", "purpose": "To know what the estate can actually see, and to detect the loss of that visibility as an event rather than at the next assessment.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the estate is observed where movement occurs. *This control* — coverage is real and its loss is detected.", "discussion": "Two failures hide behind a healthy coverage figure. The first is the console denominator: a platform reporting 100% coverage is reporting 100% *of the devices it knows about*, which is a tautology, and reconciling to `DV-1`'s inventory is the only way to get a real number. The second is silence. A sensor removed, disabled or crashed produces no telemetry, and an absence of alerts is indistinguishable from an absence of adversary — which is precisely the condition an adversary works to create. Liveness is therefore a control in its own right, not a platform health metric.", "activities": [ { "n": 1, "capability": 2, "text": "Deploy sensor coverage across the managed device estate." }, { "n": 2, "capability": 2, "text": "Report coverage as a proportion of the device inventory." }, { "n": 3, "capability": 2, "text": "Detect sensors that have stopped reporting." }, { "n": 4, "capability": 3, "text": "Reconcile coverage against the `DV-1` inventory rather than the sensor console, and report the reconciled figure as the coverage number." }, { "n": 5, "capability": 3, "text": "Treat a silent sensor as a security event with a response path, consistent with `M2.14` Control Failure Detection, rather than as a platform ticket." }, { "n": 6, "capability": 3, "text": "Ensure telemetry generation and retention on device terrain meet the retention `EN-3` requires against the dwell estimate, since reconstruction cannot reach further back than the endpoint retained." }, { "n": 7, "capability": 3, "text": "Record device classes that cannot carry a sensor, with the compensating measure and an owner." }, { "n": 8, "capability": 4, "text": "Measure time to detect a silent sensor, tested rather than assumed." }, { "n": 9, "capability": 4, "text": "Trend the gap between console-reported and inventory-reconciled coverage; a widening gap is an inventory finding, not a sensor one." }, { "n": 10, "capability": 5, "text": "Extend or replace sensing for device classes carrying persistent compensating measures, rather than accepting the compensation indefinitely." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "SOC" ], "consulted": [ "TO", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — device inventory (`DV-1`); sensor platform telemetry; dwell estimate\n(`TA-2`); evidence retention requirement (`EN-3`).\n*Outputs* — reconciled coverage figure; silent-sensor events; uncovered device\nclass register; input to `EN-1` declaration, `EN-2` reconstruction and `TA-1`\ndetect segment.", "people_skills": "Detection engineering. Telemetry pipeline operation. Discipline to report the\nreconciled rather than the flattering figure.", "policies": "Coverage reconciliation standard. Silent-sensor response procedure. Endpoint\nretention standard derived from dwell.", "culture": "", "services": "Endpoint sensing across device classes. Liveness monitoring independent of the\nsensor itself. Retention meeting the dwell requirement.", "metric_outcome": "sensor coverage reconciled to the device inventory.", "metric_performance": "measured time to detect a silent sensor.", "evidence": "Reconciled coverage figure with its denominator stated; silent-sensor event records; uncovered device class register with compensations.", "assessment": "Examine which denominator the reported coverage uses; test detection of a deliberately silenced sensor; compare endpoint retention against the current dwell estimate.", "nist_800_53": [ "SI-4", "AU-2", "AU-12" ], "csf_2_0": [ "DE.CM-09", "PR.PS-04", "ID.AM-08" ], "ztmm": "Devices, Visibility and Analytics", "d3fend": "Detect tactic", "version": "6.0.0", "changes": [ { "v": "6.0.0", "note": "PATCH. Technique back-references added so the control is reachable from the maneuver matrix, closing the orphan condition the suite auditor now fails the build on." }, { "v": "5.2.0", "note": "NEW in v5.2. Sensor coverage reconciled to the device inventory rather than the sensor console, and sensor liveness treated as a security event. Endpoint retention derived from the dwell estimate so EN-2 reconstruction can reach the entry point. Recovers PR.PS-04 and DE.CM-09." } ] }, { "id": "DV-4", "family": "DV", "title": "Execution Control", "control_statement": "What may execute on designated device terrain shall be constrained to an approved, verified set, and unauthorized execution shall be prevented rather than recorded.", "purpose": "To deny the adversary the ability to run code on the ground they cross into, which is the cheapest point at which most engagements can be stopped.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — the estate runs only what it intended to run. *This control* — execution is constrained and unauthorized execution is denied.", "discussion": "Execution control is the highest-yield and least-adopted device control, because it trades operational friction now against an outcome that is invisible when it works. The framework's position is that the constraint belongs on **designated terrain** rather than universally — decisive points, privileged access workstations, and devices reaching the data layer — which makes it affordable and keeps it enforceable. Universal application is where these programs fail, and where they are subsequently downgraded to audit mode and forgotten.", "activities": [ { "n": 1, "capability": 2, "text": "Define what may execute on designated device terrain." }, { "n": 2, "capability": 2, "text": "Prevent execution outside the approved set on that terrain." }, { "n": 3, "capability": 2, "text": "Record attempted unauthorized execution as an event." }, { "n": 4, "capability": 3, "text": "Derive the approved set from verified provenance under `LC-2` rather than from observed usage alone." }, { "n": 5, "capability": 3, "text": "Scope enforcement to designated terrain — decisive points, privileged access workstations, and devices reaching the data layer — rather than universally." }, { "n": 6, "capability": 3, "text": "Define the exception path with an owner and expiry, since an undefined exception path results in enforcement being disabled wholesale." }, { "n": 7, "capability": 3, "text": "Constrain script and interpreter execution as well as binaries, since restricting only executables displaces rather than prevents." }, { "n": 8, "capability": 4, "text": "Measure the proportion of designated terrain under enforcement rather than audit mode, and treat audit mode as unenforced." }, { "n": 9, "capability": 4, "text": "Trend attempted unauthorized executions, which is a detection signal as much as a prevention one." }, { "n": 10, "capability": 5, "text": "Extend enforcement outward from designated terrain as the exception rate falls, rather than attempting universal coverage at the outset." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "SOC", "HT" ], "informed": [ "CTI", "GOV" ] }, "information_flows": "*Inputs* — device terrain (`DV-1`); decisive points (`KT-1`); component provenance\n(`LC-2`); software inventory.\n*Outputs* — approved execution set; enforcement scope record; unauthorized\nexecution events; exception register; input to `EN-1` declaration and `M4`\ntechnique evidencing.", "people_skills": "Application control administration. Provenance verification. Negotiation with\nmission owners over friction on designated terrain.", "policies": "Approved set derivation from provenance. Enforcement scope definition. Exception\npath with expiry. Script and interpreter policy.", "culture": "", "services": "Application control capable of enforcement rather than audit. Provenance linkage.\nScript and interpreter constraint.", "metric_outcome": "percentage of designated device terrain under enforced execution control.", "metric_performance": "exception population and its median age.", "evidence": "Approved execution set with provenance linkage; enforcement scope record distinguishing enforced from audit mode; exception register.", "assessment": "Test that unauthorized execution is prevented rather than logged on designated terrain; examine whether enforcement is active or in audit mode; examine the derivation of the approved set against `LC-2`.", "nist_800_53": [ "CM-7", "CM-7(5)", "SI-7" ], "csf_2_0": [ "PR.PS-05", "PR.PS-02" ], "ztmm": "Devices, Applications and Workloads", "d3fend": "Harden, Isolate tactics", "version": "6.0.0", "changes": [ { "v": "6.0.0", "note": "PATCH. Technique back-references added so the control is reachable from the maneuver matrix, closing the orphan condition the suite auditor now fails the build on." }, { "v": "5.2.0", "note": "NEW in v5.2. Execution control scoped to designated terrain rather than universally, with the approved set derived from LC-2 provenance. Recovers PR.PS-05." } ] }, { "id": "DV-5", "family": "DV", "title": "Device Lifecycle and Sanitization", "control_statement": "Devices shall be provisioned from a trusted baseline and, on retirement, loss or reassignment, shall be removed from the estate's trust and their media sanitized within a stated period.", "purpose": "To close the ends of the device lifecycle — the point of entry and the point of exit — where trust is granted and where it is most often left behind.", "goals_cascade": "*Mission outcome* — the mission survives contact. *Defensive intent* — trust begins and ends deliberately. *This control* — provisioning is from trusted media and retirement removes trust.", "discussion": "The exit end is where this control earns its place. A retired, lost or reassigned device frequently retains enrollment, certificates, cached credentials and stored data long after it has left the population it was issued to — which makes it an unattributed device holding valid trust, exactly the condition `DV-1` is designed to surface and `WF-5` assumes has been handled. The stated period matters as much as the action: a sanitization process that completes eventually is not a control against a device already outside the agency's physical control.", "activities": [ { "n": 1, "capability": 2, "text": "Provision devices from a defined baseline image or configuration." }, { "n": 2, "capability": 2, "text": "Remove retired, lost and reassigned devices from the estate's trust." }, { "n": 3, "capability": 2, "text": "Sanitize media on retirement or reassignment." }, { "n": 4, "capability": 3, "text": "Verify the provisioning baseline's integrity and provenance under `LC-2`, so a trusted baseline is trusted for a reason." }, { "n": 5, "capability": 3, "text": "State the period within which trust must be removed following retirement, loss or reassignment, derived from what the device's retained trust could do, with provenance per `GA4`." }, { "n": 6, "capability": 3, "text": "Reconcile device retirement against the identity plane and `WF-5` revocation, so a device leaving with a person is handled once rather than twice." }, { "n": 7, "capability": 3, "text": "Record sanitization with its method and verification, and record devices that left the estate unsanitised as findings rather than as losses." }, { "n": 8, "capability": 4, "text": "Measure elapsed time from retirement, loss or reassignment to trust removal, against the stated period." }, { "n": 9, "capability": 4, "text": "Trend the population of devices holding trust with no current holder, which is the direct measure of this control's exit end." }, { "n": 10, "capability": 5, "text": "Reduce what a device retains — moving to brokered access, ephemeral credentials and non-persistent workspaces — so retirement removes less." } ], "raci": { "accountable": [ "AO" ], "responsible": [ "TO" ], "consulted": [ "GOV", "SOC" ], "informed": [ "CTI", "HT" ] }, "information_flows": "*Inputs* — device terrain (`DV-1`); baseline provenance (`LC-2`); personnel\nseparation triggers (`WF-5`); asset and property records.\n*Outputs* — provisioning baseline record; trust removal times; sanitization\nrecords with method and verification; orphaned-trust findings.", "people_skills": "Endpoint provisioning. Media sanitization to federal standards. Reconciliation\nacross asset, identity and personnel records.", "policies": "Baseline definition and provenance verification. Trust removal period with\nprovenance. Sanitization standard and verification. Loss reporting procedure.", "culture": "", "services": "Trusted provisioning source. Remote trust removal and wipe. Sanitization\nverification. Asset and identity reconciliation.", "metric_outcome": "devices holding estate trust with no current holder.", "metric_performance": "median elapsed time from retirement or loss to trust removal.", "evidence": "Provisioning baseline with provenance record; trust removal times; sanitization records with method and verification; orphaned-trust findings.", "assessment": "Test trust removal against the stated period; examine sanitization verification on a sample; examine the population of devices holding trust with no current holder.", "nist_800_53": [ "MP-6", "CM-2", "MA-2" ], "csf_2_0": [ "ID.AM-08", "PR.DS-11", "PR.PS-02" ], "ztmm": "Devices", "d3fend": "Harden, Evict tactics", "version": "6.0.0", "changes": [ { "v": "6.0.0", "note": "PATCH. Technique back-references added so the control is reachable from the maneuver matrix, closing the orphan condition the suite auditor now fails the build on." }, { "v": "5.2.0", "note": "NEW in v5.2. Device lifecycle: trusted provisioning and, critically, trust removal and sanitization on retirement, loss or reassignment within a period derived from what retained trust could do." } ] } ] }