Figure 2. Phases of CRRM Methodology
act [Activity] Perform Cyber Resilience Requirements Methodology (CRRM)
Responsible Team Systems Engineering
System Operator Security Analyst System Test
Process Description
New Project?
Yes
in SCRE Template
Setup SCRE Environment
out Resilience System Definition
out TWC
STPA-Sec
FOREST
in Mission MOP out ConOPs in Program Constraints
Perform Hazard Analysis
Define System Description
Perform Loss Scenario Assessment
Define Resilience Architecture
Perform Verification & Test Assessment
Control Structure
Hazardous Actions
Sentinel Scenarios
Requirements
Yes
Yes
Acceptable Risk?
Acceptable Plan?
No
Sufficient Resilience?
No
No
in Operational Experties
in Cyber Security Experties
in Resilience Patterns
in Test Strategy Expertise
Key: MOP=Measure of Performance; SCRE=Secure Cyber-Resilient Engineering Source. Author
Perform Validation and Test Assess - ment. Applied to AI-enabled systems, it helps reveal timing and feedback vulnerabilities such as delayed in - puts, stale data, weak time-stamp validation, and synchronization gaps across distributed components. These conditions show why AI- enabled architectures need timing validation, synchronization controls, and feedback integrity mechanisms from the outset. Loss scenarios can then be translated into risks, require - ments, remediation options, and assurance evidence. Intended Application By extending STPA-Sec to soft - ware-intensive systems modeled as hierarchical control-feedback struc - tures, this approach applies systems thinking to identify latent design flaws, emergent interaction risks, and unsafe control actions before failures occur by analyzing how in - terdependent software functions, software processing units, and logi - cal data flows, rather than physical data flows, can be disrupted, delayed,
or manipulated to propagate unsafe conditions throughout the system. Notional AI-Enabled Use Case To illustrate the methodology, consider a notional Automated AI Re - sponse Operating Node that performs alert triage, isolates affected sys - tems, and recommends remediation actions. Figure 3 shows the system boundary, the external actors, and the primary operational functions. Primary Use Cases Within that boundary, the system ingests security events from sensors, logs, and threat intelligence feeds, normalizes the data, and performs alert triage by filtering, prioritizing, and classifying events. It then ana - lyzes and correlates threats to iden - tify attack patterns and indicators of compromise. The system also as - sesses technical and mission impact, can initiate authorized containment actions, and logs decisions for audit - ability. In higher-risk or uncertain situa - tions, it supports human-in-the-loop
operations by escalating decisions and recommending mitigation, con - tainment, or recovery actions. Over time, the platform improves by learn - ing from operational outcomes and incorporating feedback from exe - cuted response activities. Figure 3 illustrates the use case model. The figure shows depicts a decision-centric cyber defense sys - tem that processes security data and does either of the following: • Automatically executes responses (in low-risk or pre-authorized cases). • Engages human operators for re - view and approval (in high-impact or uncertain cases). The internal block diagram shows how the major components interact to support alert triage, containment, and remediation. At a high level, the architecture includes the major com - ponents as shown in Figure 4. The following items explain the different architecture layers in Fig - ure 4. • The sensor and data ingestion layer collects and normalizes data
38 DEFENSE ACQUISITION MAGAZINE | SEPTEMBER –OCTOBER 2026
Made with FlippingBook - Online Brochure Maker