The Deserialisation Incident at 02:10

Answer: contain the blast radius first, preserve volatile evidence second, and accept that destroying the pod loses the memory image.

Sequence:

1. Cut the attack path, not the evidence, where possible. Block egress from the pod's network segment to the internet and to the object storage bucket, and disable the compromised partner credentials. This stops data exfiltration and further payload delivery while keeping the process alive and observable. If the attacker still has interactive access, isolation at the network layer is the priority over forensic purity.
2. Preserve state before termination. Capture the container's memory if tooling allows, snapshot its filesystem layer, and pull the full web server, application and WAF logs to write-once storage. Note the exact time of each action. Container forensics is lossy; a terminated pod may leave almost nothing.
3. Terminate and rebuild only after the above, or if containment fails. Rebuild from a known-good image; do not restart the same pod. Treat the host as potentially compromised and remove it from the pool pending inspection.
4. Rotate everything the pod could reach - partner credentials, service account tokens, storage credentials, and any secrets in the environment - on the assumption they were readable.
5. Disable the path, not the product. The vulnerable deserialisation endpoint is taken offline or restricted to a safe input filter; 240 partners will be affected, so communicate early rather than letting them discover it.
6. Keep a decision log. Every containment action, its time and who authorised it, because the notification decision and the audit will both turn on the timeline.

Answer: separate what is known, what is assumed and what is still being established, and let the accountable owner decide on that record.

Structured assessment:

• Known: a partner credential was used successfully, code execution occurred on a host, outbound traffic to an unfamiliar IP occurred, and the host could reach a bucket holding 12,000 customer records. The unauthorised access to the API is itself established.
• Not yet known: whether records were read or copied, which records, and whether the credential was stolen from the partner or reused internally. Absence of proof of exfiltration is not proof of no exfiltration - bucket access logs, egress volume and the timing of the outbound connection answer this faster than speculation.
• Time pressure is a fact, not an excuse. The regulatory clock typically starts when you become aware of a personal data breach, not when the investigation concludes. Where notification deadlines are short, the usual practice is to notify on a provisional basis with the facts available and supplement later, rather than to wait for certainty and miss the date.
• The decision belongs to the DPO and the accountable executive, not to the incident responder. The responder's job is to supply a precise timeline, an affected-data estimate with confidence bounds and the containment status, so the decision is recorded against evidence.
• Preserve the assessment itself. The notification decision record, including the reasoning at the time, is what a regulator and an auditor will examine; a good decision badly documented reads as no decision.

Answer: the verification method for that ASC was inadequate, and the incident is the evidence.

Actions:

1. Reopen the ASC across all applications that use the same pattern, not just the affected one. A code-review sign-off establishes that a reviewer looked at the code; it does not establish that every deserialisation entry point was found, that the allow-list is enforced at runtime, or that a new endpoint added after the review is covered. The verification method must include a runtime test with a crafted payload, and analysis of the call graph to find all entry points.
2. Add the threat to the planning artefacts. The application's threat model should have identified untrusted serialised input on a partner interface; if it did not, the modelling method has a gap, not just the application.
3. Feed the finding back into the ONF and the ASC library - strengthen the ASC's verification criteria, and add a requirement that third-party and partner-facing interfaces receive input-handling review at onboarding and at every significant change.
4. Check the detection gap. The WAF blocked the payload, but the shell spawn and the egress were caught only by a human noticing. Detection content for process spawning in containers and for anomalous egress belongs in monitoring, and the incident shows it was missing.
5. Re-test, then record. The ASC returns to implemented only when the runtime test is repeated on every affected application and the results are retained.

The general lesson to state: an incident is a verification result about your controls, and the corrective action is to fix the verification method, not only the instance.