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:

  1. An alert is generated by Stellar Cyber.

  2. 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.

  3. 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 that Case in over three hours

    • 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 at a steady pace and the Case is not closed by a user.

  4. Alerts with a status of Closed or Ignored are not correlated to Cases.

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

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 That Are Not Correlated to Cases

The following alerts are not correlated into cases:

  • Sensor related alerts, such as Sensor Status Anomaly.

  • Alerts where no user or asset can be found.

  • Alerts where the IP type of all associated assets are public. Only private hosts are considered as assets.

    There are exceptions to this rule for some email or cloud events in which the IP of the email sender is usually public. These exceptions have a msg_class field set to one of the following:

    • proofpoint_tap_event

    • mimecast_email_attachment_protect_log

    • mimecast_email_av_log

    • mimecast_email_impersonation_protect_log

    • mimecast_email_internal_email_protect_log

    • mimecast_email

    • mimecast_email_url_protect_log

    • aws_cloudwatch_waf

  • Some cloud alert integrations are not supported in case correlation:

    • AWS GuardDuty

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.