Key concepts
- Gunther Brenes
User Entity Behavior Analytics (UEBA)
UEBA is an acronym for User Entity Behavior Analytics. UEBA is a category of cybersecurity in which we look for abnormal behavior by entities. By "entity" we refer to not only users (for example, john.smith@corp.com) but also devices (for example, corp-server-1) and domains (for example, g00gle.com). UEBA typically leverages sophisticated analytics, such as statistical analyses and machine learning, in order to detect abnormal behavior.
In Devo, Behavior Analytics is an application which appears listed in your Devo UI under the Applications section of the main Devo navigation menu. Clicking on the Behavior Analytics link in the Applications menu will navigate to the Behavior Analytics landing page, which is called the Overview dashboard.
From a first glance at the Overview dashboard above, one may surmise that Devo Behavior Analytics tracks entities and assigns them risk scores. The concepts in this document help describe how this process works.
Behavior Models & Signals
One of the core concepts in Devo UEBA is the behavior model. The behavior model is essentially a piece of software which looks for some sort of abnormal behavior in your Devo data tables. You may ask, what specific behavior does it look for? That depends on the model. Each model is designed to look for one specific type of behavior. If the model detects that behavior, then it generates a behavior signal. The behavior signal is a record of the what, when, and who: what behavior was detected, when did the detection occur, and who were the entities involved (for example, the user, device and/or domain). Each behavior signal also has a risk score from zero to 100.
In Devo, there is one behavior model per behavior. Devo supports dozens of behavior models out of the box. The behavior models are configurable in the Behavior Analytics UI under the Content Manager > Behavior Models page. From that page, you may choose which behavior models to enable for your data.
Internally, behavior signals are stored in the Devo table entity.behavior.signals.filtered.
Risk Calculator
The behavior signals produced by the behavior models are read by the risk calculator. The risk calculator's job is to output a list of entities with a risk score computed for each entity. The list of entities and scores is updated hourly.
Internally, the results of the risk calculator are stored in the Devo table entity.behavior.risk.events. The risk calculator’s results include a variety of information; each record includes the following:
entity: name of entity;entity_type: comma-delimited list of the field names where the entity was discovered, for exampleentity_sourceIP,entity_destinationIP(see “Alerts with Entity Info” section);total_risk: cumulative risk score for the entity; an unbounded number, for example1250(see “Entity Risk Scoring” section);global_risk: relative risk score for the entity, normalized across all entities; a number from zero to 100 (see “Entity Relative Risk” section);entity_risk: normalized risk score across entities of this entity’s type;last_risk: timestamp of the most recent signal/alert which contributed to this entity’s risk score;related: list of the names of all related entities discovered in this entity’s signals/alerts;alert_metrics_ueba: total number of observed behavior signals;alert_metrics_secops: total number of observed SecOps or miscellaneous alerts (i.e., alerts that are not behavior alerts and not risk based alerts);priority_metrics_high: total number of observed SecOps/misc alerts that were of priority "High"priority_metrics_critical: total number of observed SecOps/misc alerts that were of priority "Very High";unique_alerts: count of distinct names of triggered alerts observed;unique_techiniques: count of distinct MITRE techniques observed in the triggered alerts;unique_tactics: count of distinct MITRE tactics observed in the triggered alerts.
Past results from the risk calculator are not overwritten by newer results; instead, the records are preserved for historical analysis.
Risk Groups
Risk groups are an optional feature that can be leveraged by the risk calculator. A risk group is a configurable list of entity names (i.e., the group members) and a single risk score multiplier. If an entity is a member of a risk group, then that risk group’s multiplier will be applied to the entity’s risk score as a final step in the risk calculator.
Entity risk groups enable organizations to identify specific sets of entities and adjust their risk score based on their own organization's context. Below are some examples of ideas for entity risk groups:
VIP users: Users that are very important people to the organization such as the C-suite and administrators that have access to sensitive information or many different systems. If these users were compromised or conducting risky behavior it is imperative to look into them sooner rather than later. As a result, it is important to add risk multipliers to these users such that they bubble up to the top of the risk curve within Devo Behavior Analytics.
New, terminated and flight risk employees: Groups of users whose activities may need to be bubbled up more prominently, similar to the VIP users list.
Crown jewels: Similar to the VIP users list except that it is for assets / endpoints within the IT environment.
Noisy users / entities: Entities that are involved in many risky activities that you still want visibility into but do not want their noise overshadowing everything else going on in your organization. The list maintained here would be to reduce the risk score of these entities such that they would show up in the application but have a generally lower risk score.
Note that a given entity can only be associated with one risk score multiplier. Therefore a given entity cannot be a member of two risk groups at the same time.
Risk Groups are configurable in the Behavior Analytics UI under Content Manager > Risk Groups page.
Internally, the list of risk group names & score multipliers is stored in the Devo table entity.behavior.list.groups. The list of members for each of the groups is stored in the Devo table entity.behavior.list.members.
Alerts with Entity Info
Note that alerts are not required in order for the risk calculator to function properly. Although they are not required, alerts can optionally be used by the risk calculator as input.
If some entity has triggered one or more alerts, we would expect that the entity should be assigned some risk score to reflect those alerts. For this reason, the risk calculator will look for triggered alerts with entity info in your Devo data and include them in its calculations.
Note that risk calculator only leverages triggered alerts which have entity info. Alerts without entity info are ignored by the risk calculator. A triggered alert is said to have entity info if one (or more) of the following fields is populated in the alert’s extraData:
|
|
When the risk calculator reads the alerts, it looks for entity names only in the fields above. Entity names in other extraData fields are ignored by the risk calculator. Thus the risk calculator discovers a list of entity names from the triggered alerts, as illustrated in the example below.
Note that the entity’s type (user, device or domain) is inferred from the field in which it was found. The inference logic is summarized by this mapping below:
| Inferred Entity Type |
|---|---|
| User |
| Device |
| Domain |
The contents of a triggered alert’s extraData are determined by the LINQ query of the alert’s definition. In order to populate a field within extraData, the alert definition’s LINQ query must include a select .. as .. statement for that particular field. The example below illustrates an alert definition which uses select statements to populate three supported entity name fields within extraData: entity_sourceName, entity_sourceAccount, and entity_sourceIP.
There are certain types of alerts which are ignored by the risk calculator, namely Behavior Alerts and Risk Based Alerts. Although these alerts may contain entity info, they are still excluded from the risk calculator by design. For more details, see the sections on Behavior Alerts and Risk Based Alerts in this document.
Entity Risk Scoring
Every hour, the risk calculator generates a list of entities with risk scores. This is a multi-step process, known as entity risk scoring, which begins with the risk calculator reading the latest behavior signals, alerts, and risk group configurations.
The list of entity names is discovered from the behavior signals & the alerts with entity info triggered over the last 7 days (if any). This implies that the risk calculator will not discover an entity which was not mentioned in any of those signals & alerts. Indeed, an entity may show up one week in the Behavior Analytics UI but then not show up the next week if it does not continue to trigger signals & alerts.
Once the list of entity names is discovered, the risk calculator computes a risk score for each individual entity. In simplified terms, the calculation of each risk score uses the following logic:
For a given entity, its risk score is computed by first summing the risk scores of the entity’s signals & alerts triggered over the last 7 days. By “the entity’s signals & alerts”, we refer to the signals & alerts with entity info that mention the given entity’s name. This sum is then multiplied by the score multiplier of the entity's risk group (if any). If an entity is not a member of any risk group at the time of calculation, a default multiplier of 1 is applied.
Note that the formula above implies that an entity without any alerts can still have a non-zero risk score as long as that entity triggers some behavior signals. Similarly, an entity that does not trigger any behavior signals can still have a non-zero risk score as long as that entity triggers some alerts.
Since the risk score calculation uses a 7-day sliding window, risk scores can decay over time; that is, an entity's risk score can decrease as its alerts & signals drop out of the 7-day window, as illustrated in the example below.
Entity Relative Risk
In addition to computing risk scores, the risk calculator also computes a relative risk for each entity. An entity’s relative risk is the entity’s risk score normalized against all the entities within the organization.
As illustrated above, relative risk is computed by mapping all the entity risk scores on a linear scale with a maximum value of 100. Thus the entity with the highest risk score will have a relative risk of 100.
The purpose of the relative risk is to provide some context for an entity’s risk score. Unlike the relative risk, the risk score is an unbounded number. Therefore it’s not always obvious whether a given risk score is high or low. By inspecting the relative risk, we can better understand whether the risk score is relatively high or low compared to the other entities in the organization.
To help distinguish the relative risk from the risk score, relative risk values are typically shown in the Behavior Analytics UI as fractions with a denominator of 100 (for example, 55/100).
Behavior Signal Risk Scoring
When the risk calculator discovers behavior signals, it must sum up the risk scores for those signals. Each signal record has a risk score value from zero to 100. The value is assigned by the behavior model that generated the signal. You may configure the signal risk score for each behavior model in the Behavior Analytics UI under the Content Manager > Behavior Models page.
Alert Risk Scoring
When the risk calculator discovers triggered alerts with entity info, it must determine a risk score for each alert. By default, the risk calculator will follow an internal multi-step process to derive a meaningful risk score value. However, the process is configurable through several methods as described below.
Using a Custom Alert Risk Score
You may set a custom risk score for a given alert definition. This custom risk score will override the default logic of the risk calculator for any alerts triggered by that alert definition. To set a custom risk score, you may use a select X as risk statement in the alert definition’s LINQ query, where X is the custom risk score number from zero to 100. For example:
select 50 as risk
For convenience, you can also set a custom risk score in the Behavior Analytics UI under the Content Manager > Alert Risk Scores page. In that page you can browse a list of alert definitions. Simply open the dropdown menu next to the alert you wish to customize and click “Edit Risk Score”. You will be prompted to enter a value from 0 to 100. This will add the select X as risk statement to the alert LINQ for you.
Using the Alert Technique Risk Score
The Alert Technique Risk Score (TRS) is the out-of-the-box alert risk score framework that dictates the risk contribution of a specific alert. The TRS is determined by the Devo SciSec threat research team based on research conducted around common attack patterns for MITRE ATT&CK techniques. Through the research each technique has its technique awareness, cut vertex to other techniques, technique closeness, and technique actionability evaluated to determine the risk score. The Alert Technique Risk Score represents the default model of alert risk within Devo today and is available for all SecOps alerts out of the box. TRS is additionally modulated by the priority set with an alert to drive higher risk for what an organization says is higher priority for their environment.
To take advantage of the Alert Technique Risk Score in a custom alert, you must specify both the MITRE ATT&CK Technique ID (as mitreTechniqueId) and alert priority (as alertPriority). Both of these values are used in the risk processor to calculate risk associated with an alert. To take advantage of the out-of-the-box risk score framework you can use the example alert LINQ provided below:
select "T1548" as mitreTechniqueId
select "4" as alertPriority
Excluding an Alert from Risk Scoring
If you wish to exclude an alert from the risk calculation, add the following select statement to the alert definition’s LINQ query and it will be ignored by the risk calculator.
select “Risk” as alertType
Behavior Alerts
When a behavior model detects abnormal behavior, it generates a behavior signal. In addition, you have the option of generating an alert for each signal as well. These alerts are called behavior alerts because they are generated by the behavior models.
Behavior alerts mirror behavior signals. When behavior alerts are enabled for a behavior model, a new behavior alert is generated for each new behavior signal.
Behavior alerts are optional; they are not required in order for Behavior Analytics to function correctly. In fact, the risk calculator intentionally ignores behavior alerts. Unlike SecOps alerts and custom alerts which can server as inputs for the risk calculator, behavior alerts are not inputs for risk calculator and have no impact on risk scores. The reason for this is illustrated in the diagram below. The risk calculator already includes behavior signals in its calculations. If the risk calculator were to include behavior alerts too, then it would effectively be double-counting every signal.
If behavior alerts are excluded from risk calculation, then why are they supported? They are available for the convenience of the security analyst. Some analysts prefer to work with alerts rather than signals. For example, an analyst may use Activeboards, Case Management, custom reporting or other legacy tools which are designed to work with alerts. Additionally, alerts support properties which signals do not, such as priority, MITRE tactic & technique.
Risk Based Alerts
A risk based alert is an alert which can be triggered by changes in an entity’s risk score. For example, a risk based alert could be configured to trigger whenever a user’s risk score exceeds some given value.
Behavior Analytics supports two types of risk based alerts: threshold and rate of change.
Threshold alerts are triggered when an entity’s risk score exceeds a given value.
Rate of change alerts do not specify a fixed value; rather, they are triggered when an entity’s risk score increases by some given amount over a given number of hours.
Risk based alerts can be configured in the Behavior Analytics UI under the Content Manager > Risk Based Alert Definitions section. When you click on the “Create” button, you will be prompted to specify properties of the alert definition including its type. If you choose the “threshold” type, you will be prompted to specify the threshold. Alternatively if you choose the “rate of change” type, you will prompted to provide both the change amount and the number of hours over which the change must occur.
As with behavior alerts, risk based alerts not included as inputs to the risk calculator. They are intentionally excluded from risk calculation and have no impact on risk scores. The reason for this is illustrated in the diagram below. Risk based alerts are the result of risk scores; they are not the cause of those risk scores. If the risk based alerts then were inputted back into the risk calculator and caused risk scores to increase, then they would create a feedback loop that artificially inflates the risk scores further for no reason.