Most place lightweight test points — agents or equivalent runners — on authorised endpoints, servers, or network segments. Some offer packaged tests that run without a permanent agent. Either way, scope approval comes first.
Platform Guide
How a Breach and Attack Simulation Platform Works
The operating loop inside a breach and attack simulation platform: place test points, select techniques, run inert simulations, record control outcomes, and retest after the fix.
The Operating Loop
The platform runs a closed loop, not a one-time scan.
How a BAS platform works…
Test points inside an authorised scope execute inert, ATT&CK-mapped techniques. The platform then asks each control in the path whether it blocked, detected, logged, or missed the activity — and stores that answer so the same technique can be run again.
Independent guides describe this as a five-step cycle: choose a scenario, execute it safely, evaluate detection and prevention, identify the gap, then remediate and retest. Vendor pages describe the same loop with different names for the console and the library.
The loop is only useful if step five uses the same scenario as step two. A new test after a fix does not prove the original gap closed.
Inputs
An authorised scope, a technique or short campaign from the library, and the controls you expect to respond.
Execution
Inert artefacts and behaviours that create the telemetry a real technique would, without encryption, data theft, or service loss.
Outputs
A timestamped outcome per control, an owner for each miss, and a retest result after the change.
Five Steps
From scenario selection to a closed gap.
Teams that skip the retest keep a list of findings. Teams that keep the scenario ID keep a control history.
01
Set the scope
Name the hosts, segments, mailboxes, and cloud accounts in bounds. Record exclusions and the change window before anything runs.
02
Select the techniques
Pick ATT&CK-mapped scenarios that match the threats, sectors, and controls you are accountable for — not the entire matrix in week one.
03
Execute safely
The platform runs inert simulations. Endpoint, email, and network controls see the behaviours they are supposed to catch.
04
Record the outcome
For each control in the path, store blocked, detected, logged only, or missed. A SIEM that never opened a ticket is a different result from an EDR that quarantined the activity.
05
Fix and retest
Detection engineering or the control owner changes the rule or policy. The same scenario runs again. The platform keeps both results.
What the Run Proves
Record the control result, not a story about risk.
The run records
- Technique and ATT&CK identifier
- Control that was in the path
- Prevention result and detection result
- Whether an alert was investigation-ready
- Time of the run and the scenario version
- Retest result after remediation
The run does not claim
- That every possible attack path was found
- That a CVE is or is not exploitable
- That a passing technique will pass after the next agent update
- That human operators would stop at the same point
- A risk score with no control evidence behind it
Outcome Model
Four results, and why they are different.
| Outcome | What it means for the control |
|---|---|
| Blocked | A preventive control stopped the technique before it completed |
| Detected | The control or SIEM raised an alert a person can investigate |
| Logged only | Telemetry exists, but no detection rule turned it into an alert |
| Missed | No block, no alert, and no useful log for that technique |
| Regressed | A previous pass now fails after a policy, agent, or content change |
| Retest pass | The same scenario now blocks or detects after the fix |
Frequently Asked QuestionsHow the loop runs,
How the loop runs,
answered.
Often enough to catch drift: a scheduled pack for the techniques you care about, plus an extra run after EDR policy, SIEM content, or gateway changes. Daily for a narrow pack and weekly for a broader one is a common starting cadence.
Inert artefacts, no destructive payloads, no use of real credentials or live customer data, an exclusion list, and a named owner who can stop the run. The platform should make those constraints visible, not optional folklore.
It should. A useful integration checks whether the expected log arrived and whether a detection rule fired. A screenshot of the EDR console alone misses the detection pipeline.
The miss becomes a remediation task for the control owner or detection engineer. After the change, the same scenario is retested. Closing the ticket without a retest leaves the gap unproven.
Related reading and resources
Follow the loop into the controls it tests, the programme that operates it, and the Valitrix platform.
Walk through one closed loop
Watch a technique move from miss to retest.
Request a Valitrix demo and follow one authorised simulation from execution to control outcome to retest, across endpoint, email, network, or SIEM.