Security Architecture Framework

Assume Breach.
Validate everything.

Pen tests and vulnerability scans answer the wrong question. Assume Breach changes the design mindset from hoping controls hold, to proving they work under realistic attacker conditions across AWS, Azure, and hybrid enterprise environments.

Explore the framework Full paper and infographic

// framework components

Assume Breach design methodology

Breach Attack Simulation (BAS)

MITRE ATT&CK threat mapping

SABSA security controls

Red Team validation

Continuous security assurance

AWS and Azure cloud coverage

SIEM, XDR, and EDR validation

The mindset shift

From compliance questions to adversarial ones.

Assume Breach changes the quality of the questions architects and security teams ask. The difference is significant.

// traditional security posture

?Do we have endpoint protection deployed?

?Do we have MFA enabled?

?Do we have logging configured?

?Do we have network segmentation?

?Are patches applied on schedule?

?Did the pen test find critical findings?

// assume breach posture

>If an attacker lands on a user device, what can they reach?

>If a token is stolen, what detects its misuse?

>If a workload identity is abused, how far can it move?

>If an admin credential is compromised, where are the hard stops?

>If malicious activity begins, which systems see it first?

>If we think we would detect it, have we actually proven that?

Why traditional assurance is not enough

Penetration testing remains valuable. It gives independent challenge, identifies exploitable weaknesses, and highlights risks that internal teams have normalised. Vulnerability scanning is essential for finding missing patches, poor configurations, and known weaknesses at scale.

But neither is sufficient. A pen test is time-bound, scoped, and scenario-dependent. It may prove one route to compromise exists, but it does not continuously prove controls still work after the next change. A vulnerability scan cannot tell you whether your SIEM correlates the right signals, whether lateral movement is visible, or whether privilege abuse is detected.

Attackers do not work in snapshots. They work in sequences, chains, privilege escalation paths, weak identity assumptions, missed detections, and control drift. They exploit the spaces between controls, not just the controls themselves.

Assume Breach as a design methodology

Assume Breach is not just a detection philosophy. It is an architecture mindset. It starts with a simple premise: do not design security around the hope that the perimeter, the MFA prompt, the firewall, or the endpoint agent will always stop the attack at the first step. Design as though one of those layers might fail.

A secure architecture is not just one that is hard to break into. It is one that remains observable, containable, and defensible after an attacker gains an initial foothold. That distinction changes how architects approach trust boundaries, segmentation, telemetry, and response integration from the start.

Continuous security validation

The BAS pipeline.

Breach Attack Simulation turns assumptions into evidence. This is how a continuous validation pipeline operates across enterprise controls.

Scenario Selection

Map realistic adversary behaviours to your environment using MITRE ATT&CK. Select scenarios relevant to your threat profile, sector, and architecture.

ATT&CK Mapping

Safe Simulation

Execute attack simulations safely across live controls: endpoint, identity, email, network, cloud logging, and lateral movement paths.

Safe Execution

Detection Analysis

Measure what SIEM, XDR, EDR, and cloud alerting actually detected. Surface blind spots between what fired and what should have fired.

Gap Analysis

Remediation

Fix the control gap, tune the detection rule, update the response playbook, or adjust the architecture based on evidence, not assumption.

Control Fix

Retest and Evidence

Re-run the scenario after remediation. Produce evidence that the control now works. Build a repeatable proof model over time.

Proven Coverage

MITRE ATT&CK framework

Tactic and technique coverage.

Mapping BAS scenarios to MITRE ATT&CK tactics ensures realistic, adversary-aligned validation across the full attack lifecycle.

Initial Access

Gaining the first foothold

Phishing and spearphishing

Valid account abuse

Exposed service exploitation

Supply chain compromise

Persistence

Maintaining access

Account creation and modification

Scheduled task abuse

Cloud resource backdoors

Identity token persistence

Privilege Escalation

Gaining elevated access

Abuse of IAM misconfigurations

Token impersonation

Sudo and admin abuse

Cloud role assumption chains

Defence Evasion

Avoiding detection

Log tampering and disabling

Timestomping

Living off the land binaries

Obfuscated command execution

Lateral Movement

Moving through the estate

Pass-the-hash and pass-the-ticket

Remote service abuse

Cloud workload hopping

VPC and subnet traversal

Exfiltration

Data theft detection

Cloud storage exfiltration

Encrypted channel exfil

Data staging and compression

Automated data transfer

Command and Control

Attacker communication

C2 over HTTPS beaconing

Domain fronting

DNS tunnelling

Ingress tool transfer

Impact

Disruption and destruction

Ransomware simulation

Data destruction patterns

Resource hijacking

Service disruption

SABSA security architecture

Controls across the SABSA layers.

Assume Breach maps to SABSA security architecture layers, ensuring controls are designed and validated at every level of the enterprise architecture.

Contextual

Business Risk Context

Defining the business risk appetite and acceptable breach scenarios that drive validation priorities and assurance requirements.

Risk appetite Threat profile Business impact

Conceptual

Security Architecture Principles

Assume Breach principles applied at the architecture level: least privilege, Zero Trust boundaries, layered defence, and observable design.

Zero Trust Least privilege Defence in depth

Logical

Security Services Design

Logical security services that must be validated under breach conditions: identity services, monitoring, segmentation, and response orchestration.

IAM design SIEM services Segmentation

Physical

Platform Security Controls

Platform-level controls tested through BAS: endpoint protection, network controls, cloud security groups, and privileged access workstations.

EDR coverage Network controls PAM tooling

Component

Technology and Tool Validation

Specific technology components validated through simulation: SIEM detection rules, XDR playbooks, GuardDuty findings, and Defender alerts.

SIEM rules XDR playbooks Alert fidelity

Operational

Response and Recovery

Validating that detection leads to response. Testing that SOC analysts receive actionable signals and response playbooks work under realistic conditions.

Response SLA Playbook testing Recovery RTO

Validation approaches

BAS, Red Team, and Purple Team.

Each validation approach answers a different question. Understanding where each fits helps build a complete assurance model.

// Breach Attack Simulation

Continuous Automated Validation

Automated, repeatable simulation of adversary behaviours across controls. Runs continuously or on schedule, mapped to MITRE ATT&CK. Scales across the control estate without manual overhead.

+Continuous, not point-in-time

+Scalable across all controls

+Repeatable after each change

+Evidence-based assurance reports

// Red Team Exercise

Adversarial Campaign Testing

Skilled human adversary simulation across a full campaign. Tests the organisation's detection and response under real conditions, including novel techniques and human judgment. Periodic, deep, and scenario-led.

+Human creativity and judgment

+Full campaign simulation

+Novel technique coverage

+Tests people and process too

// Purple Team Exercise

Collaborative Detection Building

Red and Blue teams working together in real time. Attacker executes technique, defender observes detection outcome immediately. Fastest route to improving specific detection gaps and tuning rules.

+Immediate detection feedback

+Collaborative rule improvement

+Knowledge transfer to Blue Team

+Targeted control improvement

Cloud and hybrid validation

AWS and Azure under breach conditions.

Cloud environments need Assume Breach validation more than on-premise environments. Dynamic infrastructure and distributed identity make static assurance inadequate.

// AWS validation questions

Amazon Web Services

?Do CloudTrail and GuardDuty surface meaningful signals from simulated activity?

?Are IAM role assumption chains visible and constrained?

?Does east-west movement between VPCs trigger detection?

?Are S3 exfiltration patterns detected by Macie or SIEM?

?Do Lambda and ECS workload identity abuses generate alerts?

?Are privilege escalation paths through IAM policies blocked?

// Azure validation questions

Microsoft Azure

?Does Microsoft Defender for Cloud detect simulated attacker behaviours?

?Are Entra ID token theft and misuse scenarios visible in Sentinel?

?Do lateral movement paths between Azure subscriptions trigger alerts?

?Are Managed Identity abuse scenarios detected and contained?

?Do Azure Blob Storage exfiltration patterns surface in SIEM?

?Are privileged role assignments and PIM abuse scenarios logged and alerted?

For architects

What Assume Breach should shape.

Assume Breach is not a post-deployment test. It should influence architecture decisions from the start.

Trust boundaries

Design explicit trust boundaries that assume compromise on one side. Never allow implicit trust to propagate across workloads, networks, or identities.

Identity models

Design identity with containment in mind. If a credential is compromised, what is the blast radius? That answer should be small and bounded.

Telemetry requirements

Architecture decisions must include logging and detection requirements. If an activity cannot be observed, the control is theoretical.

Segmentation strategy

Segmentation should constrain lateral movement, not just separate networks. Design and validate that east-west movement is visible and limited.

Privileged access

Privileged access must have hard stops. Model what happens when admin credentials are compromised. Design and test the hard limits that contain it.

Control layering

No single control should be relied upon to stop an attack. Layer controls so failure of one does not result in undetected compromise.

Response integration

Containment and response must be designed into the architecture. Detection without response capability is observation without consequence.

Recovery assumptions

Design and validate recovery capabilities. Assume Breach means assuming some impact. The architecture must support clean recovery without re-compromise.

Live simulation platform

BreachForge BAS

Everything on this page as a live interactive platform. Run the ransomware kill chain, cloud control-plane pivot, or Active Directory compromise scenarios. Get a gap report in under an hour no sales call required.

6 scenarios

Results in under an hour

Multi-persona output

▶ Run Simulation View platform

// Technical paper and infographic

BAS Framework: The Complete Reference

The full technical paper covering the BAS validation pipeline, MITRE ATT&CK integration, SABSA alignment, and cloud-specific validation across AWS and Azure.

View the infographic

Read now