Leave nothing uncovered. Leave nothing to chance.

Creating an Incident Response Plan

Creating and maintaining an incident response plan is an unfortunate circumstance of managing any IT department. It’s difficult to overstate the potential complexity of any given incident, so one must craft an incident response plan that can be applied to any number of given scenarios. So when drafting a plan, keep in mind that you don’t have to account for every single potential breach, but you do need to have steps in place that can be applied to different scenarios. Computer security events need to be handled in a rapid and efficient manner, so that the potential window for an attacker is closed as quickly as possible.

It’s important to remember that one reason you are creating an incident response plan is to mitigate risks which cannot be accounted for otherwise. This does not mean that other forms of attack prevention or auditing should be devalued or replaced. Instead, these existing practices should be leveraged to help you craft a custom response plan best tailored to suit your needs. Responding to an incident is almost always more costly than preventing one.

One often-overlooked, yet crucial part of an incident response plan is incident detection. Without proper detection, the rest of a plan is less valuable, as it may never be implemented, or will cost money to implement in the case of a false breach notification.

Another important aspect of an incident response plan include choosing a team and empowering them to make decisions.  The type of personnel you want on an IR team include technical personnel and those who can think on their feet – much has been written elsewhere about hiring hacker-types for their ability to think quickly and find and implement the best technical solutions to problems.

Communication is also important during an incident – team members should have a good understanding of what others may or may not be doing, as this helps prevent unexpected consequences.  For example, if one team member is tasked with analyzing a piece of malware on the network in order to determine what data it may be sending out, another team member should not be tasked with wiping all malware from the network.

After any sort of implementation of an incident response plan, an after-action review should be performed.  This way, team members can assess what went well and what went poorly, so that future incidents may be handled more efficiently.  While this type of after-action review usually happens informally among team members, it’s important to use this information to alter the incident response plan, so sometimes a more formal meeting may be required to document changes to the plan.

Last, consider testing your plan under a variety of circumstances.  Make sure that a copy of the plan is accessible to team members even if a piece of critical infrastructure is down, such as the company’s intranet.