Study guide
Technical reference and lesson notes
Purpose of This Lesson
Microsoft Sentinel entities are one of the core concepts that help transform raw security logs into meaningful investigation context. In a SOC, it is not enough to know that an alert fired. An analyst needs to understand which user, device, IP address, URL, file, or cloud resource was involved.
Entities allow Microsoft Sentinel to identify and organize those objects so they can be used during incident triage, investigation, threat hunting, correlation, and automation.
For the SC-200 exam, this topic matters because many scenario-based questions focus on how Microsoft Sentinel connects alerts, incidents, evidence, and affected resources. Entity mapping is especially important because it determines whether Sentinel can properly associate alert data with users, hosts, IP addresses, files, and other objects during an investigation.
Key Concepts
What Are Entities in Microsoft Sentinel?
Entities are meaningful security objects extracted from log data and associated with alerts and incidents.
Instead of treating every event as isolated raw data, Sentinel identifies important fields and classifies them into known entity types. This makes investigation faster because analysts can immediately see the objects involved in suspicious activity.
Common Sentinel entity types include:
- Account
- Host
- IP address
- URL
- File
- File hash
- DNS domain
- Process
- Mailbox
- Cloud application
- Azure resource
- Malware
- Security group
In plain English, entities answer questions like:
- Who was involved?
- What device was used?
- Which IP address communicated with the environment?
- What file or hash was associated with the alert?
- Which URL or domain was contacted?
- What resource was accessed?
Entities give Sentinel a structured way to describe the important objects connected to an alert or incident.
Why Entities Matter
Entities are important because they give alerts and incidents context.
Without entities, an alert may only show raw log fields. The analyst would have to manually determine which field represents the user, which field represents the source IP, which field represents the destination host, and so on.
With entities properly mapped, Sentinel can:
- Attach users, devices, IP addresses, URLs, and files to alerts
- Correlate activity across multiple data sources
- Build incident graphs
- Support investigation timelines
- Power entity pages
- Help automation rules and playbooks act on the correct object
- Improve threat hunting pivots
- Support User and Entity Behavior Analytics, or UEBA
For a SOC analyst, entities reduce manual effort and help connect the dots faster.
Entity Mapping
Sentinel does not automatically know what every field in every log means. Entity mapping tells Sentinel which fields in a query or analytics rule represent specific entity types.
Entity mapping is configured inside Microsoft Sentinel analytics rules.
For example:
| Log Field | Entity Type |
|---|---|
| UserPrincipalName | Account |
| SourceIP | IP address |
| Computer | Host |
| FileHash | File hash |
| Url | URL |
When the analytics rule generates an alert, Sentinel uses the mapping to attach those entities to the alert. If the alert becomes part of an incident, the mapped entities become part of the incident investigation context.
This is a key SC-200 concept: analytics rules detect suspicious activity, but entity mapping makes the alert useful for investigation and correlation.
Strong and Weak Entity Identifiers
Some entity identifiers are stronger than others.
A strong identifier uniquely identifies the object. A weak identifier may be useful, but it may not be unique enough by itself.
Strong Identifier Examples
- User Principal Name, or UPN
- Security Identifier, or SID
- Azure AD object ID
- Fully qualified domain name, or FQDN
- File hash
- Resource ID
Weak Identifier Examples
- Display name
- Short username
- Hostname without domain context
- Description field
- Non-unique label
Strong identifiers are better for correlation because they reduce ambiguity.
For example, jsmith may exist in multiple domains, but jsmith@contoso.com is much more specific. A SID or object ID is even stronger because it uniquely identifies the account behind the name.
For the exam, remember that entity mapping works best when you map the strongest available identifier.
Entity Mapping Limits
When creating or modifying analytics rules, Sentinel supports mapping multiple entity types and identifiers.
Important limits from the lesson:
- An analytics rule can map up to five entity types.
- Each entity type can have up to three identifiers.
This gives analysts flexibility when designing detection rules. For example, a single rule may map an account, host, source IP, destination IP, and file hash if all of those values are relevant to the detection.
The goal is not to map every possible field. The goal is to map the fields that matter for investigation, correlation, and response.
Entities in Incident Investigation
When an incident is created in Microsoft Sentinel, entities appear as part of the incident details. Analysts can review them to quickly understand the scope of the incident.
Entities can show:
- Which account was involved
- Which device generated the activity
- Which IP address was used
- Which URL was accessed
- Which file or hash was observed
- Which resource was affected
From an incident, an analyst can pivot into an entity page for deeper investigation.
Entity Pages
An entity page provides a focused view of activity related to a specific object, such as a user, device, or IP address.
Depending on the entity type and available data, an entity page may show:
- Alerts associated with the entity
- Timeline of recent activity
- Sign-in events
- Device activity
- Related incidents
- Anomalies
- Behavior insights
- Associated entities
- Historical activity across the environment
This allows an analyst to move beyond the single alert and ask broader investigation questions.
For example:
- Has this user been involved in other incidents?
- Has this device communicated with suspicious IPs before?
- Did this IP address appear in multiple alerts?
- Is this activity isolated or part of a wider attack pattern?
Entity pages are valuable because they provide a 360-degree view of the object involved in the investigation.
Entity Graphs and Relationships
Sentinel can visualize relationships between entities. This helps analysts understand how objects are connected during an incident.
For example, an investigation may show:
- A user account signed into a device
- The device connected to an external IP address
- The IP address contacted a suspicious URL
- A file hash was observed on the device
- Another user later authenticated to the same host
This relationship view helps an analyst follow the attack path.
Entity graphs are especially useful for understanding:
- Lateral movement
- Account compromise
- Suspicious authentication patterns
- Device-to-IP communication
- Multi-stage incidents
- Related alerts across different data sources
For the SC-200 exam, remember that entities help Sentinel correlate alerts into a broader incident story.
User and Entity Behavior Analytics, or UEBA
UEBA stands for User and Entity Behavior Analytics.
UEBA analyzes normal behavior patterns for users and entities, then looks for deviations from that baseline.
Entity mapping identifies the object. UEBA helps determine whether the object’s behavior is unusual.
Examples of UEBA-style observations include:
- A user signs in from two geographically distant locations in a short period.
- A user accesses resources they do not normally access.
- A device begins communicating with unusual external IP addresses.
- An account performs activity outside its normal working pattern.
- A user begins moving laterally across hosts.
UEBA can contribute to risk scoring and help analysts prioritize investigations.
The important distinction is this:
- Entities answer: Who or what is involved?
- UEBA answers: Is this behavior normal or suspicious?
Entity mapping and UEBA work together. Entity mapping provides the object identity. UEBA adds behavioral context.
Entities and Threat Hunting
Entities are also useful during threat hunting.
When analysts write KQL queries, they often pivot around users, hosts, IP addresses, URLs, or file hashes. These are entity-driven investigation pivots.
Common hunting questions include:
- Where else has this user appeared?
- What other devices has this account authenticated to?
- Which hosts communicated with this IP address?
- Did this file hash appear on multiple endpoints?
- Has this URL been accessed by other users?
- Did the same source IP trigger multiple detections?
Entities make hunting more efficient because they provide meaningful pivots across different data sources.
Entities and Analytics Rules
Analytics rules are used to detect suspicious activity in Microsoft Sentinel.
Entity mapping inside an analytics rule ensures the alert includes the objects needed for investigation.
Without entity mapping, an alert may still fire, but it may lack the structured context needed for:
- Incident correlation
- Entity pages
- Incident graphing
- Automation
- Threat hunting pivots
- Analyst triage
A well-designed analytics rule should not only detect suspicious behavior. It should also map the correct entities so the alert is actionable.
Entities and Automation
Automation rules and playbooks can use entity values from incidents and alerts.
For example, a playbook might:
- Block an IP address
- Disable a user account
- Isolate a device
- Create a ticket
- Notify a SOC channel
- Add an indicator
- Enrich an incident with threat intelligence
The automation needs to know which object to act on. Entity mapping allows Sentinel to pass the correct IP address, user account, host, or file hash into the automated workflow.
This is why entity mapping is not just an investigation feature. It directly affects response accuracy.
Automation should always be designed carefully because acting on the wrong entity can cause business disruption.
Microsoft Security Operations Context
How Entities Fit Into a SOC Workflow
In a real SOC, entities help analysts move from raw detection to informed response.
A typical workflow may look like this:
- An analytics rule detects suspicious behavior.
- The alert is generated with mapped entities.
- Sentinel groups related alerts into an incident.
- The analyst reviews the incident entities.
- The analyst pivots into user, host, IP, or file entity pages.
- The analyst reviews the timeline and related activity.
- The analyst determines scope and impact.
- The analyst decides whether the incident is true positive, benign positive, or false positive.
- The analyst contains or escalates the incident.
- Findings are documented.
- Detection logic or automation may be improved.
Entities improve nearly every step in that process.
Triage Use Case
During triage, entities help the analyst quickly answer:
- Which account triggered the alert?
- Is the user privileged?
- Which device was involved?
- Was the IP internal or external?
- Is the URL known malicious?
- Did this entity appear in previous incidents?
- Is the activity isolated or widespread?
This helps the analyst prioritize the incident.
For example, suspicious activity involving a domain admin account usually deserves higher priority than the same activity involving a low-risk test account.
Investigation Use Case
During investigation, entities allow the analyst to pivot.
Example investigation pivots:
| Entity | Investigation Question |
|---|---|
| Account | What else has this user done recently? |
| Host | What processes, sign-ins, or network connections occurred on this device? |
| IP address | Which systems communicated with this IP? |
| URL | Which users accessed this URL? |
| File hash | Was this file seen on other devices? |
This makes entities one of the main tools for determining scope.
Containment and Remediation Use Case
Entities also support response actions.
Depending on the entity type, an analyst or automation workflow may:
- Disable or reset an account
- Revoke sessions
- Isolate an endpoint
- Block an IP address
- Block a URL or domain
- Submit a file for analysis
- Add an indicator of compromise
- Escalate to identity, endpoint, cloud, or email teams
The response action should match the entity and the confirmed risk.
For example, blocking an IP may be appropriate if the IP is confirmed malicious, but disabling a user account may be too aggressive unless there is evidence of compromise.
Exam-Relevant Takeaways
For the SC-200 exam, remember these points:
- Entities are structured objects such as accounts, hosts, IPs, URLs, and files.
- Entity mapping is configured in Microsoft Sentinel analytics rules.
- Entity mapping tells Sentinel which query fields represent which entity types.
- Strong identifiers, such as UPNs, SIDs, object IDs, and file hashes, are better than weak identifiers.
- Mapped entities appear in alerts and incidents.
- Entity pages allow analysts to investigate activity related to a specific object.
- Entity graphs show relationships between users, devices, IPs, files, and other objects.
- UEBA adds behavioral context by identifying abnormal activity.
- Entities are used for triage, investigation, hunting, automation, and response.
- Automation rules and playbooks can act on entity values.
- Poor entity mapping can make alerts harder to investigate and less useful for automation.
- Sentinel depends on properly connected data sources and well-designed analytics rules to produce useful entity context.
Tool / Feature Decision Guide
| Scenario | Best Microsoft Security Tool or Feature | Why |
|---|---|---|
| You need to tell Sentinel which field in a query is the user account | Entity mapping | Maps query fields to Sentinel entity types |
| You need to detect suspicious activity from ingested logs | Analytics rule | Analytics rules generate alerts and incidents from query logic |
| You need to investigate all activity related to a user or device | Entity page | Provides timeline, alerts, and related context for that object |
| You need to understand how users, devices, and IPs are connected in an incident | Entity graph | Shows relationships between entities |
| You need to determine whether a user’s behavior is abnormal | UEBA | Compares behavior against baselines and risk patterns |
| You need to search for where an IP, user, or host appears across logs | KQL hunting query | Lets analysts pivot across data sources |
| You need to automatically block an IP from an incident | Playbook | Can take automated response actions using entity values |
| You need to automatically assign, close, tag, or route incidents | Automation rule | Handles incident-level automation in Sentinel |
| You need alerts to include users, hosts, and IPs for correlation | Entity mapping in analytics rules | Ensures alerts carry structured investigation context |
| You need to enrich incident investigation with behavior anomalies | UEBA with entities | Adds behavioral risk context to mapped objects |
KQL Notes
The lesson did not include a full KQL query, but it did explain how entities support KQL-based investigation and hunting.
In Sentinel, KQL is often used to search for activity related to a specific entity, such as a user, host, IP address, URL, or file hash.
Example: Hunting for Activity From a Specific Account
SigninLogs
| where UserPrincipalName == "user@contoso.com"
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType, Location
| order by TimeGenerated desc
What This Query Does
SigninLogsis the table being searched.where UserPrincipalName == "user@contoso.com"filters results to one account.projectselects only the most useful columns for review.order by TimeGenerated descshows the newest activity first.
Why This Matters
If an account appears as an entity in an incident, an analyst may pivot into sign-in logs to determine whether the account performed other suspicious actions.
Example: Hunting for Activity From a Specific IP Address
SigninLogs
| where IPAddress == "203.0.113.25"
| summarize SignInCount = count() by UserPrincipalName, AppDisplayName, ResultType
| order by SignInCount desc
What This Query Does
- Searches sign-in activity from a specific IP address.
- Groups results by user, application, and result type.
- Helps identify whether the IP was used against multiple accounts.
Exam Relevance
The SC-200 exam may expect you to understand that KQL hunting queries can pivot around entities. You do not need to memorize every table, but you should understand the investigation logic:
- Start with an entity from the incident.
- Search relevant logs for that entity.
- Determine whether the activity is isolated or widespread.
- Use results to support triage and response decisions.
Common Exam Traps
Confusing Alerts and Incidents
An alert is a detection. An incident is a collection of related alerts and evidence.
Entities may be attached to alerts and then shown in the incident. Do not treat alerts and incidents as the same object.
Forgetting Entity Mapping
Analytics rules can detect activity, but entity mapping makes the alert more useful. If a scenario asks how to ensure alerts include users, hosts, or IP addresses, the answer is likely entity mapping.
Choosing UEBA Instead of Entity Mapping
UEBA does not replace entity mapping.
- Entity mapping identifies the object.
- UEBA analyzes behavior patterns for that object.
If the question asks how Sentinel knows which field is the account or IP address, choose entity mapping, not UEBA.
Using Weak Identifiers When Strong Identifiers Are Available
A username alone may be ambiguous. A UPN, SID, or object ID is stronger.
For exam scenarios, prefer strong identifiers when mapping entities.
Assuming Automation Works Without Correct Entities
Playbooks and automation rules often depend on entity values. If entity mapping is missing or incorrect, automation may not know which user, IP, or device to act on.
Treating Raw Logs as Investigation-Ready
Raw logs are useful, but entities make them actionable. Sentinel’s strength comes from correlation, enrichment, and structured investigation context.
Over-Responding Too Early
Just because an entity appears in an incident does not automatically mean it should be blocked, disabled, or isolated. Analysts still need to validate the evidence and choose a proportionate response.
Real-World SOC Analyst Notes
Entity Quality Affects Investigation Quality
Bad entity mapping creates bad investigations. If the wrong field is mapped as the account or IP address, analysts may waste time chasing the wrong object.
In production, detection engineers should validate entity mapping when building or tuning analytics rules.
Strong Identifiers Reduce False Correlation
Weak identifiers can create confusion. For example, a short hostname or username may appear in multiple places. Strong identifiers such as UPNs, SIDs, object IDs, resource IDs, and file hashes are more reliable.
Entities Help Reduce Alert Fatigue
Good entity context helps analysts triage faster. Instead of reading every raw event, analysts can quickly review the user, host, IP, URL, and file involved.
This is especially important in high-volume SOC environments.
Automation Requires Guardrails
Automation that acts on entities can be powerful, but it needs safety controls.
Examples:
- Blocking an IP may affect legitimate traffic.
- Disabling a user may interrupt business operations.
- Isolating a device may impact a critical workload.
- Closing incidents automatically may hide real threats.
Automation should be tested, documented, and reviewed through change control when appropriate.
Escalation Still Matters
Entities help determine which team should be involved.
Examples:
- Account compromise may require identity team involvement.
- Endpoint malware may require endpoint/security engineering.
- Suspicious email activity may require messaging/security operations.
- Cloud resource compromise may require cloud operations.
- Firewall or IP blocking may require network/security infrastructure teams.
Documentation Should Include Entity Context
Good incident notes should document:
- Affected accounts
- Affected devices
- Source and destination IPs
- URLs or domains
- File names and hashes
- Related alerts
- Timeline of activity
- Response actions taken
- Escalation path
- Final determination
Entities provide the structure for that documentation.
Sentinel Cost Considerations
Entities themselves are not the main cost driver. The bigger cost factor is the data being ingested into Microsoft Sentinel.
More connected data sources can improve investigation quality, but they can also increase ingestion costs. SOC teams need to balance visibility, retention, and cost.
Quick Reference Summary
- Entities are meaningful objects extracted from security data.
- Common entities include accounts, hosts, IPs, URLs, files, and hashes.
- Entity mapping is configured in analytics rules.
- Entity mapping tells Sentinel which fields represent which entity types.
- Strong identifiers are preferred because they improve correlation.
- Mapped entities appear in alerts and incidents.
- Entity pages provide deeper investigation context.
- Entity graphs show relationships between users, devices, IPs, files, and other objects.
- UEBA analyzes whether entity behavior is abnormal.
- Entities support hunting, triage, correlation, investigation, and automation.
- Playbooks and automation rules can use entity values to respond to threats.
- Poor entity mapping weakens detection quality and incident response.
Flashcards
Q: What is an entity in Microsoft Sentinel?
A: An entity is a meaningful security object, such as a user, host, IP address, URL, file, or hash, that is extracted from log data and associated with alerts or incidents.
Q: What is entity mapping?
A: Entity mapping is the process of telling Sentinel which fields in an analytics rule correspond to specific entity types.
Q: Where is entity mapping configured?
A: Entity mapping is configured in Microsoft Sentinel analytics rules.
Q: Why are entities important during incident investigation?
A: They help analysts quickly identify the users, devices, IP addresses, URLs, files, and other objects involved in the incident.
Q: What is an example of a strong account identifier?
A: A UPN, SID, or Azure AD object ID.
Q: What is an example of a weak account identifier?
A: A short username or display name.
Q: Why are strong identifiers preferred?
A: They reduce ambiguity and improve correlation across systems.
Q: What does UEBA add to entity investigation?
A: UEBA adds behavioral context by identifying abnormal activity compared to normal baselines.
Q: Does UEBA replace entity mapping?
A: No. Entity mapping identifies the object, while UEBA analyzes whether the object’s behavior is suspicious.
Q: What is an entity page used for?
A: It provides a focused investigation view of activity, alerts, timelines, and related context for a specific entity.
Q: What does an entity graph show?
A: It shows relationships between entities, such as users, hosts, IP addresses, URLs, and files involved in an incident.
Q: How do entities help automation?
A: Automation rules and playbooks can use entity values to act on the correct user, device, IP address, or file.
Q: What happens if an analytics rule has poor entity mapping?
A: Alerts may lack useful context, making investigation, correlation, and automation less effective.
Q: How can KQL hunting use entities?
A: Analysts can search logs for activity related to a specific user, host, IP address, URL, or file hash.
Q: What is the relationship between analytics rules and entities?
A: Analytics rules generate alerts, and entity mapping ensures those alerts include structured investigation objects.
Practice Questions
Question 1:
A security analyst creates a Microsoft Sentinel analytics rule that detects suspicious sign-in behavior. The alert fires correctly, but incidents do not clearly show the affected user or source IP address. What should the analyst configure?
A. UEBA settings
B. Entity mapping in the analytics rule
C. A workbook visualization
D. A watchlist
Correct Answer:
B. Entity mapping in the analytics rule
Explanation:
Entity mapping tells Sentinel which fields in the analytics rule represent entities such as accounts, hosts, and IP addresses. Without entity mapping, the alert may fire but lack useful investigation context.
Question 2:
An analyst is reviewing an incident and wants to understand all recent activity associated with a specific user account, including alerts and sign-in behavior. Which feature should the analyst use?
A. Entity page
B. Data connector
C. Log retention setting
D. Watchlist
Correct Answer:
A. Entity page
Explanation:
The entity page provides a focused view of activity related to a specific entity, such as a user, device, IP address, or file.
Question 3:
A Sentinel detection includes both a short username and a User Principal Name. Which value is generally better for entity mapping?
A. Short username
B. User Principal Name
C. Display name
D. Description field
Correct Answer:
B. User Principal Name
Explanation:
A UPN is a stronger identifier because it is more unique than a short username or display name. Strong identifiers improve correlation and reduce ambiguity.
Question 4:
A SOC wants to automatically block malicious IP addresses found in Sentinel incidents. What must be available for the playbook to act on the correct IP address?
A. A workbook filter
B. A mapped IP entity
C. A disabled analytics rule
D. A custom dashboard
Correct Answer:
B. A mapped IP entity
Explanation:
Playbooks can use entity values from incidents and alerts. If the IP address is properly mapped as an entity, the playbook can use that value in the automated response.
Question 5:
A user signs in from two geographically distant locations within a short time window. Sentinel identifies this as abnormal compared to the user’s typical behavior. Which capability is most closely related to this behavior-based detection context?
A. UEBA
B. Watchlists
C. Data connectors
D. Incident comments
Correct Answer:
A. UEBA
Explanation:
User and Entity Behavior Analytics helps identify abnormal behavior by comparing activity against normal patterns for users and entities.