The most common complaint from modern Incident Response teams is the volume of alerts that they receive. Alert Fatigue is a well-documented problem, and automation is here to help with that! But before we can even begin to address this, we must overcome a more fundamental issue.
Alerts can come from many different sources - SIEM, EDR, Abuse Inbox, and more besides. Many of these tools will, by default, send a notification email to a shared mailbox which is manually picked up by the IR team. But email is not an incident management platform!
Automatically creating cases in a centralized Case Management System will be the first step to reclaiming the time and energy of your Incident Responders. Tines integrates seamlessly with Jira, The Hive, ServiceNow, Zendesk, Redmine, and any other case management platform with even a basic API.
In a previous blog, we looked at connecting to the CrowdStrike API through Tines. It covers the basics of how to set up an API Client in CrowdStrike Falcon, create an OAuth Credential in Tines, and connect to CrowdStrike for the first time using a Tines HTTP Request Action.
Here, we will extend this and build a Story that will connect to CrowdStrike, read new detections, and create a Jira ticket for each detection. We’ll also drift into the world of response actions, allowing analysts to contain the user’s device in CrowdStrike at the click of a button.
Permissions
As always, with APIs, it’s best to limit the scope of your client as much as possible. It should only be granted the minimum permissions necessary to carry out the required tasks. For our purposes, we will need the following permissions:
Detections
Read - This will allow the API Client to read in new detections from Falcon.
Write - This will allow Tines to update the detection from ‘New’ to ‘In Progress.’
Hosts
Read - This can be considered optional in this case but may be useful for getting additional context on the device, such as the last updated time, OS version, type, etc.
Write - This is required to contain the device in CrowdStrike and isolate it from the network.
Handling CrowdStrike Alerts in Tines
This Tines Story will pick up where the previous blog left off. Detections are periodically being read from CrowdStrike, and with just a few simple Actions, these alerts will be sent to Jira in the form of nicely formatted, customized incidents.
Using the Tines Actions above will carry out the following valuable steps:
Get all new detections from CrowdStrike Falcon.
Mark these detections as ‘In Progress’ within the Falcon platform.
Get the full detection details - this will include the host and process information that the analyst will need to see.
So far, we’ve been working with multiple detections at once. In 'Explode' mode, the Event Transformation Action will allow us to handle each detection individually rather than as a collection.
Each detection from CrowdStrike will create a new case in Jira.
Optionally, the analyst can ‘Contain’ the host in CrowdStrike from within the Jira ticket. Catch Prompt Response will identify that request, and ‘Contain Device’ in Falcon will run that command via the API.
Formatting Jira
Tines interacts directly with the Jira API, which supports the use of Jira’s markdown syntax. This can be used to structure your incident data however you’d like. The below image shows a sample of what Jira formatting will look like in Tines.
And once the Jira ticket has been created, it will be presented as:
This can be customized to suit what’s important to you and your team, but here we’re highlighting things like:
Alert Priority
Hostname
OS
IP Addresses
Host ID - Using Jira’s hyperlink format, we’re making this clickable to jump right to the device in Falcon
These will give incident response analysts a place to start for each alert - they will at least know which machine is involved and can start digging in. We’re also including a link that, if clicked, will go back into Tines and contain that device in CrowdStrike.
But the real value of CrowdStrike alerts is going to come through its ‘behaviors’. Every detection will contain at least one behavior. They provide more granular details on the events that occurred on the host at the process level. Here’s what a sample behavior looks like for a Falcon test detection:
The important items are going to jump out to a SOC analyst. Things like the command line arguments, process hash, and parent process information are exactly what the analyst will need to make a decision. We aim to enable them to make that decision quicker by providing more information upfront.
For this Story, we will start enriching the Jira ticket with some context about the processes that are running. Even something as simple as searching for the hash in VirusTotal can help make some quick decisions for any security team. So let’s do that!
Each detection has at least one behavior but can have more. These behaviors come through from CrowdStrike as a collection - so in Tines, we will break this down into individual events so that each one can be analyzed independently. We can do this using another Event Transform Action in 'Explode' mode.
Next, let’s take a look at VirusTotal. Each behavior will have the hash of the running process; we can search for this in VirusTotal and get an idea of whether it’s a known bad. A Tines template named “Search for File Hash in VirusTotal” is preconfigured for this query.
Here you can see the configuration of that template. It runs against the VirusTotal ‘files’ endpoint to attempt to find that file. The only change that has been made to the template is to update the path to the sha256 hash in the URL; it’s now directed to the sha256 of that process in question.
The VirusTotal API key is stored in the Tines Credential Store so that the secret doesn’t need to be visible and can be referenced using the ‘{{.CREDENTIAL.virustotal}}’ tag. In this case, the API key is stored as a Text Credential rather than the OAuth credential type used for CrowdStrike earlier.
This Action includes the ‘retry_on_status’ field, which contains a 429 response code. Request rate-limiting on the VirusTotal API can be quite strict - allowing a maximum of four requests per minute and 500 per day for the public API. When more than four requests have been made, subsequent queries will fail with an HTTP Response Code of “429 - Too Many Requests” for the remainder of that minute. Retry On Status will monitor for the 429 response, and if received, Tines will automatically enter a retry loop and run the query again a short time later, retrying up to 25 times over about three-and-a-half hours.
We should repeat this process for the parent process hash, too; it could help determine the severity of this issue.
The results from VirusTotal will contain some helpful information. Here’s the analysis from a known-bad file. It’s been classified as malicious by 61 AV vendors and flagged as a potential KeyLogger.
With this helpful context, we should update the Jira ticket to include this information. Again, we will construct this using Jira’s markdown syntax.
It looks like a lot of information, and it is! But we’re building a simple table in Jira line by line, including the information we want from both CrowdStrike and VirusTotal. For some added fun, this will add some direct links to the processes in CrowdStrike Falcon and the results in VirusTotal. The result is this nicely formatted table in the form of a comment to our original Jira ticket.
Now, each CrowdStrike alert will end up as a created ticket in a Jira queue, ready for review. With some extra elements, like enriching the incident with VirusTotal context on the processes involved and allowing the analyst to respond and contain from within the Jira ticket, we’re well on the way towards automating away the repetitive actions.
What's next?
The possibilities are wide open on what to do next.
More enrichment, maybe? Querying your Threat Intel Platform, SIEM, or some OSINT sources for any IOC values found will give responders more relevant information to work with.
How about some additional response actions? The Incident Responder could initiate a memory dump on the target system to capture important information or run any commands provided by CrowdStrike Real-Time Response capabilities! The host could even be auto-contained if VirusTotal indicates a high level of confidence that the file is malicious or if it is a CrowdStrike Overwatch detection.
How to get started!
You can begin your Tines journey from within the CrowdStrike Store. Within minutes, you can be set up and building in your own Tines tenant, including some prebuilt Stories ready to run.
Visit our Story Library to access more pre-built CrowdStrike Stories.