# Microsoft Sentinel Incident Investigation — Queue, Graph & Automation Source: https://ai.techclick.in/blog_microsoft_sentinel_incident_investigation Markdown: https://ai.techclick.in/blog_microsoft_sentinel_incident_investigation.md Publisher: Techclick Infosec Pvt Ltd Master Microsoft Sentinel incident investigation in 2026: incident queue, severity and status, entity pages, the investigation graph, automation rules for triage, incident tasks, and bookmark-to-incident workflow — all in one clear, interactive guide. Microsoft Sentinel Incident Investigation — Queue, Graph & Automation student learning map A visual study map for Microsoft Sentinel Incident Investigation — Queue, Graph & Automation showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Sentinel Incident Investigation — Queue,... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The incident queue — severity,... 4. Practice ② Entities & entity pages —... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most analysts think… Most people treat Microsoft Sentinel as 'an alert list you scroll through'. That misses the entire investigation layer — and costs hours per incident. Sentinel is a case management + investigation platform . The incident queue groups correlated alerts, the investigation graph draws the entity relationship map so you can see blast radius without querying, entity pages give pre-built timelines and insights on every user, host or IP, automation rules triage the easy cases before a human touches them, and incident tasks let multiple analysts divide work on a single case. Understanding the full stack is what separates a junior SOC analyst from a senior one in an interview — and in a real breach. ## ① The incident queue — severity, status and first triage The incident queue is the landing page for SOC work in Microsoft Sentinel. It shows every incident created from correlated alerts, with the most critical at the top. Each row shows the incident name, severity ( High / Medium / Low / Informational ), status ( New / Active / Closed ), owner, number of alerts, affected entities, and MITRE ATT&CK tactics. Analysts use the filter bar to narrow by severity, status, product, tactic, or assigned owner. Clicking an incident opens the incident details panel — a side pane showing a summary, the alert list, entity list, comments, tasks, and a direct link to the investigation graph. Status and severity can be changed right from the panel without navigating away. A well-disciplined SOC closes every incident with a classification: True Positive , Benign Positive , False Positive or Undetermined . These feedback signals feed Sentinel's tuning and reporting dashboards over time. Figure 1 — Incident lifecycle in Sentinel A Sentinel incident moves from New through Active to Closed, with a final classification that feeds tuning over time. - Incident lifecycle in Sentinel Alert fires analytics rule triggers Incident created correlated + queued Triage severity, owner, status Investigate graph, entities, tasks Close + classify TP / FP / Benign / TBD A Sentinel incident moves from New through Active to Closed, with a final classification that feeds tuning over time. Close with a classification every time Never close a Sentinel incident without setting the classification (True Positive, False Positive, Benign Positive, Undetermined). These labels feed Sentinel's detection-quality metrics and help you justify tuning analytics rules in a review meeting. Quick check · Q1 of 10 · Remember Which four severity levels exist for a Sentinel incident? a) Critical, High, Medium, Low b) High, Medium, Low, Informational c) P1, P2, P3, P4 d) Red, Amber, Yellow, Green Correct: b. Sentinel uses High, Medium, Low, and Informational severity labels. There is no 'Critical' label at the incident level — that is a common mix-up from other tools. 👉 So far: Incident queue = correlated alerts with severity (High/Medium/Low/Informational), status (New/Active/Closed), and a closing classification. Filter aggressively; close everything with a label. ## ② Entities & entity pages — users, hosts, IPs in context Every Sentinel alert maps its raw log fields to entities — structured objects such as accounts, hosts, IP addresses, files, processes, mailboxes and URLs. Entities are the connective tissue that lets Sentinel correlate alerts across different data sources into a single incident: two alerts from different analytics rules that mention the same user account are fused into one incident because they share an entity. Selecting any entity inside an incident opens its entity page , a three-tab view: Info (account or host properties), Timeline (all alerts and bookmarks involving this entity in the last 30 days by default), and Insights (pre-built queries that surface anomalies — off-hours logins, first-time geolocation, impossible travel, privilege escalation history). Entity pages can also be reached from the investigation graph and from the Entity Behavior menu. ### Why this matters in triage A single glance at the entity timeline tells you whether this user has appeared in two incidents this month or fifty. That context decides whether you escalate immediately or treat it as an isolated misconfiguration — without writing a single KQL query yourself. Figure 2 — Entities at the centre of an incident One user account entity can link to multiple alert types across data sources — Sentinel fuses them into a single incident. Entities at the centre of an incident User entity account object Sign-in alert Host entity IP address Malware alert Lateral move Bookmark One user account entity can link to multiple alert types across data sources — Sentinel fuses them into a single incident. 🗂️ Incident queue tap to flip The central SOC view: all correlated incidents with severity, status, owner, alert count, entity count and MITRE tactics — filterable and sortable. 🧩 Entity page tap to flip Three tabs per entity: Info (properties), Timeline (30-day activity history), and Insights (pre-built anomaly queries) — no KQL required for first-pass context. 🕸️ Investigation graph tap to flip A canvas rendering entities, alerts, and bookmarks as nodes with relationship edges — expands on click to reveal blast radius without writing a query. ⚙️ Automation rule tap to flip A trigger-and-action rule on incident creation or update: set severity, status, owner, tags, inject tasks, or fire a Logic App playbook — all before a human opens the ticket. Quick check · Q2 of 10 · Understand What does the Timeline tab on an entity page show? a) The raw JSON payload of the latest alert b) The RBAC permissions of the entity account c) A list of open incidents in the workspace d) All alerts and bookmarks involving this entity in the configured lookback window Correct: d. The Timeline tab on an entity page shows all alerts and bookmarks that reference this entity within the lookback window (default 30 days), giving historical context without writing a KQL query. 👉 So far: Entity pages give Info, Timeline, and Insights per entity — 30 days of historical context without KQL. Entities are the connective tissue that fuses multi-source alerts into one incident. ## ③ The investigation graph — visualising blast radius The investigation graph opens from the incident details panel and renders a canvas where every entity, alert, and bookmark involved in the incident is a node, with edges showing how they relate. A compromised account node might link to a host, a malicious IP, a process spawn, and a lateral movement alert — all visible at once without writing a query. Analysts can expand nodes : clicking a host node surfaces related alerts, related accounts, and related IPs from the same incident and from the entity's historical activity. This reveals the blast radius — how far the threat has spread across the environment. Each node is clickable and opens the entity page side panel without leaving the graph. Bookmarks (tagged query results) appear as nodes too. An analyst who ran a hunting query, found suspicious process execution, and saved a bookmark can see that bookmark sitting next to the alert that triggered the incident — the graph makes the causal chain visible. The investigation graph is particularly valued in interview discussions because it demonstrates understanding that Sentinel is a relationship database , not just an alert list. Figure 3 — Investigation graph layers The graph builds from raw alerts upward into entities and context, so analysts see relationships, not just rows. Investigation graph layers Bookmarks tagged hunting results as nodes Entities accounts, hosts, IPs, processes Alerts correlated analytics-rule hits Insights pre-built anomaly queries per entity The graph builds from raw alerts upward into entities and context, so analysts see relationships, not just rows. Confusing the graph with a network diagram The investigation graph shows entity relationships inside an incident (alerts, bookmarks, accounts, hosts, IPs) — not a physical network topology. Nodes represent data objects Sentinel knows about from logs, not live network devices. Expanding a node adds related entities from workspace data, not from network discovery. ### ▶ Watch a phishing alert become a closed, classified incident Step through the full investigation lifecycle. Press Play for the clean path, then Break it to see the classic automation failure. ① Alert fires An analytics rule detects a user clicking a phishing URL. Sentinel creates a High-severity incident and places it in the queue. ▼ ② Entity triage The analyst opens the incident, clicks the user entity, and reads the entity Timeline — three failed MFA attempts in the last hour confirm the account is targeted. ▼ ③ Graph expand The investigation graph shows the user linked to a suspicious external IP and a host with a recent malware alert. The analyst expands the host node and sees two more related accounts. ▼ ④ Close + classify Analyst isolates the host via the Defender playbook triggered from the incident, sets status = Closed, classification = True Positive, and adds a comment summarising the blast radius. Press Play to step through the healthy investigation path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply An analyst wants to see how far a compromised host is connected to other entities without writing a KQL query. Best action? a) Open the investigation graph and expand the host node b) Run a full workspace search in Logs c) Check the analytics rule YAML d) Export the incident to CSV Correct: a. The investigation graph lets analysts expand nodes to reveal related entities, alerts, and bookmarks visually — the fastest way to see blast radius without any KQL. 👉 So far: The investigation graph renders entities, alerts, and bookmarks as nodes. Expand a node to reveal blast radius. Bookmarks appear as graph nodes once promoted to the incident. ## ④ Automation rules, incident tasks & bookmarks Automation rules fire on incident creation or update and can: change severity, change status, assign an owner, add a tag, run a playbook, or create incident tasks — all before a human touches the incident. A classic first rule is if severity = Informational AND no High entity risk → set status = Closed (Benign Positive) . This drains the noise floor so analysts focus on real work. Incident tasks are a checklist attached to an incident. They can be created manually inside the incident or injected automatically by an automation rule. A task might read: 'Confirm host isolation in Defender' or 'Gather user manager approval'. Multi-analyst teams assign tasks to individuals; the incident shows a completed/total task count so the case manager can see progress at a glance. ### Bookmarks — raw evidence to formal case During a threat-hunting session, an analyst runs a KQL query in Logs, spots suspicious PowerShell execution, and clicks Add bookmark . The bookmark saves the row, the query, the time range, entities, and MITRE tags. From the Bookmarks blade the analyst can then Investigate (open the graph) or Add to existing incident — promoting a raw hunting find into the formal case without re-running an analytics rule. Figure 4 — Manual triage vs automation-rule triage Automation rules handle the repetitive, low-complexity incidents so analysts spend time on the true positives. Manual triage vs automation-rule triage Manual triage Analyst opens every new incident Reads alert, sets status by hand Assigns owner manually Creates tasks one by one High-volume, repetitive work Automation-rule triage Rule fires on incident creation Sets severity, status, owner, tags Injects standard task checklist Runs playbook if threshold met Analysts touch only true positives Automation rules handle the repetitive, low-complexity incidents so analysts spend time on the true positives. Divya at a Mumbai fintech SOC faces this The Sentinel incident queue has 400 open incidents, 80% rated Informational. Analysts are overwhelmed and missing real High-severity events buried in the noise. Likely cause No automation rules exist. Every incident — regardless of severity — stays open in the queue at status New until a human manually triages it. Diagnosis Open Automation ▸ Automation rules: zero rules defined. The analytics rules generating Informational incidents have no auto-close logic. High incidents are not assigned or tagged. Sentinel ▸ Automation ▸ Automation rules ▸ + Create Fix Create rule 1: IF severity = Informational AND no High-risk entity → set status = Closed, classification = Benign Positive. Create rule 2: IF severity = High → assign owner = SOC-L2 group, inject a five-task checklist, add tag PRIORITY. Re-check queue in 24 hours. Verify Queue drops to fewer than 80 incidents; all remaining items are Medium or above; High incidents show owner and tasks. Analysts now work real cases only. Prove automation rules fired After creating an automation rule, open a test incident that matches the trigger conditions. Check the incident comments — Sentinel logs an automatic comment each time an automation rule fires, listing the rule name and the actions taken. No comment means the rule conditions did not match. Quick check · Q4 of 10 · Analyze A SOC wants to ensure every new High-severity incident gets a standard five-step task checklist automatically. Best approach? a) Train analysts to create tasks manually on every incident b) Use a watchlist to store the checklist c) Create an automation rule triggered on incident creation with severity = High that injects the five tasks d) Clone the incident template in YAML Correct: c. Automation rules can inject incident tasks automatically on creation, keyed to conditions like severity = High. This is faster and more consistent than relying on analyst discipline. 👉 So far: Automation rules auto-triage on incident creation: set severity, assign owner, inject tasks, run a playbook. Bookmarks promote raw hunting results into a formal incident without re-running an analytics rule. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between an alert and an incident in Microsoft Sentinel? What are the three tabs on a Sentinel entity page? What can an automation rule do when an incident is created? How do bookmarks connect hunting to formal incidents? How does Sentinel group multiple alerts into one incident? What is the purpose of incident tasks and who can create them? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which incident status value indicates an analyst is actively working the case? a) New b) Open c) Active d) In Progress Correct: c. Sentinel uses three status values: New (untouched), Active (being worked), and Closed. 'Open' and 'In Progress' are not Sentinel status labels — a common distractor from other ticketing systems. Q6 · Understand Why does Sentinel group multiple alerts into a single incident rather than creating one incident per alert? a) To save storage costs in Log Analytics b) Because KQL cannot run on individual alerts c) Because playbooks cannot trigger on single alerts d) So analysts investigate one work item per attack chain rather than dozens of separate tickets for the same event Correct: d. Alert grouping fuses correlated alerts sharing an entity into one incident. This means an analyst works the full attack chain as one case — context preserved — rather than closing 20 separate tickets for the same compromised account. Q7 · Apply An analyst wants to check if a user had any suspicious sign-in activity in the 30 days before the incident without writing KQL. Best step? a) Open the investigation graph and expand the IP node b) Open the user entity page and click the Timeline tab c) Run a new analytics rule against the user d) Export the incident to a CSV and filter in Excel Correct: b. The Timeline tab on the entity page shows all alerts and bookmarks involving that entity in the lookback window — pre-built, no KQL needed, and available directly from the incident details panel. Q8 · Apply During a threat-hunting session an analyst finds suspicious PowerShell execution for a process not linked to any open incident. How should they attach this finding to the investigation? a) Create a new analytics rule to re-detect it b) Email the finding to the incident owner c) Add a bookmark in the Logs blade and then add it to the existing incident from the Bookmarks blade d) Close the incident and reopen it with a new name Correct: c. Bookmarks save raw query results with entities and context. From the Bookmarks blade the analyst can add the bookmark to an existing incident, making it a graph node alongside the triggering alerts — no new analytics rule required. Q9 · Analyze An automation rule is configured for severity = High incidents, but analysts report it never fires. Most likely cause? a) The rule trigger is set to 'incident updated' but the incidents are never modified after creation b) Automation rules only work on Closed incidents c) Automation rules require a Sentinel Contributor RBAC role on each incident d) High-severity incidents bypass all automation rules by design Correct: a. If the trigger is 'incident updated' instead of 'incident created', the rule only fires when an existing incident is modified — a newly created incident that is never touched afterward will never trigger it. Set the trigger to 'incident created' for first-pass triage rules. Q10 · Evaluate A SOC manager wants to reduce analyst time spent on Informational incidents from 3 hours per shift to near zero. Best single action? a) Disable all Informational analytics rules permanently b) Create an automation rule that closes Informational incidents with a Benign Positive classification on creation c) Ask analysts to skip Informational incidents d) Move all Informational incidents to a separate workspace Correct: b. An automation rule that auto-closes Informational incidents on creation eliminates manual triage for the lowest-priority tier. Disabling the analytics rules entirely removes detection coverage; skipping incidents leaves them open; separate workspaces add cost and complexity without solving the problem. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the single fastest way to understand the blast radius of a compromised account in Sentinel? Then compare with the expert version. Compare with expert answer Expert version: Open the incident, click the account entity to load its entity page Timeline (confirm scope of alerts in the last 30 days), then open the investigation graph and expand the account node — Sentinel renders every linked host, IP, malware alert, and bookmark as nodes in seconds. That two-click path replaces what would otherwise be four or five separate KQL queries, and it surfaces relationships you might not have thought to query for. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Incident queue The main SOC view in Sentinel listing all open incidents with severity, status, owner, alert count, and MITRE tactics — filterable and sortable. Severity A four-level label assigned to a Sentinel incident: High, Medium, Low, or Informational. Set by the analytics rule or changed by an automation rule. Entity A structured object extracted from an alert — account, host, IP, file, process, mailbox, or URL — that Sentinel uses to correlate alerts into incidents. Entity page A three-tab view (Info, Timeline, Insights) that shows properties, 30-day activity history, and pre-built anomaly queries for a specific entity — no KQL required. Investigation graph A visual canvas in Sentinel that renders entities, alerts, and bookmarks as nodes with relationship edges, letting analysts see blast radius by expanding nodes. Automation rule A trigger-and-action configuration in Sentinel that fires on incident creation or update: sets severity, status, owner, tags, injects tasks, or runs a playbook. Incident task A checklist item attached to a Sentinel incident to coordinate multi-analyst investigation steps; created manually or injected by an automation rule. Bookmark A saved KQL query result (with entities, time range, and MITRE tags) that can be promoted from the Bookmarks blade into a formal incident as a graph node. Alert grouping An analytics-rule setting that fuses multiple alert matches sharing an entity within a time window into a single incident instead of creating separate tickets. Classification The closing label on a Sentinel incident: True Positive, False Positive, Benign Positive, or Undetermined — required for detection-quality reporting. #### 📚 Sources Microsoft Learn — Investigate Microsoft Sentinel incidents in depth in the Azure portal . learn.microsoft.com/en-us/azure/sentinel/investigate-incidents - Microsoft Learn — Automate threat response in Microsoft Sentinel with automation rules . learn.microsoft.com/en-us/azure/sentinel/automate-incident-handling-with-automation-rules - Microsoft Learn — Microsoft Sentinel entity pages . learn.microsoft.com/en-us/azure/sentinel/entity-pages - Microsoft Learn — Use bookmarks for investigations in Microsoft Sentinel . learn.microsoft.com/en-us/azure/sentinel/bookmarks - Microsoft Learn — Incident navigation and triage in the Azure portal . learn.microsoft.com/en-us/azure/sentinel/incident-navigate-triage - Microsoft Learn — Create incident tasks in Microsoft Sentinel using automation rules . learn.microsoft.com/en-us/azure/sentinel/create-tasks-automation-rule ### What's next? Got incident investigation covered? Next, explore Microsoft Sentinel analytics rules — scheduled queries, NRT rules and fusion detections — to understand how raw log events become the alerts that feed the incident queue. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt