← BACK TO THE ARCHIVE

CASE FILE 014 / SECURITY INCIDENT

The network carried the problem.

PRIMARY SOURCE LINKED · ABOUT 3 MIN

A self-replicating worm overloaded computers—and disrupted the channels people needed to respond.

Incident dateNovember 2, 1988
computers affected · FBI estimate~6,000
CollectionTechnology failures
event_sequence / CASE 014November 2, 1988

FOLLOW THE FAILURE

How a fault became an incident.

A condensed sequence, not a minute-by-minute reconstruction.

  1. 01
    THE TRIGGER

    Worm spreads between systems

  2. 02
    THE FAILURE SPREADS

    Computing and communication are overloaded

  3. 03
    THE CONSEQUENCE

    Institutions isolate and recover systems

  4. 04
Source record: FBI · Historical case account ↗
THE CRITICAL BREAK

Computing and communication are overloaded

A response channel that depends on the affected network may fail when it is needed most. Coordination needs its own continuity plan.

Editorial interpretation of the failure pattern.

01 / THE INCIDENT

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.

Evidence: FBI · Historical case account ↗

02 / THE FAILURE CHAIN

Why it happened

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.

QUESTION FOR YOUR TEAM

How would your responders share findings if your normal messaging stopped working?

03 / THE AFTERMATH

Recovery—and its limits

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.

TWO THINGS FAILED TOGETHER

The incident also carried the message.

THE COMPUTERS

Capacity disappeared.

Spreading copies slowed systems. Keeping files intact did not keep services usable.

THE RESPONSE

Coordination slowed too.

Email delays made the impaired network a poor channel for urgent recovery guidance.

The FBI’s figure of approximately 6,000 affected computers is an estimate, not a complete device census. This exhibit does not reproduce worm code.

04 / TAKE IT WITH YOU

Where could the chain break?

Safeguards to investigate—not a claim that one change would certainly have prevented this incident.

01
SAFEGUARD 1Contain the reach of a compromised system, not just its local effects.
02
SAFEGUARD 2Prepare incident communications that survive disruption of the main network.
03
SAFEGUARD 3Include resource exhaustion in your definition of harm.

Go to the source.

A condensed editorial account. The lessons are our interpretation, not quotations. Consult the primary source for the full technical record.

FBI · Historical case account ↗
Practice your response ↗
Compare this failure with another ↗

ONE QUESTION BEFORE YOU GO

Why prepare another way to coordinate during an incident?

TAKE IT TO YOUR TEAM

How would your responders share findings if your normal messaging stopped working?

next_step.txtREAD → PRACTICE

TAKE THE LESSON FURTHER

Prove the way back.

What evidence shows your recovery path actually works?

The rehearsal is fictional; the case is historical. The review starts with unanswered questions.

CONTINUE THE CONNECTION

TRAIL 05The machine followed the rules.Three cases, one recurring question ↗