Breach and attack simulation (BAS) is the practice of safely replaying real attacker techniques against your own environment to check whether your security controls actually detect and stop them. You can run it through an automated platform, as a manual threat emulation exercise, or as a discussion-based tabletop exercise.
Key takeaways
- BAS answers one question: Would we actually catch this if it happened today?
- There are three ways to run it—an automated platform, manual threat emulation, or a tabletop exercise. Most teams only know about the first.
- BAS is continuous and repeatable. A penetration test is a point-in-time engagement that hunts for new ways in. They prove different things.
- BAS platforms validate technical controls. They can’t tell you whether your team escalated correctly or whether your plan survived contact with a real decision.
- You don’t need to buy anything to start. The discipline works manually.
Most security programs are built on an assumption that never gets checked: the controls we bought are doing what we bought them for. Breach and attack simulation is how you check. It replays known attacker behavior inside your own environment—safely, on purpose, on a schedule—and watches what your stack does about it. The results are frequently worse than teams expect, which is the point. A gap you found on a Tuesday afternoon costs a meeting; the same gap found by a cybercriminal costs considerably more. If you’d rather test your people and your plan than your tooling, the Oh Noes! incident response tabletop exercise is the free place to start.
How breach and attack simulation works
BAS runs as a loop, not a project. There are six stages:
- Select a technique. Pick attacker behavior that’s relevant to you—usually mapped to the MITRE ATT&CK framework, which gives you a shared catalog of what real adversaries do and a shared vocabulary for talking about coverage.
- Execute it safely. Run the technique in your environment without the destructive payload. Credential dumping runs, but nothing gets exfiltrated. Encryption behavior runs against a test share, not your file server.
- Observe the control response. Did prevention block it? Did a detection fire? Did an alert reach a human? These are three separate questions and teams routinely conflate them.
- Measure the gap. Record what should have happened against what did. This is where the loop produces something a detection engineer can act on.
- Fix it. Tune the rule, onboard the missing log source, or change the control configuration.
- Re-test. Run the same technique again and confirm the fix works. Skipping this step is how teams end up with a backlog of detections they believe in and can’t demonstrate.
The three ways teams run BAS
Ask most people what BAS is, and they’ll describe a platform. That’s one delivery model out of three, and it’s the most expensive one.
Automated BAS platforms
Software that runs a library of attacker techniques against your environment continuously or on a schedule, then reports coverage against a framework. Strong at breadth, strong at repeatability, strong at showing a board a number that moves. This is the commercial category—vendors like Cymulate, AttackIQ, SafeBreach, and Picus sit here.
Manual threat emulation
A human builds a scenario around a specific adversary’s tradecraft and runs it, usually in a lab or a scoped production environment, while defenders watch. Narrower than a platform and much sharper. You learn things about a specific threat that a technique library won’t surface. This is the model the Expel security operations center (SOC) uses—more on that in threat emulation.
Tabletop and discussion-based simulation
There’s no execution at all here. The team talks through an attack in real time while someone plays the scenario against them. It tests the thing the other two models can’t reach: decisions. Covered in full in our guide to the incident response tabletop exercise.
These aren’t competing options. A mature program runs all three at different cadences, because each one proves something the others don’t.
Breach and attack simulation vs. penetration testing vs. red teaming
These four get used interchangeably and they shouldn’t. Here’s what separates them:
| Breach and attack simulation | Penetration test | Red team engagement | Tabletop exercise | |
|---|---|---|---|---|
|
Goal |
Validate that controls detect and block known techniques | Find exploitable weaknesses | Test whether the whole security program notices a determined adversary | Test the plan, the people, and the decisions |
|
Frequency |
Continuous to quarterly | Annual, or per compliance requirement | Annual at most | Twice a year |
|
Relative cost |
Low to high, depending on the delivery model | Moderate | High | Near zero |
|
Who runs it |
Your team, or a platform | External testers | External or internal offensive team | Anyone on your team who can stay neutral |
|
What it proves |
Coverage | Exploitability | Whether you’d actually notice | Whether the plan works under pressure |
TL;DR: A penetration test asks “Can someone get in?”, BAS asks “Would we see it?”, a red team asks “Would we see it when they’re actively trying not to be seen?”, and a tabletop exercise asks “And then what would we do?”
All four questions matter. Most programs over-invest in the first and under-invest in the rest.
What BAS tools do, and where they stop
An automated BAS platform maintains a library of attacker techniques, executes them on a schedule, and reports what your controls did. The good ones map results to MITRE ATT&CK, track coverage over time, and hand your detection engineers a prioritized backlog instead of a PDF. That’s real value, and it’s worth paying for if you have the environment complexity to justify it.
Here’s where the category stops: A BAS platform tells you a detection fired, but it can’t tell you that the alert landed in a queue nobody watches overnight, that the analyst who saw it wasn’t sure it warranted escalation, or that the escalation path names someone who left in March. The platform’s job ends at the alert. Most incidents go wrong after that.
This isn’t a criticism of the tooling. It’s a scope boundary, and teams get into trouble when they mistake coverage for readiness.
How to get started without buying a platform
You don’t need procurement approval to start doing this well.
- Pick five techniques, not 500. Choose the ones that map to how organizations like yours actually get compromised. Phishing to execution to credential access covers a lot of real intrusions.
- Run them manually first. Atomic Red Team and similar open libraries give you safe, documented tests you can execute without a platform.
- Write down what should happen before you run it. Predicting the result and being wrong is the whole learning event. Skipping the prediction turns the exercise into a demo.
- Test the human layer separately. Run a tabletop exercise twice a year alongside the technical testing. It takes two hours, and it finds different problems.
- Fix and re-test before you expand scope. Ten techniques you’ve validated and closed beat 200 you’ve measured once.
Buy a platform when manual testing has proven the discipline is worth scaling, and you know what you’d do with continuous results. Not before.
Expel’s take
Expel Managed Detection and Response (MDR) exists in the space BAS platforms point at. We maintain 2,450 proprietary detections across 160+ coverage areas, and we run threat emulation exercises against our own environment for the same reason our customers run BAS against theirs—because a detection you haven’t tested is a hypothesis.
What we see across customer environments is that the detection layer is usually in better shape than the response layer. Alerts fire. The question is what happens next, and that’s where the 14-minute mean time to remediate on fully automated high and critical incidents comes from—not a smarter detection, but a decision path that doesn’t stall.
Ruxie handles the repeatable parts of that path—enrichment, correlation, the investigative legwork that used to eat an analyst’s first 10 minutes. It’s AI in the human loop, which means a person still makes the call. That’s deliberate. The gap BAS can’t measure is a judgment gap, and you don’t close a judgment gap by removing the judgment.
Frequently asked questions
What is breach and attack simulation?
Breach and attack simulation is the practice of safely replaying known attacker techniques inside your own environment to verify that your security controls detect and block them. It answers a specific question: would we actually catch this if it happened today?
What is the difference between breach and attack simulation and penetration testing?
A penetration test is a point-in-time engagement where humans try to break in and report what they found. Breach and attack simulation is continuous and repeatable, focused on validating whether your existing controls fire, rather than on discovering new vulnerabilities.
Do you need a BAS tool to run breach and attack simulation?
No. Automated BAS platforms make testing continuous, but teams can run the same discipline manually through threat emulation exercises or discussion-based tabletop simulations. Many teams start manually, learn where their gaps are, and buy tooling later.
How often should you run breach and attack simulation?
Automated BAS platforms typically run continuously or weekly. Manual threat emulation exercises work well quarterly. Tabletop exercises that test people and process rather than tooling are commonly run twice a year, plus after any major environment change.
What does breach and attack simulation not test?
BAS tools validate technical controls, not human judgment. They can’t tell you whether your team escalates correctly, whether leadership gets the right information, or whether your incident response plan survives contact with a real decision. That requires a tabletop exercise.