“When” Incident Response Plans

Over my years reviewing bank incident response plans (IRP) I’ve seen the gamut in approaches. On one end of the spectrum there is the Oracle approach; envision the plethora of possible incidents that could befall the institution and prescribe in great Excel detail the response to each incident. At the opposite end of the spectrum is the perfunctory exercise aimed at answering the question “Do you have an incident response plan”, without actually having a viable incident response plan. I suppose if you’re going to err on one side, more is better than nothing. However, both of these approaches miss the intent and ultimately the value of an incident response plan. In this article, I’ll breakdown the intent and layout of an effective incident response plan.

First, I’ll tackle intent or mindset. The words ‘If’ and ‘When’ dictate the place where the incident response plan ranks in a bank’s priority list. Stating that the bank will take the necessary steps ‘if’ an event occurs relegates the plan to the institution’s inner recesses where bureaucratic processes go to live. ‘If’ is a hypothetical mindset that alters the bank’s view or likelihood of the risk of an incident occurring. However, we’re are certainly aware via the internet and industry stories that cybersecurity incidents occur at a high rate and often at a significant cost to the institution. Instead of ‘if’, the bank should say ‘when’ an incident occurs the bank will act accordingly. ‘When’ dispels the notion of perpetual safety and positions the operations in a forward leaning cybersecurity posture. ‘When’ is imminent. ‘When’ calls for attention and proper focus from leadership. An incident response plan is not so much about specific, prescribed responses to a breach but rather an injection of measure, logic, resoluteness, and composed actions after the fact, as executed by a well prepared team. In this regard, a good IRP and well prepared team imparts an effective response to ANY cybersecurity incident eschewing the need for an overly detailed and specific plans.

Once the correct mindset is securely ensconced in the incident response plan the next pieces are the functional steps of the plan. Thankfully cybersecurity focused groups have assembled and published a lot of research on these steps. Here is a list of institutions with their own documentation. They vary in documentation detail, however they all capture the same essence of an IRP.

• NIST SP 800-61 (Computer Security Incident Handling Guide)
• The Cybersecurity and Infrastructure Security Agency (CISA)
• FFIEC Incident Response
• FBI Incident Response Plan

Of the incident response plans I reviewed I found that NIST SP 800-61 is the most comprehensive and a good guide for any institution looking to improve or revise their IRP.

I’ve synthesized the functional steps in this article, however you should review the documentation for a detailed breakdown of elements that define an effective IRP.

1. Preparation
   • This step encapsulates the cybersecurity risk management program; policies, plans, procedures, detective controls, compensating/mitigating controls, and the formation of the security incident response team or computer security incident response team (SIRT/CSIRT). Much of the work for the IRP should be in place long before an incident occurs.
   • The SIRT in many ways is a rapid response force. It should consist of members with the expertise in their respective fields with access and authority to act on the institution’s behalf.
   • Training is paramount for the SIRT to be of use. This is done through desktop exercises and other similar simulations that attempt to capture real-world cybersecurity events. Note; trainings should be scheduled randomly, purposely disregarding team members schedules and time off in order to identify and resolve the challenges with unavailable team members.
2. Identification
   • An cybersecurity event has to be identified/detected and evaluated for its impact on the institution. Most events don’t require the SIRT’s involvement, as they are often within the security officer’s purview and handled through the standard policies and procedures. However, some events will have a significant impact on the organization’s operations and those need to be evaluated and categorized as such based on the organizations self-defined threshold. It is the official or formal determination of such an event that triggers and authorizes action from the SIRT.
3. Containment
   • When possible do no harm. Attempt to save data from further destruction by arresting the destructive activity. The SIRT should have team members who can quickly assess the situation and recommend a course of action that is least destructive to data and systems that isolates the problem from the rest of the operation.
   • Preserve logs, accounts, and running processes if possible for future forensics and legal proceedings.
   • Analyze the impact on the institution’s operation and formulate a plan for business continuity or disaster recovery.
4. Eradication
   • Ensure that affected systems and data have been secured from alteration and available for further forensics and legal work.
   • Identify the attack vector(s) and apply the necessary security changes to address exploitable vulnerabilities.
   • Monitor network and system activity for ongoing attacks.
5. Recovery
   • Compromised systems should be deployed as new systems with known good software and data.
   • Monitor network and system activity for ongoing attacks.
6. Lessons Learned
   • Document what in the IRP worked and did not work.
   • Revise the IRP to address deficiencies in the plan.
   • Train on the changes to the plan.

This summary is not meant to address every possible scenario, but rather define the main objective of the IRP and to enumerate the six key steps needed to work through an incident. Please reference NIST SP 800-61 for more details.

Here is a good planning document for creating an IRP from Microsoft. If your organization has an IRP now is a good time to compare it against the reference documents, the ‘if’ and ‘when’ mindset, and the six steps for proper incident response. The most important take away in this article is knowing that no organization is immune from a cybersecurity attack, and the best defense is to believe that it’s imminent so that much of the response work will have been done by the time it arrives.

Please let me know if this article helped with your IRP or where it falls short.

Best of luck and feel free to suggest other topics you would like to me address.

Abel Sanchez (abel@staidworks.com) – BankSafeTech Contributor and Moderator