People > Machines (Part Four)

After first dive with Mai

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: