Lesson 13 — Microsoft Sentinel Entity Mapping
Entity mapping turns fields returned by an analytics rule into meaningful security objects such as accounts, hosts, IP addresses, URLs and files.
When entities are mapped correctly, Microsoft Sentinel can connect related evidence, enrich incidents and display relationships inside the investigation experience.
Good entity mapping helps analysts move from a flat alert to a connected story of who, what and where was involved.
What you will learn
This lesson explains how Sentinel maps query columns to security entities and uses those entities during investigation.
Learning objectives
After completing this lesson, you should understand how entity mapping adds investigation context to Sentinel alerts and incidents.
- Explain what a Sentinel entity is.
- Recognise common entity types.
- Select useful identifiers from KQL results.
- Configure entity mappings in analytics rules.
- Understand how mapped entities appear during investigation.
The problem this solves
A query result may contain usernames, devices and IP addresses, but Sentinel cannot always understand their meaning automatically. Entity mapping tells Sentinel what each field represents.
What is an entity?
An entity is a security-relevant object involved in an alert or incident. It may represent an account, host, IP address, URL, file, process, mailbox, cloud application or another observable.
Think of entities as the characters and locations in the investigation story. The alert tells you something happened; the entities tell you who and what were involved.
How entity mapping fits into Sentinel
Common entity types
| Entity type | Typical identifiers | Example use |
|---|---|---|
| Account | UPN, account name, SID, Azure AD object ID | Identify the user or service account involved. |
| Host | Hostname, NetBIOS name, DNS domain, Azure resource ID | Connect alerts to a device or server. |
| IP | IPv4 or IPv6 address | Track source, destination or caller addresses. |
| URL | Full URL | Represent phishing links or suspicious web destinations. |
| File | File name, directory, hashes | Connect malware evidence across devices. |
| Process | Process ID, command line, host, creation time | Represent suspicious execution activity. |
Strong identifiers
Some identifiers are more precise than others. A cloud object ID or SID is usually stronger than a display name. A fully qualified hostname is usually stronger than a short device name.
Weak identifiers
Display names and short account names can be ambiguous. They may still be useful, but analysts should understand that weak identifiers can produce incomplete or misleading relationships.
KQL example
- 1
- 2
- 3
- 4
- 5
- 6
- 7
SigninLogs
| where ResultType != 0
| project TimeGenerated,
UserPrincipalName,
IPAddress,
AppDisplayName
The analytics rule can map UserPrincipalName to an Account entity and IPAddress to an IP entity.
Entity mapping in analytics rules
During analytics rule creation, select an entity type, choose the identifier and map it to the matching column returned by the KQL query.
Multiple mappings
A single analytics rule can map several entities. For example, a suspicious sign-in rule may map the user account, source IP address and cloud application.
Investigation graph
Mapped entities help Sentinel display relationships between alerts, accounts, hosts, IP addresses and other evidence in the investigation experience.
Entity pages
Entity pages can provide additional context such as related alerts, activities, bookmarks and historical behaviour associated with a user, device or IP address.
Real-world suspicious sign-in mapping
| Query column | Mapped entity | Investigation value |
|---|---|---|
| UserPrincipalName | Account | Shows the affected user and related alerts. |
| IPAddress | IP | Connects the sign-in to other activity from the same address. |
| DeviceDetail | Host, where suitable | Helps identify the endpoint associated with the activity. |
| AppDisplayName | Cloud application context | Shows which service the user attempted to access. |
Entity limits
Only map the entities that genuinely improve the investigation. Mapping every available column can create clutter and reduce clarity.
Schema consistency
Ensure the query always returns the columns used by the mappings. Renaming or removing a projected column can break the intended entity mapping.
Testing
Generate a controlled alert and confirm that entities appear correctly in the alert and incident. Check names, identifiers and relationships before enabling the rule broadly.
Common mistake
A common mistake is mapping a display name when a unique identifier is available. This can make separate accounts or devices appear to be the same entity.
Agent Foskett investigation tip
If the investigation will search by account, device and IP address, make sure those fields are returned clearly by the query and mapped using the strongest identifiers available.
Entity mapping vs custom details
Entity mapping creates recognised security objects. Custom details add useful alert fields but do not provide the same entity relationships or investigation behaviour.
Agent Foskett takeaway
Good entity mapping turns a detection into an investigation-ready alert. It connects the people, devices and infrastructure involved so analysts can follow the evidence faster.
Related Agent Foskett learning
Continue learning
Microsoft Sentinel Entity Mapping
Microsoft Sentinel entity mapping connects accounts, hosts, IP addresses, URLs, files and other evidence to analytics rule alerts and incidents.
Microsoft Sentinel Lesson 13
This Agent Foskett Microsoft Sentinel Academy lesson explains entity types, identifiers, analytics rule mappings, investigation graphs, entity pages and SOC investigation context.
