The Incident Response (IR) Process & Lifecycle
Incident response focuses on how organizations deal with data breaches. Cybersecurity incident response plans work to minimize damage to systems and data in the event of a cyber attack, data breach, or outage. Having an effective incident response program is crucial for any organization to recover with minimal disruption in the event of an incident. Learn more about incident response and how to create an incident response plan.
What Is Incident Response?
Incident response (IR) is how an organization responds to cyber attacks and data breaches to minimize system damage and mitigate or address data theft. Organizations may deploy incident response plans to react to other IT threats, including server downtime and outages.
Not only does incident response refer to how an organization responds to network threats, it also addresses factors such as:
- Controlling damage to a brand’s reputation
- Addressing any legal concerns presented by the incident
- Enabling business operations to continue with minimal disruption
- Improving the network’s future security posture through the application of best practices
Why Is Incident Response Important?
Incident response plays a crucial role in preventing incidents from evolving into costly issues such as data breaches, system outages, and other losses. Incident response plans ensure that organizations can respond quickly to attacks to minimize losses, identify and fortify vulnerabilities, create new processes to mitigate the risk of future incidents, and strengthen old processes.
While cyberattacks may always be a threat, having an organized incident response plan to counter them can prevent a lot of damage to a brand’s image in the long run.
NIST Incident Response Lifecycle
Incident response is a complex activity requiring expertise from multiple disciplines and lasting anywhere from weeks to months. As such, there are multiple models and frameworks to assist businesses in understanding and implementing the incident response process. [redacted] subscribes to the NIST incident response framework, outlined in NIST 800-61 R2.
NIST 800-61 R2 outlines four phases of cyber security incident response:
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident activity
Each of these phases will be explored in more detail below.
The following topics fall into the preparation phase:
- Creating and practicing an incident response plan
- Establishing a secure communications plan
- Creating and maintaining accurate network diagrams
- Training system administrators and network security professionals
- Creating and maintaining secure backups
1. Incident Response Plan
Creating and rehearsing an incident response plan (IRP) is a critical part of the preparation phase and, at a minimum, should address the following:
- Roles and responsibilities
- Incident classification
- Internal and external communications
- Reporting requirements
- External resource requests and management
More details and assistance in creating an IRP can be found here.
An incident response plan must be studied and practiced or will likely fail to function as desired during an actual incident. Bring together everyone who has a role in the plan to read through and discuss it prior to an incident.
2. Secure Communications
After compromising a network, advanced bad actors will monitor email and chat communications for evidence that they have been detected. If they discover they have been detected, they will change their tactics, techniques, and procedures to better evade network defenses. For this reason, it is important to have a plan for secure out-of-band communications that can be used exclusively during an incident. This could be as simple as a chat room using a service like Signal, or as complicated as rapidly hosting a chat server on an external infrastructure.
3. Accurate Network Diagrams
Accurate network diagrams and critical asset inventories are a valuable force multiplier to a skilled incident response team. With these in hand, an IR team may more effectively triage the network, contain the actor, and, ultimately, evict the actor and remediate the network. Network diagrams and asset inventories are not something that can be generated once, then forgotten. They must be constantly revisited and updated as the network adapts and evolves to meet the changing demands of the company.
4. Regular Training
Incidents do not happen every day, and without regular training, the skills necessary to perform incident response will atrophy. It is important that system administrators, network administrators, and security professionals all receive regular training to keep their skills sharp.
5. Secure Backups
Since ransomware is the primary threat to business networks, backups are an integral part of preparation. Backups must be immutable, meaning that they cannot be changed after they are taken. When implemented properly, this will prevent backups from being encrypted by ransomware. It is also important that old backups are preserved for some period after a new backup is taken to eliminate the risk that an encrypted backup overwrites an unencrypted one.
Detection and Analysis
The second stage of incident response, according to NIST, is detection and analysis. This can be divided into the following topics:
It is best to detect bad actors in a network before the actors reveal themselves. The greater the network visibility, the greater the number of detection opportunities. Common methods of detection include:
- Antivirus or EDR alerts
- Firewall alerts of suspicious inbound or outbound activity
- Email report of malicious file or link
- User or administrator report of unusual activity
The first step of analysis is to determine if the event detected is a malicious occurrence. False positives are more common than true positives. For instance, anti-virus scans often detect legitimate programs as malicious, firewall alerts are triggered when users back up files, email scanners flag financial spreadsheets with necessary macros, and users question changes from a recent update. This first step seems simple, but the consequences of an erroneous conclusion at this point are often disastrous to a network.
Once an event is confirmed to be an incident, it must be investigated to determine its scope . Scoping attempts determine the following:
- What systems and applications are compromised or otherwise impacted
- What is the origin of the compromise
- What tactics, techniques, and procedures (TTPs) the adversary is using
- Who is the attacker (if evident)
This may be done using the network’s existing visibility tools or by deploying additional ones. All work should be documented for concurrent and future reference, but it is of utmost importance that any actions taken against the network are immediately and thoroughly documented. Without thorough documentation, it rapidly becomes difficult to determine what actions were taken by the defender vs. the adversary.
Once the IR team has a reasonable understanding of the scope of an incident, the incident should be prioritized. This prioritization often ties into resource allocation in an IRP. NIST recommends prioritizing incidents based on three factors: functional impact, information impact, and recoverability.
- Functional Impact refers to the impact an incident has to the business needs of an organization. It addresses the question, “Is the organization able to continue to achieve its goals?” This is ranked on a four-point scale from no impact to high impact.
- Information Impact refers to the impact on the confidentiality, integrity, and availability of an organization’s information. Information impact is categorized as none, impact to privacy, impact to confidentiality, or impact to integrity.
- Recoverability Impact refers to the amount of time and resources required to recover from an incident. Recoverability is categorized as regular, supplemented, extended, and not recoverable.
This is only a recommended method of prioritization; incident prioritization should be customized to an organization’s needs.
Containment, Eradication, and Recovery
Once an incident is scoped, the next steps are to contain the actor within the network, evict the actor from the network, then recover the network to normal operations.
This phase requires actions against the network and will alert adversaries that they have been discovered. Once bad actors know they have been detected, they will change TTPs and make eradication even more difficult. For this reason, it is important that the IR team has a solid understanding of the scope of the compromise, has coordinated and synchronized before entering this phase.
Be sure to closely monitor a network after completing an actor eradication. It is common for actors to “survive” eradication attempts. While this is not the ideal, it is an accepted part of the incident response process and accounted for by NIST. In this case, the flow of the response loops back to the “Detection and Analysis” phase, as indicated in the NIST graphic above.
Containment is simply limiting the spread of the malicious actor. For example, if a user downloaded and executed malware and scoping determined the malware did not spread beyond the single machine, containment would only entail removing this machine from the network. As incidents grow larger, they require stronger and larger containment strategies such as isolating servers, disabling functionality on a network, or even disconnecting a network.
Eradication is about getting the actor out of the network by deleting actor accounts, tooling, and persistence mechanisms alongside removing known compromised infrastructure from the network. Patching and network hardening are almost always included in eradication, as these techniques limit the opportunity for the actor to reinfect the network after eviction.
Recovery is about bringing the network back to its pre-incident functionality. This stage may involve restoring systems from backups, rebuilding systems, patching, password resets, and additional network hardening such as tightening firewall rules and ACLs or implementing additional sub-nets.
The three major components to post-incident operations are:
- Meeting to discuss how the organization can improve based on the incident experience.
- Generating a comprehensive report on the incident
- Analyzing and sharing threat intelligence with the computer security community
1. Lessons Learned
Hold a non-confrontational meeting to discuss how the organization can do better next time. This meeting must not devolve into a meeting about ascribing blame. Some examples of questions that may be discussed include:
- How might a similar incident be prevented or detected in the future?
- What tools or resources were needed, but unavailable?
- How could communication be improved?
- What parts of the IRP worked well?
A comprehensive report brings everybody to the same page after an incident has concluded. It is also a valuable reference document for future incidents. A report should include, at a minimum, a chronology of events including not only actions taken by the adversary, but the actions taken by the network defenders.
3. Sharing Threat Intelligence
After an incident, an organization can help the information security community by sharing actor TTPs. The same threats often impact multiple organizations, and by sharing this information and having an actionable threat intelligence plan, organizations can help one another prepare and address the threats.
NIST 800-61 R2 is only one of many cyber security incident response frameworks, but all IR frameworks encourage organizations to prepare ahead of time, detect the actor, analyze the evidence, contain and evict the actor, and then learn and prepare for the next incident.
Cyber security services from [redacted] include incident response and empower organizations by taking the guesswork out of effective planning. To learn more about the benefits of partnering with an experienced IR team, schedule a call with us today.
Lauren serves as the Director of Incident Response and Forensics at [redacted] where she’s frequently found on the front lines, leading incident response efforts on behalf of clients. Prior to joining [redacted], Lauren worked at Los Alamos National Laboratory where she specialized in malware analysis as a member and occasional leader of the incident response team. She enjoys teaching technical content and has experience teaching malware analysis to students ranging from private sector managers to US military and everything in between. She holds a BS and MS in Computer Criminology - Computer Science and a BA in International Affairs, all from Florida State University.