Sometimes lumped in with digital forensics and incident response (DFIR), the cybersecurity incident response lifecycle is a continuous loop that incorporates preparation, detection, containment, eradication, recovery, and learning.
Properly responding to a cyberattack requires an effective incident response plan. Your incident response plan should account for the attack vector, business needs, priorities, and relevant laws and regulations.
The immediate priority is to isolate the business-critical network while preserving digital evidence, but there are several methods for doing this. We’ll give an overview of the NIST Computer Security Incident Handling Guide, which is one of the dominant frameworks. Then, we’ll outline popular alternatives to help you assess your options.
Effective incident management can carry countless benefits:
Minimize losses
Fix vulnerabilities
Restore operations
Reduce future risks
Protect your reputation
NIST Computer Security Incident Handling Guide (NIST SP 800-61 Revision 2)
The National Institute of Standards and Technology (NIST) established incident handling recommendations in 2004 and has revised them several times since then. This framework is among the most detailed and comprehensive, making it a favorite of many information technology professionals. It breaks the cyber incident response lifecycle into four main stages in an “incident response life cycle.” We’ll provide a brief overview to give you the lay of the land.
Preparation
If an attack occurs, you’ll need to act quickly. That’s why it’s crucial to plan ahead. NIST details several key categories that require preparation. A security team might put together a jump kit with the essentials so that the incident commander or handler has everything they need in one place.
Incident handler communications and facilities
Document relevant contact information, reporting and tracking mechanisms, communication options, and usable facilities to streamline your team’s immediate actions. Otherwise, your response may be chaotic and uncoordinated from the get-go.
Incident analysis hardware, software, and resources
Analysis is a critical step in the security incident response process, so you should be prepared for a thorough DFIR investigation. This forensic evidence can help you understand what happened to fortify affected systems before the next attack. It may also be critical should law enforcement or regulatory agencies investigate.
You should document and maintain resources for collecting and preserving digital evidence, including the following:
Backup devices
Removable media
Portable printers
Digital forensic software
Packet sniffers
Evidence storage bags
Port lists
Current baselines
Network diagrams
Incident mitigation software
Recovering from the security event is essential to resuming normal business operations. Maintain images of clean OS and application installations so that you can restore systems after an attack.
Even with powerful resources in place, you should do everything in your power to prevent a security breach. To that end, you might implement the following:
Risk assessments: Regularly assess and prioritize risks, then mitigate what you can.
Host security: Patch machines, use the principle of least privilege, enable auditing, log security events, and continuously monitor host security.
Network security: Configure the network perimeter to allow only expressly permitted activity.
Malware prevention: Use software to detect and halt malware.
User awareness and training: Train users on policies and procedures, and share lessons learned from previous incidents.
Detection & analysis
Businesses face a barrage of potential signs of an attack. Analyzing this wealth of data to identify actual cybersecurity incidents is an uphill battle. But automated analysis, event correlation software, established logging standards, and regular reviews of data can point you in the right direction. Here are a few steps to keep in mind:
Classify attacks based on the attack vector
Different types of attacks call for different responses. A threat actor may use a variety of attack vectors:
External media
Attrition
Web
Email
Impersonation
Improper usage
Equipment loss or theft
Other
Properly identifying the attack vector can point you toward the best course of action.
Detect signs of an incident
Signs can be categorized as precursors or indicators. Most businesses won’t detect precursors, which hint that an attack may soon occur (explicit threats, unexplained usage of a vulnerability scanner, etc.). Indicators are typically more noticeable and show that an attack may already be in progress. These may include the following:
Alerts from your antivirus software or network intrusion detection sensor
Filenames with unusual characters
Evidence of auditing configuration changes
Failed login attempts from unfamiliar remote systems
Variations from normal network traffic
Analyze incidents
Unfortunately, presumed precursors and indicators can be misleading. Analyzing symptoms using predefined procedures is critical to validating the threat. To that end, businesses should follow these steps:
Establish network and system profiles
Study normal behaviors
Retain logs
Correlate events across logs
Synchronize host clocks
Keep a knowledge base
Research unusual activity online
Use packet sniffers
Filter data
Get external help as needed
Document incidents
Maintain records of all relevant incident-related information, including system events, changes, conversations, and incident response steps. Time-stamp entries, and ensure any documents are signed and dated by the incident handler. While this can seem like a hassle during a cyberattack, it may be essential during any resulting legal prosecution.
Prioritize incidents
If juggling multiple incidents, don’t just take them as they come. Prioritize based on the functional impact, information impact, and recoverability, and respond in a logical order.
Notify relevant individuals
Your preparations and policies should already document who to contact and when, so this should be a layup. Here are a few parties that might be on your contact list:
Incident response team (internal or external)
Chief technology officer (CTO)
Chief information security officer (CISO) and other information security leaders
System owner
Public affairs department
Legal department
Law enforcement
US-CERT
Prepare several communication methods (email, phone calls, paper, etc.) since the nature of the attack may influence the ideal medium. For instance, out-of-band channels (written communication, personal interactions) may be critical if your email or VoIP system is affected.
Containment, eradication, & recovery
While some IR frameworks treat these as separate steps, NIST groups containment, eradication, and recovery together. This phase is essential to isolating mission-critical network resources and resuming normal operations.
Choose a containment strategy
Containing the attack quickly can help minimize damage. Potential strategies include shutting down the system, disconnecting an affected device from the network, or disabling key functions. Ideally, you should map out potential approaches ahead of time so that you don’t have to make major decisions in the heat of the moment. Consider the following factors:
Possibility of resource damage and theft
Evidence preservation
Service availability
Necessary time and resources
Effectiveness
Duration
Gather evidence
Collect digital evidence to help resolve the incident, learn from the experience, and provide as documentation for any legal proceedings. Follow relevant laws and regulations, and maintain a clear chain of custody. You should log the following information:
Identifying information (device serial number, model number, IP address, hostname, location, etc.)
Name, title, and phone number of those who handled evidence
Date and time of evidence handling
Evidence storage location
Identify attacking hosts
Let’s be honest: Identifying the attacking hosts is a super low priority compared to containment, eradication, and recovery. Not only is it time consuming, but it’s frequently futile. That said, if you have the staff, time, skills, and incredible luck, it can shed light on your situation. If you choose to go with this route, you might attempt these steps:
Validate the attacker’s IP address
Research the attacking host online
Leverage incident databases
Monitor attacker communication channels
Eradicate the threat and recover
After you’ve contained the threat, it’s time to eliminate any lingering traces. Delete malware, and disable breached accounts. Mitigate any vulnerabilities that the attack exposed. Depending on the extent of the attack, you may need to perform some combination of the following steps:
Restore from clean backups
Rebuild systems
Replace compromised files
Install patches
Change passwords
Enhance network perimeter security
Eradication and recovery typically require a phased approach with careful prioritization. While the main goal is restoring functionality, remember that attackers may aim to exploit the same vulnerabilities again. Therefore, you should learn from the experience to prevent a similar incident from occurring in the future.
Post-incident activity
Once things have settled down, set aside time to organize your data and make adjustments. This step should cycle directly back around to the preparation phase so that each incident enhances your cybersecurity posture.
Hold a meeting on lessons learned
Provide closure and promote improvement by holding a meeting to discuss what you learned from the incident. Go over what happened, how you responded, and what you might do differently next time.
Put together a follow-up report
Follow-up reports can help you train new team members and revise existing policies and procedures.
Share incident data
You can use relevant data to justify allocating budget for incident response, reveal systemic weaknesses, track incident trends, and more.
Retain evidence
You should have (and follow) a documented policy on retaining evidence. Saving evidence may be critical if the attacker is prosecuted.
Alternative incident response frameworks
The NIST Computer Security Incident Handling Guide is undoubtedly one of the most well-known IR frameworks, but it’s not the only horse in the race. Countless other options have loyal devotees. While they have significant overlap, any of these frameworks may be ideal depending on your security needs.
We won’t provide as much detail on these guidelines since they’re somewhat redundant, but we’ll briefly summarize two popular alternative frameworks to help you weigh your options.
In 2021, the Cybersecurity and Infrastructure Security Agency (CISA) released a document with two separate playbooks specifically targeting incidents and vulnerabilities. The incident playbook is very similar to NIST’s response framework but breaks the process down into smaller chunks. The vulnerability guidelines are also quite similar but reframed to focus on problems that have not yet resulted in incidents. We’ll highlight a few of the activities involved in each stage.
Incident Response Playbook
Preparation
Define baselines
Document policies
Instrument detection
Make staffing plans
Educate users
Use threat intelligence
Detection & analysis
Report the incident to the CISA
Determine the scope
Gather and maintain data
Analyze the incident
Correlate events
Containment
Isolate impacted systems
Capture forensic images
Update firewall settings
Block unauthorized access
Close relevant ports, servers, and services
Eradication & recovery
Remediate and reimage affected environments
Replace infected files
Install patches
Change passwords of suspected compromised accounts
Watch for signs of response from the attacker
Fortify perimeter security
Test systems
Post-incident activities
Continue to monitor the environment
Produce incident reports
Analyze lessons learned
Coordination
Coordinate with the CISA
Vulnerability Response Playbook
Preparation
Inventory systems and networks
Identification
Monitor threat feeds
Evaluation
Assess whether the vulnerability occurs in your environment
Remediation
Install patches
Isolate vulnerable assets
Change configurations
Reports and notification
Share information with the CISA
Released in 2012 by the cybersecurity training organization SANS Institute, The Incident Handler’s Handbook provides an approachable and concise guide. It is similar to the NIST guidelines but more concise, so it might be ideal for professionals seeking quick answers. We’ll break down the key sections.
Preparation
Prepare the following:
Policy
Response plan
Communication
Documentation
Team
Access control
Tools
Training
Identification
Gather information
Determine whether there was an event
Report to the designated team
Document everything
Containment
Isolate infected segments
Take a forensic image
Rebuild clean systems
Remove backdoors and attacker accounts
Install patches
Eradication
Remove malicious content
Reimage the hard drive
Patch vulnerabilities
Disable unused services
Scan with antimalware software
Recovery
Test, monitor, and validate systems
Return recovered systems to the production environment
Lessons learned
Complete documentation
Prepare an incident report
Hold a lessons learned meeting
Even businesses with the most robust cybersecurity programs could face a cyberattack. Enhancing your incident response capabilities helps you tackle threats head-on and leverage learning to continuously improve your posture.
Incident response lifecycle FAQs
What is incident management?
Incident management entails identifying, analyzing, and resolving disruptions to normal IT operations. In some cases, incidents may be attributed to software glitches or user errors. In others, the root cause is more nefarious, such as a data breach, insider threat, or malware. However, most incident response frameworks focus exclusively on the latter, aiming to tackle cybersecurity attacks as quickly as possible.
What is the difference between a security incident response plan and a disaster recovery plan?
Incident response planning focuses on detecting and responding to cyberattacks. In contrast, disaster recovery planning concentrates on recovering resources and restoring normal business operations after any type of disaster, including cyberattacks, natural disasters, user errors, hardware failure, and software failure.
Who should be on an incident response team?
An IT incident response team often consists of your security operations center (SOC), computer security incident response team (CSIRT), or computer emergency response team (CERT). Common roles include an incident manager, incident responders, SOC analysts, investigators, researchers, legal representatives, and a communications liaison. Some businesses also benefit from having a certified incident handler on the team.
How do you reduce the likelihood of future incidents?
Post-incident activity should include reviewing what happened, why it happened, and how you might prevent it from happening again. In many cases, this involves beefing up your incident response capability and cyber resilience. Incorporating more penetration testing, threat hunting, and other cybersecurity tests — along with security awareness training and strong IT policies — can also help you enhance your security posture and decrease your susceptibility to attacks.
As part of the preparation and recovery stages, businesses should ensure their machines are up to date. Delaying the installation of critical patches gives attackers the opportunity to exploit newly discovered (and publicized) vulnerabilities. Luckily, patch management is easy with PDQ.
You can spot outdated software at a glance with PDQ Inventory's robust data. Meanwhile, you can deploy updates and custom scripts with just a few clicks using PDQ Deploy. We’d say these two solutions are like Batman and Robin, but both are full-fledged superheroes. So they’re basically like Batman and Batman. And if you're struggling with those hard-to-reach remote endpoints, PDQ Connect comes to the rescue. Get a free trial to start your PDQ origin story.
