Sentinel Entity Mapping and Investigation Graph

Entity mapping is the process by which Microsoft Sentinel extracts structured entities—such as user accounts, IP addresses, hosts, and file hashes—from unstructured or semi-structured log data and normalizes them into a common schema. This allows the platform to automatically link related events that share the same entity, enabling the Investigation Graph to display a unified relationship map. Without entity mapping, an analyst would need to manually correlate data across different tables and time ranges, a tedious and error-prone process.

Sentinel ingests data from multiple sources: Azure AD logs, Windows Security Events, Azure Activity logs, third-party firewalls, and more. Each source has its own schema. For example, a Windows Security Event 4624 (successful logon) contains fields like TargetUserName, IpAddress, and WorkstationName. A firewall log might contain src_ip, dst_ip, and user. Sentinel uses built-in parsers (functions that normalize data) to map these disparate fields into a standard set of entity types defined in the Azure Sentinel entity schema.

The entity types include: - Account: Represents a user or service account. Key identifiers: AccountSid, AccountUPN, AccountName, AccountDomain. - Host: Represents a device. Key identifiers: HostName, DnsDomain, AzureID, OMSAgentID. - IP: Represents an IP address (IPv4 or IPv6). Identifier: Address. - URL: Represents a URL. Identifier: Url. - FileHash: Represents a file hash. Identifier: Algorithm (e.g., SHA256) and Value. - Process: Represents a running process. Identifiers: ProcessId, CommandLine, ImageFile. - Malware: Represents a malware entity (often from threat intel). - Mailbox: Represents an Exchange mailbox. - MailMessage: Represents an email message. - SubmissionMail: Represents an email submission.

When an alert is triggered (either from a built-in analytics rule or a custom rule), Sentinel automatically extracts entities from the alert's results. For example, if a rule detects multiple failed logons from an IP, Sentinel extracts the Account and IP entities. These entities are then stored in the SecurityAlert table (or SecurityIncident table for incidents) under the Entities column, which is a JSON array of entity objects.

The Investigation Graph is a visual tool that displays entities and their relationships. It is accessible from the Sentinel incident details page. When you open an incident, click "Investigate" to launch the graph. The graph starts with the incident's root entities (those extracted from the triggering alert). From there, you can expand entities to see related alerts, other entities, and even bookmarks.

Key features of the graph: - Entity expansion: Right-click an entity (e.g., an IP) and select "Explore related alerts" to see all alerts involving that IP in the last 30 days (configurable up to 90 days). - Relationship types: Lines between entities are labeled with the relationship (e.g., "Connected to", "Contains", "Related alert"). The relationship is derived from the context in which entities appear together in an alert. - Bookmarks: You can add bookmarks to save a particular state of the graph for later reference. - Hunting integration: You can run a hunting query directly from the graph by selecting an entity and choosing "Run query".

Entity mapping is largely automatic, but you can influence it via: - Analytics rule settings: When creating a custom analytics rule, you can explicitly map fields from the query results to entity types. This is done in the "Set rule logic" step under "Entity mapping". For example, if your KQL query returns a column UserPrincipalName, you can map it to the Account entity's AccountUPN property. - Normalization parsers: You can write custom parsers using KQL functions to normalize data from custom logs into the standard entity schema.

To verify entity mapping, run a KQL query against the SecurityAlert table:

SecurityAlert
| where TimeGenerated > ago(24h)
| extend Entities = parse_json(Entities)
| mv-expand Entities
| evaluate bag_unpack(Entities)
| project TimeGenerated, AlertName, Entities_Type = tostring(Entities['Type']), Entities_Name = tostring(Entities['Name'])

This shows which entity types were extracted for each alert.

Entity mapping integrates with: - UEBA (User and Entity Behavior Analytics): UEBA uses the same entity schema to build behavioral profiles for entities (e.g., baseline of logon times, locations). Anomalies detected by UEBA are surfaced as alerts and appear in the investigation graph. - Threat Intelligence: Indicators of compromise (IOCs) from threat intelligence feeds are mapped to entity types (IP, URL, FileHash). When an alert involves an entity that matches an IOC, the graph shows a threat indicator. - Watchlists: You can import custom data (e.g., VIP users) as watchlists. These can be joined with entity data in analytics rules, but they do not automatically become graph entities unless mapped.

A large enterprise uses Sentinel to monitor Azure AD sign-ins. An analytics rule detects a user logging in from an unusual location. The alert extracts entities: Account (user@contoso.com), IP (203.0.113.5), and Host (laptop01). The incident is assigned to an analyst who opens the Investigation Graph. The analyst expands the IP entity and discovers that the same IP was used in 15 other sign-in attempts to different accounts in the last 24 hours, indicating a brute-force attack. By expanding one of those accounts, the analyst finds that the attacker successfully logged into a privileged account. The graph shows all related alerts, enabling the analyst to contain the breach quickly. In production, the organization has set the graph time range to 7 days to balance performance and coverage. They also use bookmarks to document the investigation path for compliance.

A security operations center (SOC) receives a threat intelligence feed containing SHA256 hashes of known ransomware. Sentinel automatically maps these hashes to the FileHash entity. An analytics rule triggers when a hash matches an alert from Microsoft Defender for Endpoint. The investigation graph shows the file hash node connected to the host where it was executed, the user who ran it, and the network connections made. The analyst expands the host to see all alerts involving that host, revealing that the same host also downloaded a malicious URL. The graph allows the analyst to pivot from file to host to network, identifying lateral movement. In this deployment, the SOC has configured the graph to show up to 90 days of related alerts, but they limit expansions to 50 results to avoid performance issues. They also use the "Merge" feature to combine duplicate host entities that appear due to different identifiers (AzureID vs. HostName).