Operate
Console route · /chaos
Chaos Engineering (Test Fire)
Breach-and-attack simulation. A Test Fire injects a labeled synthetic attack, runs the real detection engine over it, and scores which expected detectors actually fired — detected, partial, or missed — mapped to MITRE ATT&CK. It never executes a live response and never disguises synthetic activity as production telemetry.
Why this surface exists
Executives do not trust green checkmarks; they want proof the system works. A quiet detection console can mean coverage is solid, or that the detectors are silently blind. Chaos Engineering exists so the second case is measurable rather than assumed.
A Test Fire is adversarial proof of detection, not response orchestration. It sits under Operate next to Hunt Ledger because both answer a leadership question about whether the platform is actually working . Hunt Ledger proves continuous hunting happened; Test Fire proves the detectors fire when an attack shape appears.
How a Test Fire works
Each scenario crafts a small set of events shaped to satisfy a specific detector's documented threshold (for example a credential-stuffing burst, a password spray across identities, a C2 beacon cadence, DNS tunnelling, or bulk exfiltration). Those events are written as telemetry with synthetic provenance and a per-run dataset id, then the genuine detection engine evaluates them exactly as it would live data.
Scoring compares the detectors that fired against the scenario's expected detectors. Each expected signal resolves to detected (fired and raised an evidence case), partial (fired in shadow or without opening a case), or missed (stayed dark). The run reports a coverage score, mean time to detect, events injected, and the evidence incidents it raised.
Because the injected data carries synthetic provenance, it is isolated from real hunting, dashboards, and operational metrics. A Test Fire can be run safely against a production tenant: isolated telemetry, real detectors, no containment.
What the workbench shows
- Route: /chaos (Operate)
- Simulation Arena: the scenario library with a Test Fire button per scenario
- Scorecard: coverage meter, detected/partial/missed per detector, evidence case links, mean time to detect
- Coverage Matrix: detector-by-detector coverage aggregated across recorded runs, mapped to ATT&CK technique
- History: prior simulations with outcome and coverage
- API: GET /v1/chaos, GET /v1/chaos/scenarios, GET/POST /v1/chaos/runs
Permissions and boundaries
Viewing scenarios and results uses normal tenant read access. Launching a Test Fire requires detections:manage (or an admin baseline), because it writes telemetry and exercises the engine. A fired detector links to Detection Engineering, where the detector is tuned; a raised case links to Incidents.
Chaos Engineering is not Automation and not a live response tool. It proves detection coverage; it never isolates, disables, revokes, or blocks. When the control plane is unreachable the page says so and does not substitute a synthetic board.
If a Test Fire reports missed for a detector you expected to fire, that is the point of the surface: a real coverage gap to tune in Detection Engineering, not a UI bug to hide.