DE1.4 Entity Mapping and Alert Enrichment

2-3 hours · Module 1 · Free

Operational Objective

The Correlation Requirement: Entity mapping is what transforms an isolated alert into a correlatable data point. Without entity mapping, Sentinel cannot link a password spray alert to a subsequent suspicious sign-in alert to a suspicious inbox rule alert — even when all three involve the same user from the same IP. Entity mapping extracts Account, Host, IP, URL, File, Process, Mailbox, and CloudApplication identifiers from your query results, enabling Sentinel to automatically correlate alerts into multi-alert incidents. Skip entity mapping and every alert is an island.

Deliverable: Understanding of entity types, mapping configuration, and the impact of entity mapping on incident correlation and investigation efficiency.

⏱ Estimated completion: 25 minutes

Why entity mapping is not optional

When a scheduled rule fires, Sentinel creates an alert. That alert can include entity mappings — structured references to the accounts, hosts, IPs, and other objects involved in the detected activity. These entities serve three critical functions.

Function 1: Incident correlation. Sentinel groups alerts into incidents based on shared entities. If Alert A (password spray) maps to IP 198.51.100.12 and Alert B (suspicious sign-in) also maps to IP 198.51.100.12, Sentinel can group them into a single incident. Without entity mapping, both alerts lack IP context and Sentinel cannot correlate them — the SOC sees two separate incidents instead of one coordinated attack.

Function 2: Investigation context. When the SOC analyst opens an incident, the entity panel shows all entities involved — user accounts, devices, IP addresses, URLs. The analyst clicks an entity to pivot: “show me all alerts involving this IP” or “show me all sign-ins for this user in the past 24 hours.” Without entity mapping, the analyst reads the raw alert text and manually searches for related activity. Entity mapping saves minutes per investigation and prevents missed connections.

Function 3: Automated response. Automation rules and playbooks can act on entities — “if this alert contains a High-severity Account entity, disable the account and revoke sessions.” Without entity mapping, the automation rule cannot identify which account to disable. The response must be manual.

Figure DE1.4 — Entity mapping transforms raw query fields into correlatable entities. Shared entities across multiple alerts enable Sentinel to group alerts into multi-alert incidents.

Entity types

Sentinel supports eight entity types. Each type has required and optional identifier fields.

Account — the user or service principal. Map to: UserPrincipalName (preferred), AccountObjectId, or AccountName + AccountDomain. This is the most important entity for identity-based detections. Every rule that involves a user action should map the Account entity.

Host — the device or server. Map to: DeviceName, HostName, or FQDN. Critical for endpoint detections. Map when the detection involves process execution, file operations, or logon events on a specific device.

IP — the network address. Map to: IPAddress (for source IP) or DestinationIP (for destination). Map in sign-in rules (source IP of the authentication), network rules (C2 destination), and firewall rules (blocked/allowed connection).

URL — the web address. Map to: Url. Map in phishing detection (the malicious URL), web activity detection (suspicious browsing), and C2 detection (beacon URL).

File — the file involved. Map to: FileName, FileHash (SHA256 preferred), Directory. Map in malware detection, exfiltration detection (files copied), and persistence detection (files created in startup locations).

Process — the running process. Map to: ProcessId, CommandLine, ProcessName. Map in execution detection (suspicious PowerShell), credential access (LSASS access), and defense evasion (tool tampering).

Mailbox — the email mailbox. Map to: MailboxPrimaryAddress. Map in email collection detection and BEC detection.

CloudApplication — the SaaS app. Map to: AppId or AppName. Map in OAuth consent detection and cloud activity anomalies.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
// ENTITY MAPPING EXAMPLE — password spray detection
// The query must OUTPUT the fields that entity mapping references
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == "50126"
| summarize
    FailedAttempts = count(),
    DistinctUsers = dcount(UserPrincipalName),
    TargetUsers = make_set(UserPrincipalName, 10),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by IPAddress, Location
| where FailedAttempts > 20 and DistinctUsers > 5
// ENTITY MAPPING:
//   IP entity → IPAddress column
//   Account entity → cannot map from summarized set; use separate alert per user if needed
//   Alternative: extend a representative TargetUser = tostring(TargetUsers[0]) and map Account → TargetUser

NE entity mapping strategy

For Northgate Engineering, the entity mapping strategy is designed to enable cross-rule correlation across the six attack chains. Each chain involves a user (Account), at least one device (Host), at least one network address (IP), and in some cases a URL, File, or Mailbox. Mapping all relevant entities on every rule creates the maximum correlation surface.

The practical impact: when CHAIN-HARVEST fires across three rules (password spray detection, AiTM token theft detection, suspicious inbox rule detection), the shared Account entity (s.chen) and IP entity (198.51.100.45) link all three alerts into a single incident. The SOC analyst sees one incident with the complete attack story — not three unrelated incidents that happen to involve the same user.

NE entity mapping standard (applied to every rule in DE3-DE8):

Every detection rule maps at minimum:

Account — always. Every detection involves a user or service principal. Use UserPrincipalName as the identifier (more readable than ObjectId, consistent across tables).
IP — whenever the detection involves a network source. Source IP for sign-in rules, destination IP for C2 detection, both for lateral movement.
Host — whenever the detection involves a specific device. DeviceName from endpoint tables, target server name from logon events.

Additional entities mapped when present:

URL — phishing URL detection, C2 beacon URL, suspicious redirect chains.
File — malware detection, exfiltration detection (specific files copied), persistence detection (files in startup locations).
Process — execution detection (suspicious process name, command line).
Mailbox — email collection detection, BEC detection.

Production pattern: multi-entity mapping

The following query demonstrates multi-entity mapping for CHAIN-HARVEST Phase 2 detection (AiTM token theft). The query output includes fields for three entity types — all three should be mapped in the rule configuration.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// MULTI-ENTITY MAPPING EXAMPLE — AiTM Token Theft Detection
let lookback = 1h;
let interactiveSignins = SigninLogs
    | where TimeGenerated > ago(lookback)
    | where IsInteractive == true
    | where ResultType == 0  // Successful
    | project InteractiveTime = TimeGenerated, UserPrincipalName,
        InteractiveIP = IPAddress, InteractiveDevice = tostring(DeviceDetail.displayName),
        InteractiveBrowser = tostring(DeviceDetail.browser),
        SessionId = CorrelationId;
let nonInteractiveRefresh = AADNonInteractiveUserSignInLogs
    | where TimeGenerated > ago(lookback)
    | where ResultType == 0
    | project RefreshTime = TimeGenerated, UserPrincipalName,
        RefreshIP = IPAddress, RefreshDevice = tostring(DeviceDetail.displayName),
        RefreshBrowser = tostring(DeviceDetail.browser);
interactiveSignins
| join kind=inner nonInteractiveRefresh on UserPrincipalName
| where RefreshTime between (InteractiveTime .. (InteractiveTime + 30m))
| where RefreshIP != InteractiveIP  // Different IP on refresh = token stolen
| where RefreshDevice != InteractiveDevice  // Different device confirms theft
| project
    InteractiveTime, RefreshTime,
    UserPrincipalName,               // → Account entity
    InteractiveIP, RefreshIP,         // → IP entity (map RefreshIP — attacker's IP)
    InteractiveDevice, RefreshDevice, // → Host entity (map InteractiveDevice — victim's device)
    InteractiveBrowser, RefreshBrowser
// ENTITY MAPPING in Sentinel rule config:
//   Account → UserPrincipalName (identifier: UPN)
//   IP → RefreshIP (identifier: Address) — this is the attacker's IP
//   Host → InteractiveDevice (identifier: HostName) — this is the victim's device
// All three entities enable correlation with:
//   - Password spray rule (shares IP entity if spray came from same attacker IP)
//   - Inbox rule detection (shares Account entity — same compromised user)
//   - Device logon detection (shares Host entity — same victim device)

The entity mapping enables three correlation paths: by Account (links to any other alert involving s.chen), by IP (links to any other alert from 198.51.100.45), and by Host (links to any other alert involving s.chen’s laptop). If any of these entities appear in another rule’s alert, Sentinel can correlate them into the same incident.

Entity mapping and the investigation graph

Mapped entities populate the Sentinel investigation graph — the visual tool analysts use to explore relationships between entities in an incident. Without entity mapping, the investigation graph is empty. With mapping, the analyst clicks the Account entity (s.chen) and sees: all alerts involving this user across all rules, recent sign-in activity, UEBA anomaly scores, and related entities (devices she uses, IPs she connects from).

This investigation efficiency is particularly important for CHAIN-MESH, where the attacker moves across three sites. The investigation graph shows: j.morrison (Account) → Edinburgh VPN (IP) → SRV-NGE-DC01 (Host — Bristol DC) → SRV-NGE-APP01 (Host — Sheffield server). The analyst traces the lateral movement path through the entity relationships — each hop visible as a connected entity in the graph. Without entity mapping, each hop is a separate investigation requiring manual correlation.

⚠ Compliance Myth: "Entity mapping is optional — it just makes the alert look nicer"

The myth: Entity mapping is cosmetic. The alert contains the same information whether entities are mapped or not — the SOC analyst can read the raw results.

The reality: Entity mapping is structural, not cosmetic. Without it: incidents cannot correlate across rules (every alert is isolated), the investigation graph has no entities to explore, automation rules cannot act on specific accounts or hosts, and UEBA entity pages lack alert context. The practical impact: a multi-phase attack that generates 5 alerts across 5 different rules appears as 5 separate incidents instead of 1 correlated incident. The SOC analyst investigates each in isolation, potentially missing the connection between the password spray (Alert 1) and the suspicious inbox rule (Alert 5). Entity mapping is what makes multi-signal detection work operationally.

Try it yourself

Exercise: Audit entity mapping on your existing rules

Open Sentinel → Analytics → Active rules. Click on each scheduled rule and check the Entity Mapping section. How many of your rules have entity mappings configured? How many map Account? IP? Host? Rules without entity mapping cannot participate in incident correlation — they produce isolated alerts.

Check your understanding

Rule A detects password spray and maps the IP entity. Rule B detects suspicious sign-in and maps the Account entity but not the IP entity. A password spray from IP 198.51.100.45 targets s.chen, who then has a suspicious sign-in from the same IP. Will Sentinel correlate these into one incident?

Answer: Not automatically by IP. Rule A maps IP but not Account. Rule B maps Account but not IP. There is no shared entity type between the two alerts. If Rule A also mapped the target Account and Rule B also mapped the source IP, both alerts would share the Account entity (s.chen) AND the IP entity (198.51.100.45), enabling correlation. The lesson: map ALL relevant entities on every rule — Account AND IP AND Host where applicable — to maximize correlation potential across rules.

Troubleshooting: Entity mapping issues

“My entity mapping shows ‘unknown’ in the incident.” The mapped field contains a value that Sentinel cannot resolve to a known entity. For Account entities, this usually means the query outputs an ObjectId that does not match any Entra ID user. Use UserPrincipalName instead of ObjectId for readability. For Host entities, ensure the DeviceName matches the name format in Defender for Endpoint inventory.

“Entities are mapped but incidents are not correlating.” Check the alert grouping configuration (DE1.9). Even with entity mapping, alerts only correlate into incidents if the grouping strategy allows it. If grouping is set to “group alerts into a single incident by associated entities,” alerts with shared entities will correlate. If grouping is set to “group all alerts triggered by this rule into a single incident,” correlation is rule-specific, not entity-specific.

📋 Operational Artifact — Entity Mapping Specification

Rule name: ___
Entity mappings configured:
Account → query field: ___ | Identifier: [UPN / ObjectId / Name+Domain]
Host → query field: ___ | Identifier: [HostName / FQDN]
IP → query field: ___ | Identifier: [Address]
URL → query field: ___ | Identifier: [Url]
File → query field: ___ | Identifier: [Name / Hash / Directory]
Process → query field: ___ | Identifier: [ProcessId / CommandLine]
Cross-rule correlation targets: This rule should correlate with rules: ___

References used in this subsection

Course cross-references: DE1.1 (rule types), DE1.9 (alert grouping — correlation configuration), DE1.11 (rule specification template includes entity mapping), DE3-DE8 (all production rules include entity mapping)

You're reading the free modules of Detection Engineering

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts. Premium subscribers get access to all courses.

View Pricing See Full Syllabus

← DE1.3 Scheduled Rules — Frequency and Trigger Logic DE1.5 Severity Classification and MITRE ATT&CK Mapping →