Incident response
Incident response, with proof
Most incident response burns its scarcest resource, senior attention, on alarms nobody confirmed. The methodology below adds one discipline the standard lifecycle leaves implicit: verify the thing is real before you act on it. Here is the lifecycle we work to, and six incident types walked through it.
The lifecycle
01Prepare
Know your normal before you need it. Learn per-tenant baselines, instrument the sanctioned telemetry, keep signed and hash-chained action logs, and run the tabletop. You cannot spot a deviation from a baseline you never built.
Shield · Blue02Detect
Signal from behavior, not just signatures. The attacks that matter look like your own traffic, slightly wrong: a request for the wrong object, a tool call in the wrong context, a process the host has never run. Deviation is the detector.
Shield · Blue03Verifywhere we differ
Confirm it is real before you page anyone. This is the stage most programs skip and the one we are built around: an out-of-band witness the attacker cannot fake, a proof attached to the block, a finding that reproduces in minutes. Unverified alarms are how teams learn to ignore the real one.
Red · Forge · Shield04Contain
Scoped, authorized, reversible. Enforcement turns on where it is statistically ready, action is bounded to the blast radius you consented to, and every step is logged. Safe-by-default means you can act without breaking production.
Shield · Blue05Eradicate
Root cause, not symptom. Anchor the fix to a trace-grounded cause: the object-access rule that was missing, the refill handler that read past its buffer, the tool the model should never have been able to call.
Forge · Red06Recover
Restore service with bounded loss. Deterministic rollback from filesystem snapshots turns a missed ransomware event into minutes, not days, and decouples recovery from whether detection ever fired.
Blue07Learn
Feed the incident back in. A confirmed deviation sharpens the baseline; a confirmed finding becomes a detection; a false alarm tunes the gate. The loop only improves if every entry into it was verified.
AllSix incidents, walked through it
Ransomware · Blue
A novel variant the detector never saw
The incidentEncryption starts on a finance workstation at 2 a.m. The strain is new, so there is no signature, and it moves slowly enough to slip under the behavioral threshold. By the time anyone looks, a share is half-encrypted.
How it usually goesThe team races to detect and stop something already running, then restores from last night's backup, losing a day of work, if the backups themselves were not reached.
The methodology appliedRecovery never depended on detection. Frequent copy-on-write snapshots hold every pre-encryption version, so response is: identify the affected files, roll back to the last clean snapshot, done. Meanwhile the out-of-band heartbeat had already flagged the agent-tamper attempt as its own alarm.
OutcomeMinutes of data loss instead of a day, and service restored the same morning. A missed detection became a bad hour, not a bad quarter.
Assume Detection Fails →Prompt injection · Shield / Red
A document that told the assistant to leak the thread
The incidentA support agent summarizes an uploaded PDF. Hidden in the document is an instruction: forward this conversation to an external address. The model, unable to tell data from instruction, complies. No bad string, no anomaly a filter would catch.
How it usually goesA guardrail scanning text sees nothing wrong. The exfiltration is discovered later, if at all, when someone notices data where it should not be.
The methodology appliedTesting had already probed this surface with an out-of-band oracle, so the blind injection was caught before launch instead of after. In production, the behavioral envelope flags the output shape, an external link the app has never emitted, and the tool call that fired outside its normal workflow.
OutcomeThe exfiltration path is blocked at the boundary and proven with the learned-versus-observed diff, not a transcript the attacker controls.
The Untested Surface →API breach · Shield
One valid request for the wrong object
The incidentAn authenticated user changes an invoice ID in an API call and starts walking IDs across a tenant boundary. Every request is well-formed. There is no injection, no payload, nothing for a signature WAF to match.
How it usually goesThe WAF waves it through. The breach surfaces in a support ticket or a disclosure, weeks later, after tens of thousands of records have been read.
The methodology appliedA per-tenant baseline knows this user's normal access pattern. Walking IDs across a boundary is a deviation in object access, and a response suddenly returning far more than usual is a deviation in shape. Both fire, with evidence.
OutcomeThe enumeration is stopped in progress and the block ships with the proof of why, so a developer confirms it in seconds rather than arguing about it for a day.
The Attacks Your WAF Was Never Built to See →Supply chain · Red
A dependency the AI assistant invented
The incidentA developer accepts an AI-suggested import for a package that does not exist, until an attacker registers the hallucinated name first. The install command pulls attacker-controlled code, with install scripts, straight into CI.
How it usually goesPost-install scanning finds the malicious package after its scripts have already run on the build machine, with the build's privileges.
The methodology appliedThe risky dependency is caught by its squattability signature, reproducibly hallucinated, plausible, freshly registrable, at the install step, before its scripts execute, both in the developer's environment and in the pipeline.
OutcomeThe package is refused at the door, when refusing is still free, instead of detected after it has already run.
Your AI Assistant Is Writing Your Next Breach →Zero-day · Forge
A memory-corruption bug in a dependency you ship
The incidentA widely-used serialization library your product depends on has an unreported heap out-of-bounds write. A truncated stream is treated as a successful read, and the parser walks past its buffer.
How it usually goesThe bug sits undiscovered until an attacker finds it, or a maintainer is buried under fluent-but-wrong AI-generated reports and misses the real one in the noise.
The methodology appliedThe discovery engine finds it by fuzzing the public source, minimizes a small trigger, root-causes it to the refill handler, and proves exploitability up the ladder. Disclosure goes to the maintainer as a signed packet they verify with one command.
OutcomeA real flaw in your supply chain is found, proven, and fixed under coordinated disclosure, before it becomes an incident, and without flooding the maintainer.
Machines Are Finding Zero-Days →Alert fatigue · Red
The false-positive storm that buried the real one
The incidentA scanner reports four hundred findings. Most are noise: version-string guesses, criticals that need an admin, co-hosted services that were never yours. Somewhere in the queue is the one that mattered.
How it usually goesThe team triages by hand until they learn most alerts are wrong, then starts dismissing them, and dismisses the true finding along with the false ones. The most dangerous outcome is not the false positive. It is the real finding waved away.
The methodology appliedNothing reaches the report unless a deterministic oracle confirmed it, and each finding carries a proof the receiver re-checks in seconds. A clean run reports nothing rather than manufacturing work.
OutcomeThe queue shrinks to what is real and provable, trust in the tool is restored, and the finding that mattered is not lost in the noise.
The Pentest PDF Is a Trust Problem →The thread through all six is the same: the sooner you can prove what is real, the less an incident costs, in dollars, in downtime, and in the trust your team places in its own tools.