Brandon Maxwell, Detection & Response Manager at Auth0, explains how Tines helps the Detection & Response team enhance their Alert Development Lifecycle.
Automation is a core tenet of the Detection & Response team at Auth0. Our goal is to automate as many of the alert processing and response tasks as possible, and we have an ‘API-first’ mentality when considering new tools or services to support our operations. You can see this first hand when we covered how we automate phishing analysis using Tines.
Besides phishing, one of the key areas where automation comes into play is throughout our Alert Development Lifecycle.
Alert development
Personally, I believe documentation is one of the most important areas of focus when it comes to alert creation. We’ve adopted Palantir’s Alerting and Detection Strategies Framework as a baseline for alert development at Auth0, which helps standardize the way we document critical considerations and responses for alerts. This includes:
Goal of the Alert
MITRE ATT&CK Categorization
Technical Context
Blind Spots & Assumptions
False Positives
Validation
Priority & Severity
Response Story
Each alert will include this important information, to help the on-call engineer understand and respond to the alert. While we try to automate the response and enrichment as much as possible, there may be steps to validate automation, or manual steps outlined in the included response playbook.
Enrichment
After the alert is developed based on logs via our SIEM or security tools, it is forwarded to our Tines platform. This is where we further enrich the alert using Send to Stories that are created for specific purposes, including looking up information on IPs, hashes, email addresses, and more across our various log sources and threat intel services.
These repeatable Send to Story Actions can be used for all of our alerts. This enables us to make better-informed decisions with full context, rather than processing or filtering the alert with limited information. There may be some data correlation involved as well, including looking up an IP address from a security event in our asset management system, and then making this information available for the engineer in the alert.
Processing & filtering
It’s important to understand how your developers and engineering teams interact with systems during their normal day-to-day operations, as a baseline of normal activity. This can help you to better process and filter out known false positives.
Certain characteristics of an alert, or information gleaned during the enrichment phase, can also dynamically impact the severity or priority of the alert, resulting in different automated response actions. We process our security events in Tines to reduce false positives before alert creation. This can save considerable time when processing a large volume of security events per day.
Once we’ve processed the event and filtered out known false positives, we generate the alert. It can then be enriched even further with other automation, or take automated response steps.
Response
Automated response actions
These are the automated response actions that we take after confirming the alert is a true positive, via filtering. This includes moving a known phishing email to quarantine automatically for all impacted users. Even though these response actions are always well tested, mistakes can happen. It’s important to document procedures or create manually invoked automations to revert the actions in the event of a false positive.
We can also take additional automated steps and further enrich our alerts with other automation projects like SecurityBot.
Securitybot
We built Auth0’s SecurityBot using Tines in just a few days. Some features include rate-limiting messages based on priority (no one wants to spam the people you work with), out of band push identity verification, and reminder messages where user input is required but missed.
We primarily use SecurityBot to interact with our co-workers to better triage alerts related to their activity and shorten the time for alert resolution. This is done in two ways:
Inquiry Messages
These messages elicit either a positive or negative response from the end-user. The user receives a Slack direct message (DM) with two interactive buttons along with a brief description of the activity we are inquiring about.
If we receive a positive response, we may trigger a push to their mobile device to verify their identity and increase our confidence in the response.
If we receive a negative response, we automatically escalate the alert and page the on-call engineer to respond.
In either scenario, the user’s response can trigger further automation stories. These can include blocking an IP address, disabling an API key, or moving an email message to quarantine based on the user’s confirmation.
Notification Messages
These messages are typically used to acknowledge a security report by a user or to notify them that some action has been taken as a result of their activity.
For example, we may acknowledge a phishing report or security review request via a notification message.
Other notable security teams like DropBox and Slack have blogged about their own projects, serving as an inspiration to our version. We’ve also blogged about this project previously in Alejandro Ortuno’s GuardDuty automation blog post.
This has been just a high-level overview of how we handle alert automation at Auth0 using Tines. Obviously, you can’t automate everything. There will be certain scenarios, especially involving insider-focused detections, that won’t be as automatable through tools like SecurityBot.
Hopefully, this has given you some ideas on ways to improve upon your own alert automation projects!
Visit the Tines Story Library to explore, download and customize more automation Stories.