A Microsoft Sentinel analytics rule fires an alert for a suspected Azure OpenAI abuse incident. The security team wants to ensure that entity information (the source IP address and the Azure OpenAI resource name) is automatically mapped and enriched in the incident so analysts can pivot to entity pages immediately. Which Sentinel analytics rule configuration enables this?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — a is correct because Microsoft Sentinel analytics rules include an 'Entity mapping' configuration section where administrators map specific KQL query output columns to Sentinel entity types (Account, IP, Host, Azure resource, URL, etc.). When an alert fires and the rule has entity mappings configured, Sentinel automatically creates enriched entity objects in the incident, allowing analysts to immediately pivot to the entity's behavior page, timeline, and related incidents.
Full explanation below image
Full Explanation
A is correct because Microsoft Sentinel analytics rules include an 'Entity mapping' configuration section where administrators map specific KQL query output columns to Sentinel entity types (Account, IP, Host, Azure resource, URL, etc.). When an alert fires and the rule has entity mappings configured, Sentinel automatically creates enriched entity objects in the incident, allowing analysts to immediately pivot to the entity's behavior page, timeline, and related incidents. B is wrong because the UEBA connector enhances entity analysis over time using behavioral baselines; it does not extract entities from individual alert fields. C is wrong because using a Logic App automation rule to extract entities is an overly complex workaround when entity mapping is a native analytics rule configuration. D is wrong because Sentinel workbooks are visualization and reporting tools; they display data about entities but do not configure entity extraction from alert rules.