Fine-tuning incident response automation for optimal results

Much has been said about incident response automation in the past several years, but many questions remain. One of the most common questions I hear in the industry is "Where do I best apply automation within the IR cycle?" Along with this question are the usual concerns about applying automation in the wrong places, where manual assessment and actions from experienced professionals are really needed.

If you follow the IR process outlined in the National Institute of Standards and Technology Special Publication 800-61 Revision 2, there are several opportunities in each phase for IR automation:

• Preparation: Many of the incident response automation tools available today allow incident handlers and responders to turn their existing plans and workflows into automated workflows with event triggers, inflection points, alerting and more. This can be a huge benefit solely for information capture alone, which can help organizations gather information so junior analysts can learn; it also lessens the impact of any staff turnover because incoming analysts can get up to speed more quickly by studying captured playbooks. This can also help to streamline communications during incidents, since automated alerting and notifications to appropriate stakeholders will be defined at the appropriate times.
• Detection and analysis: Detection and analysis is likely the phase that gives responders the most concern in using automation, as this is the critical "make or break" stage where you choose to pull the fire alarm or not. Teams must be careful to avoid false positives and negatives and take the time needed to only automate detection events that make sense and are relatively certain. Fortunately, many incident response automation tools can ingest events from any number of sources. Analysts who have already identified "known bad" scenarios or "very likely" incidents can automate activities like opening tickets to initiate formal investigations -- the most common automated event many start with -- emailing investigators and stakeholders, updating threat dashboards and databases, or escalating for a second opinion.
• Containment, eradication and recovery: While most organizations are somewhat gun-shy about incident response automation in the containment, eradication and recovery phases, it's becoming more common than ever to automate network isolation for systems infected with ransomware, or to change a password for an account that seems to be compromised. Using automation to quarantine or remove malicious files or artifacts, or to automatically block a domain or IP address that is suspected of command and control traffic or other malicious activity, is also more accepted today than in the past, but will require more testing and validation prior to automation to ensure minimal disruption to business activities.
• Post-incident activity: IR workflow engines will provide some degree of logging and tracking for the entire executed series of stages and events within those stages, so developing postmortem and follow-up reports with these tools makes a lot of sense. While automation platforms likely won't capture all relevant details of an investigation, they'll capture the workflow and ticket creation and changes, which will provide a framework for reporting.
  

Aside from specific stages of the IR process, incident response automation tools can be useful as "expert learning" systems as well; these can be gradually tuned over time to perform actions more effectively as team members' skills develop and threat intelligence data improves. Automating coordination efforts, such as communications between internal stakeholders and law enforcement or partners, rapid creation of tickets with prefilled content, and evidence capture for analysis can also be incredibly useful to simply streamline processes and make security teams faster and more effective.