In November 2013, Target’s FireEye system did exactly what it was built to do. It flagged the malware installation. It flagged the staging servers where stolen card data was being funneled. Twice. Nobody acted on either alert, and someone had turned off the feature that would have deleted the malware automatically. Forty million payment cards later, the postmortem reports converged on the same conclusion: the technology worked. The team behind it didn’t see it in time.
That’s the uncomfortable truth sitting underneath most SIEM failures. It’s rarely a detection problem. It’s a queue problem.
How this article was put together: the figures below come from named, publicly available vendor and academic reports, cross-checked against secondary coverage where possible. Where a claim rests on a single vendor-commissioned survey, that’s flagged explicitly rather than presented as settled fact. This is desk research and synthesis, not a first-hand incident writeup — if you want a live walkthrough of your own SIEM’s coverage gaps, see the [related guide] link at the end.
The numbers behind the noise
Security teams aren’t ignoring alerts because they’re lazy or undertrained. They’re ignoring alerts because there are too many of them, and most of them don’t matter.
| Metric | Figure | Source |
| False positive rate | 46% of all alerts | Microsoft/Omdia, State of the SOC (2026, N=300) |
| Alerts never investigated | 42% | Microsoft/Omdia (2026) |
| Alerts that go unaddressed | 63% | Vectra AI, State of Threat Detection and Response (2026, N=1,450) |
| Average consoles managed per analyst | 10.9 | Microsoft/Omdia (2026) |
| Security leaders reporting a serious incident in the past year | 91% | Microsoft/Omdia (2026) |
Worth flagging before you cite these anywhere: both are vendor-commissioned surveys. Real respondents, real numbers, but not a controlled academic study, and the Microsoft/Omdia sample skews US/UK/ANZ rather than Southeast Asia specifically. Treat them as directional, not gospel.
More telemetry isn’t the fix. It might be the problem.
Here’s the part that surprises people. The gap isn’t a visibility gap. Most enterprise SIEMs already have more raw data than they know what to do with.
CardinalOps’ fifth annual State of SIEM Detection Risk report analyzed 2.5 million log sources, over 13,000 detection rules, and hundreds of live production SIEM environments (Splunk, Sentinel, QRadar, LogScale, Google SecOps). The environments they studied were ingesting an average of 259 distinct log types from roughly 24,000 sources per organization — enough, in theory, to detect more than 90% of known MITRE ATT&CK techniques.
Actual coverage? 21%.
The other 79% of attacker techniques aren’t slipping through because the logs don’t exist. They’re slipping through because nobody wrote, tuned, or maintained a detection rule for them. That’s a staffing and engineering discipline problem wearing a technology costume.
Southeast Asia’s version of this is worse
Global alert fatigue is bad. Indonesia’s specific combination of numbers makes the case for why the region can’t just copy a US playbook and call it done.
| Indicator | Figure |
| Cyberattacks and traffic anomalies, 2025 | 5.5 billion (+714% vs. 2020–2024 average) |
| Cyberattacks, Jan 1–Apr 15, 2026 | 1.52 billion |
| National Cyber Security Index score, 2023 → 2025 | 63.64 (rank 48) → 47.50 (rank 84 of 136) |
| Digital fraud losses through May 2025 | Rp2.6 trillion |
Source: Indonesia’s National Cyber and Crypto Agency (BSSN), OJK/IASC, and the e-Governance Academy’s NCSI country report.
Read those two numbers side by side and the shape of the problem gets obvious. Attack volume is going up sevenfold. National security readiness, by an internationally benchmarked index, is going down — dropping Indonesia behind Singapore, Malaysia, and the Philippines in the process. That’s not a gap that closes on its own.
Four breaches, one root cause
Pull apart any well-documented major breach from the last decade and the pattern repeats with almost boring consistency: something in the security stack caught the intrusion. The organization didn’t act on it in time.
| Breach | Entry point | Where it broke down | Cost |
| Target (2013) | Stolen HVAC vendor credentials, unsegmented network | FireEye flagged the malware and exfil servers; alerts were ignored, auto-delete was disabled | 40M cards, 70M records, $200M+ |
| Equifax (2017) | Unpatched Apache Struts (CVE-2017-5638), public dispute portal | Patch sat unapplied for 2 months; SSL inspection cert had been expired 19 months, blinding monitoring for 76 days | 147M records, $700M–$1.4B+ |
| ADT (2026) | Vishing call compromised an employee’s Okta SSO session | Attacker pivoted into Salesforce; this was ADT’s third disclosed breach since August 2024 | 5.5M accounts |
| Change Healthcare (2024) | Stolen credentials, Citrix remote access portal with no MFA | Nine days of lateral movement went unnoticed before ransomware deployed | Hundreds of millions in recovery costs, weeks of US healthcare payment disruption |
Different industries, different attackers, different years. Same failure mode: a working signal, buried or unactioned. (Case summaries above are drawn from public breach disclosures and contemporaneous reporting on each incident; consult the original regulatory filings or vendor postmortems for exact figures if you’re citing these in a compliance document.)
What actually fixes this
There’s a reasonably well-established four-stage model for pulling a SOC out of this loop. None of it requires ripping out your SIEM.
1. Pre-queue filtering. Suppress the predictable, benign stuff before a human ever sees it. This is where the DEEPCASE research (IEEE Symposium on Security and Privacy, 2022) is worth knowing: tested against 10.5 million real-world security events, it automatically filtered 86.72% of them and cut manual analyst workload by over 90%, without materially increasing missed-threat risk. It’s one study under specific conditions, not a universal guarantee, but it proves the ceiling is a lot higher than most SOCs are currently operating at.
2. Dynamic triage. Score alerts by actual asset criticality and behavioral context, not a static severity label a vendor assigned three years ago.
3. Case-driven correlation. Stop making analysts manually stitch together twelve related alerts across network, identity, and cloud logs. Group them into one incident automatically.
4. GenAI and human-AI teaming. Let automated agents handle the repetitive first-pass investigation (asset lookups, IP reputation checks, file behavior analysis) so analysts spend their time on judgment calls, not data gathering.
A roadmap you can actually start this week
| Phase | Focus | Key actions |
| Days 1–30: Foundation | Clean the baseline | Audit and disable broken correlation rules. Recalibrate thresholds against real traffic, not default vendor settings. Validate log source health continuously. Enforce MFA on every remote-access and admin portal. |
| Days 31–60: Contextualization | Stop treating alerts as isolated events | Move to case-driven triage grouped by shared entities (user, host, IP). Automate context enrichment. Segment finance, POS, and dev environments from general corporate access. Deploy identity threat detection and response. |
| Days 61–90: Automation | Free analyst time for judgment work | Deploy automated playbooks for high-volume, low-complexity alerts. Roll out UEBA to catch lateral movement static rules miss. Redirect the time saved toward proactive threat hunting and rule tuning. |
Notice what’s not on this list: buying another tool. Every organization in the four breach case studies above already had the detection technology. The fix isn’t more signal. It’s building the muscle to act on the signal you already have, fast enough for it to matter.
Your SIEM isn’t lying to you. It’s telling you the truth faster than your queue can listen.