Utilizing Playbooks in Incident Response
Utilizing Playbooks in Incident Response
gh
Ri
The use of playbooks in the incident response process
ll
Fu
GIAC (GCFA) Gold Certification
ns
ai
Author: Andreas Seiler, seiler937@[Link]
Advisor: Chris Walker
et
Accepted: 7/1/2022
rR
ho
ut
,A
te
itu
Abstract
Playbooks are a promising tool for incident response personnel. However, where to
st
start? What resources are available, and what is the best way to use them? Playbooks
In
offer a guiding thread in stressful response situations and can improve the technical and
NS
organizational quality of procedures. So, let us look at the use of playbooks within the
incident response process. An analysis of four existing, publicly available incident
SA
response playbooks demonstrates state of the art. The discussion of the surrounding
processes for creation, validation, and training, provides an introduction to how to use
incident response playbooks. A survey approach is a great way to create playbooks for
e
Th
gh
Ri
ll
This paper provides an overview of existing playbooks in incident response and
Fu
analyzes their structure and contents. I selected and analyzed four incident response
ns
playbooks. Besides this analysis, we discuss incident playbook definitions, usage, and
ai
processes. The goal is to give an overview of incident response playbooks and guidance
et
on the creation and use of playbooks.
rR
What are playbooks? A general definition states that playbooks are “a set of rules
ho
or suggestions that are suitable for a particular activity, industry or job” (Playbook, n.d.)
ut
as well as a “document defining one or more business process workflows aimed at
,A
ensuring a consistent response to situations commonly encountered during the operation
te
of the business” (Playbook, 2007). Concerning the incident response process, playbooks
itu
are documents or rulesets (e.g., within the software) which define a workflow or a
st
Playbooks are an auspicious tool to support activities within the incident response
NS
process. They can provide a guiding thread in stress situations and improve the technical
SA
playbooks are an essential tool for incident response to create better plans, train processes
Th
and skills, and increase the security awareness of staff. Even the creation or preparation
22
The tricky part is to adapt and customize playbooks to the company’s needs. It is
©
essential to balance the coverage of different use cases with excellent and current
documentation concerning the latest threat landscape. For this it is crucial to have an
overview of existing playbooks, their structure, and content and the know-how to use
those and adjust them to the company’s needs. The author’s experience with processes,
tasks, and problems from working with and within SOC, SIRT, and CERT teams in the
energy industry, are the foundation of this work.
gh
Ri
ll
Playbooks support the implementation of the Incident Response Process through
Fu
documented tasks and workflows. To elaborate on the use of incident response
ns
playbooks, first, we look at the incident Response process itself, the current State-of-the-
ai
art, as well as the processes for creation, validation, and training of those playbooks.
et
rR
2.1. Incident Response Process
ho
The incident response process is a phase or life cycle model defining key
ut
activities for handling a cyber security incident. Most current models use the military
,A
six-step OODA (observe, orient, decide, act) model (Murdoch, 2016, p. 5). The National
te
Institute of Standards and Technology (NIST) (Cichonski et al., 2012, p. 21) and the
itu
SANS Institute (Kral, 2021) published the most seen models in the industry. Both are
st
quite similar in their structure and suitable for categorizing the contents of playbooks.
In
NS
NIST SANS
SA
1) Preparation 1) Preparation
e
4) Eradication
20
5) Recovery
4) Post-Incident Activity 6) Lessons Learned
©
Within the preparation phase, the crucial tasks are creating a policy and strategy,
defining the communication, and preparing the team and their toolset. In the next phase,
events are detected and analyzed to identify incidents and their scope. The phases of
containment, eradication, and recovery are about limiting the impact of incidents and
restoring regular operations. Lessons learned and post-incident activities aim to
document findings and improve incident handling in the future.
gh
There are specific ones tailored to tasks in defined phases and playbooks that
Ri
cover all the phases to deal with specific incidents. These incident response processes
ll
Fu
structure playbooks and ensure coverage of needed tasks within the different phases. Due
to the uniqueness of security incidents, responders require different activities in each
ns
phase. For example, the needed steps for recovery from a phishing campaign differ from
ai
those of a ransomware attack.
et
rR
2.2. A short analysis of existing incident response playbooks
ho
We now look at existing playbooks to learn about their structure, content and use
ut
within the incident response process. The starting point for looking into existing incident
,A
response playbooks was a talk on incident response playbooks as an open-source resource
te
at the SANS DIFIR Summit 2021 by Mathieu Saulnier. There is currently only a small
itu
supply of playbooks available online. The following four playbooks are publicly
st
available and have a high level of maturity. Their authors are a banking CERT, a
In
gh
playbooks, which they call IRM (Incident Response Methodologies), on [Link].
Ri
These short playbooks cover a lot of use cases on a higher abstraction level.
ll
Fu
ns
Published 29.04.2016
ai
Use Cases worm infection, windows intrusion, Unix Linux intrusion detection,
et
DDoS, malicious network behavior, website defacement, windows
rR
malware detection, blackmail, smartphone malware, social
ho
engineering, information leakage, insider abuse, phishing, scam,
ut
trademark infringement, ransomware
,A
Scope 2 pages (per playbook)
te
Structure six phases like the SANS incident response process
itu
Abstraction high
In
Level
NS
Published 22.02.2021
Use Cases ransomware
Scope 22 pages
gh
Ri
Structure six phases based on the NIST incident response process; for each
phase, it documents the objectives and different activities with
ll
Fu
descriptions and referred stakeholders
Form task list with flow diagram in the annex
ns
Abstraction medium
ai
et
Level
rR
User IT CIRT and CIRT team members
Content •
ho
Refers to IT CIRT and CIRT teams as well as business
continuity and resilience leads
ut
•
,A
Recommends adjusting the playbook to organizational needs
and capabilities
te
•
itu
This playbook contains a definition of activities for the
detection, analysis, and remediation of a ransomware incident.
st
In
22
gh
Ri
Use Cases malware outbreak, phishing, data theft, virus outbreak, denial of
service, unauthorized access, elevation of privilege, root access,
ll
Fu
improper usage
Scope 10 pages (per playbook)
ns
Structure seven phases based on the NIST incident response process
ai
et
Form process diagram
rR
Abstraction medium – high
Level
ho
User Core Ops Team, Extended Team
ut
•
,A
Content Focus on what to do, not on how to do it
• Entry Level playbook with a clear and structured overview
te
itu
Mathieu Saulnier has focused his work on SOC, Blue Teaming, and content creation in
Th
this field. He shared his findings at different security conferences. At the SANS DFIR
22
Summit 2021, he presented his work in a talk and published his playbooks in July of
20
Published 22.07.2021
Use Cases Account compromised, critical, data loss, malware, phishing, ransom.
Scope 2 – 11 pages (per playbook)
Structure six phases based on the NIST incident response process
Form Combination of task lists and process diagrams
Abstraction low
Level
User SOC Team
gh
•
Ri
Content Technical and organizational details
• Focused on SOC tasks
ll
Fu
• References to other playbooks (e.g., Malware reference in
ns
compromised account eradication)
• Good overview, partly complex process diagrams
ai
et
Table 6: Analysis overview: Syntax-IR playbooks
rR
ho
2.3. Processes for playbooks
ut
2.3.1. Creation of playbooks and playbook templates
,A
How are playbooks created, and what templates, methods, or frameworks,
te
therefore do exist?
itu
Crafting the InfoSec Playbook (Bollinger et al., 2015, p. 72) defines the structure
st
In
and content of the playbook as report identification, objective statement, results from the
analysis and data query/code, and comments/notes. In the sense of this book, the
NS
playbook templates act, as well as documentation for the task results. Furthermore, it
SA
playbooks in the context of this book aligns with the definition of an incident response
Th
plan. Although the overall goal is an abstract plan on how to deal with security, these
22
• What are you trying to protect? (What is the goal of the playbook)
©
• What are the threats? (What use case is the playbook for, and how can it be
identified)
• How do we detect them? (What are the needed tasks for preparation and
detection, and identification)
• How do we respond? (What are the needed tasks for containment and
eradication?)
gh
Besides these content-focused questions, the book also emphasizes the criticality
Ri
of the internal incident response team (roles and responsibilities), internal stakeholders,
ll
Fu
external contacts, and partners.
ns
ai
On their website, the company Atlassian provides an incident management
et
handbook as well as guidance on how to create incident response playbooks
rR
([Link]
ho
incident-response-playbook). They have defined a relatively high-level five-step process:
ut
1. Define incidents for the organization (specific definition of what constitutes an
incident)
,A
te
2. Establish predesignated roles (Incident roles and responsibilities)
itu
st
issue fields)
e
Th
after the NIST process and lists a description for each incident response step. Within
those, a workflow chart depicts the procedure and needed decisions.
So finally, there are different ways and processes for creating incident response
playbooks, but there are similarities and critical components and contents.
gh
The main takeaways concerning playbook templates are to base them on one
Ri
existing process framework and decide on an abstraction level and a form (task list,
ll
Fu
workflow, or a combination). Also, use the templates in training situations and lessons
learned and adapt them over time with a continuous improvement cycle.
ns
ai
et
2.3.2. Validation
rR
How can one validate playbooks or use playbooks as a validation tool for their
ho
incident response process? To answer this question, we have to look at what we want to
ut
validate. Generally, the validation focus can be on quantity or quality.
,A
Concerning quantity, the question is: Is there a playbook for every needed
te
situation? There are different perspectives to that question: threat-focused, task-focused,
itu
responders look at specific incident use cases. For this approach, it is crucial to align
In
with existing threat analysis and intelligence information within the company. If there is
NS
no threat information available, using current threat reports (e.g., The 14 most common
SA
When looking at the quality of playbooks, the Blue Team Handbook: Incident
©
Response Edition (Murdoch, 2016, p. 22-23) provides different success criteria for the
development of incident response plans: top-down support, partner with DR/DC, dual-
purpose and benefits, policies, ownership, IR education, PMO integration, provisioning,
SOC, issue focus, LEA/LEO. Further, implement playbook reviews into the lessons
learned phase of given incident handlings.
gh
2.3.3. Training
Ri
How to use playbooks in the training of incident responders? Besides general
ll
Fu
advice on regular training of incident response tasks and processes, there were no specific
guidelines on how to incorporate playbooks into a training within the analyzed sources.
ns
But playbooks can have different beneficial uses for training. They can introduce new
ai
incident response handlers to the company specific procedures and capabilities.
et
rR
Training-specific playbooks are a good documentation for new incident response use
cases. Furthermore, the use of a playbook over multiple trainings can identify needed
ho
skills and knowledge, as well as document learning progress.
ut
,A
As preparation for a training take one, or a set, of the presented playbooks. Mark
tasks and procedures where skills are lacking and familiarize with the fundamental
te
itu
concepts. Within the training try to refer to the playbook as much as possible and make
notes. Parts that were helpful should be detailed in respect to the target infrastructure and
st
In
organization. Parts that were not relevant will be deleted. If within the training a
NS
All those notes should be worked at after the training to recap the learning goals
and improve the given playbook. This last improvement cycle is done within the incident
e
response team to ensure that playbooks are not too person-specific. When this process is
Th
repeated over multiple trainings and different kinds of trainings playbooks will evolve
22
over time.
20
©
The sources and authors of playbooks vary from committed individuals, such as
security researchers and industry-focused communities, to large CERT teams and
governmental institutions. They either focus on criticality or frequency of security
incidents. An Example of critical non-frequent incidents is ransomware-attacks.
Malware infections are much more frequent but less critical concerning their impact.
The analyzed playbooks have in common that they cover the whole incident
response process. Furthermore, they consist of task lists, workflows, or a combination of
gh
both. The focus of the playbooks and the abstraction level of their contents vary a lot.
Ri
Depending on the targeted users and stakeholders, the documents and abstractions level
ll
Fu
can be categorized as follows:
ns
ai
Stakeholder / User Documents Abstraction
et
Management, C-Level Incident Response Plans Organizational, tasks,
rR
processes, business impact
ho
CERT-, SOC-Management Playbooks Organizational, technical,
ut
and incident focused
,A
CERT-, SOC-Analyst Micro plays, Plays,
te Technical, response task-
Runbooks focused
itu
Concerning the stakeholders or users of the playbooks, the interest and usage vary
NS
minimize the business impact of cyber security incidents, technical analysts want to
document, standardize, and automate their incident response tasks.
e
Th
Information on creation for playbooks, sample playbooks, and in some cases, also
templates are available. Therefore, everything to get started using playbooks within the
22
generic metrics for good playbooks. It is also difficult to validate or compare them on a
qualitative level. Also, in the field of training playbooks, there is room for improvement,
publicly available information, and best practices.
What is the role of playbooks in the current incident response? The role and
usage of playbooks differ a lot: from high-level procedures and workflows to technically
detailed task lists and automated runbooks within incident response tools.
With every standardized tool, framework, and process of the document come
limitations and situations where they are contra-productive for a specific, given situation.
This limitation is also valid for using playbooks within the incident response. An
gh
incident response situation is always dependent on the information available, the
Ri
infrastructure, the skills of the personnel, and other factors. Often for incident responders
ll
Fu
it is more important to act quickly and based on the current situation than following a
predefined playbook.
ns
ai
Nevertheless, the analyzed playbooks are a starting point and guidance for
et
creating company-tailored playbooks. Companies need to adopt the generic workflows
rR
and tasks to their specific conditions, like software and tools, organizational roles and
ho
responsibilities, risk, and compliance frameworks.
ut
,A
2.5. Survey approach for playbook creation
te
itu
Employees are the most valuable resource of a company for incident response.
st
process. The survey approach for playbook creation combines those two elements to
NS
For smaller and medium-sized companies, the best approach is to build up to two
different kinds of playbooks. On the strategic level, incident plans define tasks and
e
Th
campaigns). On the tactical level, incident playbooks define technical and operational
20
tasks and workflows focusing on events and triggers (e.g., incident playbooks for lateral
©
First, the security management should pick the use case based on threat and risk
analysis. Then define all the stakeholders of the company needed for every incident
response phase for the picked use case. Besides the business management and security
management (CEO, CISO/ISO), the operational security staff (CERT, SOC), and the IT
administrators, also users, legal department, communication department, and external
partners can be of interest.
For every phase, there will be a survey session with the identified stakeholders.
Within this survey session, each stakeholder writes down his tasks, triggers, needed input,
gh
and output. Then the beforementioned published playbooks are the starting point for
Ri
discussions and the definition of the tasks. Based on this information, the security
ll
Fu
manager can build the workflow diagram for the given use case.
ns
The result of the first survey session will be an alpha version of the incident plan
ai
or playbook. This version is handed to the stakeholders for review, feedback, and
et
comments within a two-week deadline. The result of incorporating the feedback is a 1.0
rR
version of the incident plan or playbook. These documents should then not only be used
ho
for security operations but also training and every penetration test or purple teaming.
ut
After every incident or test incident, the documents should be used as a documentation
,A
tool for the lessons learned phase. Everything that worked, did not work, or could be
improved has to be written down in comments, for example. This feedback then helps to
te
itu
On the tactical level, the same approach can be used for the more technical
In
documentation with the difference that they will be reviewed more often in a shorter
NS
period.
SA
In concluding the work on incident response playbooks, here are the discovered
22
main findings:
20
problem concerning playbook publication: the better the quality and detail of a playbook,
the greater the need for confidentiality: detection mechanisms, containment strategies,
and response plans should not be known to attackers.
gh
response, processes, and procedures) and primarily important the given staff (number of
Ri
employees, skill set and experience).
ll
Fu
Publicly disclosed knowledge within the different incident response phases
ns
could be gathered in more generic but technically more detailed sample playbooks
ai
(e.g., Sigma detection rules for given use cases). Know-how for specific use cases could
et
also be shared confidentially within certain institutions or groups.
rR
There is a lack of evaluation of the benefits of playbooks – but it is a trusted
ho
tool for practitioners. Why should playbooks be used more often? They can be used to
ut
improve the situational awareness of incident response personnel and are a tool for
,A
training and improving the processes and skills of incident response personnel.
te
What are the next steps? Within current cooperation with the University of armed
itu
forces, Munich and Incident Response teams for critical infrastructures within the energy
st
sector, I plan to use incident response playbooks alongside serious games as a method for
In
creation of good playbooks and training of processes and skills for incident responders.
NS
SA
4. Acknowledgements
e
Th
This work was only possible due to the help of reviews, feedback, and time
resources from friends, family, and colleagues. Therefore, many thanks go to my family
22
for the time, my employer and boss for the support, and to Prof. Dr. Ulrike Lechner
20
(University of armed forces Munich) and my Advisor Chris Walker for all the reviews,
©
gh
References
Ri
ll
Fu
About the IRC. (2017, July 2). Incident Response Consortium. Retrieved May 29, 2022,
ns
from [Link]
ai
Bollinger, J., Enright, B., & Valites, M. (2015). Crafting the InfoSec playbook: Security
et
rR
monitoring and incident response master plan. O'Reilly Media.
ho
Cichonski, P., Mllar, T., Grance, T., Scarfone, K., & U. S. Department U.S. Department
ut
of Commerce. (2012). Computer security incident handling guide: Nist special
,A
publication 800-61, revision 2. CreateSpace.
te
itu
Mandia, K., Pepe, M., & Luttgens, J. (2014). Incident response & computer
In
Mathieu Saulnier. (2021, July 22). Public incident response Ressources / Public
from [Link]
22
Mathieu Saulnier. (2021, August 26). IR Playbooks: A New Open Source Resource.
20
from [Link]
Murdoch, D. (2016). Blue team handbook: Incident response edition: a condensed Field
Murdoch, D. (2019). Blue team handbook: SOC, SIEM, and threat hunting (V1. 02): A
condensed guide for the security operations team and threat hunter.
Playbook. (2007, January 17). Wikipedia, the free encyclopedia. Retrieved April 1, 2022,
from [Link]
gh
Playbook. (n.d.). Cambridge Dictionary | English Dictionary, Translations & Thesaurus.
Ri
ll
Retrieved April 1, 2022,
Fu
from [Link]
ns
Roberts, S. J., & Brown, R. (2017). Intelligence-driven incident response: Outwitting the
ai
et
Adversary. O'Reilly Media.
rR
ho
ut
,A
te
itu
st
In
NS
SA
e
Th
22
20
©
The Blue Team Handbook suggests criteria like top-down support, partnerships with disaster recovery, dual-purpose benefits, and SOC integration for validating playbooks . Validation is challenging because playbooks must align with specific organizational conditions and lack standard qualitative metrics .
Organizations face challenges such as the need for quick action over strict adherence to playbooks and tailoring workflows to specific conditions like software tools and organizational roles . Moreover, predefined playbooks may be limiting if not adapted to the organization's immediate context .
CERT Societe Generale's playbooks have a high level of abstraction and are intended for administrators, SOCs, CISOs, and CERT Teams . The Scottish Government's playbook has a medium abstraction level and targets IT CIRTs and business continuity leads . The Incident Response Consortium's playbooks range from medium to high abstraction aimed at Core Ops and extended teams . Mathieu Saulnier's playbooks provide a lower abstraction with a focus on SOC tasks .
Publicly available playbooks serve as a foundational template that companies can adapt to specific organizational requirements, such as their software, compliance frameworks, and risk profiles. This may involve customizing workflows and responsibilities to better fit their unique operational context .
Stakeholders contribute by participating in survey sessions to document their tasks, triggers, inputs, and outputs for each incident response phase. Their feedback refines playbooks during review cycles, ensuring documents are comprehensive and tailored to organizational needs .
Playbooks can be used in training to introduce specific procedures and capabilities, identify needed skills, and document learning progress by referring to them during simulations and exercises . This approach ensures responders become familiar with organizational processes and highlights areas for improvement .
Abstraction levels vary to cater to different stakeholders: management focuses on business impact through organizational-level plans, while CERT or SOC management requires technical and incident-focused playbooks. Analysts rely on detailed, task-specific guides or runbooks for operational response .
The MITRE ATT&CK framework provides a model for evaluating the response capability coverage against standard cybersecurity attack techniques, helping organizations determine if their playbooks address key threat vectors .
After each incident or test, it's crucial to document what worked, what didn't, and any potential improvements in the playbook. Incorporate feedback from the involved stakeholders to update and evolve the playbook, ensuring it remains relevant and effective .
Most playbooks cover the entire incident response process and typically consist of task lists, workflows, or a combination thereof. They aim to provide guidance on both technical and organizational tasks .