Automating incident response

NIST provides a comprehensive Incident Handling Framework, which serves as a blueprint for organisations aiming to improve their cyber posture. This article will look at possible opportunities to automate incident responses around this standard.

NIST Special Publication (SP) 800-61 Rev. 2, Computer Security Incident Handling GuideCSRC | NIST

NIST SP 800-61

1. Preparation Phase:

   • Playbooks: Expected incidents and known security findings / alerts can be automated. For example, building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake, or using Azure's Sentinel workbooks.

   • Asset Inventory: Begin by automating the process of maintaining an up-to-date inventory of assets, including hardware, software, and network components. Use tools for continuous monitoring and asset discovery to ensure comprehensive coverage.

   • Simulations: Ensure you test your IR capabilities by running simulations. Simulations can be table top exercises, purple teaming, or red teaming. The 2 latter options that could include running scripts / deploying test malware could be automated using tools and custom tools. This can help test readiness over time, rather than only during exercises.

   • Threat landscape: Ingest and enrich your environment / incidents with threat intelligence. Automating this enrichment can give responsers context to incidents which can help save time.

     • Consider creating further actions to take actions if the confidence of the incident being a true positive is high. For example, a known bad URL or sender in an email is found, so this can automatically be resolved.

   • Automating forensics: Avoid human error and time consuming evidence collection by automating forensics. Base this on Containment > Acquisition > Examination > Analysis. See https://github.com/awslabs/aws-automated-incident-response-and-forensics

2. Detection and Analysis Phase (Operations):

   • Detection rules: Consider ways to automate the creation or detection rules. If you are creating detections based on TTPs, do you rely on manually researching new TTPs or is there a way to automate this?

   • Detection: What happens when a detection is triggered? A ticket is created, or a notification is sent to the SOC. Then what? How can you initiate an action to the next phase - contain, eradicate, and recover.

3. Containment, Eradication, and Recovery Phase:

   • Validate, scope, and assess impact of alert: Check the origin / environment of the incident to validate the incident.

   • Enrich: with threat intelligence to help make quick decisions about containment. Implement an automation to query logs (such as CloudTrail) for relevant (such as API) activity performed by the alert body’s identity or resource around the time of the alert, providing additional insights.

   • Forensics: Again, using automation and having automatic documentation of this collection generated can help, in addition to storing the artifacts in read-only repositories.

   • Eradication: Based on the decision for (need of) eradication, you can automate a handful of actions such as IAM, key deletion/rotate, deleting resources. This will cut the time and limit impact.

   • Recovery: Rebuilding resources can take time, so using templates like IaC (Terraform, Azure templates, CloudFormation, etc) could help quickly rebuild safe and clean infrastructure.

4. Post-Incident Activity Phase:

   • Incident Reporting and documentation: Automate the generation of incident reports and documentation to maintain a comprehensive record of security incidents, response actions taken, and lessons learned. This documentation is invaluable for post-incident analysis and compliance purposes.

   • Metrics: To help improve IR capabilities, automate the collection of metrics such as mean time to detect, acknowledge, respond, recover, contain, etc. This can automatically be put in a post incident report.

   • IOCs: Some of the most valuable IOCs could come from within your organisation from known bad activitiy. Sort of like an internal honeypot - we know traffic on there will be bad, so collect that information, enrich, and create detections against them. Automate it.

Another perspective

Visualising your SOC processes or incident flows could help identify areas which can be automated. Taken from ISF's "Building a Successful SOC" report:

Security event to incident flow: ISF report.

AWS IR and forensics pattern

AWS have some detail and Cloudformation templates on automating IR and forensics:

Automate incident response and forensics - AWS Prescriptive GuidanceAWS Prescriptive Guidance

Automation workflow for capturing evidence for forensics

Example solution - Defender XDR

SOAR or XDR solutions already exist. Avoiding custom scripts helps with scalability and maintenance. I'll give an example of how Microsoft's Defender can automate incident response:

Automated investigation and response in Microsoft Defender XDRMicrosoftLearn

1. Alert creates an incident

2. Start an automated investigation

3. Result (verdict) in malicious, suspicious, no threat found.

4. Remediation actions for malicious or suspicious entities are identified and can be quarantined, process stopped, device isolated, URL blocked, etc. This can be automatic or approved depending on configuration.

5. Related alerts are added during investigation.

6. Signals correlated and added.