An untuned security console is functionally the same as no detection. This is the tuning sequence that turns alert volume into an incident queue somebody actually works.
Your team has stopped opening the security console. That is a rational response to several hundred daily alerts that are almost all benign, and it means your estate is effectively unmonitored despite being fully licensed. This guide covers the work that fixes it.
Coverage verification, alert suppression rule design, custom detection rules, automated investigation configuration, and the response playbook work that has to accompany it.
Alert fatigue is a design failure, not a discipline failure. A console producing several hundred alerts a day where almost all are benign will be ignored, and the one that mattered is ignored along with the rest.
The fix is not more analysts. It is suppression of known-benign activity, correlation across signal sources so a compromise appears as one incident rather than four alerts, and a response process that exists before it is needed.
Check these before beginning. Most stalled implementations stall on one of them.
Microsoft 365 E5, or E3 with Defender for Endpoint P2 and Defender for Office 365 P2. Defender for Identity requires the appropriate tier.
Security Administrator in the Defender portal. Read-only for the assessment phase is sufficient.
Onboarding completed across endpoints, identity, email and cloud. Tuning incomplete coverage produces confident blind spots.
An agreed position on what automated response is permitted to do without human approval.
Configuration is straightforward once these are clear. Skipping them is why most first attempts produce something that works and cannot be maintained.
Defender XDR correlates related alerts across endpoint, identity, email and cloud into a single incident with an attack story. A team working alerts is working fragments; a team working incidents is working cases. Make sure the queue is configured to the latter.
A suppression rule can apply to a specific device, device group, or the whole organization. Global suppression of a detection type is almost always too broad. Scope to the context that makes the activity benign.
Your environment has legitimate activity that looks suspicious and suspicious activity that looks legitimate. Custom detection rules written in advanced hunting queries close that gap, and they are how a mature deployment differs from a default one.
Settings shown are the ones that matter, not every field on the form. Values are starting points to validate against your own environment.
Produce a map: which endpoints are onboarded, which identity sources are monitored, whether email protection covers all domains, and which cloud workloads are in scope.
Most organizations have less coverage than they believe, particularly across identity and SaaS. Tuning an estate with gaps produces a quiet console and a false sense of security.
Export thirty days of alerts and group by title and severity. The distribution is almost always heavily skewed — a small number of detection types produce most of the volume.
That skew is good news. Suppressing three or four benign patterns typically removes the majority of the noise.
For each high-volume benign pattern, identify what makes it benign — a specific process, a specific device group, a known administrative tool — and scope the suppression to exactly that.
Document why each rule exists. A suppression rule with no recorded rationale becomes a permanent blind spot nobody is willing to remove.
In a professional services firm the distinctive risks are usually around client data movement: unusual volumes of document access, bulk downloads before a departure, external sharing spikes.
Write these as advanced hunting queries, test them against historical data, then promote them to custom detection rules.
Automated investigation and response can isolate a device, disable an account or remove a message from every mailbox. Set the automation level deliberately and agree with leadership what it may do without approval.
Full automation on servers is rarely appropriate. Full automation on standard user endpoints usually is.
Every one of these is avoidable, and every one of them is common enough that we check for it by default.
It removes the noise and the signal together. A detection type suppressed globally will not fire when it matters, and nobody will remember it was suppressed.
A tuned console over a partially covered estate is the most dangerous configuration available — it looks healthy and is not.
Detection without agreed authority to act produces an accurate record of an incident you watched happen. Build the playbooks and rehearse them as part of the same engagement.
Manual-only response means containment happens at ticket speed while lateral movement happens at machine speed. Agree boundaries and enable within them.
We will run the coverage and alert-quality assessment first, and give you the findings before you commit to any tuning work.
Describe the situation in your own words.
