Imagine that someone detects a breach in one of your systems. How would you react? Would you dig into all of your network and host logs immediately? Or would you contain the situation first, by disconnecting the machine(s) from the network?
Actually, you shouldn’t just start thinking about these questions when the incident has already occurred. Incident response procedures should be described in a standardised way and your team should be able to use them without hesitation.
Simply said: you need an Incident Response Playbook.
The Playbook collects ‘plays’. Each play contains a list of actions that are needed to accomplish an incident response task. Plays are extremely useful. They aren’t just a lot of complex queries of code to detect whatever ‘bad stuff’ hit you. In your plays, you will find fully documented prescriptive procedures. They allow you to find – and act upon – undesired activity in a structured way.
Every play contains a set of sections:
- Report ID and title: with a specific structure, you indicate the data source, the type of report – such as ‘investigative’ or ‘containment’ – and the title.
- Objective statement: here you describe the ‘what’ and ‘why’ of a play. This should provide background information and reasoning on why the play exists. Don’t give too many specifics, this should be high-level.
- Scope and applicability: describe who should run the playbook and when or how often.
- Methodology and procedures: this is the ‘meat’ of the play; here you describe the procedures in detail.
Every Playbook counters a different threat. A playbook can handle malware traffic, phishing, ransomware and many more situations.
The biggest benefit of the Playbook is its flexibility. It is not a rigid framework? It has an open-ended nature of play objectives. This allows your security experts to explore different ways of achieving their objectives.
