This article is the eighth in a series of articles by NAV CANADA Vice-President and Chief Information Officer Claudio Silvestri about talking to your board about cybersecurity.
Describe what your incident response plan is, and what your return-to-service plan looks like
I recently read a vendor study that indicated that less than 15 per cent of Canadian companies have a documented cyber-incident response plan. I was shocked but not surprised. While I have no cause to disbelieve or dispute the finding, I worry they may be overstating the number.
The basic goal of your incident response plan is to detect and react to computer security incidents (not necessarily limited to a cyber-event), determine the scope and impact of the event, respond appropriately, and communicate effectively to all of your stakeholders.
Whatever standard you use (e.g., NIST, ISO), there will be definitions related to incident handling. In general, the rose smells the same and will be described in phases such as Prepare, Detect, Contain, Investigate, Remediate, and Recover.
The specifics and level of robustness of any part of your incident response plan will differ, whether or not you are in a highly regulated industry or in the public sector. Nevertheless, you must have your plan ready to go, with clear criteria for setting it in motion, and with all roles clearly defined.
In many regulated industries, there will likely be an overarching Enterprise Wide Emergency Response plan, which should be leveraged within your plan, and fully aligned and integrated within it. This will go a long way to helping with your preparedness (policies, procedures, governance through an event, communication plans). The rest of the plan, however, should largely be defined by you.
You must also remember that, though you have a plan ready to go, every incident will be unique, and will require game-time decisions that shape the execution of the plan. Be comfortable with this as it is far better to manage with some fluidity during the early phases when you’re dealing with a rapidly evolving threat.
Don’t hold onto each step of the plan if things are not relevant or required. At game time, depending on the event itself, the incident commander may have to make some real-time decisions before an incident is fully understood. For example, if you have what is clearly a significant breach of private or classified information, you may be forced — by regulation, for instance — to enter a communication phase well before anyone has been able to get a handle on containment.
Do not overlook the technical return-to-service plan. This would rightly be described as part of your Disaster Recovery Plan (DRP), but could require some additional activities that would not normally be performed in the normal course of a DRP event such as the loss a data centre due to a fire or flood.
For example, if you have experienced a ransomware attack, and you learn that the attack had a dwell time that spanned your data backup cycles, then there is a high probability you will not be able to rely on your data backup source as it would likely have also been infected with the encryption payload.
So then what do you do? How far back would you have to go to find a clean source of your data? Odds are it would be well past the recovery point and time objectives set out in your DRP if the attack had an extended dwell time (which for the Americas is a mean time of 75 days, as mentioned above).
This specific example should also cause you to think about your overall backup and data protection strategy as part of your DRP capabilities. I would hazard a bet that most IT organizations do not have capabilities to scan backup sources, whether inline or on demand.
Lastly, and perhaps most importantly, you must practice the plan on a regular basis. The incident response plan may have elements that reflect a point in time in your organization, technology footprint, policies, etc.
Just like your DRP, if it’s not kept current and practiced on a regular basis, you may not be able to fully rely on it other than for the false sense of security it provides.
Two of the most common challenges for a DRP are 1) documentation that is not kept current, and 2) not enough practice time for staff to exercise the plan. Your cyber incident response plan will suffer the same fate unless you take deliberate approaches to avoid that outcome.
Remember that your DRP is only as valid as your last production change. If that change is not reflected in your DRP documentation, then when it comes to a real-life disaster your team will be relying on memory.
You might be able to get away with a few misses, but over time if you don’t have the controls in place to keep production and DRP synchronized, you will have eroded the value of your DRP to the point of rendering it ineffective. Again, your cyber incident response plan will suffer the same fate. The message is to keep your cyber incident response plan current, and practice it as often as you can.
Next article in the series: “Cybersecurity essentials – Communications“
