Charles Herring 11 September 2017

Playbook Automation in Incident Response

An emerging concept in 2017 is “Playbook Automation.”

What is Playbook Automation?

Playbook automation collects data from different security and logging tools and makes decisions on behalf of the incident responder.

Data Domains

Incident responders work in several data domains in an investigation: 1) network 2) endpoint/host 3) user/credential 4) file/disk 5) namespaces/fqdn/url 6) human intelligence.

Vendors have created detection tools that exist in one or two of these domains but no point products live in all of them. This creates a workflow that requires the investigator to query several different tools from other domains to determine how to handle an alarm.

When does it work?

Playbook Automation can help reduce noise by taking playbooks in the form of flowcharts that have logic that connect to other data sources to decide. These Boolean checks can close an alarm as noise before an analyst must look at it or make a remediation decision such as quarantine a machine or add a firewall rule. These approaches can take a significant load off a SOC.

Another benefit of Playbook automation is it creates structure in a security practice that enables teaching, quality assurance and audit trails. In 2016, I delivered this talk at GrrCON on the importance of Process in Incident Response: http://f15hb0wn.com/GrrCON2015.

Automation Limitation

Automation is limited to making Boolean (yes/no) decisions. Even with all information available, the power of the human brain is critical during an investigation. As noted earlier, investigations, criminal activity and the human condition is analog. While playbook automation can filter out certain noise or remediate certain nefarious activity, most decisions are not made in certainty.

The post People > Machines (Part Four) appeared first on WitFoo.

Tags

Original URL
https://www.witfoo.com/blog/people-machines-part-four/

About the Author

Charles Herring

Charles Herring

Co-founder & Chairman, WitFoo

I started WitFoo in 2016 to make information and operations shareable across the craft of cybersecurity — between companies, law enforcement, national security and insurers, who mostly cannot see what each other sees. Before that I was at Lancope and Cisco, and I began in 2002 as Network Security Officer for the Naval Postgraduate School.

I lead research and development on a platform that ingests trillions of messages a day across hundreds of clusters. It is sold as Conductor, Reporter and Analytics, licensed flat per appliance with unlimited data — because a team charged by the gigabyte ends up making coverage decisions on a spreadsheet, months before the incident that needed the logs they dropped.

Everything here is mine, not the company's, and it wanders. Corrections are genuinely welcome — I would rather be right than consistent.

A note on how this was written: I use artificial intelligence tools to help me research, check facts, and edit these posts. The ideas, the arguments, and any mistakes are mine. I read the sources, I check the claims, and I take full responsibility for what I publish here. The views are my own and the writing is my intellectual property.