We want to learn from you, so we're running a contest to gather the best incident response playbooks from the community. It's an open-ended contest–you pick the use case, draw up the playbook, and submit it to the community for consideration. The 3 top-voted playbooks will be awarded prizes.
What's the best incident response strategy? How much time can it save you? How much of the incident response process can you automate? You don't need to be an expert to design the winning playbook. Work with others in the community to flesh out your ideas!
Have ideas for incident response use cases but don't know how to build a playbook? You can still be a part of our contest.
You don't need to build out a downloadable, shareable piece of content. Those who participate need to design only the framework and the decision points of the IR use case. The contest is designed to only take a few minutes to gather as many IR use cases as possible before voting begins!
I'm really looking forward to this. Here's one that I use a lot and works pretty well. Hopefully, you may find it useful.
This playbook offers a quick way to identify malware leveraging cheap (in terms of compute) indicators of compromise (such as filehashes) and sends email notifications. It also has an additional flow to identify malware using a sandbox for those who need the extra check.
Note: the entire playbook is 100% automatable.
Here is the flowchart for my (recently scrubbed of client data) ransomware IR playbook, in PDF format for those who don't have Visio.
There is supporting documentation that goes with it – Instructions for use and how to perform some of the analysis called out in the flowchart, and a final report template. I haven't scrubbed those, but if there is interest I can post them when I have time to do so.
Normally I customize this playbook to reflect client internal processes, departments, resources, and security products. I have left generic references to common departments or tool categories in this version.
My take on Crit/High event monitoring.
This could potentially be used to cover the full array of all severity levels once the analyst portion is modified to meet the needs of the environment where deployed. I guess the trigger could be applied to anything truthfully. Aliases would need to be created to unify meta naming based on various severity feeds. Tuning/additional automation, to be based on actual use of actionable indicators returned after the 'Identify' phase (variations would be based on tools available in an env).
Here's my submission on response automation for Palo Alto Networks WildFire Submission results.
Background: Zero-day exploits and APTs are very serious cyberthreats. Palo Alto Networks WildFire provides cloud-based sample sandboxing and produces a verdict in a few minutes. Due to the nature of the Palo Alto Networks threat intelligence cloud, samples are submitted for analysis only if they are unique and have never before been analyzed by Wildfire. If you see a 'malicious' result from a submission, it means the host is not only infected, it's infected with a piece of malware that's never been seen before. This could indicate a targeted attack with a piece of malware specifically crafted to penetrate your organization. Response times in these situations are critical, especially considering that by the time you've received the verdict, the malware already has a several minute head start. The difference in immediate action versus opening a ticket and waiting for helpdesk or a SOC engineer to reach out could be the difference between a single infected host and an entire network of ransomware or cryptominers.
The goal of this automation is to take immediate action to quarantine the infected host, while also providing the user an indication of what's going on and instructions to contact the IT helpdesk.
Note: While this submission is focused on what I know (Palo Alto Networks), the same process could be used to ingest logs from an endpoint solution, a SIEM correlation engine, or anything you want.
•	For any Wildfire submissions returned with a "benign" verdict, send an email notification and a slack alert to the SOC or security team responsible (just so they know a unique file has been detected).
•	For any Wildfire submissions returned with a "grayware" verdict, send an email, a slack alert and open a medium-priority IT ticket for follow up to determine if any remediation is required.
•	For any Wildfire submissions returned with a "malicious" verdict, send an email, a slack alert, open a critical-priority IT ticket and run the "quarantine" playbook on the infected workstation.
In our scenario, Wildfire has returned a "malicious" verdict for a file downloaded 10 minutes ago by 192.168.1.100. Our playbook will effectively quarantine the host and redirect any HTTP/HTTPS requests to an internal server hosting a notification page informing the user of the infection.
Here's how I configured the Palo Alto Networks firewall.
I've created a dynamic address group which will accept API calls to populate values without the need to log into the firewall or do any config changes or commits. This dynamic group is configured to populate any value containing the keyword "Quarantine" made with a valid API call.
From the incoming syslog message, we parse 3 values: type=wildfire, verdict=malicious, and the victim IP address. We extract the victim IP and make an API call to populate it into the quarantine group.
Here's the API call I make to the firewall to populate the dynamic address group.
Essentially, this is saying "Add "192.168.1.100" to any dynamic groups configured to include the keyword "Quarantine" (ie, the "WF-Quarantine-Group" dynamic address group)".
•	Rule 1 permits the infected host to resolve DNS, as we need the infected workstation to be able to resolve an IP before it can make an HTTP/HTTPS request which we can intercept.
•	Rule 2 permits the infected host to make HTTP/HTTPS requests, however, we will be 302 redirecting any requests made (see the authentication policy below) so they won't be able to get anywhere other than our notification web server.
•	Rule 3 denies all other traffic.
•	Rule 1 says if the infected host makes a tcp/80 or tcp/443 request to anywhere, redirect it.
The final result is an automatically quarantined infection, critical alerts to the appropriate teams, and hopefully the end user is calling helpdesk for remediation before anyone in IT ever realize a ticket was opened.
It's now time to vote on your favorite! Which playbook do you like best? Which one would be most helpful to you?
Congrats, @nihalpasham! Your playbook won the contest!
Great job! Thanks for sharing your ideas with the community!