The real life cyber incidents you will face are quite easy to categorise, and it makes sense to look at how you would handle them generically at a principles level. A Cyber Incident Playbook allows you to make generic decisions on generic trigger events.
You will never be able to detail a Cyber Incident Playbook scenario in sufficient depth to match a real cyber incident, there are simply too many variables to account for, but that is not the point of the playbook. The playbook will provide you with guidance on when a particular type of response is required and what are the principle considerations that got you to that point.
Why bother with the effort?
A Cyber Incident Playbook allows you to make decisions based on principles that were agreed ahead of the cyber incident. If event (P) happens, we will take these actions (Q), because of the following reasons (R).
You then need to explain why Q is a good candidate in those circumstances. During a real cyber incident, simply confirming whether Q is still a good response in the current circumstances will save you a lot of time. And that is the point of a Cyber Incident Playbook. It buys you time. 80% of the thinking is already done.
P may never happen to you, but (P+1) might. You need to have articulated the logic behind why (Q) was a good response for (P), and then you will be able to see if (Q) might be a good candidate starting point for figuring out (P+1).
Understanding the reasoning behind why you would respond in a particular way, is key to generating a broad-spectrum Cyber Incident Playbook.
But where do I start?
Sometimes it’s easier to think about the Cyber Incident Playbook in reverse.
Under what circumstances would we take our Internet presence off-line?
Under what circumstances would we call the Police?
Under what circumstances would we consider paying a Cyber ransom demand?
By thinking about a particular trigger point, you can then work out what the scenario has to be to create that condition.
Natural groupings and categories of Cyber Incident
It is also useful to consider that Cyber Incidents tend to naturally fall into groups or categories.
DDoS
Someone (and we don’t really care who) is trying to take you offline. All we can really gauge is how serious they are by the size of the cannon they are using. But the response is pretty much the same.
It will start with an ISP conversation and there will be a re-routing conversation. There will be a threshold point where you concede defeat and take your own site offline to preserve the integrity of your data. There will be another threshold point where it is sensible to contact the Police (whether that is due to duration or because of some ransom demand made is down to your organisations particular risk appetite).
Phishing Attacks
A Phishing attack compromises a user account. Again, we don’t really care about scale as a distinguishing factor (whether it was a privileged account or not), because the trigger points follow a similar pattern. Once you have dealt with a number of these, the response is almost muscle memory. There will be a chain of events from suspending the account, looking through the logs, identifying access patterns, etc.
Malware on a device
We don’t care if it’s a worm, a virus, a root kit or ransomware. The triggers and the response process sort of unravels by itself. All dependent on the IT environment you have, and the IT tools you have at your disposal.
Systems hacked
An external has broken in and taken residence in the network. The IT-centric scenarios will all start to blend together, because at a principles level you are trying to do all of the same things in the same order.
Containment, Investigation, Remediation, Communication, Recovery.
Insider attack
Someone who was trusted has taken something. It could be Intellectual Property, company employee PII data, client confidential data. Again, we don’t really care, as this group sits together quite naturally in how the company responds and what the trigger points are. Clearly if you have Data Protection requirements under GDPR, this adds an incentive to respond in a controlled and consistent manner.
Third Party Cyber Breach
Not even your mess up (other than your lousy Third Party Assurance process potentially). Someone else has lost your data for you. As you have very little direct control, how do you find out what has happened and how it is being dealt with? This is a communications exercise. A balance between stick and carrot.
Your Cyber Incident Playbook over time
What will happen over time is that you will get quite good at dealing with the cyber incidents you get regularly (regularly does generally depend on the scale of the organisation). The obvious candidates for cyber simulations then become the scenarios you have in the Cyber Incident Playbook that you haven’t had in the last period (year, six months, whatever you decide as your threshold for corporate memory).
Most importantly, constantly update your Cyber Incident Playbook with lessons learnt from cyber simulations and real cyber incidents. It is a guide. You will come up with things on the fly in real cyber incidents and cyber simulations that are really good, that weren’t thought of before. Make sure those improvements make it back to the Cyber Incident Playbook.
Lessons learnt
Cyber Incident Playbook focus should be on lessons learnt, and unfortunately the biggest lessons are learnt in the biggest disasters. When something goes horribly wrong, it is really important to write those lessons down, so you don’t do that again.
Which is why you want to be testing your scenarios in cyber simulations rather than waiting for the real cyber incident to occur. At least you can then have your disaster moments in private.
