LOOK ACROSS THE INCIDENTS
Different failures.
Shared lessons.
Put cases side by side. Find the common assumptions—and the safeguards that could break the chain.
Loading comparison…
LOOK ACROSS THE INCIDENTS
Put cases side by side. Find the common assumptions—and the safeguards that could break the chain.
Loading comparison…
SHARED FAILURE PATTERNS
No single tag is shared by all selected cases. The differences can be just as useful as the similarities.
On smaller screens, swipe the comparison horizontally.
| Case file | The early Internet ↗November 2, 1988 | Knight Capital ↗August 1, 2012 |
|---|---|---|
| Failure pattern | Shared dependencies · Untested recovery | Unsafe changes · Hidden assumptions |
| What happened | On November 2, 1988, the Morris Worm began spreading through Internet-connected Unix computers. The FBI estimates roughly 6,000 computers were affected within 24 hours. Universities and research institutions faced severe slowdowns even though the worm did not destroy their files. | Knight Capital’s order router sent more than four million orders while attempting to fill just 212 customer orders. In the first 45 minutes of trading, the firm accumulated unwanted positions and lost more than $460 million. |
| Why it spread | The worm could propagate without attaching to a host program. Multiple weaknesses in network services gave it routes between machines. As copies spread, computing capacity and communication suffered. A system can become unusable through resource exhaustion even when stored data remains intact. | An incomplete deployment and the reuse of a flag activated obsolete trading logic. Controls failed to stop the resulting orders. |
| Impact in context | ~6,000 — computers affected · FBI estimate | $460M+ — trading loss |
| Recovery | Administrators investigated the program, removed it, and in some cases disconnected systems or rebuilt them. Guidance was harder to distribute through the impaired network. The episode helped prompt the creation of a dedicated computer emergency response team, making coordination part of the lasting response. | Knight stopped the problematic trading and unwound positions. The incident exposed gaps in deployment verification and market-access safeguards. |
| Safeguards to discuss | Contain the reach of a compromised system, not just its local effects. Prepare incident communications that survive disruption of the main network. Include resource exhaustion in your definition of harm. | Verify deployment consistency across every node. Remove dead code before reusing its controls. Enforce independent limits on automated actions. |
| Primary source | FBI · Historical case account ↗ | U.S. SEC · Enforcement release ↗ |
Take one shared pattern into a rehearsal or review the evidence behind your own safeguards.
Review your safeguards →