Most companies have a cybersecurity plan of sorts in place already. When we speak, in general terms, about the first three key functions in the NIST Cybersecurity Framework, “Identify”, “Detect”, and “Protect”, we are met with understanding. After all, these categories make sense to all of us. Identifying those assets that need protection makes sense, protecting those identified assets is a logical next step. And finally, detection is something that has been done for years on end. Even though it may not be wholly sufficient, people understand the concept of endpoint protection, including antivirus and anti-malware software. After all, you want to keep the bad guys out, right? What better tools to use than those that offer to protect your network? The next step in your security program must be an incident response plan. Accepting that breach will occur, in some form, is the first step to developing an effective plan.
If you do not already have a plan, there are a few easy places that you can start. Your firm might consider adding to its Business Continuity and Disaster Recovery plans in order to properly consider cybersecurity threats and the required response should breach, similar to or as a form of disruption, occur. Regardless of if you determine that a stand-alone plan is necessary, or if it can be rolled into an existing rubric, it must be tested and updated. Similar to a Disaster Recovery plan that sits on the shelf and is only dusted off in the event of a disaster, an un-tested or out-of-date Incident Response plan is almost as bad as no plan at all.
With testing and updating understood, what are some important items for an incident response plan? According to the NIST Cybersecurity Framework, the first (and somewhat obvious) phase of incident response is to, in fact, execute the plan during or after an event. While this certainly seems elementary, there is an important reason for stating this requirement in the NIST Framework: In order for the plan to be implemented, the RIGHT PEOPLE must be involved. If your plan has been designed without an effective trigger mechanism, or clearly defined terms of declaration, or without the knowledge of the staff who are most likely to detect an incident, your plan will remain dormant. Make sure that the people who are responsible for monitoring your networks are doing so and that they understand their key role in “sounding the alarm” when an incident occurs. It is often the case that your advanced guard for Incident Response is your IT team, who are also mandated to maximize system uptime. In the event of an incident, a frazzled IT staffer might be likely to just “Fix the problem” to maintain key business processes, and thereby circumvent the entire response plan. From an operational standpoint this may seem effective (after all, they got the systems back up quickly, right?) but from a forensic standpoint this type of rapid-restore can destroy a forensic chain. While the IT staffer may have fixed the one system impacted by the incident, by ignoring (or not enacting) the incident response plan, that incident may have spread surreptitiously to other systems and can return, without warning, in the future. By entrusting the execution of the plan to those who are most likely to note an incident, a firm achieves a dual benefit: the IT Team will respond positively and will be likely to offer suggestions an enhancements to the plan as necessary and, secondly, you can be more confident that the alarm will be sounded when an incident occurs.
In order to help all teams in effectively executing an Incident Response Plan, a common language must be developed. If you have not yet considered classification of data, now might be an excellent time to do so. By categorizing your data according to criticality or by sensitivity, a firm can understand what it considers to be “High-Risk” “Medium-Risk” or “Low-Risk” data and can therefore develop an appropriate response. (Note: The conversation of Data Classification is, in and of itself, a complex topic which we will address in future posts.) Once this common language is developed and understood, the firm can begin work on codifying their incident response if necessary, based upon the criticality of the affected data. Codifying an incident response includes creating checklists and procedures for addressing an issue. By learning and rehearsing a checklist weaknesses can be discovered and winnowed out and response can become an automatic, repeatable process.
We would recommend as well, and quite similar to a BCP/DR plan, that a list of key vendors and their contracts be retained. Make sure that the key vendor list, wherever possible, has a direct contact to a specific individual or a specific department. You do not want to discover on the day of your breach that the only phone number you have to your affected cloud service provider is their 1-800 number for sales. Finally, we would add that every critical member in the incident response plan has a backup. If no suitable backup can be named, the firm has a key-person issue that must be remedied. Ensure that everyone in the IT department has a backup, so that Incident Response is a seamless event regardless of the day or time that an attack strikes.
Incident response does not need to be an overly-complex book of rules and procedures, in fact it likely shouldn’t be. Your firm, regardless of industry, should develop a plan that works effectively given the team and the scope of the business. By testing a plan regularly, a firm should shed items that are deemed superfluous, and add to areas where weaknesses are discovered. By continually logging, reviewing, and updating, your company will be more adequately prepared to deal with an incident when it occurs.
In our next post we will discuss the next critical step to take after an incident: Recovery.
