Incident response

How to Develop an Incident Response Plan in 9 Simple Steps

Introduction

Developing an incident response (IR) plan is not an easy task that can be accomplished in a day. It is a process that requires thought and several layers of development. That does not mean that you have to overcomplicate the entire plan when you are developing it, however.

You must create a plan that will protect your organization from hackers, malware infections and system failures. All of these hazards have the potential to leave your company dead in the water if you don’t have the necessary tools, staff and IR plan in place to help get your systems back online.

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

Now that we know what we are trying to accomplish with such a procedure, let us take a look at how you too can develop an IR plan in nine simple steps.

Step 1: Analyze Your Company’s Operating Environment

The first thing you must do is look at your company and its IT infrastructure and find out what the most critical components of that system are. Understand what is running within your company’s environment and you will be able to properly plan for an incident. You must learn what functions are performed and by what, from the different networking layers and site links, right down to the individual components of your network.

Understand what is in place within the organization, and you can begin with making contingency plans in the event of any system failures. It also helps find out which components on the network could lead to a loss of revenue for the company in the event of a system failure, and to make sure that these systems are protected and backed up.

Step 2: Identify Potential Business Issues

Be realistic about what the potential weak points are within your system, and treat this as a risk management task. Any component that has the potential for failure needs to be bolstered and shored up so it is no longer vulnerable. By performing this analysis early on, you will be able to allocate the necessary resources, both staff and equipment, to ensure these systems are suitably maintained and protected.

Again, it is a good idea to speak with the heads of each of your departments to find out from them what their concerns are in the event of a system failure, and also what their most critical services and applications are for the company and its clients. This way you can learn more about how each department operates, and what the business-critical services are that each one needs to run effectively.

Step 3: Build a Solid Team

The next thing you need to do is assemble a group of specialists within your company, or outsource to a provider. Clearly define each role when responding to an incident, and what steps need to be taken during different scenarios. You will need a computer emergency response team (CERT) that can be deployed to any area where your company operates.

You may not need to hire them individually either, especially if there are specialized roles that you simply do not require on a permanent basis. It is for these reasons that it is an especially good idea to develop strong relationships with your service providers and vendors, implementing service-level agreements (SLAs) with emergency response times built into them.

For incident responders that are based within your company, incentives (managed via KPIs) are an effective way to manage your overall uptime and company-wide IT performance. A systems administrator that is rewarded for keeping systems up and running will put in the extra effort to keep things running smoothly.

Step 4: Develop KPIs & SLAs

Create a severity chart for your incident responders similar to the example below:

SEVERITY LEVEL LEVEL OF BUSINESS IMPACT RESOLUTION EFFORT REQUIRED

SEVERITY 1 LOW LOW EFFORT

SEVERITY 2 MODERATE MODERATE EFFORT

SEVERITY 3 HIGH EXTENSIVE, ONGOING EFFORT

SEVERITY 4 SEVERE DISASTER RECOVERY INVOKED

Credit Jese Valentin, original article here.

Whoever is on duty or is on standby must be ready to respond in a timely manner as soon as a threat becomes apparent. Your team will need to detect, respond, mitigate damage, report, recover and debrief within a set time frame for each level of severity.

Step 5: Create Quick Response Guides

Design and create quick response guides that address specific systems and scenarios for those systems. Use clear descriptions and illustrations if necessary, and lay out your responses in a logical format. If a specific system is attacked, it is critical that the symptoms of such an event are understood. System degradation, error messages, log files and system events can all point towards a failure, error or attack, and must be laid out within the guide for your team to act quickly.

That means that your quick response guide should include the most likely scenarios, how to check them and what steps need to be taken to correct the damage and to restore your systems back to full operation. You must make sure that they are readily available for your team, so having them printed out and kept as a physical print out is a good idea, in case of a complete network or system failure.

Step 6: Simulate & Perform Test Runs, Then Adapt

Train your staff to deal with any and all of the most common scenarios that are likely to affect your organization. This can be difficult, especially if you lack the required resources within your organization. It is a good idea to reach out to specialist companies that offer incident response and disaster recovery system design, implementation and integration into your organization if you do not have the required talent pool.

It is important to make sure your incident response team takes this exercise seriously, and does not treat it as something trivial like a fire drill. It is your job to keep your teams motivated and conscious of the importance of their role. Introducing a competitive feel where teams try to outperform one another can certainly help elevate the teams’ interest in simulations.

Once you are aware of what needs to be safeguarded, you can create a test or lab environment, completely separate from the rest of your production network. Then, when you have a realistic analog of your system, you can start trying to replicate issues you are noticing on your live system. You can also act preemptively by simulating attacks and infections on clones of your key servers.

This creates the opportunity for you to adapt your plan and change old methods in favor of newer, more effective ones. This will help your team stay current with the most likely potential challenges that are out there, allowing you to keep up with ever evolving threats from cybercriminals.

Step 7: Integrate Disaster Recovery Steps

Include disaster recovery into your plan. Part of your incident response plan should definitely focus on disaster recovery protocols. While it is not always the case that an incident will lead to a disaster recovery scenario, it is certainly a good idea to have the systems in place if they are needed.

Make sure that your virtual environment is backed up and that your host redundancy has been addressed. Crucial servers must be catered for if there is a hardware error, so backup hosts are essential. Make sure that you have a process tree at hand so your team can follow the procedures correctly, without unnecessarily instituting disaster recovery measures.

Step 8: Involve Relevant Departments

Not everybody in your incident response team needs to be an IT specialist. If your organization has a biometric and surveillance system that goes offline and is critical for access control and safety, then your security manager must be involved in an incident response scenario. In this example, they would have to ensure all staff are able to access areas on the premises without any issues.

If there is a need to restore financial backups for a specific system and there are parts of records missing that need manual capturing, then the financial manager should be involved to give your team the go ahead before undertaking any restorative action.

There are many more key players within the organization than just the IT department, so be sure to involve managers from all departments where mission-critical systems are most likely to affect operations in the event of downtime.

Step 9: Establish an Incident Debriefing Process

You must debrief your team so that anything that is to be learned after a breach or system attack can be properly ventilated. Your team must explain what their challenges and successes were during this time, when they were alerted to problems and how they were able to deal with the situation.

Remember that evidence collection by a computer forensics expert will be required if there are legal ramifications, so having suitably qualified staff or providers on hand is a requirement. Depending on your industry, you will have to report such incidents to the authorities and/or the public.

In the event that your IR plan failed or was not executed correctly, there needs to be a review and possible refinement of the guide so that in the future, these issues do not resurface. Be sure to highlight what went right as well as what went wrong, and help guide your team towards a better understanding of what exactly needs to happen in the future if such incidents reoccur.

Conclusion

These are nine potential steps to assist you with building and incident response plan, which will help your company to recover from incidents much more quickly. These are by no means the only measures that can be taken, but this is a good starting point. We hope that this will help you to formulate an incident response plan of your own. By becoming a certified CISSP, you will learn how to build your own IR plan and assemble a competent CERT to tackle the difficult situations within your company.

 

Learn Incident Response

Get hands-on experience with incident response tools and techniques as you progress through nine courses.

Get Started

Sources

Building an Incident Response Team and IR Process, InfoSec Institute