An incident response playbook is a set of pre-defined steps and procedures that outline how to respond to a specific type of security incident. The playbook typically includes detailed instructions on how to identify, contain, and remediate the incident, as well as any additional actions that may be required, such as communicating with stakeholders or escalating the incident to higher levels of the organization.
The incident response playbook is an important part of a SOAR (Security Orchestration, Automation, and Response) solution, as it provides a structured and standardized approach to responding to security incidents. This can help reduce the time and effort required to respond to incidents, and it can also help ensure that the appropriate actions are taken in a consistent and effective manner.
To build an incident response playbook, organizations should follow a structured process that includes the following steps:
Identify the types of security incidents that the playbook will cover. This may include common types of threats, such as malware infections or phishing attacks, as well as more specific types of incidents, such as data breaches or insider threats.
Define the steps to be taken in response to each type of incident. These steps should be specific and actionable, and they should be based on the organization's security policies and procedures.
Determine who is responsible for each step in the playbook, and ensure that the necessary personnel are trained and prepared to carry out their roles.
Test and validate the playbook to ensure that it is effective and efficient in responding to incidents. This may involve conducting simulated incident response exercises or incorporating feedback from security analysts who have used the playbook in real-world scenarios.
Some SOAR solutions may include pre-defined playbooks as a starting point, which can be customized and tailored to the specific needs of the organization. Check out popular SOAR platforms such as Palo Alto XSOAR, Splunk phantom, and DTonomy AIR for out-of-box playbooks. These playbooks can provide a useful foundation for building an incident response process, but they may need to be modified and adapted to fit the organization's specific security policies and procedures.
Search for a product comparison in IT Alerting and Incident Management
Incident Response Playbook is the guide lines and group of processes, policies, plans, and procedures, along with appropriate oversight of response activities, that the organization should take to make a proactive response, quick containment, effective remediation and action plan with "what if" scenario in case of certain cyber incident has taken place.
How do you build an incident response playbook?
Regarding to NIST, to build an Incident Response Playbook you need to design the process which contains 4 main phases:
Do SOAR solutions come with a pre-defined playbook as a starting point?
- Sure, most of SOAR solutions today comes with predefined templates. However, it's a double-bladed weapon based on Cyber Security Awareness and maturity level of the organization. If it's implemented with no or low maturity level, it may harm the organization production and utilize the resources improperly.
Incident Response playbooks detail how to act when a threat or incident occurs. PICERL - Preparation, Identification, Containment, Eradication, Remediation, Lessons Learned (From SANS). The playbook outlines what to do at each stage.
Typical SOAR playbooks automate the response to detected threats.
- Create a Ticket to Track the Incident
- Identify the source and target
- Confirm the attack is suspicious (SOC Analyst Lookup, On known blacklist? other events?)
- Contain or Clean the Host (EDR, Patch, Update AV...)
- Block the Known Attacker (on a Firewall, IDS, etc...)
- Disable a Compromised Account
- Notify anyone necessary
SOAR actions include scripts to set or fire off actions on devices.
A playbook usually has a series of actions when a threat/incident is detected.
Most SOARs include playbooks, but they have to be tailored and customized to the specific devices you have in your environment (Palo Alto Firewall vs. Checkpoint, Cylance vs. McAfee EPO...), Ticketing System integration, SIEM/UEBA threat detection integration...
Playbook automates the gathering of threat intelligence from a myriad of sources of threat intelligence. Playbooks ingest alerts from tools like SIEM and scan the alerts against the threat intelligence sources like VirusTotal and others in order to get information related to the alert. Playbook for example can scan suspicious domains /IPs against virus total and provide reputation score of the domain/IP.
Depending on the workflow, the playbook may be configured to close a case if it's a false positive or pass the case together with threat intelligence gathered to SOC Analyst for further investigation. This way the playbook will reduce time spent on false-positive alerts. Also saves time for analysts by automatically gathering threat intelligence instead of analysts doing that manually.
Be careful of cases where you set alerts to be automatically closed though. You can try this on some community editions soar platforms: Splunk phantom, SIEMplify ...
Building a playbook
Magdy has provided perfect industry standards for building playbooks. Just a little, the playbook mainly has actions and decisions. Actions: take an action against an alert (like scanning) and based on the results playbook decides what to do with the results: whether to close, do further scanning using other tools, pass it to the SOC analyst and this really depends on your workflow.
Cyber Security Services Operations Manager at a aerospace/defense firm with 501-1,000 employees
Real User
2021-09-22T10:01:47Z
Sep 22, 2021
For a given incident type, it describes a series of actions that can be a mixture of automated and manual steps. When you start, the steps are often manual. As the playbook and confidence in the steps improve, you can start automating.
For example a playbook for a “suspicious email” might read as:
1) check if the case is already opened for this user and/or asset, if yes go to step 3open case
2) open case and record details
3) extract suspicious attachment
4) generate MD5 and SHA256 hashes
5) submit hashes to Virustotal and record results
6) if 50% (pick your threshold) of AV engines detect the sample skip to step 10
7) forward email attachment to sandbox
8) does a sandbox report indicate suspicious behavior? If yes escalate to T3
9) inform the user
10) open a ticket to IT to re-template PC or fix
11) when you receive a response from IT about the ticket, then close a SOC ticket with relevant closure details
This is a quick illustration of what steps should be included depending on your environment and how far you go.
What are IT alerting and incident management? IT alerting is a process by which the software that is responsible for monitoring the health of an IT system generates alerts that notify the appropriate teams when an incident occurs.
An incident response playbook is a set of pre-defined steps and procedures that outline how to respond to a specific type of security incident. The playbook typically includes detailed instructions on how to identify, contain, and remediate the incident, as well as any additional actions that may be required, such as communicating with stakeholders or escalating the incident to higher levels of the organization.
The incident response playbook is an important part of a SOAR (Security Orchestration, Automation, and Response) solution, as it provides a structured and standardized approach to responding to security incidents. This can help reduce the time and effort required to respond to incidents, and it can also help ensure that the appropriate actions are taken in a consistent and effective manner.
To build an incident response playbook, organizations should follow a structured process that includes the following steps:
Some SOAR solutions may include pre-defined playbooks as a starting point, which can be customized and tailored to the specific needs of the organization. Check out popular SOAR platforms such as Palo Alto XSOAR, Splunk phantom, and DTonomy AIR for out-of-box playbooks. These playbooks can provide a useful foundation for building an incident response process, but they may need to be modified and adapted to fit the organization's specific security policies and procedures.
Hi,
what an incident response playbook?
Incident Response Playbook is the guide lines and group of processes, policies, plans, and procedures, along with appropriate oversight of response activities, that the organization should take to make a proactive response, quick containment, effective remediation and action plan with "what if" scenario in case of certain cyber incident has taken place.
How do you build an incident response playbook?
Regarding to NIST, to build an Incident Response Playbook you need to design the process which contains 4 main phases:
1- Prepare.
2- Detect and Analyze.
3- Contain, Eradicate and Recover.
4- Post-Incident Handling.
*reference, NIST Computer Security Incident Handling Guide:
https://nvlpubs.nist.gov/nistp...
*reference, SANS Incident Handler's Handbook:
https://www.sans.org/reading-r...
Do SOAR solutions come with a pre-defined playbook as a starting point?
- Sure, most of SOAR solutions today comes with predefined templates. However, it's a double-bladed weapon based on Cyber Security Awareness and maturity level of the organization. If it's implemented with no or low maturity level, it may harm the organization production and utilize the resources improperly.
@Maged Magdy agree. These playbooks are a good starting point and need to be customized.
Incident Response playbooks detail how to act when a threat or incident occurs. PICERL - Preparation, Identification, Containment, Eradication, Remediation, Lessons Learned (From SANS). The playbook outlines what to do at each stage.
Typical SOAR playbooks automate the response to detected threats.
- Create a Ticket to Track the Incident
- Identify the source and target
- Confirm the attack is suspicious (SOC Analyst Lookup, On known blacklist? other events?)
- Contain or Clean the Host (EDR, Patch, Update AV...)
- Block the Known Attacker (on a Firewall, IDS, etc...)
- Disable a Compromised Account
- Notify anyone necessary
SOAR actions include scripts to set or fire off actions on devices.
A playbook usually has a series of actions when a threat/incident is detected.
Most SOARs include playbooks, but they have to be tailored and customized to the specific devices you have in your environment (Palo Alto Firewall vs. Checkpoint, Cylance vs. McAfee EPO...), Ticketing System integration, SIEM/UEBA threat detection integration...
Hi Rony,
Playbook automates the gathering of threat intelligence from a myriad of sources of threat intelligence. Playbooks ingest alerts from tools like SIEM and scan the alerts against the threat intelligence sources like VirusTotal and others in order to get information related to the alert. Playbook for example can scan suspicious domains /IPs against virus total and provide reputation score of the domain/IP.
Depending on the workflow, the playbook may be configured to close a case if it's a false positive or pass the case together with threat intelligence gathered to SOC Analyst for further investigation. This way the playbook will reduce time spent on false-positive alerts. Also saves time for analysts by automatically gathering threat intelligence instead of analysts doing that manually.
Be careful of cases where you set alerts to be automatically closed though. You can try this on some community editions soar platforms: Splunk phantom, SIEMplify ...
Building a playbook
Magdy has provided perfect industry standards for building playbooks. Just a little, the playbook mainly has actions and decisions. Actions: take an action against an alert (like scanning) and based on the results playbook decides what to do with the results: whether to close, do further scanning using other tools, pass it to the SOC analyst and this really depends on your workflow.
I am a junior but I love this SOAR thing.
For a given incident type, it describes a series of actions that can be a mixture of automated and manual steps. When you start, the steps are often manual. As the playbook and confidence in the steps improve, you can start automating.
For example a playbook for a “suspicious email” might read as:
1) check if the case is already opened for this user and/or asset, if yes go to step 3open case
2) open case and record details
3) extract suspicious attachment
4) generate MD5 and SHA256 hashes
5) submit hashes to Virustotal and record results
6) if 50% (pick your threshold) of AV engines detect the sample skip to step 10
7) forward email attachment to sandbox
8) does a sandbox report indicate suspicious behavior? If yes escalate to T3
9) inform the user
10) open a ticket to IT to re-template PC or fix
11) when you receive a response from IT about the ticket, then close a SOC ticket with relevant closure details
This is a quick illustration of what steps should be included depending on your environment and how far you go.
Each step could be related to different teams.