- Alert fatigue is a detection-engineering problem: too many low-fidelity rules firing on expected behaviour, not simply a high volume of logs.
- Track precision (true positive rate) alongside mean time to detect and respond. Alert count on its own hides whether the pipeline is working.
- User and entity behaviour analytics helps with slow, low-and-slow anomalies, but needs a genuine baselining period and clean identity data before analysts can trust it.
- Tuning is recurring maintenance. Rules that were accurate at go-live decay as the network, the identity provider and the attack techniques change under them.
What Actually Generates the Noise
Most alert fatigue traces back to three decisions made when the SIEM was deployed and never revisited. Out-of-the-box correlation content gets turned on wholesale instead of mapped against the organisation's actual attack surface, so rules built for a generic environment fire constantly on this specific one. Thresholds get set conservatively low to avoid missing anything, which guarantees they catch everything, including normal administrative activity. And log sources get onboarded faster than anyone builds context for them, so a new VPN concentrator or cloud tenant starts feeding events into correlation rules that have no idea what normal looks like for that source.
A single overly broad rule, one that flags any failed authentication from outside a defined IP range, can dominate a queue once a workforce goes hybrid and half the logins come from home networks. Analysts learn which rule that is and learn to skip past it. That is a manual, inconsistent decision made under time pressure, not a controlled exception, so the same instinct that filters the noise eventually filters out a real hit that looks similar.
Why This Is Sharper in the UAE and the Wider GCC
None of this is region-specific in mechanism, but a few regional conditions make it worse. Enterprises here have moved fast on cloud adoption and hybrid work, often layering Azure, AWS and SaaS logging on top of an on-premises SIEM scoped for a smaller, simpler network. Each additional log source is another set of baselines nobody has built yet. The market for experienced SOC analysts and detection engineers is also tight, and it is common for a small team to own triage, tuning and reporting at once, leaving little time for anything but the queue in front of them. Tuning is the first thing that gets deferred when a team is understaffed, and it is exactly the activity that would reduce the workload.
Regulatory pressure adds a second layer. Frameworks that examiners in the region reference, including NESA guidance, CBUAE requirements for banks, and ISO 27001 controls, expect evidence of continuous monitoring and documented incident handling, not just a SIEM licence on paper. An assessor will ask how alerts get triaged, how false positive rates are tracked, and how rules get reviewed. A queue of un-triaged alerts is a worse answer to that than a smaller, well-managed alert volume, even though it looks like more security activity on the surface.
Recognising Fatigue Before It Costs You an Incident
Alert count on its own is a poor indicator. A better set of signals:
- Mean time to detect and respond drifting upward while alert volume stays flat, usually meaning analysts spend more time per alert deciding whether it matters at all.
- A growing share of alerts closed with a generic disposition like "reviewed, no action" rather than a specific finding, suggesting triage has become a box-ticking exercise.
- Escalation paths bypassed informally, for example analysts keeping their own private lists of rules or indicators to ignore. That knowledge lives in a spreadsheet instead of the rule base, so it disappears when the person leaves and cannot be audited.
- Rising analyst turnover. Fatigue is felt as much as measured, and a team that keeps losing people to burnout is drowning in noise, whatever the dashboards say.
Tuning Is a Method, Not a Project
The instinct after a bad quarter is to buy something new. The higher-value work is almost always to cut what is already firing.
Start By Killing the Worst Offenders
Pull a report of the rules generating the highest alert volume against the lowest confirmed true-positive rate, and start there. A rule that fires a thousand times a month and has never once produced a genuine finding is adding cost, not coverage. Either raise its threshold, exclude the specific benign pattern it keeps matching, or retire it in favour of a better-scoped rule covering the same technique. This discipline is covered in more platform-specific depth in a Splunk SIEM tuning guide, and it generalises to any SIEM: measure precision per rule, not just volume.
Build Toward Fewer, Higher-Confidence Alerts
Rather than alerting on every discrete low-fidelity event, correlate weak signals into one composite detection with a much higher confidence level. A single failed login is noise. A failed login from a new country, followed by a successful login from that session, followed by a new mail forwarding rule created minutes later, is a business email compromise pattern worth an analyst's full attention. This is the argument for platforms with a strong correlation engine: FortiSIEM's incident model, for instance, groups related events into a single incident with an assigned severity rather than surfacing every contributing event as its own ticket, doing at the platform level the same consolidation a hand-tuned rule set does manually.
Close the Loop Between Analysts and Rule Owners
Whoever triages alerts every day knows which ones are useless faster than whoever wrote the rule six months ago. Without a formal channel for that knowledge to reach the rule owner, fatigue never actually goes down; it just gets managed informally, which is fragile. A short weekly or biweekly tuning review, where the team looks at the noisiest rules and either fixes or retires them, does more for alert quality than any single tool purchase.
Where Machine Learning Genuinely Helps, and Where It Does Not
Vendors sell anomaly detection and behavioural baselining as a solved problem. It is not, but it is also not nothing. Baselining models are good at the thing rule-based detection is bad at: catching a slow deviation from a specific user or asset's normal pattern, like a service account authenticating from a new geography at an unusual hour. That is a genuinely hard pattern to write a static correlation rule for.
The honest tradeoff is that these models need a real baselining period, typically weeks, and clean underlying data. If the identity and asset inventory feeding the model is wrong, it learns the wrong normal and produces its own new category of noise, often around routine but irregular activity like backup jobs or patch cycles. Anomaly-based detection is additive to tuned rule-based detection, not a shortcut around the tuning work above.
In-House or Managed: The Staffing Question Behind the Tooling
A recurring reason tuning gets skipped is that it competes for the same limited analyst time as triage, and triage always wins because it has to happen today. This is one of the genuine decision points between running a SOC in-house and outsourcing to a managed provider: a managed SOC's business model depends on keeping alert volume and analyst time under control, so tuning tends to be built into the service rather than deferred every quarter. The tradeoffs, including the visibility and control an organisation gives up by outsourcing, are covered in the managed SOC versus in-house guide. Neither model removes the need for tuning; it only changes who is accountable for it.
Measuring Whether Any of This Worked
None of the above matters if nobody tracks whether it changed anything. The relevant metrics show whether the SOC is catching real threats faster, not whether the alert count went down, which can just as easily mean rules got turned off carelessly. Mean time to detect, mean time to respond, alert-to-incident ratio and analyst-reported confidence in the queue are worth a monthly review. A fuller list of what to track sits in the SOC metrics and KPIs guide.
Where to Start
Identify the five or six detection use cases that matter most for the organisation's real risk, such as credential compromise, data exfiltration and lateral movement, and get those rules clean and well-tuned first. Suppress or archive everything outside that set rather than fixing everything at once. Only then look at anomaly detection or a managed service to extend coverage. Buying a new tool before doing this just adds another noisy feed to the pile.
