Practical Guide for Beginners: Developing Your Initial Incident Response Policy

It only makes sense to assume that sooner or later your company will have to handle a security incident and the subsequent recovery from any damage caused.

Creating an incident response policy before an incident occurs can help you minimize risk and ensure that you and your team are prepared. By planning your response ahead of time, you will be able to respond faster and more efficiently, and possibly even prevent additional damage from occurring.

What Is Incident Response?

In the Information Security space, incident response refers to a set of processes and plans that are used to detect, contain, eradicate, and repair systems after a security incident occurs. Incidents refer to any loss of functionality or data and may be caused by malicious attacks. An article from Digital Guardian defines the five steps of incident response as:

1. Preparation
2. Detection and Reporting
3. Triage and Analysis
4. Containment and Neutralization
5. Post-Incident Activity

Your companies incident response policy must therefore cover and document each of these five areas.

Steps for Creating an Incident Response Policy

Having a structured policy is the key to an effective response. The following steps will help direct the creation of this policy and guide you on what aspects should be considered.

Evaluate Your Current Situation

The first step to creating any sort of incident response strategy requires an evaluation of what assets you need to protect, how those assets are vulnerable, what can be done to prevent an incident from occurring with them, and who your available resources are.

During this evaluation, you need to take inventory of all of your assets and assign them priority levels in terms of privacy, value, and any regulations that may apply. This will later be used to inform protocol actions if an incident occurs.

Evaluate what security measures you already have in place as well as who is responsible for them. You need to make sure that they are appropriate to the priority levels you determined and are being applied reliably. Don’t be surprised if you find gaps in your measures or practices. Part of incident response planning is taking proactive measures━you can use this information to ensure that your prevention efforts are effective and comprehensive.

Gather Your Team

During your evaluation phase, you should develop a good idea what skills and knowledge are required specific to your infrastructure and current security posture. You may already have staff in place with specialized skills that will be helpful in a response situation, or you may identify gaps that you’ll want to hire or outsource for. This is your Cybersecurity Incident Response Team (CIRT).

Your CIRT is responsible, not only for responding when an incident occurs, but for defining policies and procedures for an incident, and evaluating response actions after an incident is over. They are the ones who will initiate the incident response process, periodically audit strategies, and implement additional security measures to ensure effectiveness.

When establishing your team, it is vital that everyone understands their current roles and responsibilities, while being open to the possibility of their roles changing as plans progress. To help improve the efficiency of your team, as well as the overall process of securing your systems, you should consider adopting a DevSecOps approach.

Create Your Plan

Depending on your team and your evaluation, you might need to enact preventative measures before creating your Incident Response Plan (IRP), particularly if you are planning to drastically change policies or the tools you’re using. Taking preventative actions before plan creation will ensure that the protocols you create are accurate to the tools you’re using and can even help you eliminate the need to plan for incidents by eliminating the chance of them occurring.

During plan creation, you need to clearly define incident detection criteria based on the possible attack vectors and known vulnerabilities you uncovered in the evaluation step. These criteria should be applied as policy rules in any monitoring or detection tools you’re using.

You also need to create explicit incident priority determination guides━flow charts can be particularly useful here. These guides should help your team determine priority based on the functional, informational, and recoverability impacts of any incidents that occur.

As we mentioned above, all IRPs should include and define the following steps:

• Preparation━what security tools or policies are already in place and what is their purpose?
• Detection━how will current systems detect an incident, how will you know an incident has occurred, and who will be notified?
• Analysis━where are data logs located, who is responsible for analysis, and when is analysis sufficient to initiate action?
• Containment and eradication━how should threats be neutralized and damage be contained, and what priority does security have over productivity or service availability?
• Recovery━how to measure the damage done, what order to restore systems or data in, and if there are compliance steps to be taken.
• Post-incident handling━what metrics to measure response by and protocols for implementing future improvements.

Your plan needs to define actions and actors as explicitly and simply as possible so that when an incident occurs, responders aren’t slowed down by confusing documentation or unclear chains of command.

Once your plan is created, make sure it is widely available both on and offline. A digital copy won’t do you any good if you can’t access your servers or use your devices. You should also consider periodically running incident response drills. This can help verify that your plan is clear and makes sense, and will allow your team to practice their roles and responsibilities.

Conclusion

An incident response plan may be complicated to plan and implement, but it’s well worth the effort. The quality of your IRP will determine the resiliency of your organization, and its ability to restore customer confidence. The key to an effective incident response strategy is adopting a mindset of continuous improvement. Don’t just create a plan and forget about it—test it and build on it, responding to new threats as they emerge, and involving your security and development teams in the process.

Rather than risk hefty compliance fines or loss of valuable brand reputation, take a bit of time now and create an IRP. Using this guide in combination with existing frameworks, such as the one developed by the National Institute of Standards and Technology (NIST), will ensure that you can rest easy knowing an incident won’t catch you unaware.