ThreatLink
- Borja Moro Moreno
About ThreatLink
Alert triage is a complex and time consuming problem for SOCs to solve because analysts examine an overwhelming number of alerts without proper aggregation and correlation, which rapidly contributes to alert fatigue and burns out analysts.
ThreatLink is an alert triage playbook that automatically groups an organization's alerts into cases, thus drastically reducing the organization’s workload. Its case correlation capability encompasses an algorithm that reduces SOC Triage work:
ThreatLink ingests all of your enabled SecOps Alerts directly from your Devo instance (see minimum requirements in the Connecting section below).
Using graph theory ThreatLink correlates by similar entities and further stitches together related alerts
When a grouping of alerts builds up enough risk, ThreatLink creates a case that includes all relevant alerts correlated by entities and visualizations including a timeline & the graph of the case.
How does Threatlink work?
Gather alerts - ThreatLink starts by reading all of your organization’s Devo alerts into the playbook every 15 minutes or less, based on stream parameters.
Extract alert entity data - If an alert does match with an existing case, its entities are extracted from the alert. If it does not match then a new case is created.
Link with existing cases - Once the alerts from the last 15 minutes are retrieved, the alerts are cross-referenced with the existing cases from the last 7 days (customizable number). If a match is found then the alert is added to the existing case.
Build new case - With all of the alert data parsed and normalized, the alerts are then correlated with each other through the explicit matching of the alert entities. All of the data from each of the alerts is organized into a human-readable format that is displayed within the case template.
The explicit matching of the entities between alerts is done by taking the hash of all the entities within an alert and then comparing that hash to all the alerts currently tracked by the playbook and the ones recently fetched. If there is a match for all the entity values for a set of alerts then a case is created with that set of alerts. If there is no set and no previous cases were created, then a case with just that single alert is created.
How does it work on Devo
ThreatLink pulls directly from your siem.logtrust.alert.info Devo table and inserts them into the Devo SOAR platform for analysis. This table contains all of the fired alerts from the Devo platform in a single location.
After alerts are ingested, the past 60 minutes worth of alerts are analyzed every 15 minutes, on a continuous basis. With this pattern, all alerts will be analyzed up to 4 times.
Once an alert is escalated to a case, the alert is removed from the analysis to reduce duplication. Any alert that does not make it to a case after 4 interactions of analysis can be considered closed.
How does it correlate?
Most conventional correlation systems only group by a single asset at a time (e.g. all of user1 alerts). However, many attacks are more complex that tend to span across many assets. Connecting related alerts using graph theory allows analysts to see more of the picture without needing to chase down related alerts.
ThreatLink uses a combination of grouping by similar fields as well graph theory to correlate alerts together. For example, given the following alerts:
Alert ID | Source Username | Source IP Address |
|---|---|---|
alert-1 | alice | 10.0.0.1 |
alert-2 | bob | 10.0.0.1 |
alert-3 | bob | 10.0.0.5 |
alert-4 | charlie | 10.0.0.5 |
alert-5 | charlie | 10.0.0.10 |
alert-6 | charlie | 10.0.0.1 |
A common step for an analyst looking at the series of alerts above would be to perform an alert propagation analysis. For example, an analysts might look at our first alert and ask:
Did anything else suspicious happen in or around this time involving alice?
Did anything else suspicious happen in or around this time involving 10.0.0.1?
We can use graph theory to group the alerts as shown in the picture below. ThreatLink saves time as it pre-compiles all assets related graphically to each other giving the analyst a big head start in their investigation.
Connecting ThreatLink with Devo SOAR
Currently, ThreatLink is installed by Devo on behalf of the customer please contact your Devo Account Manager or Technical Project Manager for assistance.
Minimum alert requirements
A minimum of 100 SecOps alerts that include mapping of the following fields within the alert extraData is required to get value from ThreatLink:
entity_sourceIP
entity_sourceAccount
entity_sourceName
Client
Entity mapping
The entity mapping is defined by adding lines such as this one to each alert:select sourceIPAddress as entity_sourceIP
Customization to improve correlation
Case Triggers - ThreatLink has a default threshold condition under which it escalates a set of alerts to a case. These threshold conditions such as number of assets and aggregate alert priority can be tuned for an organization to increase or decrease the number of cases created.
Currently there are only two case triggers; thresholds which decide whether a grouping of alerts has a case created or not. These can be modified in the Custom ListCase_Creator_Variables. As Devo continues to research and validate more case triggers, their settings will also be modifiable in the same list.Number of assets in the graph → the default number required is 4 or more.
Max Alert Priority → the maximum alertPriority of all the alerts in the potential case.
Whitelisting - ThreatLink correlates based on entities within the alerting data, these entities may be well known, test account, internal scanner, etc. Whitelisting enables customers to exclude these well known entities from case creation, as they can lead to an increase in non-actionable cases.
The nextgen_whitelist_rules_v2 allows you to apply whitelisting rules against the alerts for any field in the additional_data field. Each line may only contain one evaluation (e.g. alert_name = SecOpsFailedLogin), however, if you need multiple evaluations, you can use multiple rows and assign the same Rule_ID. All rules associated with a Rule_ID must be true for the rule to successfully suppress an alert. In other words, all rules within the same Rule_ID will be combined with an AND operator.To create a rule you will need the following fields:
RULE_ID - An ID for your rule.
FEATURE - Key within the additional_data json blob you wish to evaluate.
OPERATOR - Operator used in the evaluation (>,<, =, regex).
VALUE - Value within your evaluation.
EXPIRY_DATE_UTC (optional) - Date in human readable format. There is no function that uses this field, but it can be helpful to quickly interpret the list.
EXPIRY_DATE_EPOCH - Date in epoch time in seconds indicating when the alert will expire. This field is used during alert evaluation and will suppress alerts within the suppression window.
DATE_ADDED (optional) - Date in human readable format. There is no function that uses this field, but it can be helpful to quickly interpret the list.
COMMENT (optional) - comment for your rule. Often a short description of why you are creating this rule along with a date is helpful for giving context.
High Value Targets (HVT) - Maintains a list of important entities within an organization and increases their risk score, which increases the sensitivity that cases will be created if alerts occur on these entities.
The High Value Targets lists allows you to identify your high risk assets that need to be monitored with more scrutiny. To manage assets, locate the Custom ListHigh_Value_Targets. This list has the following fields:TYPE - This describes the type of asset, which can be IP, Machine, or User.
ENTITY - The name of the entity as it would appear in the alert (e.g. source ID, username etc.).
ENABLED - This will turn an HVT entry on or off, allowing you to keep a list intact if you need to disable an entry. This value can be True or False.
RISK_SCORE - This allows you to score the HVT entry 0-10, where 10 is the highest risk. This allows you to implement your HVT list on a more granular scale, as not all HVT assets need to be assessed at the same risk level.
ThreatLink output
The output of ThreatLink is the creation of a case that an analyst can triage, investigate, and respond to if necessary. It takes the information from the alerts that have been correlated into a single case, which contains a set of information tailored to make each case actionable. The information provided in each case is divided into the following sections:
Left section
On the left pane, the Summary is divided into Who, What, When, Why and Why not sections. This will include all assets in the graph, key details in the alerts that may aid with the investigation, all alerts that contributed to the case as well as a detailed list of which triggers were triggered and which were not.
There is also a series of other tabs that can be accessed, some of them specially relevant here:
The Linked Alerts section will allow the analyst to see a list of the alerts that contributed to the case, along with a drill down of the information within each alert.
The History section gives the team a detailed audit trail of actions and modifications performed in the case.
Right section
On the top right section, there is a case Workflow including priority, and drop down boxes allowing the analysts to track their progress, reassign the case and ultimately close with resolution. You can also use Additional Fields and Extracted Fields if needed, which contain the entity correlation hash and the extracted entity fields respectively.
Below that section, you can find the Task section. There are several automated tasks including one-click actions for visualizations and intrusive remediations as well as no-touch automations that run on case creation, typically reserved for enrichment functions. You can click the “Run” button to start the automation, and track its state in the status box on the right.
The Alerts Timeline and the Netxgraph are the case valuation. Once these tasks complete, they are attached to the case. You can open them on the Left pane, navigating to the Attachment section.
The Alerts Timeline will allow an analyst to visualize the alerts to help them get an idea of how this potential compromise occurred and the order the event took place. On the Y axis, each asset gets its own horizontal line, which adds additional context as to which alerts were set off at a given time involving which assets.
The Netxgraph task will visualize the case correlation that formed the case. Each edge (line between two assets) represents 1 to many alerts in which both assets were involved. Hovering over an edge will display all the alerts that are shared between two assets. Hovering over an asset will display all the alerts involved just that particular asset.
The bottom section is reserved for analyst comments and one-off commands.