What to Include in Your Incident Response Plan

Cybersecurity data breaches have almost become a way of life. We hear about businesses impacted by security incidents and data breaches every day.  As the adage goes, it’s not “IF”, but rather “WHEN” a security incident will take place at your business. 

It is therefore a best practice for every business to create an incident response plan. An incident response plan delivers two cybersecurity benefits to your business:

1. Systematic response to incidents which helps to minimize information loss or theft and service disruption.
2. Use of the information gained from an incident to help prevent future threats by strengthening system protections and to be better prepared for handling future incidents.

A breach of your information is always stressful. Don’t compound that stress by not having a plan to address a successful cyberattack. 

Before creating an incident response plan, you must create an incident response policy.

Create an Incident Response Policy

The National Institute of Standards and Technology (NIST) recommends in its Computer Security Incident Handling Guide that an organization should create a policy before building an incident response program.

This policy:

• Defines which events will be considered incidents
• Establishes the structure for incident response
• Defines roles and responsibilities
• Lists the requirements for reporting incidents

Develop your policy to include all applicable regulations and laws under which your business operates. Compliance requirements such as those associated with HIPAA and HITECH, Gramm-Leach-Bliley Act, and Sarbanes-Oxley (SOX) will drive your policy requirements. 

The 4 Phases of the NIST Incident Response Lifecycle

Once the policy has been created, NIST outlines four broad phases an incident response plan should include.

NIST identifies four phases in an incident response lifecycle:

1. Preparation
2. Detection and Analysis
3. Containment, Eradication, and Recovery
4. Post-Event Activity

Each of the four phases includes a number of actions. Here’s an outline of what you can include in your organization’s incident response plan.

Preparation and Prevention

“Prevention” in the context of incident response is essentially your information security strategy and the software tools used to implement your strategy. It is your layered defense against cybercriminals -- firewalls, encryption, antivirus software, data backup, user training, etc. 

Part of being prepared is having a complete list of your information security tools (including any portions of your IT infrastructure managed by a third-party managed service provider). 

Effective response is based on communication. Smartphones are an excellent way to communicate with and coordinate team members while responding to an incident. It may be a good idea to have some of the information below as hard copy or on devices not connected to an organization’s network (it will be difficult to coordinate a response if, for example, you are victimized by a ransomware attack and cannot access your plan):

• Contact information for primary and backup contacts within your organization plus relevant law enforcement and regulatory agencies that may need to be alerted
• An incident reporting mechanism so users can report suspected incidents (phone numbers, email, online forms, or secure messaging systems)
• Issue tracking system
• Space to respond. Identify a permanent “war room” or temporary location where team members can centralize their response to the incident
• Secure storage facility to keep evidence if needed

Detection and Analysis

Attacks can come from anywhere and take many forms - a denial of service attack, ransomware, email phishing, lost or stolen equipment (such as a laptop, smartphone, or authentication token), etc.

Once an incident is positively identified, follow defined processes to document the response (which can be helpful in showing a good faith effort to limit the impact of the breach on customer data should you end up in litigation or are investigated as the result of a breach).

Identify your affected networks, systems, and/or applications and determine the scope of the incident. From there, the response team can prioritize next steps from containment to further analysis of the incident. Recommendations for making analysis more effective include:

• Profile networks and systems so changes are more readily detectable
• Understand normal behavior so abnormal behavior is more easily spotted
• Create a log retention policy
• Perform event correlation
• Keep all host clocks synchronized
• Filter data to investigate the most suspicious data first
• Run packet sniffers to collect additional data

These techniques should be used in conjunction with one another. Relying on a single method will be ineffective.

Document incidents as they are found. A logbook is one way to do so as are laptops, audio recordings, or a digital camera. 

Those affected by the incident need to be notified as well. For an incident that affects customers, a message on your website, email notification, or other communication will be needed.  Often, breach notification procedures are driven by laws applicable to your industry, your state or your country, or a combination of these.

Containment, Eradication, and Recovery

Develop containment strategies for different incident types as containment for malware entering your network from an email will be different than for a network-based denial-of-service attack.

Document your strategies for incident containment so you can decide the appropriate strategy for the incident (e.g., shut down a system, disconnect it from the network, disable certain functions).

Once an incident is contained and all affected elements of the IT infrastructure have been identified the eradication and recovery process begins. For larger systems, this could take months to move from high-priority to lower priority systems. Systems may be able to be restored from backup or may need to be rebuilt from scratch. As eradication and recovery proceed, steps can also be taken to tighten security measures. 

Post-Event Activity

Information security is an ongoing, iterative process. A key part of any incident response should be to learn from it:

• Were the procedures followed? Were they effective?
• Did we do anything that slowed the recovery process?
• What could we have done differently?
• Are there steps we can take to prevent a similar attack?
• Were there indicators of the attack that we can use to prevent/detect a similar incident?
• Do we need more resources to detect, analyze, and mitigate future events?

Apply what you learn to improve your cybersecurity defenses and response to the next incident.

Testing, Testing

Test your plan once per year. EIther working with an independent third-party or internally, create a scenario and walk your team through it. This not only allows team members to understand their roles, but will also help you identify gaps or weaknesses in your plan. 

Do You Have an Incident Response Plan?

Research from IBM and the Ponemon Institute reveals that if you do have a plan, you are ahead of the crowd as 77% of organizations reported not having a formal cybersecurity incident response plan.

The cost of a data breach continues to rise (in 2018 the cost of a data breach was $3.86 million; in 2019 the total cost rose to $3.92 million).

Be different from the crowd. Develop and follow an incident response plan.