User and entity behaviour analytics

Most of the rules built so far look for something specific: twenty failed sign-ins, a cleared log, a forwarding rule, a known bad address. The phishing cases of October had shown Nadia the limit of that approach. In each one, the first sign of trouble was not a known bad thing but an ordinary thing done in an unusual way: a buyer signing in from an internet provider she had never used, a store manager reading far more mail in an hour than she ever had. "I don't want a rule for every kind of unusual," Nadia said on the morning of Thursday, November 12. "I want the platform to know what usual looks like." That is what user and entity behaviour analytics (UEBA) is for.

What UEBA does

UEBA builds behavioural baselines for users, hosts, IP addresses, applications and other entities from the data in the workspace, and then flags activity that departs from those baselines. It compares an entity with its own history, such as whether this user has ever used this device, country or application before, and with its peers, the people it most resembles by group membership and other associations. The result is not an alert but enrichment: scores and flags attached to activity, which analysts use for triage and hunting, and which anomaly rules and other analytics can build on.

The feature is included with Microsoft Sentinel without a separate charge; its output is written to tables in the workspace like other data. It is enabled in the Sentinel settings for the workspace, where you choose which data sources it should analyze. Microsoft names Microsoft Entra ID, Defender for Identity and Office 365 as the key connectors to enable for UEBA, with on-premises Active Directory information available through Defender for Identity. UEBA can also use some other sources, such as other clouds' identity and audit logs, when their connectors are in place.

Scores and flags

Two scores appear in UEBA data, and they measure different things. The investigation priority score, in BehaviorAnalytics, ranges from 0 to 10, where 0 is benign and 10 highly anomalous. It is calculated for individual events in near real time, combining how anomalous the entity is with how anomalous the event is in a time series, and it is meant for quick triage. The anomaly score, in the Anomalies table, ranges from 0 to 1 and comes from machine learning models that look at behaviour over time in batches. A high investigation priority means "look at this event"; a high anomaly score means "this pattern of behaviour is unusual".

BehaviorAnalytics also carries insight flags in its UsersInsights, DevicesInsights and ActivityInsights columns, such as whether this is the first time the user has connected from this country, used this device, or performed this action, and whether the action is uncommon among the user's peers. For analysts these flags are often more useful than the score, because they say why something is unusual.

BehaviorAnalytics
| where TimeGenerated > ago(1d)
| where InvestigationPriority >= 5
| extend FirstCountry = tostring(ActivityInsights.FirstTimeUserConnectedFromCountry),
         UncommonISP = tostring(ActivityInsights.ISPUncommonlyUsedAmongPeers)
| project TimeGenerated, UserPrincipalName, ActivityType, ActionType,
          SourceIPLocation, InvestigationPriority, FirstCountry, UncommonISP
| sort by InvestigationPriority desc

Enabling UEBA at Harrow & Finch

Sunil enabled UEBA on November 11 with three sources: Microsoft Entra ID sign-in and audit logs, Defender for Identity, which brings in the on-premises Active Directory view of users and groups, and Office 365 activity. He also installed the UEBA Essentials solution from the content hub, which adds dozens of hunting queries built on the UEBA tables. Baselines need history, and UEBA's first days of output are less reliable than its later ones, so Nadia asked the team not to build any automation on UEBA scores until it had several weeks of data, planned for review in mid-December.

Enabling UEBA also changed the Defender portal. User pages gained a UEBA anomalies tag and a Top UEBA anomalies section showing the three most significant anomalies for that user over the last 30 days, with links to the queries behind them. Incident graphs offered a Go hunt option for all of a user's anomalies, and advanced hunting started to suggest joining the Anomalies table. Ama found these more useful than the tables themselves: when she opened a user's page from an incident, the anomalies were already there.

Reading the first results

By the morning of November 12, UEBA had less than a day of history and had already flagged something. A store manager at Selkirk had signed in at 06:40 with an investigation priority of 7. The insight flags said it was the first time she had connected from that internet provider and that the provider was uncommon among her peers. Ama checked the sign-in: multifactor authentication had succeeded with the Authenticator app, the device was compliant, and a quick call confirmed that the manager had a new phone on a new mobile plan. Ama closed it as benign and noted that early UEBA output would flag many changes like this until baselines settled.

events = [
    # user, investigation priority (0-10), first-time country?, uncommon among peers?
    ("r.delgado", 7, False, True),
    ("a.mendes", 3, False, False),
    ("t.marchand", 2, False, False),
    ("p.lindqvist", 8, True, True),
    ("p.lindqvist", 6, False, True),
    ("svc-reporting", 9, True, False),
    ("a.mendes", 4, False, True),
]
from collections import defaultdict
score = defaultdict(int)
reasons = defaultdict(set)
for user, prio, first_country, uncommon in events:
    if prio >= 5:
        score[user] += prio
        if first_country: reasons[user].add("first-time country")
        if uncommon: reasons[user].add("uncommon among peers")
for user in sorted(score, key=score.get, reverse=True):
    print(f"{user:<14} total priority {score[user]:>2}  {', '.join(sorted(reasons[user]))}")

p.lindqvist    total priority 14  first-time country, uncommon among peers
svc-reporting  total priority  9  first-time country
r.delgado      total priority  7  uncommon among peers

The service account in second place mattered more than its score suggested. Service accounts should behave very consistently, so any first-time country for one is suspicious. Ama checked and found that the reporting vendor had moved its integration to a data centre in another country without telling anyone. Nadia asked the vendor to confirm in writing and added the new location to a watchlist used by the rules, which lesson 10 uses again.

Anomaly rules

Anomaly detections are a kind of analytics rule built on Microsoft's machine learning models. Sentinel provides anomaly rule templates, for example for unusual sign-in patterns or unusual volumes of activity, and their results go to the Anomalies table rather than directly creating incidents. The SC-200 study guide expects candidates to configure them. An anomaly rule's thresholds and parameters can be adjusted by duplicating it and running the copy in a test mode, often called flighting, beside the original in production, then comparing the two sets of results in the Anomalies table before switching which one is live.

Because anomaly results are not incidents on their own, the SOC uses them in two ways. Hunting queries look for users with several anomalies in a short time, which is more telling than any single one. And scheduled rules can join Anomalies with specific events, for example creating an incident when a user with a high anomaly score in the last day also changes their multifactor authentication methods.

Anomalies
| where TimeGenerated > ago(1d) and AnomalyScore >= 0.8
| summarize AnomalyCount = count(), Rules = make_set(RuleName) by UserPrincipalName
| join kind=inner (
    AuditLogs
    | where TimeGenerated > ago(1d)
    | where OperationName has "security info"
    | extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
  ) on UserPrincipalName
| project UserPrincipalName, AnomalyCount, Rules, OperationName, TimeGenerated

Privacy and fairness

Behavioural analytics watches employees closely, and Nadia raised that before switching it on. UEBA uses data the company already collects for security, but it builds profiles of people's normal behaviour, which is a new use. Harrow & Finch's privacy officer, Carmen Ortiz, reviewed the change against PIPEDA's principles on limiting use to the purposes identified to employees; the company's employee privacy notice already said that sign-in and system activity is monitored for security, and the review confirmed that UEBA fell within that purpose. The review added two conditions: UEBA output would be used only for security investigations, not performance management, and access to user pages would stay limited to the SOC roles in lesson 2.

How analysts use UEBA day to day

In practice UEBA shows up in three places in the SOC's work. In triage, the user page and the BehaviorAnalytics rows answer the first question about any account in an incident: is this behaviour normal for this person? In hunting, the UEBA Essentials queries look for patterns across many users, such as several first-time countries in one department on the same day. And in rules, the Anomalies table can raise the severity of an incident or add a condition, as in the example query above. Ama's habit, which Nadia encouraged, is to open the user page for every account entity before deciding anything, because the anomalies section often settles in seconds whether an alert is worth deeper work.