A visual infographic and technical paper covering the full BAS methodology, MITRE ATT&CK mapping, SABSA controls, validation approaches, and cloud-specific security validation across AWS and Azure. Designed for security architects, engineers, and programme leads.
The full Breach Attack Simulation framework visualised, covering the mindset shift through to MITRE ATT&CK mapping, validation approaches, and cloud coverage.
The complete technical reference covering the Assume Breach methodology, continuous validation design, MITRE ATT&CK integration, SABSA security architecture alignment, and architect implementation guidance.
The framework presented covers the conceptual foundation of Assume Breach as a design and operational philosophy, the BAS validation pipeline, MITRE ATT&CK tactic and technique mapping, SABSA security architecture layer alignment, cloud-specific validation across AWS and Azure, and practical guidance for security architects responsible for implementing and sustaining continuous security validation programmes.
The security assurance challenge facing enterprise organisations is not a shortage of tools or frameworks. It is a fundamental gap between what security teams believe their controls do and what those controls actually do under adversary conditions.
A firewall policy may exist in a policy management system. An EDR agent may be deployed across endpoints. SIEM correlation rules may have been written and committed. But none of these facts individually prove that the organisation can detect, contain, and respond to a realistic attack. They prove only that the components are present. The question of whether they work together under realistic attacker behaviour, across real infrastructure, in response to actual threat techniques remains unanswered until someone tests it.
Penetration testing has historically been the primary mechanism for this kind of challenge. Red team exercises provide depth and human adversarial judgment. Both remain valuable. But both share a fundamental limitation: they are time-bound, periodic, and scope-limited. An environment changes continuously. New services are deployed, configurations drift, detection rules are modified, and new attack techniques emerge. A quarterly or annual assurance exercise cannot keep pace with the rate of change in modern enterprise environments.
Assume Breach and Breach Attack Simulation address this gap by shifting from periodic challenge to continuous validation. The core premise is simple: assume an attacker may already have an initial foothold, and continuously prove that detection, containment, and response controls work against that assumption.
Penetration testing provides independent, adversarial challenge against a defined scope and within a defined time window. It is valuable for identifying exploitable vulnerabilities, misconfigurations, and weak trust boundaries that internal teams may have normalised. A skilled penetration tester brings creative adversarial thinking that automated tools cannot replicate.
However, penetration testing does not prove continuous control effectiveness. A finding remediated after a test may reappear through configuration drift before the next test. A control that successfully blocked a technique in one test may fail against a slightly modified version of the same technique. The test validates a point in time, not the ongoing operational state of the control environment.
Vulnerability scanning identifies missing patches, known misconfigurations, and publicly disclosed weaknesses at scale. It is operationally essential and should be continuous. But it cannot answer whether detection controls are working, whether lateral movement paths are visible to SIEM, whether identity abuse patterns trigger alerts, or whether response playbooks execute correctly.
Compliance frameworks provide a structured baseline for control requirements. Audits against those frameworks confirm that controls exist and are documented. But compliance is not security. An organisation can pass a compliance audit with controls that are technically present but operationally ineffective, poorly tuned, incorrectly scoped, or unable to detect the specific techniques attackers actually use.
Assume Breach is both a design philosophy and an operational posture. As a design philosophy, it changes the questions architects ask during system design. As an operational posture, it changes the standard against which security controls are measured.
Traditional security design asks: how do we prevent an attacker from gaining access? Assume Breach asks: if an attacker gains an initial foothold, what happens next, and can we detect and contain it?
This shift has significant architectural implications. Trust boundaries must be designed to contain compromise, not just prevent it. Segmentation must limit lateral movement, not just separate networks. Identity design must minimise blast radius, not just enforce authentication. Logging and telemetry must be treated as first-class architectural requirements, not operational afterthoughts.
As an operational posture, Assume Breach means continuously asking: if we think a control would detect this, have we proven it? If we believe a segment would contain lateral movement, have we validated it? If we expect a playbook to trigger, have we tested it recently?
The answer to these questions should not be "we believe so based on the last assessment." It should be "yes, and here is the evidence from this week's simulation run."
Breach Attack Simulation operationalises the Assume Breach posture through a structured, repeatable validation pipeline. The pipeline has five stages that together create a continuous improvement loop for security control effectiveness.
Effective BAS begins with threat-informed scenario selection. Scenarios should be chosen based on realistic adversary behaviour relevant to the organisation's sector, technology stack, and threat profile. MITRE ATT&CK provides the framework for this selection, mapping attacker tactics and techniques to the specific controls and telemetry sources the organisation has deployed. A government organisation with a cloud-first architecture should run different scenarios than a manufacturing organisation with significant OT infrastructure, even if both use the same core BAS platform.
BAS platforms execute attack simulations safely by replicating attacker behaviours without causing actual harm. This includes simulating credential harvesting techniques without actually stealing credentials, executing lateral movement patterns without disrupting production systems, and triggering C2 communication behaviours without establishing external connectivity. Safe simulation allows organisations to test controls in production environments without the operational risk associated with live red team activities.
The detection analysis stage is where the core value of BAS is realised. After a simulation runs, the platform correlates what happened against what was detected by SIEM, XDR, EDR, and cloud-native security services. This produces a gap analysis: techniques executed versus techniques detected, alerts generated versus alerts that should have generated, response playbooks triggered versus playbooks that should have triggered. This gap analysis is objective, evidence-based, and directly actionable.
Remediation actions following a BAS run may span multiple layers of the security architecture. Detection rules may need to be tuned or written. Response playbooks may need to be updated. Architecture changes may be required to reduce attack surface or improve segmentation. IAM configurations may need to be tightened. The key distinction from traditional assessment-driven remediation is that the remediation is directly linked to a specific, reproducible simulation that can be re-run to verify the fix.
Once remediation actions are complete, the original simulation scenario is re-run. If the control now works correctly, meaning the technique is detected, the alert fires, and the playbook triggers, the organisation has produced evidence of control effectiveness that can be used for assurance reporting, board-level security reporting, and regulatory compliance documentation. This evidence model represents a fundamentally different quality of assurance than a point-in-time assessment.
MITRE ATT&CK is the primary reference framework for BAS scenario selection and coverage measurement. The framework maps adversary tactics, the high-level objectives of an attack, to specific techniques and sub-techniques that represent how those objectives are achieved.
| Tactic | Key techniques for BAS coverage | Primary detection sources |
|---|---|---|
| Initial Access | Phishing, valid account abuse, exposed service exploitation | Email security, identity logs, VPN and access logs |
| Execution | Command and script interpreter abuse, scheduled task execution | EDR process telemetry, SIEM command line logging |
| Persistence | Account creation, cloud backdoor creation, identity token persistence | IAM logs, CloudTrail, Azure Activity Logs |
| Privilege Escalation | IAM misconfiguration abuse, token impersonation, role chaining | IAM logs, PIM alerts, CloudTrail AssumeRole events |
| Defence Evasion | Log tampering, timestomping, living off the land techniques | SIEM log gap detection, EDR behavioural analytics |
| Lateral Movement | Pass-the-hash, remote service abuse, VPC traversal | Network flow logs, east-west traffic analytics, SIEM |
| Exfiltration | Cloud storage exfiltration, encrypted channel exfiltration | DLP, S3 and Blob access logs, Macie, DNS analytics |
| Impact | Ransomware simulation, data destruction, resource hijacking | File integrity monitoring, cloud resource change detection |
SABSA provides a risk-driven framework for security architecture that maps controls from business context through to operational execution. BAS aligns naturally to SABSA because it validates that the controls designed at each layer of the architecture are actually working as intended at the operational layer.
At the contextual layer, BAS scenarios are selected based on the organisation's business risk profile and threat environment. At the conceptual layer, Assume Breach principles inform the architectural design of trust boundaries, identity models, and segmentation. At the logical layer, BAS validates that security services including SIEM, XDR, EDR, and DLP are delivering the detection and response outcomes they were designed to deliver. At the physical layer, BAS exercises specific technology controls including firewall rules, endpoint agent configurations, and cloud security service policies. At the component layer, BAS validates the specific configuration of detection rules, response playbooks, and integration between security tools. At the operational layer, BAS produces the continuous evidence of control effectiveness that supports ongoing assurance and governance reporting.
Cloud environments present particular challenges for security validation because they are dynamic, API-driven, and heavily dependent on identity for access control. Static validation approaches are especially inadequate for cloud because infrastructure changes continuously and the boundaries between what is internal and external are less clearly defined than in on-premise environments.
In AWS environments, BAS should validate whether CloudTrail and GuardDuty are correctly ingesting and correlating security events, whether IAM role assumption chains are constrained and generate alerts when abused, whether east-west traffic between VPCs triggers network-level detection, whether Lambda and ECS workload identity abuse scenarios generate alerts through Security Hub, and whether S3 exfiltration patterns are detected by Macie or through SIEM ingestion of access logs. AWS Security Hub provides a consolidated view that should be used as the primary validation target for AWS-based BAS scenarios.
In Azure environments, BAS should validate whether Microsoft Defender for Cloud correctly surfaces simulated attacker behaviours across workloads, whether Entra ID token theft and misuse scenarios are visible in Microsoft Sentinel, whether lateral movement paths between subscriptions and resource groups trigger conditional access policies and alerts, whether Managed Identity abuse scenarios are detected through activity logs and Defender alerts, and whether Azure Blob Storage exfiltration patterns surface through Defender for Storage or SIEM integration.
Security architects responsible for implementing BAS programmes should consider the following areas when designing a continuous validation capability.
BAS is most effective when scenario selection is informed by a current threat model. STRIDE-based threat modelling at the architecture level, combined with MITRE ATT&CK mapping, produces a prioritised list of scenarios that reflects the organisation's actual threat profile rather than a generic simulation checklist.
The most common finding from initial BAS runs is that detection telemetry is missing or incomplete. Logging is not enabled. SIEM rules are not written. Cloud security services are not forwarding to SIEM. These are architecture failures, not configuration issues. Architects should treat detection and logging requirements as first-class deliverables in any cloud or security programme, specified and validated alongside functional requirements.
Before running BAS simulations, review the identity and segmentation architecture with blast radius in mind. If a user credential is compromised, how far can it reach? If a workload identity is abused, which other workloads can it access? The answers to these questions should guide both the BAS scenario selection and any architectural remediation required before validation begins.
BAS provides the most value when it is integrated into the change management process. Every significant infrastructure or security configuration change should trigger a relevant simulation run. This ensures that security controls are continuously validated against the current state of the environment, not the state at the last formal assessment.
The evidence produced by BAS runs simulation executed, technique detected or not detected, control gap identified, remediation applied, retest passed, forms a continuous assurance record. This record has value beyond the security team. It can be used for board-level security reporting, regulatory compliance evidence, and security programme maturity assessment.
The gap between what organisations believe their security controls do and what those controls actually do under adversarial conditions is one of the most significant risks in enterprise security management. Penetration testing, vulnerability scanning, and compliance assessments provide valuable inputs but cannot close this gap on their own.
Assume Breach as a design and operational philosophy changes the question from "do we have controls?" to "do our controls work?" Breach Attack Simulation provides the mechanism for answering that question continuously, with evidence, at the speed modern enterprise environments change.
Security architects who embed Assume Breach principles into their design process and implement continuous BAS validation as an operational capability will build environments that are not just harder to compromise but genuinely more observable, more containable, and more defensible when compromise occurs. That is the architectural outcome the discipline demands.