Image source

Companies of every size are attacked by cybercriminals everyday. Too many of these attacks end in a successful breach. In the first six months of 2019 alone, it’s estimated that 4.1 billion records were exposed. These breaches can have serious impacts on an organization; from regulatory fines to loss of customer trust and revenue. 

It’s near impossible to perfectly secure your systems. However, you can take steps to ensure that you’re prepared for if and when a breach occurs to you. Part of this preparation includes the creation of an Incident Response Plan (IRP).

What Is an Incident Response Plan (IRP)?

An IRP is a plan for identifying, responding to, and recovering from security incidents. It is meant to minimize or prevent damages caused by service outages, data loss, or system breaches.

A Computer Security Incident Response Team (CSIRT) carries out an IRP. This team is responsible for managing incidents as well as communicating with internal stakeholders and outside parties. External parties might include legal counsel, press, law enforcement, or customers.

Although they are often confused, an IRP is different than a Disaster Recovery Plan (DRP). A DRP is related to how an organization manages events like natural disasters or accidental data loss. A DRP’s focus is on meeting Recovery Time Objectives (RTOs) for returning to production. It involves less focus on investigation of events or corrective action.

What Steps Should an IRP Include?

Every effective IRP should take outline the steps below.

1.  Preparation

The first step of any IRP includes a review of existing security policies and tools. You need to incorporate this information into the following steps. You should also do a risk assessment to determine what vulnerabilities might remain, how likely they are to be exploited, and how easily they can be detected. 

Once you have the results of your risk assessment, you can use the information gained to prioritize both your data and your vulnerabilities. Prioritization can help you effectively allocate limited resources by placing focus on critical systems and risks. It can help you determine which steps you need to take when an incident occurs and, as a result, minimize the damage.

In the preparation step, you need to create a CSIRT team. Your team should then create documentation that includes communication plans, roles and responsibilities, and processes to be followed. Training of your team and anyone else who may be involved in incident response, such as employees, should occur.

2. Identification

For your identification step, you need to put into place tools and policies for the effective identification of security incidents. Make sure to include security monitoring tools, such as Security Information and Event Management (SIEM) solutions, and guidelines for detection, such as known Indicators of Compromise (IOCs).

When you discover an incident, your team needs to begin collecting evidence, determining incident priority, and documenting any actions taken. Documentation should be clear and comprehensive for later analysis. Both documentation and evidence need to be maintained through a clear chain of custody. A documented custody chain is often required during legal proceedings or regulatory compliance audits.

At this stage, your team needs to determine the appropriate time to contact stakeholders and relevant outside parties. Alerting stakeholders too soon can cause panic or lack of confidence due to incomplete information. Too late can make it appear as though your response is inadequate or that you are trying to hide an incident. Setting up clear procedures for alerts can help you keep everyone appraised in due time.

3. Containment

Once you determine an incident has occurred, you need to contain the incident and work to keep damage to a minimum. Your plan should include procedures for both short and long term containment. 

Short term containment focuses on isolating affected parts of your network or disabling infected devices. Long term containment focuses on temporarily patching systems for use while affected systems or devices are being replaced with clean versions. 

Using first short term and then long term strategies enables you to stop an incident from progressing and begin preparing systems for a return to production. 

4. Eradication

After you contain the incident, your team can focus on determining the cause of the incident. Their focus should include what actors were involved, which vulnerabilities were exploited, and why an attack occurred. During this step, you should evaluate all potentially affected systems. 

Any existing infections should be removed and any remaining attackers eliminated from your system. You must patch all exploited vulnerabilities, as well as any new vulnerabilities your team may have discovered. You should apply patches to the clean copies of machine images and server configurations that you prepared in the previous step. 

The next step cannot be taken until you completely finish the eradication step. Recovering your systems and bringing them back into production before this step is complete is a mistake. Doing so will only provide attackers with another opportunity to infiltrate a weakened system.

5. Recovery

Once you are ready for recovery, your team should begin bringing your now fully patched and protected systems and devices back into production. You must take care regarding what order and when to restore systems to avoid recurrence. For example, you should restore security measures and access permissions before databases. 

As you reactivate systems and devices, you should test them to ensure they are no longer vulnerable. After restoration, you should monitor systems for an established period of time. Through monitoring, you can ensure that attackers really were eliminated and that no reinfection occurs.

6. Lessons Learned

You have one final step to complete after recovery—evaluating your incident response. During this step you should finish any incomplete documentation or communications. Your team should fully analyze all incident data. Your analysis can provide additional insights that were previously missed and help in building a legal case. 

When analyzing incident response events, include any actions your team took, team member feedback, and evidence of effectiveness. Your analysis can tell you what worked well in your plan, what information or processes may have been missing, and what mistakes were made. You and your team can then use this information to refine your IRP so that it is more effective and efficient in the future.

IRP Best Practices

Once you verify that your IRP includes the steps covered above, you can focus on further refining your plan. To do so, consider these best practices: 

Keep Your Plan Simple

Keeping your plan as simple and concrete as possible will make it easier to implement successfully. Create clearly defined procedures to eliminate confusion during incident response. Clear documentation can reduce the need for on-the-spot problem solving, which is likely to be inconsistent or incomplete.

Verify Your Plan

After your plan is created, but before you need to use it, practice the steps it outlines. You don’t want to find out that you forgot processes or included conflicting instructions during a real incident response. Instead, practice using your plan with incident drills. 

Drills can help you make sure that instructions are coherent and executable. Drills can also increase the confidence and speed of your team for when a real incident occurs. Make sure to revisit your plan anytime changes are made to your CSIRT team or system configurations. You should also revisit them any time tools or devices are added or removed.

Don’t Reinvent the Wheel

Using established templates and resources can simplify your planning. There are any free resources, such as this Carnegie Mellon University plan or this TechTarget’s IRP template. Incorporate any existing policies you may have whenever possible. If your policies are comprehensive and effective, there is no need to rewrite them. 

Conclusion

An IRP is key to successfully and efficiently responding to security incidents, but only if your plan is complete. Hoping that you won’t be affected or waiting until after you’re attacked to create a plan is dangerous. Both you and your stakeholders are at risk. Create a plan with the information covered here in mind.  If you do, you can ensure that you will be ready when an incident occurs. 

——————–

Author Bio

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

 LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/