Writing your Incident Response Plan

Define, analyze, identify and prepare

For some organizations, an incident is an attempt, whereas for others an attacker needs to be successful for the incident to qualify as such.

Next, analyzing and determining which of your system components, services, and applications are most crucial to maintaining the operations of the business. These items will be prioritized if a security incident, as you have defined it, should occur. Additionally, identify what critical data needs to be protected, where it is stored, and how valuable it is both to you and your attacker. This is essential as you are writing a response plan, so you are better positioned to recover data more quickly.

Know where there may be weak points in your systems and address anything with the potential failure. Doing this pre-emptively will protect and maintain those systems while also qualifying necessary resources like building a response team and budgeting for tools and equipment.

Establishing a timeframe in advanced

Your response team will build the framework that outlines their roles as well as how they will detect, respond, mitigate damage, resolve an incident they’re addressing. It is important to establish a time frame in advance, so the response team knows what expectations they are working against when an occurrence arises.

It may be a good idea to write guidelines into your response plan that outline required actions, the subsequent steps and associated times necessary to react quickly. Clearly document what steps will be taken to repair the damage and have your systems fully operational again.

Write up a strategy, get familiar

Write up your strategy. Once you’re satisfied that the plan covers the investigation, analysis, and rehabilitation of your services following the incident, you need to publish your plan internally.

It is a good idea to operate with enough caution that you can build in a disaster recovery backup and storage solution when writing the CSIRP. This improves your chances of surviving a breach by conducting frequent backups and recovery processes to mitigate a loss of data and potential future damage.

Planning for disaster recovery as you write your incident response plan can safeguard your organization with a quick and more ideal recovery point, while giving the response team allowance to troubleshoot what happened and put additional preventative measures in place.

Identify what works and what doesn’t

Testing is critical because it is going to help identify which parts of the plan will work, and where you have gaps and will need to re-work and further optimize the plan in case of an actual attack or breach.

Have the response team go through a virtual scenario wherein they notify the proper departments such as marketing communications, executive leadership, security, or the legal team that an attack has occurred. As the scenario plays out, the incident response manager should regularly report on how notifications are proceeding to those affected. Here is also where you may determine how you will communicate to customers, patients, or partners, and in some cases law enforcement. In case of an actual breach, keep in mind that if you are, or work for a Department of Defense (DoD) contractor, notifying authorities is a legal requirement.

Handling the aftermath

Set the expectation early that your plan will include debriefing. Should a real security incident occur, debriefing should focus on handling the aftermath and identifying what went well and what areas could use improvement. You will want to identify your process for completing incident reports, and analyzing your team’s skill set for potential gaps, as well as any other post-incident action items that should be addressed.

The best-case scenario is that you never experience a security incident, however, it is imperative that you plan for one. Having a CSIRP written and implemented means that your organization is well prepared to handle it should you be faced with an event.