This is Part III, the final chapter in this three-part series on incident response planning as part of your overall information security plan. Part I discussed why an incident response plan is important and Part II details seven steps on how to prepare and organize before you start to write your plan.
Here in Part III, we’ll focus on the key elements and outline of a typical incident response plan.
1. Introduction. While it may seem like window dressing, having a thoughtful introduction that outlines the goals, scope, and guiding principles is important. Highlighting the purpose of the plan (e.g., a hospital’s plan should mitigate downtime of essential services and loss of sensitive patient data) will help act as a lodestar for the rest of the document. The introduction should also include any assumptions or limitations: particularly in the first few iterations of your plan, it’s important to document what your plan intends to do – and what it currently cannot.
2. Incident Identification and First Response. Appropriate agreement on how to recognize and determine whether to activate the plan is important. Who has the authority to invoke the plan? Where/how does the incident response team meet and communicate? Particularly in the COVID-19 era when personnel may not be “just down the hall”, it’s essential to think through these logistics in advance.
3. Resources. Incident responders will often have “go kits” ready in the event of an incident. Spare cables, chargers, contact cards, notepads, etc. should be at hand at an office, remote office, or at hosting facility. Requirements for these “go kits” and schedules for review and replacement can be appear in this section.
4. Roles and Responsibilities. Crises are never scheduled at a convenient time. Personnel may be away; a deadline may be looming. It’s essential to define the roles and responsibilities of the members of the incident response team, along with backup or secondary contacts in the event someone is unavailable. Time will be of the essence in the event of a cyber incident, so everyone needs to know what they’re supposed to do. These activities run the gamut from client communications, support notification, and hands-on technical triage.
5. Detection and Analysis. Clearly, this is one of the key sections of the plan. Here will be your documentation regarding how an incident is defined and detected, through to the procedures for reporting, investigating, and containing the threat. Often this section will be scenario-based, as your recognition and response may depend greatly on the type and scope of an attack. Use templates, web examples, brainstorm/whiteboard response activities, or seek professional assistance from cybersecurity partner who has lived through the situations and can provide real-life insights. These ideas will help generate the playbooks that will form the essence of this section of your plan.
6. Containment, Eradication and Recovery. This portion of the plan will be the most technical of the document. The containment section will outline the strategies for limiting the scope of the incident. For example, an external ransomware attack will be handled quite differently from a rogue employee abusing admin privileges. Procedures for containing and isolating an attack may include taking affected systems offline to prevent the spread, or even isolating unaffected systems to prevent further spread of ransomware.
This section also outlines the procedures for eradicating the threat through to the recovery of all affected systems. Recovery steps should be prioritized (essential customer-facing services often take priority over internal systems, but relationships and system dependencies need to be considered). Particularly in the case of ransomware, recovery by restoring to backup or snapshot may be the answer in eradicating an infection. In other cases, malware extraction tools and defensive applications can be employed to tweeze out the problem areas. Configuration changes may be required to devices to patch or block vulnerabilities. Whatever the approach, recovery time and recovery point objectives should be addressed here. Tolerance for downtime and data loss is a critical factor in crafting your response, bringing you all the way back to your original analysis of risk acceptance. Can your operation tolerate a loss of a minute of data? An hour? A day? Your answers will have shaped your response and recovery efforts and strategies.
Note that cyber forensics considerations are also outlined in this section; inelegant approaches to removing the malware may destroy important evidence. Furthermore, incomplete or improper threat removal may cause malfunctions to systems, or leave backdoor opportunities for attackers to return. Taking system state snapshots, and protecting logs and time stamps to the extent possible could be very valuable in tracing the origin of an attack. Even details like how long you retain the incident logs (e.g., for litigation or regulatory compliance) should be embedded here.
7. Incident Communications. Woven into the two “heavy lifting” sections above will be the details on handling incident communications and management. Notification procedures are detailed, covering the involvement of internal personnel, trusted cybersecurity consultants, third party providers (including managed service providers), law enforcement, communications, regulators (industry and privacy), and breach coaches in the form of legal and/or trusted cybersecurity incident forensics specialists. Effective incident response requires a co-ordinated team effort, so the moving parts must be identified and documented in advance to help ensure nothing goes amiss.
8. Retrospective. Once the incident is resolved, a two-pronged retrospective process must be followed. First, it is essential to determine how the breach occurred, how to prevent similar incidents in the future, and prepare a plan to address the necessary changes. A second reflection needs to take place on the execution of the plan per se. A serious breach may be handled very well by your plan, or a minor breach could be exacerbated by poor plan execution. Recognition should be given to team members who went above and beyond, while other more drastic action may be appropriate where partners failed to perform as expected or contracted. It’s vital to learn and evolve from any security incident.
9. Appendices. Depending on the scope and size of your plan, you may choose to include reference materials as appendices to the incident response plan, or have them separately documented. Whatever works for you is fine, as long as you are confident you have access to the following key resources. Many organizations still resort to maintaining a paper copy of the plan and resources, in the event that systems are unavailable (e.g., due to ransomware attack or compromise of power systems)
+ physical and logical network infrastructure diagrams
+ web and cloud service connections
+ virtualization documentation
+ backup and snapshot schedules – these could be vital, especially in recovering from a ransomware attack
+ documentation of security solutions at sensitive points (e.g., firewalls, IDS/IPS, etc.) that may provide resistance to attack, logs of incidents, etc.
+ call tree or contact listing including phone and email details for staff, vendors, and essential partners – many organizations look to third party notification systems to offer a quick and resilient method of contacting larger groups all at once
+ tracking templates – contemporaneous note-taking may be the first thing to get thrown overboard in a crisis, but is an important element in assisting cyber forensics, expense tracking, insurance claims, after-action reporting and plan revision, etc. Use these forms to capture events as they happen
+ risk, severity, and impact tables – some organizations will formally assign severity levels, revenue impacts, and corresponding response, containment, and recovery time targets for various systems. This help reinforce the notion of recovering the most business-critical systems first, and can be used as a benchmark for measuring the efficiency and effectiveness of the plan
Finally, additional essential elements of an incident response program must also include:
+ A formal update and revision schedule, and documentation of release dates and authorship
+ A schedule of promotional and operational training to heighten general awareness of your company’s plan
+ A formal, detailed testing schedule and routine of procedures targeted at the team members designated in the roles and responsibilities section. It is essential to conduct controlled periodic tests on your response plan to help give comfort that you’ve covered foreseeable issues, and to develop a “muscle memory” for staff so they have some level of preparedness in the event of an actual breach. (And if just being prepared isn’t compelling enough, note that many cyber insurance applications and IT control audits will probe the breadth and frequency of your response plans and tests.) Each test must include a retrospective to evaluate the success of the test and provide for revisions and updates to the plan based on lessons learned.
Helpful Resources
The National Institute of Security Technology (NIST) provides a wealth of resources for companies getting started on their own incident response plans, including a detailed Computer Security Incident Handling Guide. The document outlines the philosophy behind the key elements of your incident response plan, even to the extent of painting a series of scenarios for you to consider when crafting a plan that’s right for your company size, your industry, and the level of sensitivity of the data you hold.
The SANS Institute has a variety of incident handling forms that can be used as templates for sections of your plan and for tracking forms to use during an incident event (either live or test).
TechTarget has a complete plan template as part of its knowledgebase. The plan is presented as an editable PDF so you can use it to build a preliminary plan, or refer to it for inspiration in building a new document.
Finally, ISA Cybersecurity provides a host of incident response services, from assisting in the construction of your plan, to providing technical assistance in the event of a breach, right through to data forensics to identify what happened, who did it, and how to help strengthen defenses to prevent it from happening again. Contact us anytime to see how we can help.
We hope this series has been helpful in encouraging you to build an incident response plan, or reviewing your existing plan to make updates or refinements.