Sentinel: Cutting Incident Noise and Cost Without Losing Coverage

Work in this order, because each step is measurable and reversible:

1. Baseline before touching anything. Use the analytics rule efficiency and incident metrics to rank rules by incidents created versus incidents that produced a true positive, and record current MITRE technique coverage. That baseline is your defence when someone later asks what coverage was lost.
2. Collapse, don't disable. Enable incident grouping so related alerts merge into one incident (all alerts in one incident, or grouped by entity), and configure entity mapping on the rules so alerts for the same host or account actually correlate. 250 incidents a day from 320 rules usually means one noisy event is generating several incidents.
3. Tune the rule, not the incident. Add thresholds, add exclusion logic via watchlists or ASIM parsers for known-good scanners, backup ranges, and vulnerability-scan sources. Only retire a rule after confirming its technique is covered elsewhere or is genuinely not applicable to the estate.
4. Automate the known-benign, do not hide it. Use automation rules to close or tag the recurring benign pattern and to route it to a documented closing reason, so the volume drops but the signal is still recorded.
5. Reserve Fusion and multi-stage detections for the low-volume, high-fidelity cases - they are what buy you analyst attention back.

Target the 220 benign closures specifically: they are the direct cause of the acknowledgement-time problem, because the queue is what delays triage of the 30 that matter.

Layer 1 - Sentinel's permission to run the playbook. When an automation rule runs a playbook, Sentinel uses a dedicated service principal for that management group. That principal needs the Microsoft Sentinel Automation Contributor role on the resource group that contains the playbooks. This is the usual cause of an automation rule that never fires at all.

Layer 2 - the playbook's permission to act on the target. The playbook itself authenticates with its own managed identity. That identity needs the rights for the specific action at the narrowest scope:

• VM isolation: the permissions required to write the deny rules and, per your implementation, the VM power/network operations - grant on the target resource group or, better, on a dedicated resource group holding only the VMs the playbook may touch.
• User disable: the corresponding directory permission scoped down, granted through an app role assignment rather than a broad directory role.

Checks that catch the rest: the trigger must be Microsoft Sentinel incident (the legacy alert trigger will not work), the API connections inside the playbook must use the managed identity rather than an expired user credential, and the automation rule must be ordered after the analytics rule that creates the incident. Privileged directory roles such as Global Administrator must not be assigned to the playbook identity - that converts one misconfigured playbook into a tenant-wide risk.

Arithmetic first. 30% of 90 GB/day is 27 GB/day. The 45 GB/day of firewall logs is the only volume large enough to close the gap without touching detection value.

Options, in order of preference:

1. Filter at ingestion with a data collection rule transformation. Drop records and fields the three rules never reference (port scans from approved scanners, health-check traffic, verbose message bodies). This is lossless with respect to the detections if you derive the filter from the rules' actual queries.
2. Move the residual firewall table to a low-cost plan and re-point the three rules. Tables on a low-cost plan are not queried by scheduled analytics rules, so either the rules move to a summarization/aggregation approach or the signal stays in the interactive tier. State this trade-off to the CISO rather than discovering it in an incident.
3. Retention. Shorten interactive retention to the operational window and push the rest to long-term or archive, which is where most of the cost sits in a 90 GB/day workspace with default retention.
4. Verify free entitlements are actually being used for the Microsoft 365 Defender connector - comparing the workspace Usage table by solution is the only reliable way to see where gigabytes actually go.

Trade-off to state explicitly: the reduction is bought by giving up full-fidelity firewall data, not by giving up detection. Confirm with the three rule owners in writing, run the filtered and unfiltered rules in parallel for two weeks, and compare alert output before you delete the raw feed. Do not present the saving until that comparison is clean.