3.3.2. Microsoft Sentinel Incidents
💡 First Principle: Sentinel incidents come from analytics rules over workspace data: firewalls, Linux servers, cloud platforms, custom applications. Investigating them follows the same story-building process as Defender XDR incidents, but the evidence lives in Sentinel tables, and the richest context comes from entity pages and behavior analytics built from that data.
In the Defender portal, Sentinel alerts are correlated by Defender XDR into the same incidents as other signals, so many incidents mix Sentinel and Defender alerts. The incident's alerts, entities, and evidence come from the analytics rule's entity mapping (2.5.2): poor mapping means thin incidents. Key investigation tools:
- Entity pages for accounts, hosts, and IPs gather alerts, activities, and timelines across all data sources; UEBA (User and Entity Behavior Analytics) adds behavioral insights and anomalies, such as first-time access to a resource or unusual volume.
- Advanced hunting queries Sentinel tables alongside Defender tables; you can pivot from an entity into queries over
SigninLogs,CommonSecurityLog,Syslog, or custom tables. - Investigation graph and the incident's attack story show relationships between entities and alerts.
- Incident tasks (added by automation rules or manually) provide a checklist for the response.
- Playbooks can be run manually on the incident or its entities (2.6.2), for example to enrich an IP or block it on a firewall.
Synchronization is bidirectional: status, owner, and the closing reason sync both ways, with status and classification mapped between the two platforms' schemas; severity, title, description, tags, and new comments also flow across. Closing an incident in one view closes it in the other. Automation rules triggered on incident updates see these changes (in batches after onboarding, 2.6.1).
When Sentinel detects a threat on an asset Defender XDR manages, response crosses back over: a Sentinel firewall alert implicating a device leads to Defender for Endpoint isolation; one implicating a user leads to Entra ID session revocation. When the asset is outside Microsoft's products, playbooks carry the response to the third-party system.
⚠️ Exam Trap: "An incident from a Sentinel analytics rule shows no entities, so the analyst can't pivot to the user" points to missing entity mapping in the rule, not missing data. Fix the rule; the next incidents will carry entities.
Reflection Question: Why does good entity mapping in an analytics rule matter more for investigation speed than a well-written alert description?
