Anatomy of an Incident
summary
A bad CrowdStrike update ships an old data file so a kernel‑mode C++ routine expects 21 vs 20 array items, triggers blue screens across Windows hosts for about an hour and twenty minutes, and causes outages in customers and suppliers. Response uses a rehearsed Slack workflow with four fields (and Teams as a fallback), prewritten customer/status templates, and a prioritized list of critical services (Twilio SMS, banks, transaction monitoring). Reboots sometimes allow a successful patch, post‑incident review fixes contacts, runbooks and quarterly live DR tests.
AI-written summary · about
chapters (21)
- 0:00Start
- 0:10Incident management intro
- 1:53What is an incident
- 3:39Need for incident plan
- 7:29Testing the incident plan
- 11:20Communication templates
- 13:48Handling incident comms
- 16:17Slack/Teams for records
- 17:22Assigning incident roles
- 18:46Status pages and advisories
- 20:10Post-incident reporting
- 23:01Incident plans for major incidents
- 23:44Major incident examples
- 27:35CrowdStrike incident overview
- 31:30CrowdStrike incident timeline
- 33:13Activating CrowdStrike plan
- 35:59Critical systems in incident
- 40:55Customer comms during incident
- 43:05Resolving CrowdStrike incident
- 44:32Key takeaways from CrowdStrike
- 46:38Final incident advice
related talks
51mAnatomy of an Incident
51mReal World Stories of Incident Response and Threat Intelligence
17mIncident Response @ Scale-Building a Next Generation SOC
01h 33mInnovate with Resilience!
40mIncident Response – How to Give the Advantage to the Hackers!
58mOutpacing threats w/ CrowdStrike, Anthropic Claude & Amazon Bedrock
27m“Why are they asking me to do this?” or Adventures in IR Land
44mPanel: Peak Performance Under Pressure: Building Cross-Functional Resilience in Incident Response