5 min read

How to Build and Test an Incident Response Plan (IRP)

How to Build and Test an Incident Response Plan (IRP)

Whether you're a small startup or a major financial institution, having a well-crafted incident response (IR) plan is crucial for effectively managing and mitigating the impact of a cyberattack.

In this blog, we’ll cover all the necessary components of a robust IR plan, along with key considerations that often get overlooked.

 

Which Incident Response Framework Should I Start With?

 

The good news is that there are plenty of resources offering detailed steps and components for building your IR plan, so you won't have to start from scratch. A key player to involve early in this project is your designated cyber insurance firm, as your policy will outline the required components for coverage.

When starting, it’s important to note that relying solely on a single IR template might not be ideal. Such templates are often too generic, leading to gaps in coverage or excessive measures for your organization.

Two popular IR frameworks that offer great detail and often get referenced include:

For this blog, we'll focus primarily on the NIST SP 800-61. While it’s currently undergoing its third revision, we’ll base our discussion on the original IR lifecycle found below:

 

 

Pre-IR Tasks & Considerations

 

Before creating an incident response (IR) plan, consider several key factors. First, assess your organization's size and the number of employees to determine the plan's complexity. Understand the type and sensitivity of the data you handle, as more sensitive data requires stricter measures. Additionally, consider common vulnerabilities in your industry. For example, the financial sector often relies on numerous vendors, necessitating a detailed and comprehensive vendor management program to document critical third parties. This might also involve employing external forensics teams, security experts, or managed services.

Additional topics to consider include

  • Clear definition of what constitutes an incident.
  • Agreement and prioritization of high-risk vulnerabilities - can be determined through Quantitative Risk Assessment (QRA)
  • A designated communication and notification channel
  • Establishing regularly scheduled review and update process for IR plan (emphasized in newest NIST revision)  
  • Implement regular employee training

Phase 1: Preparation and Prevention

 

Preparation is crucial to incident response, this step is primarily focused on setting up the right tools and resources, along with training your entire team. The goal is to prevent cyber events by conducting regular assessments and vulnerability scans. By having a clear picture of your network security, you can protect it more effectively. Your preparation phase should include regular risk and network security assessments, malware prevention, antivirus scanning, and security awareness training. These steps will all help keep your organization safe and prepared for any cyber threats

NIST lists two parts to this initial phase, one is preparation, and the second is prevention. Methodologies for preparation focus heavily on ensuring your system, networks, and making sure applications are secure, while prevention focuses on securing the IT environment and monitoring your systems and network continuously to detect any anomalies. 

Steps to tackle in this phase include:

  • Collect contact information for all incident handlers
  • Establish incident reporting mechanisms to support anonymous reporting
  • Equip digital forensic workstations to preserve incident data
  • Assemble the necessary hardware and software for technical analysis
  • Conduct periodic risk assessments to identify and mitigate threats and assess the effectiveness of the Incident Response (IR) capabilities.
  • Train and educate everyone on recognizing unusual behavior and the specific steps for reporting suspected breaches.
  • Deploy comprehensive malware protection across all levels of your organization’s IT infrastructure.
  • Consider building “Playbooks” for high probable events such as BEC, ransomware, etc

Phase 2: Detection & Analysis

 

In the detection and analysis stage, the first step is identifying the nature of the threat and determining if it constitutes an incident. NIST categorizes signs of incidents into two types: precursors, indicating a potential future incident, and indicators, suggesting a current or past incident. We prefer to break this down into three parts: event, incident, and breach. An event is a suspicious activity found in a log that warrants investigation, an incident involves known malware, and a breach means data has been exfiltrated from your environment.

Once incidents are identified, the analysis phase involves documenting and prioritizing them effectively. Documentation in a ticketing system is essential for maintaining security and compliance standards. Effectively prioritizing incidents is one of the most crucial decisions in the incident response process. It's important not to handle incidents solely based on their order of occurrence due to resource constraints. According to NIST, factors to consider for incident prioritization include: 

  • Functional Impact: IT incidents can disrupt business operations, affecting users and system functionality. Consider both immediate and future impacts on affected systems.
  • Information Impact: Incidents may compromise data confidentiality, integrity, or availability. Assess how this could impact the organization's mission and relationships with partners.
  • Recoverability: The scale and resource requirements for recovery vary. Evaluate whether recovery efforts align with the incident's impact and organizational priorities. Some incidents may not warrant extensive resources if recovery isn't feasible or valuable for future prevention.

Finally, the last step in this phase is promptly reporting incidents internally and to relevant agencies, law enforcement, or affected parties to facilitate timely response and resolution.

 

Phase 3: Containment Eradication & Recovery

 

The primary objective of this phase is to isolate the cyber incident, removing the cyber threat, and return systems to their pre-compromised state. To prevent further harm, conduct forensic operations immediately after containment. Response teams will then remove the cyber threat and isolate infected systems during containment. This effort continues until eradication is complete. Begin the recovery process by restoring clean backups, but remember to address any vulnerabilities exploited in the original attack with security patches and remediation efforts.

***Remember! Before reconnecting systems to the internet, monitor for abnormal log activity indicating persistent malware

Although not recommended, During this phase you can divert some of your attention and efforts to identifying attackers. Common methods include:

  • Validating IP Addresses: Verifying an IP address can be misleading due to spoofing or dynamic reassignment.
  • Online Research: Searching the IP address can provide additional attack information.
  • Incident Databases: Use incident databases and internal knowledge bases to find related activity.
  • Monitoring Communication Channels: Observe channels like IRC for potential leads, but treat this information cautiously

Phase 4: Post-Incident Recovery

 

Learning and improving are crucial yet often overlooked aspects of incident response. Teams must adapt to new threats, technology, and insights to stay effective. Holding a "lessons learned" meeting after major incidents, and occasionally for smaller ones, can greatly enhance security and response efforts. These meetings, ideally held within a few days of an incident, offer a chance to review what happened, evaluate the actions taken, and assess their effectiveness. They also provide a valuable opportunity for team reflection and growth. Consider asking the following questions during your review phase:

  • How well did staff and management handle the incident?
  • Were the documented procedures followed and adequate?
  • What information should have been shared earlier?
  • Were any actions taken that slowed recovery?
  • What changes would staff and management make for a similar incident?
  • How can information sharing with other organizations be improved?
  • What corrective actions can prevent future incidents?
  • What warning signs should be monitored for early detection?
  • What additional tools or resources are needed for future incidents?

Best Way To Test IRP According to NIST SP 800-84

 

Testing is crucial for the success of your incident response plan. According to NIST SP 800-84, two effective methods are Tabletop Exercises and Functional Exercises.

Tabletop Exercise:

A tabletop exercise is a great way to test your incident response plan. It's a discussion-based session where the team explores their roles and responses during a security incident through example scenarios. The main goals are to:

  • Increase security awareness
  • Discuss appropriate incident responses
  • Identify gaps and issues in the Incident Response Plan

In these exercises, a facilitator presents a scenario and asks questions to initiate discussion about roles, responsibilities, coordination, and decision-making. Tabletop exercises are particularly useful if you already have a response plan in place for the scenario being tested. They help ensure your plans are effective and comprehensive.

Functional Exercise:

A functional exercise tests your team's readiness by having them perform their duties in a simulated environment. Unlike tabletop exercises, functional exercises involve real-time actions, testing how your team would handle a major incident and the specific roles, procedures, and resources involved.

These exercises can range from simple validations of certain plan elements to comprehensive tests of the entire plan. They help ensure everyone knows their responsibilities and can effectively respond during an actual emergency.

 

How Rivial Can Help

 

Rivial’s incident response software offers a robust foundation for creating a comprehensive and actionable incident response plan. With the Rivial Platform, you can either leverage our pre-built IR plans or customize them to your organization's size and scope through the guidance of our experienced IT staff. Additionally, our Platform enables you to test the plan thoroughly, allowing you to track real incidents efficiently, all within a single, integrated solution. This holistic approach simplifies the incident process and enhances your organization's preparedness and response capabilities. Schedule a call to learn more!

 

Schedule A Demo

 

Incident Response Playbook: Business Email Compromise (BEC)

Incident Response Playbook: Business Email Compromise (BEC)

Flying under the radar for years, BEC attacks have been slowly climbing the ranks as one of the most popular tactics amongst cybercriminals to...

Read More
Incident Response Playbook: Ransomware

Incident Response Playbook: Ransomware

Considered one of the most detrimental threats to businesses, government entities, and individuals, ransomware attacks have escalated significantly...

Read More
INCIDENT REPORTING: NCUA'S 72-HOUR RULE

INCIDENT REPORTING: NCUA'S 72-HOUR RULE

National Credit Union Administration's (NCUA) recent policy on reporting Cyber Incidents went into effect September 1, 2023, and now requires all...

Read More