Breach and Attack Simulation (BAS)

Definition

Breach and Attack Simulation (BAS) is the controlled and repeatable execution of adversary-like techniques to test whether security controls can prevent, detect, and support response to defined attack paths. It differs from a penetration test because BAS is commonly automated, scenario-based, and repeated to measure control performance over time rather than discover every exploitable weakness. Programs should authorize scope, protect production safety, map scenarios to threats, validate telemetry, assign remediation, retest failures, and distinguish simulated activity clearly from a genuine incident.

Overview

Breach and Attack Simulation (BAS) is the controlled and repeatable execution of adversary-like techniques to test whether security controls can prevent, detect, and support response to defined attack paths. The control exists to reduce the likelihood and impact of compromise by making assets, identities, software, data, exposures, and control responsibilities visible and governable. It differs from a penetration test because BAS is commonly automated, scenario-based, and repeated to measure control performance over time rather than discover every exploitable weakness. It should be interpreted alongside Attack Surface Management (ASM) because the concepts can affect the same decision without representing the same control, event, or risk.

The workflow identifies the protected object and owner, evaluates threats and dependencies, applies preventive and detective safeguards, and routes exceptions or failures to accountable teams. Controls should be tested against realistic misuse, version changes, privileged access, third parties, and recovery conditions. In this context, programs should authorize scope, protect production safety, map scenarios to threats, validate telemetry, assign remediation, retest failures, and distinguish simulated activity clearly from a genuine incident.

It should connect the term to Control Testing where that relationship changes access, transaction treatment, investigation, communication, or recovery.

Records should preserve scope, ownership, configuration or policy version, changes, approvals, test results, alerts, exceptions, incidents, remediation, and verification that the risk was reduced. Evidence must be protected from alteration and retained according to legal and operational need.

Useful measures include coverage, control effectiveness, unresolved critical findings, remediation age, unauthorized changes, detection time, incident frequency, repeat weaknesses, exception volume, and recovery performance.

The relationship with Digital Forensics and Incident Response (DFIR) should be documented where it affects residual risk or control ownership.

Key Takeaway

Programs should authorize scope, protect production safety, map scenarios to threats, validate telemetry, assign remediation, retest failures, and distinguish simulated activity clearly from a genuine incident.

Sources

MITRE ATT&CK — MITRE (2026-08-03)
Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5 — NIST (2026-08-03)
Incident Response Recommendations and Considerations for Cybersecurity Risk Management, SP 800-61 Rev. 3 — NIST (2026-08-03)