1. Introduction
What makes incident response meaningful is not the tools we use or the novelty of a particular exploit. It’s not the capabilities of a forensics platform, nor the promises of bulletproof endpoint protections. It’s not the sophistication of a threat intelligence feed, nor the assurances of a managed service provider.
What makes incident response meaningful is that the choices we make under pressure directly shape outcomes.
An incomplete understanding of scope can lead to confident but incorrect assurances to leadership, regulators, and customers about the extent of the attacker’s access. A containment action taken too early or too narrowly can reveal the response to an attacker before removing their access. A rushed eradication effort can leave behind persistence mechanisms that quietly restore access to systems. Miscommunication of a recovery plan can lead to costly downtime or data loss.
In incident response, how responders act matters at least as much as what they respond to. This book aims to help readers make better decisions in those moments.
Rather than focusing on a catalog of tools or one-off case studies, this book examines the process of incident response. It explores the strategies that distinguish effective, measured responses from reactive tasks in isolation. We will explore incident response models, understand their contributions and limitations, and examine how they fare against real-world adversaries that adapt and evolve. We will look at incidents in which organizations appeared to fix the problem, only to later discover that the attacker had never truly left. We will extract the patterns behind those failures and successes, and use them to build a dynamic, iterative response approach.
The goal is not to provide a script to follow, but to help readers develop the skills and judgment to adapt their response to each incident’s unique circumstances. We will focus on the mechanics of identification, verification, and triage. We will examine scoping, containment, eradication, and recovery. We will explore how to complete these activities in a way that reduces the likelihood of re-compromise and missed impact, while mitigating the overall impact on the organization. Each chapter detailing this process concludes with Step-by-Step sections that translate concepts into actionable procedures readers can apply immediately.
The path ahead requires commitment. Incident response demands continuous learning, willingness to operate under uncertainty, and resilience to maintain focus when outcomes are not fully within one’s control. An effective response requires collaboration across teams, clear communication under pressure, and a balance between technical precision and strategic thinking. It requires understanding one’s sphere of influence and working effectively with decision makers and other stakeholders. It requires recognizing that no organization, however well-prepared, is immune to incidents, and that what differentiates effective incident response is how responders act.
For those responsible for responding to incidents today, or those who expect to be, this book is a practical companion. The aim is to provide a clear, repeatable approach that improves decision quality when the stakes are high, the information is incomplete, and the clock is ticking in the attacker’s favor.
Let’s get started.
The Need for Incident Response
In the opening narrative, Jordan works as a developer at the fictitious NovaRise, developing the NovaFlow product. Like many developers, Jordan spends time integrating third-party code into products, leveraging libraries, packages, frameworks, and Software Development Kits (SDKs) to speed up development and reduce the amount of code to write. This is a common practice in software development and saves organizations significant time and money. It also introduces a new risk: the threat of supply chain interdiction.
Jordan investigates an unexpected process listening on port number 8080. The SDK provided by Gilded Freight has some questionable components, including undocumented listeners and processes, and obfuscated code in the SDK installer script.
To many organizations, this is the beginning of an incident, one that should be investigated, documented, and responded to in a timely manner to prevent further harm to the organization. In Jordan’s case, as in many organizations, there is no formal incident response plan in place, and no clear requirement for Jordan to report the incident to anyone in the organization. Jordan attempts to manage the situation by terminating the concerning processes and removing the SDK from the filesystem.
| The term incident refers to an adverse event in an information system or network, or the threat of such an event, implying harm or the attempt to harm. |
The narrative continues to illustrate the threat actor, Pyrix’s, perspective and the actions taken to gain access to NovaRise systems. Jordan’s actions to remove the SDK from the system are not enough to prevent further harm. Pyrix uses stolen credentials and SSH keys to move laterally through internal development servers, pivot into NovaRise’s AWS environment, and exfiltrate customer shipping data and the proprietary NovaFlow routing algorithm. By the time anyone investigates, Pyrix has accessed systems well beyond Jordan’s workstation, compromising both customer data and the intellectual property that differentiates NovaRise in the market.
The case study concludes with an incident response analyst investigating Jordan’s ticket and following a structured, competent response process. The analyst’s work is thorough for the single workstation examined, but the linear progression from identification through recovery never prompts the broader scoping that would reveal the extent of the compromise. This gap illustrates a problem common in many organizations, and one that recurs as a theme throughout this book. Linear incident response models that omit iterative scoping and verification steps often result in incomplete responses.
As incident responders, we are tasked with preparing organizations to respond to incidents like the one NovaRise faced. We are responsible for developing the plans, procedures, and strategies to respond to incidents. We observe, orient, detect, and act by applying triage, verification, scoping, containment, eradication, and recovery processes. We continually improve our processes by reviewing actions taken before and during incidents, using metrics to assess our effectiveness, and applying lessons learned to enhance our response in the future.
The Purpose of This Book
This book is not intended to be a comprehensive guide to the tools used to collect and analyze evidence during an incident. There are several excellent books that cover this topic in great detail. [1] Nor is it intended to be a treatise on the elements of incident management, or the high-level strategic planning required to build an incident response program.
Instead, this book provides insights into incident response and the strategies responders can adopt to meaningfully reduce the impact of incidents on their organization. Intended for technical analysts and incident responders, this book provides a clear path to understanding the incident response process. It covers how to minimize mistakes, improve the effectiveness of the response effort, leverage information resources to inform decision-making, and prepare organizations to respond to changing attacker Tactics, Techniques, and Procedures (TTPs).
Changing Demands of the Incident Response Function
Over the last few decades, the needs of incident response have changed significantly for organizations. What was once an effort designed to respond to a computer virus or a violation of an acceptable use policy has evolved into complex, company-wide initiatives designed to limit the impact of cyber threats and maintain compliance with regulatory requirements.
The changing demands of the incident response function are driven by several factors, including:
-
Increased reliance on digital services: The digital transformation of organizations has heightened reliance on digital services, thereby increasing the severity of cyber incidents.
-
Increased threat complexity and volume: The number and sophistication of cyber threats have increased significantly in recent years. Organizations need to respond to a wide range of threats, from small-scale malware infections to sophisticated nation-state attacks.
-
Regulatory requirements: Organizations are subject to a growing number of data protection and privacy regulations, with mandatory breach notification requirements in many jurisdictions and increasingly complex reporting requirements for cyber insurers.
-
Coordinated intelligence sharing: Organizations are increasingly participating in threat intelligence sharing initiatives to better understand the threats they face and to collaborate with other organizations to defend against them.
-
Rise of ransomware and extortion threats: Ransomware and extortion threats have become more prevalent and sophisticated, with attackers targeting organizations of all sizes and industries.
-
Cloud and third-party risks: Cloud environments and third-party services are integral to business operations, requiring specialized incident response strategies to address misconfigurations, breaches, and shared responsibility models.
-
Remote work challenges: The shift to remote work for many industries has introduced new challenges for incident response, including securing remote endpoints, managing remote incident response teams, and responding to incidents in a distributed environment.
-
Public and stakeholder expectations: Organizations are under increasing pressure to demonstrate effective incident response capabilities to customers, regulators, and other stakeholders.
-
Emphasis on proactive defense: Incident response teams are increasingly focused on tools such as Security Information and Event Management (SIEM), Extended Detection and Response (XDR), and Security Orchestration, Automation, and Response (SOAR) to quickly identify and mitigate the impact of security incidents.
-
AI-driven attack orchestration: The rise of AI has enabled attackers to automate and scale their operations, creating new challenges for incident response teams to detect and respond to threats using conventional response methods.
These factors collectively require organizations to adopt more sophisticated, coordinated, and adaptable incident response capabilities. While many organizations have adopted models to guide their response functions, these models often predate modern challenges and do not sufficiently address the demands described here.
A Path Forward
The chapters that follow aim to close the gap between traditional models and the demands of modern incident response. The next chapter traces the history of incident response from its earliest incidents through the development of the formal models that organizations rely on today. The frameworks, techniques, and considerations introduced throughout the rest of the book are designed to equip responders with a practical, repeatable approach to working under pressure with incomplete information, while remaining adaptable to the unique circumstances of each incident.