A response playbook may be one of the most important documents that senior management ever signs in terms of protecting an organisation against disasters. It helps you understand what you have got, where it is, and then articulates the processes for how you are going to protect it. During an incident it expedites response, shortens conversations, and puts everyone – literally – on the same page. However, one size does not fit all. While templates are useful, it is essential that your playbook fits with the roles, responsibilities, and objectives of your organization. It should be a collaborative effort with the entire IT team to ensure all assets, programs and endpoints are logged, backed-up, accessible and able to be investigated.
Part of the playbook implementation exercise involves thinking though worst-case scenarios, for example, who gets the call in the middle of the night? What if someone is on holiday? Is there a process for when certain people cannot be contacted? Where will your data come from? What are the internal and external communication plans? Who takes the lead? What if it is your payment server that is compromised and needs to be shut down – who has the authority to make that decision? How will you communicate a breach to your customers? Who will handle the press enquiries? Incident management often stretches far beyond security operations centre and IT teams.
One should think of the playbook as a living document that must be continually fed. Assume that your organisation, as it grows and evolves, will undergo changes that must be reflected in your playbook for it to be an effective document. But before it is signed off, it is crucial that you test it to ensure all participants are clear on their role and that all processes can run as smoothly as possible. You can think of it as like testing your disaster recovery scenario. Every person in the core team also needs to be trained and tested in every role required. This ensures that all eventualities – and absences – are ready to be handled. In any organisation, things change – and they change quickly. This can lead to any number of oversights in existing plans. For example, when corporate restructuring occurs, something as simple as a contact list of who is responsible for certain processes could quickly become obsolete. For example, the Equifax breach occurred because the instructions to patch a known vulnerability went to an outdated list of recipients. Your incident response plan needs to be continuously re-evaluated, especially if your organisation has undergone any kind of restructuring, merging. This is also the case after any new incident to make sure your plan reflects your security posture and your evolving understanding of how and why you are targeted. The bedrock of collaboration is having all network maps, mailing lists and more, up to date.