DE1.9 Alert Grouping and Incident Creation

From alerts to incidents: the grouping decision

When an analytics rule fires, it creates one or more alerts. Sentinel groups these alerts into incidents based on the rule’s grouping configuration. The SOC analyst works with incidents — they are the fundamental unit of investigation. The grouping configuration directly determines whether the analyst sees a coherent investigation target or a confusing pile of disconnected signals.

Three grouping strategies exist. Each produces a fundamentally different operational experience. The choice is made per-rule in the analytics rule configuration under “Incident settings → Alert grouping.”

Figure DE1.9 — Three alert grouping strategies with NE examples. Entity-based grouping (recommended) consolidates related alerts. One-per-alert creates independent incidents for each detection. All-in-one accumulates over time for persistent monitoring.

Strategy 1: Group by entity (recommended default)

Alerts with the same entity value (same Account, same IP, same Host) are grouped into one incident. The grouping entity is configurable — you choose which entity type to group by (Account, IP, Host, or a combination).

This is the correct choice for most detection rules because it produces one incident per attack source. A password spray from one IP produces one incident containing all spray alerts. A compromised user account produces one incident containing all alerts related to that account — the initial sign-in alert, the inbox rule alert, the bulk email access alert. The SOC investigates one coherent attack story.

Grouping entity selection matters. For identity-based detections (credential attacks, sign-in anomalies), group by Account — one incident per compromised user. For network-based detections (spray, scanning, C2 beaconing), group by IP — one incident per attacker source. For endpoint detections (process execution, file operations), group by Host — one incident per affected device. For multi-dimensional detections, group by the entity that best represents “one attack.”

Grouping window. The window determines how long Sentinel continues adding new alerts to an existing incident. Default: 5 hours. If a spray continues for 6 hours, the first 5 hours of alerts go into one incident and the 6th hour starts a new incident. For sustained attacks, increase the window to 24 hours. For short-burst detections, 5 hours is sufficient.

Strategy 2: All alerts in one incident (state monitoring)

Every alert from this rule goes into the same incident, regardless of entity values. The incident grows over time as new alerts accumulate. Use this for rules that monitor an ongoing condition rather than detecting discrete events.

NE example: a rule that monitors conditional access policy modifications (CHAIN-DRIFT detection). Every CA policy change generates an alert that goes into the same persistent incident. The SOC reviews this incident during the daily security review, checking whether any changes created exposure windows. This is not “investigate and close” — it is “monitor and track.”

Strategy 3: One incident per alert (critical, independent tracking)

Every alert creates its own incident. No grouping. Use this for Critical detections where each alert represents an independent finding that requires its own investigation thread and tracking.

NE example: LSASS credential dump detection (NRT rule). If two different devices report LSASS access within the same hour, those are likely two separate compromises (or the same attacker on two devices) — each needs independent investigation, containment decision, and tracking. Grouping them would obscure the scope.

Cross-rule incident correlation

Beyond within-rule grouping, Sentinel can correlate alerts from DIFFERENT rules into the same incident based on shared entities. If the password spray rule (Rule A) produces an alert with IP entity 198.51.100.45, and the suspicious sign-in rule (Rule B) produces an alert with Account entity s.chen and IP entity 198.51.100.45, Sentinel can group both alerts into one incident because they share the IP entity.

This cross-rule correlation is what makes entity mapping (DE1.4) essential. Without entity mapping, cross-rule correlation is impossible — each rule’s alerts exist in isolation. With entity mapping on both rules, Sentinel automatically builds multi-alert, multi-rule incidents that tell the complete attack story.

The cross-rule correlation is configured in the “Incident settings → Alert grouping” section of each rule: “Group alerts triggered by different analytics rules into a single incident if the associated entities match.” Enable this for all rules that should participate in cross-rule correlation (which is most rules).

NE grouping strategy per attack chain

For Northgate Engineering, the grouping strategy is selected per detection rule based on the attack chain and detection pattern. The goal: one incident per attack (not one per alert) for volume-based detections, and one incident per finding for critical detections where each instance requires independent tracking.

CHAIN-HARVEST rules (identity + email): Group by Account entity. All alerts related to s.chen’s compromised account — the spray detection, the token theft, the inbox rule, the email collection — consolidate into one incident. The SOC sees one investigation target: “s.chen account compromise.” The grouping window is 12 hours (long enough to capture the multi-hour attack timeline).

CHAIN-MESH rules (lateral movement): Group by Account entity (not Host). The attacker uses j.morrison’s credentials across three devices (Edinburgh endpoint, Bristol DC, Sheffield server). Grouping by Account links all three hops into one incident showing the complete lateral movement path. Grouping by Host would create three separate incidents — one per device — hiding the movement chain.

CHAIN-FACTORY rules (USB exfiltration): Group by Host entity. Each manufacturing workstation where USB exfiltration is detected is an independent investigation — different contractor, different device, potentially different data accessed. Grouping by Host keeps each device’s investigation separate.

CHAIN-PRIVILEGE rules (insider abuse): Group by Account entity. All scope-creep activity from a.patel — PIM activation, app registration, mailbox access, data exfiltration — consolidates into one incident showing the complete abuse timeline.

Critical detections (ransomware, credential dump): One incident per alert. Each LSASS access event or ransomware indicator is an independent critical finding. If two devices show ransomware pre-encryption activity, those are two separate containment decisions — not one investigation.

Monitoring incident volume by rule

After deploying rules, monitor the incident volume to verify grouping is working correctly. Rules that generate more than 5-10 incidents per day are candidates for grouping review.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// INCIDENT VOLUME BY RULE — identify grouping issues
SecurityIncident
| where TimeGenerated > ago(30d)
| extend AlertProductNames = tostring(parse_json(tostring(AdditionalData)).alertProductNames)
| extend ProviderName = tostring(parse_json(tostring(AdditionalData)).alertProductNames[0])
| summarize
    IncidentCount = count(),
    DailyAvg = round(count() / 30.0, 1),
    AvgAlertsPerIncident = round(avg(AlertsCount), 1)
    by Title
| where DailyAvg > 3
| sort by DailyAvg desc
// Rules with DailyAvg > 5 and AvgAlertsPerIncident = 1: likely one-per-alert grouping on a volume rule
// Rules with DailyAvg < 1 and AvgAlertsPerIncident > 20: likely all-in-one grouping accumulating over time
// Sweet spot: DailyAvg 1-5 with AvgAlertsPerIncident 3-10 (entity-grouped, each incident is one attack)

The query identifies rules where grouping may be misconfigured. A rule with 15 incidents per day and 1 alert per incident (DailyAvg=15, AvgAlertsPerIncident=1) is almost certainly using one-per-alert grouping on a pattern that should be entity-grouped. Switch to entity-based grouping and the 15 daily incidents become 2-3 incidents with 5-7 alerts each — a dramatically better operational experience.

Troubleshooting: Grouping issues

“Too many incidents from one rule.” The grouping strategy is likely one-per-alert on a rule that fires frequently. Change to entity-based grouping. If the rule has no entity mapping (and therefore no entity to group by), add entity mapping first (DE1.4) — entity-based grouping requires at least one mapped entity.

“Alerts from different rules are not correlating into incidents.” Check two things: (1) Both rules must have entity mapping on at least one shared entity type (e.g., both map Account or both map IP). (2) The “Group alerts triggered by different analytics rules into a single incident” setting must be enabled on both rules. If either is missing, cross-rule correlation fails.

“One incident is growing indefinitely — it has 500+ alerts spanning weeks.” The grouping window is too long, or the rule uses all-in-one grouping on a frequently-firing rule. For entity-based grouping, reduce the window from 24 hours to 5 hours so long-duration attacks are split into manageable investigation units. For all-in-one grouping, confirm this is intentional (state monitoring) — if not, switch to entity-based.

References used in this subsection

• Course cross-references: DE1.4 (entity mapping — prerequisite for entity-based grouping), DE1.3 (frequency interaction with grouping), DE1.12 (wrong grouping as anti-pattern #7)