What is a playbook and do you need one?

In this blog post, I am going to describe what is a playbook and then give examples of two different types. 

What is a playbook?

A playbook for me is typically associated with responding to a cyber incident and gives the actions, procedures and communications associated with responding to a certain incident. As per its name, it is derived from American Football. Plays are selected depending on the position on the field, strengths and weaknesses of the opposition and the stage of the game. Lots of different parishioners have different ideas of what a playbook is for and what they should contain. I am going to share with you my ideas for a decision and a response playbook. In looking playbooks, we need to first look at the contents of a cyber response plan.

For me plans for managing incident should be in two parts:

1. Incident Management Plan

This plan is generic and can deal with any incident regardless of the cause and whether it was a foreseen incident such as a ransomware attack or an unforeseen incident such as the closing down of European airspace due to volcanic ash.

This diagram shows a typical incident management team and headings you would expect to find within the plan.

2. Contingency plans

Contingency plans are plans for specific incidents which should be determined from an organisations risk assessment and cover the most likely incidents. They could be developed in response to single points of failure e.g. the organisations call centre is housed in one building, typical incidents for the industry such as a plane crash for an airline or good practice contingency plans such as disaster recovery plans dealing with the loss of an IT application or datacentre. For cyber incidents, I think the playbook format is a very good way of writing a contingency plan for dealing with a specific incident.

Two different sorts of playbooks

Personally, I think there are two different types of playbooks which can be written to respond to cyber incidents. They are decision playbooks and response playbooks.

1. Decision Playbooks

The idea of a decision playbook came to me a couple of years ago.

Case study

We were having a discussion with a client about whether they would ever pay a ransom if the organisation became infected with ransomware. They said the answer was “of course” no. We then got discussing further if there was no possibility of getting the IT back online would they pay? Nobody was sure what the legal position was if a ransom was paid. Nobody had spoken to the Police so they were unsure of what they would advise if they were called in response to the incident. It was decided that the organisation’s board should discuss when they would or wouldn’t pay and have the debate now when they could discuss the matter in an unpressured environment instead of waiting until an actual event was to occur. They also decided to do the research to answer any questions which the board would like to know on making a decision on payment. The information and the results of their decision-making would then be written up so they could remember what they decided and criteria they made the decision on if a real incident occurred. 

In some incident responses, the way of resolving the incident may not be obvious and there may be a number of options which needed to be considered on the day of the incident and which one to take very much depends on the circumstances of the incident.   

Examples of where decisions are needed

Typical examples of the decision could be:

• Do you switch to your alternative data centre or do you wait until the main comes up?
• Do you pay a cyber ransom?
• When do you need to inform those on your databases that their information has possibly been hacked?
• If you have denial of access attack do you disconnect your system from the internet?

In all of these examples, there is no obvious response and it will very much depend on the circumstances and will be a judgment call on the day. Often this judgement call might need to be made without the full facts being available and the consequences of whatever decision may be substantial.

Decision playbook contents

So, what might we want to record against each of the scenarios in our playbook, using the ‘whether we switch to the alternative data centre’ as an example?

1. What is the scenario the ‘play’ covers? 
2. Options available?
3. What circumstance is there a clear decision?  
4. What are the issues to be taken into account on making the decision? 
5. How long does it take to implement the decision? 
6. Who can make the decision? 
7. What needs to be done to implement the decision, and who needs to do it? 
8. What is the downside of operating the alternative? 
9. What subsequent actions need to be taken and how will the recovery be carried out?

If you would like an example of a decision playbook there is a link at the bottom of this blog.

2. Response Playbook

The second type of playbook is for a specific type of incident. I know that incidents don’t always fit the plan, but I think some of the detailed planning is worth carrying out. The sort of cyber incident playbooks should be written for are the basic attacks including ransomware, DDoS attacks and data loss (this might want to be segregated into the different types of data the organisation hold). It is only worth writing these playbooks for larger incidents which would have a reputational impact, and for smaller incidents an IT response plan is sufficient.

These are the headings I think the playbook should have:

1. Type of incident – DDoS etc.
2. Likely means of detection – include the main ways the incident could be detected.
3. Likely impacts – which part of the organisation might be affected? E.g. ransomware could stop all company systems, but data loss will have no impact on actual systems.
4. IT plans in place for dealing with it and their strategy for recovery – crossreference the relevant IT plans.
5. Who needs to be informed of the incident, internally and externally? I think this is a key part so that you can quickly identify all those who might be affected. These should be segregated, so don’t just include staff, as there could be contractors, temporary staff, those off sick, maternity/paternity leave, staff that have left and retirees. I also think there should be information on how to contact your staff, as well as a plan on how to get in contact if the IT systems are down.
6. What regulatory and statutory notifications are required, including time frames and what information is needed? For example, reporting to regulators, Information Commissioners Office and the stock market.
7. How will the incident be managed and are there any requirements for specialists joining the incident team? Which team will manage the incident, and do you need specialists, such as external public relations help, plus legal and compliance people on the team?
8. What third party support is required? This could include forensic IT specialists.
9. Risks, decisions and issues to consider – put down as many as you can think of.
10. Guidance on communications and lines to take – this could be debated and exercised so that there is a structure in place already.
11. Relevant business continuity plans and recovery strategies – are there business continuity plans and manual workarounds which can help the response?
12. What actions can be taken to support those affected, and what support are you going to give the victims of the incident?
13. What matrices should be used and monitored to check the effect on the organisation? How do you tell if your response plans are being successful?
14. Priorities and predetermined objectives for this type of incident – can you write them now?
15. Other – under this heading, when choosing an example, I wrote ‘what data we hold’, so if this playbook was for a breach of the staff database, we know what data we hold on staff.

Cyber incidents by their nature are difficult to manage, especially at the beginning of the incident. If your headquarters burn down, the incident and the consequences are obvious, but if there is a cyber breach then there is nothing to see, so it can take a while to understand the true impact of the incident. As with all business continuity, the more you plan, exercise and think about your response, the more you realise what you can do now, which will help your response on the day. The old army adage comes to mind “train hard fight easy”.