Prove Sentinel is ingesting — first tool + proof field

1. Why “is Sentinel ingesting?” is five questions

Operators collapse five failures into one sentence. The query is scoped to the lab workspace. The Entra table is empty. The connector tile is Connected to a sibling data type. The scheduled rule is Enabled but never reached its threshold. The incident exists and is still New. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught table → analytics → alert → incident → playbook → owner. Here you learn the five Microsoft Learn surfaces you actually open, in order, when someone asks you to prove Sentinel is ingesting — or to explain why there is no incident.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you rebuild a healthy AMA or disable detection at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open Content hub or click Isolate until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the portal. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the lake: workspace, last event, connector. Side B proves the detector: analytics last run. Side C proves the case: incident + entity. On a messy Sev-2, do them in this order until a field lights up.

Side A — Workspace, Logs, Data connectors (the lake)

1. Name the workspace before you hunt

   Azure: directory + subscription selector, then the Microsoft Sentinel workspace. Defender: Select a workspace at the top right. Lab production lake is law-soc-prod. law-soc-lab is the training workspace. Source: Microsoft Learn — Multiple workspaces in the Defender portal; Extend Sentinel across workspaces and tenants.

2. Prove the last event, not the blade

   Path: Azure Logs, or Logs on the incident page, or Defender Advanced hunting. Official: Get started with log queries in Azure Monitor Logs; scheduled rules use TimeGenerated as the lookback reference. Filter the table the ticket named. Quote max(TimeGenerated) and the row count. Empty is a picker or a table problem — not a reason to rebuild AMA yet.

3. If the table is empty in the right workspace, open the connector page

   Path: Configuration → Data connectors (Azure) or Microsoft Sentinel → Configuration → Data connectors (Defender). Search the connector, Open connector page. Official: when the connector is connected you see a Data received graph and the connectivity status of the data types. Health workbook Overview adds volume, EPS, and time last log received. Quote the data type you need — Entra SigninLogs is not CEF CommonSecurityLog.

4. Optional health row for supported connectors

   If Microsoft Sentinel health monitoring is on, query SentinelHealth for OperationName == 'Data fetch status change' and Status Success / Failure. Official: currently supported for a listed set (Office 365, Defender for Endpoint, Dynamics 365, AWS, TAXII, CCF, and others). Absence of SentinelHealth is not “the connector is dead.”

Workspace:       law-soc-prod     (not law-soc-lab)
Path:            Logs  ·  or Advanced hunting
Table:           SigninLogs
Quote:           max(TimeGenerated) + count()
If empty here:   Data connectors → Open connector page → Data received
If empty in lab: switch picker first — do not rebuild AMA

Side B — Analytics last run (why no incident)

1. Open the rule, not Content hub

   Path: Configuration → Analytics → Active rules. Find the scheduled rule the ticket named (lab: MFA-Fatigue). Official: Status Enabled runs on the query interval; Disabled is created but does not run. Sort by name if you suspect AUTO DISABLED — Microsoft prefixes the name and writes the reason in the description after repeated failures.

2. Read Insights, then Rule runs

   Select the rule → Insights tab (health monitoring must be on). Official fields: failed executions, top health issues, alert graph, incident classification. Open Rule runs (Preview). Quote Execution time and Status Success (system-triggered). A user-triggered replay is a test — it is not last night’s schedule.

3. A Success can still create zero incidents

   SentinelHealth for a scheduled run can say: “Rule executed successfully, generating n alerts” or “Rule executed successfully, but didn’t reach the threshold (n) required to generate an alert.” Official: Monitor the health and audit the integrity of your analytics rules. If incident creation is Disabled on a standalone Azure-portal workspace, you get alerts without a case. If the workspace is onboarded to Defender, XDR may own incident creation — do not “fix” that mid-shift by flipping the toggle.

Path:            Configuration → Analytics → Active rules → MFA-Fatigue
Status:          Enabled          (or AUTO DISABLED + description)
Insights:        Failed executions · alert graph
Rule runs:       Execution time + Status Success (System-triggered)
If Success + 0:  threshold not reached  ·  or incident creation Disabled
Do not:          disable the rule to “stop the noise”

Side C — Incidents + UEBA / entity (the case)

1. Work the incident, not each alert

   Path: Incidents → the case. Official: an incident is an aggregation of the relevant evidence — alerts plus the entities those alerts mapped. Left panel: Status, Severity, Owner, Evidence → Events / Alerts / Bookmarks. Button bar: Tasks, Activity log, Logs, Incident actions → Run playbook. Quote alert count and owner before anyone isolates.

2. Read Activity log before you act again

   Official: Activity log shows actions already taken (automation rules, playbooks) and comments. If a playbook already succeeded, do not isolate twice. Finish the mailbox / sessions. Close later with a classification: True Positive, Benign Positive, False Positive, or Undetermined — not “cleared.”

3. Open the entity, quote InvestigationPriority

   Entities widget or Entities tab → the Account. Official UEBA: BehaviorAnalytics.InvestigationPriority is 0–10 (0 = benign, 10 = highly anomalous). Anomalies.AnomalyScore is 0–1 and is a different field. The score supports taking the account. It does not prove malware and it does not replace the three alerts. Investigation graph only works if the rule mapped entities.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

Journey · empty hunt is often the wrong lake

SEVD-01 — Prove the last event (Logs)

01:42 · P2. Slack: “Is Sentinel even ingesting?” A hunter pasted a zero-row query. The workspace chrome says law-soc-lab. L1 already drafted a connector rebuild.

First tool: name the workspace, then Azure Logs (or Defender Advanced hunting). Run last-event KQL on SigninLogs.

If empty in lab: that sentence is allowed to mean “this picker is the training lake.” Switch to law-soc-prod. Re-run the same query. Quote max(TimeGenerated) and the count. Official: one workspace context at a time.

If empty in prod: now you are allowed to open Data connectors. The Logs page is not a connector health event.

SEVD-02 — Prove the source (Data connectors)

02:05 · P2. “Entra is down. Rebuild AMA / CEF.” They point at a green firewall connector because it is the only tile they know.

First tool: Configuration → Data connectors → Microsoft Entra ID → Open connector page.

Proof field: connector Connected, Data received on SigninLogs, last log received inside the ticket window. The CEF-via-AMA sibling can be Connected with last-log 12 seconds ago and still be the wrong object for an identity case. Official: Data received graph + connectivity status of the data types. Health workbook Overview: time last log received.

SEVD-03 — Prove the detector (Analytics last run)

02:20 · P2. SigninLogs has 28 ResultType 50074 rows for finance.user@lab.example. No incident. Chat says “Sentinel missed it — reinstall the solution.”

First tool: Configuration → Analytics → MFA-Fatigue → Insights / Rule runs.

Proof field: Status = Enabled, last Execution time Success, and either “didn’t reach the threshold” or incident creation Disabled — or the name starts with AUTO DISABLED and the description holds the reason. Official: a successful run that misses the threshold generates no alert. Reinstalling Content hub will not fix a threshold of 100 on a 28-row burst.

SEVD-04 — Prove the case (Incidents)

02:40 · P1. “We have 40 alerts. Open three tickets so nothing is missed.”

First tool: Incidents → INC-1042. Official incident details: Overview + Entities; Evidence Alerts / Events / Bookmarks.

Proof field: Severity = High, Status = New, Alerts = 3 (MFA fatigue + impossible travel + new TAP inbox rule), Owner empty. That is one mailbox story. Assign. Do not auto-close. Do not split the bundle. Read Activity log before anyone isolates the laptop again.

SEVD-05 — Prove the entity (UEBA)

03:00 · P2. Manager: “Investigation priority is high — isolate every Finance host.” Someone read a number and heard malware.

First tool: INC-1042 → Entities → Account finance.user@lab.example (or the entity page / Entity behavior).

Proof field: InvestigationPriority = 8 (range 0–10) on BehaviorAnalytics. Official: the score quantifies deviation from baseline. It supports taking over the account. It is not a host-isolate order and it is not a tenant Sev-1. You still need the three alerts and mailbox containment.

7. Traps + close-the-ticket proof

Sources

• Microsoft Learn — Get started with log queries in Azure Monitor Logs (Logs / KQL)
• Microsoft Learn — Create scheduled analytics rules (TimeGenerated lookback; Status Enabled / Disabled; incident settings; threshold)
• Microsoft Learn — Connect data sources using data connectors (Configuration → Data connectors; Open connector page; Data received; connectivity status)
• Microsoft Learn — Microsoft Sentinel data connectors
• Microsoft Learn — Monitor the health of your data connectors (time last log received; SentinelHealth Data fetch status change)
• Microsoft Learn — SentinelHealth table columns schema
• Microsoft Learn — Investigate Microsoft Sentinel incidents in depth (Status, Severity, Owner, Evidence, Activity log, Logs, Incident actions, Entities)
• Microsoft Learn — Scheduled analytics rules (alert grouping, 150-alert cap)
• Microsoft Learn — Monitor and optimize analytics rule execution (Insights; Rule runs Execution time / Success)
• Microsoft Learn — Troubleshoot analytics rules (AUTO DISABLED)
• Microsoft Learn — Monitor analytics rule integrity (Success generating n alerts / didn’t reach the threshold)
• Microsoft Learn — UEBA in Microsoft Sentinel (InvestigationPriority 0–10; AnomalyScore 0–1)
• Microsoft Learn — UEBA reference (BehaviorAnalytics.InvestigationPriority)
• Microsoft Learn — Microsoft Sentinel entity pages
• Microsoft Learn — Multiple workspaces in the Defender portal
• Microsoft Learn — Extend Microsoft Sentinel across workspaces and tenants
• Microsoft Learn — Automate threat response with automation rules

Related: Blog 1 · An incident is a bundle of alerts · Microsoft Sentinel practice hub · Dummy Sentinel lab · Incident investigation · UEBA lesson · SOAR automation