Understanding Cases

Stellar Cyber leverages ML to correlate disparate alerts into coalesced Cases.

A Case represents a grouping of potentially related alerts in a single data structure. Cases provide holistic context, allowing the analyst to examine the Case and its associated alerts to assess whether the Case represents a real attack, true high-risk behavior, or event connections without security significance.

To understand why a Case's alerts are potentially related, consider the following example – a trojan alert and a traffic anomaly alert found on the same asset within an hour of one another. This could represent real malware or it could just be a coincidence. Additional related alerts and scoring will help distinguish the difference. The analyst can work with the algorithm collaboratively to apply context and investigate what is potentially threatening or risky.

Cases accelerate complex detection and response by providing a higher-level construct to analyze instead of individual alerts. Compared to the triage of individual alerts, a Case provides more context of correlated behaviors to help analysts make a more holistic evaluation during triage.

How Case Correlation Works

The Case correlation algorithm works as follows:

An alert is generated by Stellar Cyber.
The Case correlation algorithm attempts to associate the alert with a Case in real time.
1. If there is a strong connection with an existing Case, the alert is grouped and correlated with that Case. One alert can belong to multiple Cases; the algorithm attaches the alert to any Case as long as there is a strong enough connection.
2. If there is no strong connection with an existing Case, a new Case is created containing this alert. The result is a new Case with this single alert.
A Case continues to accept new correlated alerts and grow until whichever of the following happens first:
- The Case is closed by a user (Status is set to either Resolved or Cancelled)
- No new alert is associated with the case within the time window specified by the global Correlation Timeout
- The duration of a Case exceeds 30 days.
This means that the maximum duration for a Case is 30 days (the time between the first and last alerts) as long as new alerts come in more frequently than the Correlation Timeout and the Case is not closed by a user.
Alerts with a status of Closed or Ignored are not correlated to Cases.

About the Correlation Timeout

An alert can be correlated into an existing case if it occurs within a specific time window of the case. This time window is determined by Correlation Timeout, which is the amount of time that has passed after the latest alert that was correlated into the case or before the case's earliest correlated alert. The figure below illustrates how this works:

As summarized in the figure above:

A new alert is not considered for correlation if it occurs after the amount of time specified by the Correlation Timeout has passed since the last correlated alert for the case. An alert such as this has occurred too late for correlation.
A new alert is not considered for correlation if it occurs earlier than the amount of time specified by the Correlation Timeout before the earliest alert associated with the case. An alert such as this has occurred too early for correlation into the case.

The default Correlation Timeout is three hours; the maximum is 24 hours.

Refer to Setting the Correlation Timeout for details on configuring a global correlation window for your organization.

How Connection Strength Works

The connection strength between an alert and a potential Case has to do with shared entities (for example, assets or users), shared properties (for example, hashes or URLs) and time (close time windows), which are also considered to evaluate how to build strong context. The algorithm is trained on real-world attacks and data; that training is what informs the level of connection strength necessary for correlation. The algorithm continues to improve as more data is incorporated into training, thereby improving Case output as well.

Case Correlation Details

Stellar Cyber correlates both asset and user-based alerts into cases. In general, if an alert has any of the fields in the tables below populated, it is correlated into a case:

Asset-Related Fields for Case Correlation

Alerts that have any of the asset-related fields in the table below populated are correlated to cases:

Category	Fields
Asset ID	hostip_assetid srcip_assetid dstip_assetid
IP	hostip host.ip srcip dstip
Host Name	hostip_host host.name computer_name srcip_host dstip_host
Cloud Resource ID	cloud.resource.id Stellar Cyber can correlate alerts to cases based on matches in the Cloud Resource ID using data from integrations with Microsoft Defender for Cloud and AWS GuardDuty. You may see alerts correlated to cases from other cloud sources (for example, OCI CloudGuard), but those will be based on matches in other fields (IP addresses and user names, for example) rather than Cloud Resource IDs.

User-Related Fields for Case Correlation

Alerts that any of the user-related fields in the table below populated are correlated to cases:

Category	Fields
User SID	srcip_usersid hostip_usersid dstip_usersid event_data.SubjectUserSid event_data.TargetUserSid
User ID	user.id
Username	srcip_username hostip_username user.name username secondary dstip_username wineventlog_user.name event_data.SubjectUserName event_data.TargetUserName
Email	user.email

Alerts Correlated to Cases

Starting with the 5.2.0 release, Stellar Cyber creates cases for all alerts, including those without any observables. Only the following alerts are not correlated into cases:

Alerts from the Sensor index (Data Ingestion Anomaly and Sensor Status Anomaly).

In contrast to previous releases, this means that Stellar Cyber now creates single-alert cases for the following situations:

Alerts where no user or asset can be found.
Alerts from third-party cloud alert integrations, such as AWS GuardDuty.
Alerts from automated threat hunting with only raw data.

Note that you will only see single-alert cases if you change the Minimum Number of Alerts option in Global Case Settings from its default value of two to one. The single-alert cases are created regardless of how Minimum Number of Alerts is set; this option only controls whether they are displayed.

This approach ensures that users who rely on a case-driven approach to managing security events can see all alerts surfaced as cases in Stellar Cyber.

All alerts that can be correlated to cases can also be synchronized to ServiceNow via an active InSync, when configured.

Cases created for alerts without any observables may not be able to display values for all fields, including the Who field in the Case Detail display, as well as the Case Graph in the Analysis tab. If you'd prefer not to see single-alert cases, you can leave the Minimum Number of Alerts option in Global Case Settings set to two (the default) or higher. With this setting, Stellar Cyber still creates single-alert cases, but does not display them. Refer to Setting Global Case Settings for details.

Searching for Alerts Without Correlated Cases

You can use the following search in the Lucene Search bar in either the Alerts or Threat Hunting page to see alerts that have not been correlated to cases in the current time window:1

(NOT ( (_exists_:(xdr_event.name OR event_name) AND _exists_:orig_index) OR (stellar.ath.type:raw AND stellar.ath.to_incident:true))) OR xdr_event.name: (ade_outbytes_anomaly OR ade_outbytes_anomaly_flip)

Cases without Observables from Third-Party Alert Integrations

Starting with the 5.2.0 release, Stellar Cyber creates single-alert cases for alerts from third-party cloud integrations. However, with the exception of Microsoft Defender for Cloud , observables are not yet created for these cases. This includes single-alert cases based on the following integrations:

Alerts from AWS GuardDuty
Alerts based on SigmaHQ rules on AWS CloudTrail
Alerts based on SigmaHQ rules on Azure Activity Logs

In addition, Stellar Cyber correlates alerts to cases using matching Cloud Resource IDs from Microsoft Defender for Cloud and AWS GuardDuty, as described in Case Correlation Details.

Case Correlation and Manually Generated Events

Considerations for manual event generation: Due to the nature of Stellar Cyber's alert correlation and machine learning models, manually generated or ad-hoc events may not always trigger the expected alert or case creation. The Stellar Cyber platform is designed to analyze and correlate multiple events over time, assessing patterns and context to determine the severity of a potential threat. As a result, isolated or artificial events might not meet the criteria for high-severity alerts or case generation, and may not be representative of the system's full detection capabilities in real-world threat scenarios.

How Case Scores Are Calculated

Stellar Cyber assigns scores to cases based on how critical they are. A case's score updates in real time as events and entities are added to or removed from the case. This section provides details on how case scores are calculated.

In general, a case's score is determined by the number of different alert types associated with the case. A case's score typically increases with the number of different alert types associated with it.

Case scores are also affected by the fidelity and severity of the associated alerts:

Fidelity– our confidence in our analysis. The higher the Fidelity Score, the higher our confidence that we correctly observed a malicious event. If this is high, it drives the Alert Score higher. If this and the Threat Intel score are low, they reduce the Alert Score.
Severity– the importance of the category of the event. The higher the Severity Score, the more dangerous the possible consequences of the event. In general, later-stage events have a higher severity.

Score Calculation Details

Stellar Cyber begins to assign a case score by calculating an Event Score for each different alert type associated with the case. We do this by summing the maximum Alert Score, Severity, and Fidelity for all individual alerts of a given type. For example, consider the case illustrated below:

This case has only two different alert types associated with it – Private to Public Exploit Anomaly and Uncommon Application Anomaly

There is only one Private to Public Exploit Anomaly alert, so we will use the only Alert Score we have, which is 68. Similarly, we'll also use the Severity and Fidelity scores from this alert. You can't see those in the table, but you could by clicking the More Info button in the table for the alert. For example:
There are five different Uncommon Application Anomaly alerts associated with the case. As you can see in the table, the highest Alert Score across those five alerts is 33, which is the value Stellar Cyber will use to calculate the score. Similarly, we'll also take the highest Severity and Fidelity score across these five alerts.

Once we are done, we'll have separate Event Scores for both the Private to Public Exploit Anomaly and Uncommon Application Anomaly alert types. To arrive at a final score for the case,we perform the following steps:

Calculate a combined total score using the Event Scores for all alert types associated with the case. Because of this, the more different alert types that are associated with a case, the higher the score for the case will generally be.
Normalize the total score to a final score using the following equation: final_score = (total_score * total_score) / 100.0

Cases in the Stellar Cyber User Interface

Stellar Cyber reports cases in the XDR Kill Chain dashboard, as well as in the Cases interface, giving you a powerful tool to understand and respond to ongoing attacks.