by Muhammad Haekal Alghifary, Security Researcher & Brian Hikari, UX Writer @ PT ITSEC Asia Tbk
Now imagine, if it happens on a larger, much bigger scale. You received not only 10 notifications, but hundreds thousands even. And you have to open it one by one. Every. Single. Day. Not because you wanted to, but you have to.
According to the State of AI in the SOC 2025 report, a typical security operations team fields close to a thousand alerts a day, and roughly 40% are never investigated at all. Not because the analysts are lazy, but because the math has never worked. Of the alerts that do get looked at, industry surveys put the share that prove benign at around nine in ten. And it wears people down: more than seven in ten analysts report burnout, according to recent surveys from Tines and Cybersecurity Insiders.1
This is what people are talking about when they say "alert fatigue." It isn't one bad shift or one noisy tool. It's the steady-state reality of being a Tier 1 analyst, the front-line responder who has to look at each alert first and every vendor in the space, IntelliBroń included, has spent years trying to fix it from the volume side. Better rules. Smarter suppression. AI-tuned sensitivity. Whitelists for traffic you've already cleared. They all help, until they don't.
Past a certain volume, filtering alone cannot get you to a number a human can actually triage. And volume, it turns out, isn't even the full problem.
What we already do, and where it caps out
IntelliBroń's system, Orion, pulls its raw material from sensors, the tools that watch network traffic and flag anything that looks suspicious. Each thing they flag is an event: a single record of something that happened on the network. Before any of it reaches a human, Orion runs those events through a stack of filters (rules the analysts write themselves), a "known-good" list of sources already cleared as safe, and sensitivity settings the team can dial up or down. Anything already reviewed gets muted; anything from a trusted source never raises an alert at all.
This is good plumbing, and every mature security operations centre has the equivalent. But "the equivalent" still leaves a large enterprise SOC swamped. Larger 2026 studies from Vectra AI and the Ponemon Institute put enterprise volumes at three to four thousand alerts a day, well over a hundred thousand a month. You can keep tuning rules, and you should, but tuning is never a one-time fix. It's continuous labour: analysts have to stay aware of a constantly shifting environment and keep the rules adapted to it. That's heavy effort upfront, and even once an environment is well tuned it never stops needing maintenance. And for all of it, the curve still flattens. There is a floor you cannot filter past, and that floor is still well above what three humans can read in a shift.
Worse, even the alerts that survive the filters arrive as alerts: one row at a time, each on its own, stripped of any surrounding context. An analyst opens one, then has to ask the second question. Where did this come from? What else is this attacker doing? Does it touch anything I care about? and answer it by hand, jumping between tools.
That second job is the half of the problem nobody talks about. It's the part that's actually exhausting.
A reframe: alerts versus actors
This is the reframe we think matters. The existing tooling treats alerts as the unit of work. But an alert is not a thing in the world. An attacker is a thing in the world. A compromised asset is a thing in the world. An alert is just one signal that one of those things happened.
If you group alerts by who and what they belong to, by entity rather than by event, two things happen at once. The number of items an analyst has to triage drops, because a thousand alerts from the same actor against the same target collapse into one story. And the context problem disappears, because each story arrives already stitched together. The analyst stops jumping between alerts. They start reading a narrative.
Alert-centric SOC tooling, reframed as entity-centric.
Why this reframe isn't new, and why that's the point
None of this is new. The basic idea is to take the alerts that belong to the same attacker and treat them as one case instead of many separate ones. This has been around for decades, and the big monitoring platforms most security teams use can already do a rough version of it.
So why isn't it simply how everything works already? Because the idea was never the hard part. The hard part is doing it cheaply and reliably enough to run non-stop, on the full, live flood of alerts a real organisation produces, not a tidy sample in a demo. Plenty of clever systems connect the dots beautifully on a small test set and then buckle the moment they meet real-world volume. Our bet is that the plain, predictable approach, the one that isn't trying to be clever, is the one that actually holds up in daily use. And a tool that holds up is the only kind worth putting in front of an analyst.
The unglamorous answer often wins, because it is the one you can actually run every day.
What this changes for the analyst
The point of all of this is not the engineering, even though the engineering is what made it work. The point is what shows up on the analyst's screen.
Picture the evidence board from any detective show photographs pinned to a wall, coloured string running between them, a timeline scrawled down one side.
An analyst's screen, without correlation, looks a lot like this.
That board is where a scatter of fragments, a witness statement, a timestamp, a footprint finally becomes a story. Today an analyst has to build that board themselves, one alert at a time, before they can even tell whether the pieces belong to the same picture. The reframe hands them a board that has already been assembled.
Instead of an endless queue of one-off alerts to sort through in no particular order, they open a short list of ready-made stories. Each one already says, in plain terms: here is who is behind it, here is what they touched, here is the order it happened in, and here is the single strongest clue that ties the chain together. The work that used to be "click, read, pivot, search, repeat" becomes "open one, and read what happened."
One incident page in Orion: timeline, affected systems, threat intelligence, and recommended action, already assembled.
Fewer things. Each with context. That is the only combination that meaningfully changes how fast and how accurately threats actually get resolved, and it is the combination that filtering alone, no matter how aggressively tuned, was never going to deliver. Here is what that looks like in practice:
The visual graph view, entities, connections, and a timeline that tells the full story at a glance.
Conclusion
The lesson here is simple: the unit of work in a SOC should never be the alert. It should be the attacker, the asset, the story. When you group signals by what they belong to instead of when they arrived, two things happen at once: the queue shrinks, and the context appears.
That's the reframe. And it changes everything downstream:
- Analysts spend less time reconstructing, more time deciding
- Confirmed attack chains rise to the top, noise stays out of the way
- The same address that appeared three weeks ago gets surfaced immediately, not discovered by coincidence
Security operations doesn't get easier by seeing more. It gets easier when you can see how things connect.
So the next time your team is buried in alerts, ask yourself: are we treating symptoms, or the actual problem?
If the answer is symptoms, it might be time to stop filtering harder, and start correlating smarter.
References
1 Sources. Daily alert volume: ~960/day for a typical team (State of AI in the SOC 2025); ~3,000/day (Vectra AI, 2026 State of Threat Detection) rising to ~4,330/day (Ponemon Institute, 2026 State of SecOps) for larger enterprises. Never investigated: ~40%, AI SOC Market Landscape 2025, corroborated by the State of AI in Security Operations survey (higher-volume studies such as Vectra put the uninvestigated share above 60%). Benign rate: estimates vary widely, from ~46% false positives (Microsoft/Omdia, State of the SOC 2026) to around nine in ten in other SOC surveys. Analyst burnout: above 70%, Tines (71%) and Cybersecurity Insiders, Pulse of the AI SOC Report 2025 (73%).