This chapter covers Microsoft Sentinel's Entity Behavior Scoring (EBS), a critical feature for detecting advanced threats by modeling normal behavior and scoring anomalies. On the SC-200 exam, questions on EBS typically appear under objective 2.2, 'Configure and manage Microsoft Sentinel analytics,' and can represent up to 10-15% of the analytics section. Understanding EBS is essential because it enables proactive threat hunting and reduces alert fatigue by prioritizing high-confidence behavioral anomalies over simple rule-based detections.
Jump to a section
Imagine a high-stakes poker room in a casino. The room has a sophisticated surveillance system that doesn't just record video; it analyzes player behavior in real time. Each player is assigned a baseline profile: their typical betting patterns, chip movements, and even the frequency of their glances. The system scores each player's behavior against this baseline. A player who suddenly bets huge sums after being cautious all night might trigger a high anomaly score, just as a user who accesses sensitive files at 3 AM from an unusual location would in Sentinel. The system also correlates events across players: if two players at different tables both receive a mysterious phone call and then start playing recklessly, the system links those behaviors into a combined score. The casino's security team doesn't watch every feed; they rely on the scoring engine to flag only the most suspicious patterns. This is exactly how Microsoft Sentinel's Entity Behavior Scoring works: it builds baselines, scores deviations, correlates across entities, and surfaces only the most critical anomalies for analysts to investigate.
What is Entity Behavior Scoring and Why Does It Exist?
Entity Behavior Scoring (EBS) is a machine learning-driven capability in Microsoft Sentinel that assigns a risk score to entities (users, hosts, IP addresses, applications, etc.) based on how their current behavior deviates from their historical baseline. The purpose is to detect advanced threats that evade signature-based detection, such as insider threats, compromised credentials, or lateral movement. EBS reduces alert fatigue by generating fewer, more accurate alerts that correlate multiple low-severity events into a single high-severity incident.
How EBS Works Internally
EBS operates through a pipeline of data ingestion, baseline modeling, anomaly detection, scoring, and correlation. Here's the step-by-step mechanism:
Data Ingestion: Sentinel ingests logs from various sources (Azure AD, Windows Event Logs, Syslog, etc.) into Log Analytics workspaces. EBS relies on specific data tables, primarily BehaviorAnalytics, which is populated by the UEBA (User and Entity Behavior Analytics) engine.
Baseline Modeling: For each entity, EBS builds a behavioral profile over a configurable lookback period (default 14 days, minimum 7 days). The profile includes attributes like:
- Typical logon times and locations - Accessed resources and applications - Amount of data transferred - Peer group behavior (e.g., users in the same department) - Historical anomalies
Anomaly Detection: When new data arrives, the scoring engine compares it against the baseline using statistical and ML models. It calculates an anomaly score for each attribute (e.g., logon from a new country, access to a never-before-seen app). The score ranges from 0 to 10, where 0 is normal and 10 is highly anomalous.
Scoring: The individual attribute scores are aggregated into a composite entity score using a weighted formula. The weights are determined by the ML model based on historical effectiveness. The composite score is also 0-10. Scores above a threshold (default 3) trigger an alert. The alert severity is mapped: 0-3 = Low, 3-6 = Medium, 6-8 = High, 8-10 = Critical.
Correlation: EBS correlates scores across multiple entities. For example, if a user's score spikes and they connect to a host that also has a high score, the system may create a single incident linking both entities. This correlation uses time windows (default 24 hours) and entity relationship graphs.
Key Components, Values, Defaults, and Timers
BehaviorAnalytics Table: The core table storing baseline and anomaly data. Schema includes fields like UserId, UserName, UserType, ActivityType, ActionType, SourceIPAddress, DestinationIPAddress, Devices, AnomalyScore, BaselineType, IsAdmin, IsServicePrincipal, TimeGenerated.
Lookback Period: Default 14 days, configurable via the UEBA settings in Sentinel. Minimum 7 days.
Anomaly Score Threshold for Alerting: Default 3. Can be adjusted per analytics rule.
Correlation Time Window: Default 24 hours for linking entity anomalies.
Data Retention: BehaviorAnalytics data is retained for 90 days by default, configurable up to 2 years.
Entity Types: Currently supports User, Host, IP Address, and Application (Azure AD enterprise apps).
ML Models: Microsoft uses proprietary models trained on billions of signals from Azure AD and Microsoft 365. No customer data is used for global model training.
Configuration and Verification Commands
EBS is enabled by default in Sentinel workspaces that have the UEBA feature turned on. To verify:
In the Sentinel portal, navigate to Entity behavior > Entity behavior settings.
Ensure Enable UEBA is toggled on.
Check the Data sources tab to confirm required connectors are connected (Azure AD, Windows Security Events, etc.).
To query BehaviorAnalytics data:
BehaviorAnalytics
| where TimeGenerated > ago(24h)
| where AnomalyScore > 5
| project UserName, ActivityType, AnomalyScore, SourceIPAddressTo list entities with high scores:
BehaviorAnalytics
| summarize AvgScore = avg(AnomalyScore) by UserName
| where AvgScore > 3
| order by AvgScore descInteraction with Related Technologies
EBS is closely integrated with:
- UEBA: The underlying engine that generates BehaviorAnalytics data. EBS is essentially the scoring layer on top of UEBA.
- Analytics Rules: EBS can be used as a data source in custom analytics rules. For example, a rule can trigger when BehaviorAnalytics | where AnomalyScore > 7.
- Incident Creation: High-scoring anomalies automatically generate incidents in Sentinel, which can be triaged in the incidents queue.
- Threat Intelligence: EBS can incorporate threat intelligence feeds to boost scores for entities associated with known malicious IPs or domains.
- Playbooks: EBS incidents can trigger automated playbooks (e.g., disabling a user account when score > 8).
Performance Considerations
EBS processing is near real-time, with a latency of 5-10 minutes from log ingestion to score update.
The number of entities is limited only by data volume; however, very large environments (millions of entities) may see slower baseline updates.
Log Analytics workspace retention and cost should be considered as BehaviorAnalytics data consumes storage.
Exam-Relevant Details
The SC-200 exam expects you to know that EBS is part of UEBA, and that UEBA must be enabled for EBS to work.
You must be able to identify the correct KQL query to retrieve anomaly scores.
Know the default threshold (3) and how severity maps to scores.
Understand that EBS is not a standalone feature; it relies on data connectors for identity and network logs.
Be aware that EBS supports user, host, IP, and application entities.
Enable UEBA in Sentinel
Navigate to Microsoft Sentinel > Entity behavior > Entity behavior settings. Toggle 'Enable UEBA' to On. This activates the machine learning models that will start building baselines for entities. The setting takes effect immediately, but baselines require at least 7 days of data to stabilize. During this period, anomaly scores may be unreliable. Ensure required data connectors (Azure AD, Windows Security Events, etc.) are connected and ingesting data.
Data Ingestion and Baseline Building
Once enabled, Sentinel begins collecting identity and activity logs into the BehaviorAnalytics table. For each entity (user, host, IP, app), the system builds a baseline over a rolling 14-day window. The baseline includes typical login times, locations, accessed resources, and peer group patterns. The model uses statistical methods like z-score and time-series decomposition to establish normal ranges. During the first 7 days, the baseline is considered 'learning' and anomaly scores may be suppressed.
Anomaly Detection and Scoring
When new log data arrives, the scoring engine compares each activity against the entity's baseline. For each attribute, an anomaly score from 0 (normal) to 10 (highly anomalous) is calculated. For example, a user logging in from a new country might get a score of 7 for location. The composite entity score is a weighted average of all attribute scores, with weights optimized by ML. Scores are updated within 5-10 minutes of data ingestion.
Correlation Across Entities
EBS correlates high-scoring entities to identify related anomalies. For instance, if a user's score spikes and they connect to a host with an elevated score, the system links them. This correlation uses entity relationship graphs and a 24-hour time window. The goal is to identify multi-step attacks like lateral movement. The correlation can create a single incident with multiple entities, reducing alert noise.
Alert Generation and Incident Creation
When the composite score exceeds the configured threshold (default 3), an alert is generated. The alert severity is determined by the score: 0-3 Low, 3-6 Medium, 6-8 High, 8-10 Critical. These alerts are automatically turned into incidents in Sentinel. Analysts can then investigate the incident, which includes a timeline of anomalous activities and linked entities. Playbooks can be triggered automatically based on score thresholds.
Enterprise Scenario 1: Insider Threat Detection
A large financial institution uses EBS to monitor for insider threats. They have 50,000 employees with access to sensitive customer data. EBS builds baselines for each user, including typical work hours, accessed applications, and data transfer volumes. One day, a finance manager's account shows a sudden spike in data export from a database they never accessed before, at 2 AM from an IP in a foreign country. EBS assigns a composite score of 9.2, generating a critical incident. The SOC team investigates and finds the account was compromised via phishing. They disable the account and initiate password reset within minutes. Without EBS, this activity might have been missed or buried among thousands of low-priority alerts. The key configuration was setting the alert threshold to 3 and enabling correlation with threat intelligence feeds to boost scores for known malicious IPs.
Enterprise Scenario 2: Lateral Movement Detection
A healthcare organization with 10,000 endpoints uses EBS to detect lateral movement. EBS correlates user and host scores. When a user with a high anomaly score (e.g., 7.5) logs into a server that also has an elevated score (e.g., 6.0), the system creates a single incident linking both. This reveals a potential attacker moving from a compromised workstation to a domain controller. The SOC can then isolate both machines. In production, they found that the default 24-hour correlation window was too long for fast-moving attacks, so they reduced it to 6 hours. They also customized the analytics rule to trigger only when both entity scores exceed 5, reducing false positives.
Common Misconfiguration Pitfalls
Insufficient data sources: If Azure AD or Windows Security Events are not connected, EBS has no identity data and scores are meaningless. Always verify data connectors.
Short lookback period: Setting the lookback to less than 7 days results in unstable baselines and high false positive rates. Stick to the default 14 days.
Ignoring threshold tuning: The default threshold of 3 may generate too many alerts in large environments. Tune it based on historical data; e.g., raise to 5 if alerts are overwhelming.
Not integrating with threat intelligence: Without threat intel, EBS cannot boost scores for known malicious entities. Enable threat intel connectors to improve detection.
SC-200 Exam Focus on Entity Behavior Scoring
The SC-200 exam tests EBS under objective 2.2, 'Configure and manage Microsoft Sentinel analytics,' with a focus on understanding how EBS works, its prerequisites, and how to interpret its output. Expect 2-3 questions on this topic, typically in the form of scenario-based multiple choice or KQL query interpretation.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong answer: 'EBS is a standalone feature that does not require UEBA.' Candidates think EBS is independent because it appears in the Sentinel menu. In reality, EBS is a component of UEBA; UEBA must be enabled. The correct answer always mentions UEBA as a prerequisite.
2. Wrong answer: 'The default anomaly threshold is 5.' Candidates confuse the threshold with the severity mapping. The default threshold for alerting is 3. Severity levels are: 0-3 Low, 3-6 Medium, 6-8 High, 8-10 Critical. Remember: threshold 3.
3. Wrong answer: 'EBS analyzes only user entities.' Candidates forget that EBS supports hosts, IPs, and applications. The exam may test that EBS analyzes user, host, IP, and application entities.
4. Wrong answer: 'Baselines are built over 30 days.' The default lookback is 14 days, not 30. Minimum is 7 days. The exam often uses 14 as a distractor.
Specific Numbers, Values, and Terms That Appear Verbatim
Default lookback period: 14 days
Minimum lookback: 7 days
Anomaly score range: 0-10
Default alert threshold: 3
Correlation time window: 24 hours
Data retention: 90 days (BehaviorAnalytics table)
Entity types: User, Host, IP Address, Application
KQL table name: BehaviorAnalytics
Severity mapping: 0-3 Low, 3-6 Medium, 6-8 High, 8-10 Critical
Edge Cases and Exceptions
Service Principals: EBS can analyze service principal behavior, but the baseline may be less reliable due to non-human patterns.
New entities: Entities with less than 7 days of data have no baseline; EBS may suppress scoring or use peer group baseline.
Data gaps: If no data is ingested for an entity for more than 7 days, the baseline expires and must be rebuilt.
Multiple identities: If a user has multiple UPNs (e.g., on-prem and cloud), EBS may treat them as separate entities unless linked via Azure AD Connect.
How to Eliminate Wrong Answers
If an answer says EBS does not require UEBA, it's wrong. UEBA is mandatory.
If an answer mentions a threshold of 5 for alerting, it's wrong; it's 3.
If an answer limits entities to users only, it's wrong; includes hosts, IPs, apps.
If an answer says baselines are 30 days, it's wrong; 14 days default.
If an answer says EBS uses only statistical methods, it's partially wrong; it uses ML models as well.
Always cross-check with the BehaviorAnalytics table and remember that EBS is a scoring layer on top of UEBA.
EBS requires UEBA to be enabled in Sentinel.
Default lookback period for baselines is 14 days; minimum is 7 days.
Anomaly scores range from 0 to 10; default alert threshold is 3.
Severity mapping: 0-3 Low, 3-6 Medium, 6-8 High, 8-10 Critical.
EBS supports User, Host, IP Address, and Application entities.
Correlation time window between entities is 24 hours by default.
BehaviorAnalytics table stores all EBS data; retention is 90 days.
EBS is not a standalone feature; it relies on data connectors for identity and network logs.
These come up on the exam all the time. Here's how to tell them apart.
Entity Behavior Scoring (EBS)
Uses machine learning to detect unknown threats
Builds baselines automatically over 14 days
Generates fewer, higher-quality alerts
Correlates anomalies across multiple entities
Supports user, host, IP, and application entities
Custom Analytics Rules
Based on explicit query logic (KQL)
Requires manual tuning and maintenance
Can generate many false positives if not tuned
Does not correlate across entities by default
Can analyze any log data, not limited to behavior
Mistake
EBS works without UEBA enabled.
Correct
EBS is a feature of UEBA (User and Entity Behavior Analytics). UEBA must be enabled in Sentinel's Entity behavior settings for EBS to function. Without UEBA, the BehaviorAnalytics table is not populated.
Mistake
The default anomaly score threshold for alerting is 5.
Correct
The default threshold is 3. Scores above 3 generate alerts. The severity mapping is: 0-3 Low, 3-6 Medium, 6-8 High, 8-10 Critical. A threshold of 5 would miss many medium-severity anomalies.
Mistake
EBS analyzes only user entities.
Correct
EBS supports four entity types: User, Host, IP Address, and Application (Azure AD enterprise apps). The exam may test that all four are analyzed.
Mistake
Baselines are built over a 30-day lookback period.
Correct
The default lookback period is 14 days, with a minimum of 7 days. This is configurable in UEBA settings. 30 days is not a standard value.
Mistake
EBS uses only rule-based detection, not machine learning.
Correct
EBS uses both statistical methods (e.g., z-score) and machine learning models trained on billions of signals. It is not purely rule-based.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
EBS is enabled by default when you turn on UEBA. Go to Microsoft Sentinel > Entity behavior > Entity behavior settings and toggle 'Enable UEBA' to On. Ensure required data connectors (Azure AD, Windows Security Events) are connected. Baselines will start building, but it takes at least 7 days for stable scoring.
UEBA (User and Entity Behavior Analytics) is the underlying engine that collects data, builds baselines, and detects anomalies. EBS (Entity Behavior Scoring) is the scoring layer that assigns a numeric score (0-10) to each entity based on UEBA's anomaly detection. In short, UEBA does the analysis; EBS provides the score. Both are part of the same feature set.
Yes. In the analytics rule that uses EBS (e.g., 'Entity Behavior Anomaly Detection'), you can adjust the threshold for alerting. The default is 3. You can also create custom analytics rules that query BehaviorAnalytics and set your own threshold in KQL.
EBS requires identity logs (Azure AD sign-ins, audit logs) and security events (Windows Security Events, Syslog) to build baselines. Without these, the BehaviorAnalytics table will have limited data. Recommended sources include Azure AD, Windows Event Logs, and Microsoft 365 Defender.
Baselines require at least 7 days of data to become stable. During the first 7 days, the system is in 'learning' mode and scores may be suppressed or unreliable. After 14 days (the default lookback), scores are typically accurate.
Yes, EBS supports Application entities, which include service principals. However, baselines for service principals may be less reliable due to non-human patterns. It is best to use EBS for user entities primarily, but application anomalies are also detected.
The default retention period is 90 days. This can be extended up to 2 years in the Log Analytics workspace settings. Note that longer retention increases storage costs.
You've just covered Sentinel Entity Behaviour Scoring — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?