In this lesson,
we're going to discuss incident response playbooks.
Now, incident response playbooks are used
to describe the specific actions taken in response
to emergency scenarios of different types.
A playbook acts as a checklist of actions
that should be performed to detect
and respond to a specific type of incident.
By preparing for an incident response ahead of time
and creating these playbooks, you can ensure
that your team has documented their procedures
and that they're ready to respond when an incident occurs.
Now, most organizations have incident response plans
that are documented for each major type of incident.
When a triage analyst sees something suspicious
or malicious, they can categorize it
and then assign it to an incident handler for remediation
based on your organization's procedures.
The incident handler can then look up the type of incident
and follow the playbook to respond accordingly.
For example, if your organization is suffering
from a DDoS attack, a virus, a worm, a phishing attack,
or data exfiltration,
each of those should have a playbook created
with the different responses and procedures
to mitigate their effects.
Your playbooks are going to serve
as a standard operating procedure
to tell your junior analysts
and incident handlers exactly
what they should be doing in response
to different situations.
If your organization doesn't already have a set
of incident response playbooks,
you can find playbook galleries
that contain several playbooks already created for you.
For example, if you click on the phishing playbook,
we can then see that we can open it up
and get a 10-page document that tells us exactly
what an organization should do in each of the four steps
of the NIST incident response process
in responding to a phishing attack.
This playbook is going to detail
how you can automate your responses,
how you can detect and analyze it,
what actions you take to contain it, eradicate it,
and recover from it, and more.
In each of these phases, the playbook also has a flow chart
that has the relevant actions in it.
In the preparation phase, for example,
you can see how to determine the core team and their roles,
how to review the timeline, how to train your personnel,
and the internal and external path to use
for that organization.
In the detection phase, there's a flow chart
that documents the different ways
to detect this phishing attack
by defining threat indicators.
In the analysis phase,
the flow chart shows you how to define the risk factors
that are involved with the phishing attack,
so you can better triage
and categorize a phishing attack.
In the containment phase,
the flow chart also shows different steps used
to determine how widespread the attack might be.
In the eradication phase,
we can see how the report is going to be triaged and confirmed,
and then the steps taken to remove any malware
that could have been installed
during the successful phishing attack.
This phase also shows the communications
and notifications that could be made based on the severity.
In the recovery phase, we see the steps used to recover
and remediate the systems.
And finally, in the post-incident activity phase,
we can see the required steps
of conducting the incident review or root cause analysis,
the lessons uncovered and applied,
together known as the lessons learned,
and then the response workflows
that are going to be updated based on what we discovered.
Now, as you can see, these playbooks are pretty generic,
but they do provide you with a great starting point
for creating tailored playbooks
within your own organization.
These playbooks can really help a junior analyst
to do their work quickly and more efficiently
by following the flowcharts and knowing exactly what to do
in response to any given threat.
Another great resource in terms
of playbooks is the Microsoft provided playbooks
on their website.
Their playbooks include more technical descriptions
of non-automated response activities
that you can conduct for a phishing attack,
a password spraying attack,
or an authentication bypass attack.
When it comes to responding to a particular indicator
of compromise or incident, you can also automate a lot
of these responses for you in a myriad of different ways.
To do this, our security operation centers will often
implement a SOAR,
or security orchestration automation and response system.
Now, a SOAR is a class of security tools
that helps facilitate incident response, threat hunting,
and security configurations by orchestrating
and automating runbooks and delivering data enrichment.
A SOAR system can be used in incident response
to automate many of your response actions by partially
or fully automating your playbooks.
A SOAR has the capability to scan security
and threat data from your systems,
analyze it using machine learning,
and then automate the process of doing data enrichment
to make that data available
inside your SIEMs to your analysts.
A SOAR can also respond to different threats
and incidents by provisioning new resources,
creating new accounts, disabling old accounts,
starting up new virtual machines,
and fully re-imaging a client using automated playbooks.
For example, you might have a playbook
for a successful phishing campaign
that says you need to perform steps one through nine
anytime somebody clicks a link in a phishing email.
This might include deleting the email from the user's inbox,
determining if the other users received that email,
isolating workstations from the network
that opened the email,
conducting a virus scan of those machines,
conducting a registry scan of those workstations
to confirm infection,
backing up the user's data from those machines,
re-imaging the workstation, restoring the user's data,
and then reconnecting the newly restored workstation
to the network.
That would be a lot of work to do manually,
but by automating this, using a playbook inside of SOAR,
I can create what is known as a runbook.
Now, a runbook is an automated version of a playbook
that can partially
or fully automate the incident response process.
For example, in the phishing example I just described,
we can have the runbook perform the first five steps.
Then it can pause
and wait for the analyst
to confirm the workstation should actually be re-imaged
in step five.
Then, the runbook can take over again,
once the analyst confirms they want that machine re-imaged,
and it'll perform steps six through nine.
By using these runbooks, we can gain a lot of efficiencies
and allow a single analyst to do a lot more work
than they could do singly on their own,
doing everything manually.
This allows us to free up our analysts
for higher level work without wasting their time
on minor things that could easily be automated.
So, what types of playbooks
and runbooks should you have in your organization?
Well, most organizations face at least three common threats
that can be proceduralized using runbooks and playbooks.
This includes ransomware, data exfiltration,
and social engineering attacks.
First, we have ransomware.
A ransomware playbook should be used to describe the people,
processes, and tools that are going to be employed
during a ransomware event.
Ransomware playbooks need to also have considerations
for determining which systems are impacted,
the methods used to impact those systems,
how to isolate those systems,
and which key stakeholders to work with
for different ransomware scenarios
based on the data being held for ransom.
In general, ransomware playbooks should stress the need
to isolate and disconnect networks
and systems as quickly as possible
to prevent the ransomware
from spreading across your network.
The system should not be powered off, though.
They should only be disconnected
because ransomware works through encrypting the data
and those encryption keys could be found
in the random access memory of that system
by a skilled forensic technician
if those systems remain powered on during the entire attack.
Second, we have data exfiltration.
A data exfiltration playbook should be used
to describe the specific
and necessary tasks that are needed to stop
or mitigate ongoing data exfiltration attack,
such as notification requirements, the system analysis,
and the forensic analysis needed
to determine what was accessed and possibly exfiltrated.
Forensic analysis can often determine what data was read
and what data was transmitted out of the network too.
Data exfiltration can be tricky
because it can occur from many different types of exploits,
including SQL injections, password compromises,
and lateral movement across the network
into other data stores.
Your playbooks and runbooks should always focus
on mitigating known instances
and protecting the data stores first,
then identifying any other potential compromises
that may exist in the network.
Third, we have social engineering,
which usually involves some form of phishing.
Now, a phishing playbook should involve
the necessary responses to identifying the phishing emails,
determining which users clicked on or opened links
or files in those emails,
and then identifying the extent of the exploitation.
Your playbook or runbook may also include a notification
to the larger user base to be wary of suspicious emails
if your organization is currently being targeted
using a spear phishing attack.
Now your playbook should focus on identifying all users
who have received that email,
identifying how many have opened, read,
or clicked on the email,
and then resetting their passwords
and re-imaging their workstations.
From an analysis standpoint,
you should open the email in a sandbox environment
as a form of dynamic analysis
in order to determine any IP addresses, URLs,
or other indicators of compromise
that you can use to identify that phishing campaign
once you open it inside the sandbox.