Risk-based alerting slashes SOC noise -- when done right
A landmark independent study validates risk-based alerting, revealing which scoring strategies cut false positives and which popular vendor rules fail in practice.
When the Cybersecurity and Infrastructure Security Agency (CISA) recently announced it would end its 22-year-old weekly vulnerability bulletin, the move marked a federal acknowledgment that the sheer volume of security alerts has made static severity scores nearly useless for prioritization.
CISA's pivot toward risk-based prioritization reflects an industry-wide reckoning with an overwhelming avalanche of threat telemetry. But while the policy direction is clear, the path to practical implementation has remained murky for many security operations centers (SOCs).
Security analysts face a relentless flood of notifications, leaving them overwhelmed by false positives and driving severe alert fatigue. When critical threats risk getting lost in the noise, the foundational promise of the SOC breaks down.
"Traditional SIEM setups continue to fail analysts because they are often alert-centric rather than incident-centric," said Anand Sagar, a cybersecurity analyst at IT consulting firm CGI.
"A single attack can generate multiple alerts across the SIEM, EDR, firewall, DNS, identity, email security and threat-intelligence platforms, but these alerts may remain fragmented instead of being connected into one attack story," Sagar said[PS1] . "Analysts then have to manually correlate users, endpoints, processes, network connections, DNS activity, vulnerabilities and threat intelligence to understand what actually happened."
To address this crisis, enterprise security teams have increasingly turned to risk-based alerting -- a methodology that aggregates lower-severity signals into contextual threat scores over time, firing an alert only when a cumulative threshold is crossed.
Risky business
While vendors have aggressively marketed risk-based alerting as a silver bullet, implementation has largely relied on anecdotal evidence.
Now, a landmark study from researchers at the Fraunhofer Institute for Communication, Information Processing and Ergonomics (Fraunhofer FKIE) provides the first systematic, empirical evaluation of risk-based alerting, proving its efficacy while identifying which risk-scoring strategies actually work.
To move risk-based analysis out of the realm of vendor claims and guesswork, the researchers reformulated risk-based alerting as a continuous alert-prioritization problem using their novel, open source experimentation suite, CATS (Cybersecurity Alert Triage Exploration and Evaluation System).
The team distilled risk-based alerting into five fundamental risk hypotheses and evaluated them across eight diverse alert datasets:
Rule Level. Prioritizing based on the intrinsic severity level of the triggered detection rule.
Accumulation. Scoring based on the spatiotemporal volume of alerts linked to an entity.
Variety. Scoring based on the diversity of distinct alert types/detection rules triggered by an entity.
Rarity. Scoring based on how infrequently a particular alert type occurs across the environment.
Aperiodicity. Scoring based on nonrepetitive or irregular timing patterns to filter out scheduled batch jobs or periodic background processes.
The results revealed a clear line between what works and what fails. Combining these scoring mechanisms boosted risk-based alerting prioritization performance to an average score of 0.92 (out of 1.0), compared to 0.72 for standard severity rules and 0.50 for unprioritized alerts.
The study also demonstrated that three factors do the heavy lifting in separating real attacks from noise: high rule severity, the volume of alerts tied to a single asset within a short window and the variety of different alert types triggered on that asset within an hour.
Conversely, assumptions long favored by vendors -- such as scoring alerts based on how "rare" or "irregular" they are -- failed to perform better than random chance. According to the report's authors, once a rare event repeats during an attack, it loses its "rarity" score, causing those models to fail when needed most.
"What surprised us the most is that the same combination of simple heuristics -- especially the spatiotemporal variety and accumulation of alerts -- prioritized alerts very well across heterogeneous datasets," Rafael Uetz, lead author of the study and researcher at Fraunhofer FKIE, told TechTarget.
Uetz noted that shifting from fixed alerting thresholds to continuous risk scores fundamentally changes how analysts work: "[It] enables analysts to triage alerts in descending order of risk until they are out of time," he explained. "With fixed thresholds, they usually get either too few or too many alerts with respect to their time resources."
Moving beyond static severity
The study highlights why traditional reliance on static security metrics, such as the Common Vulnerability Scoring System (CVSS) severity levels, struggles in live operational environments.
CVSS acts as a static vulnerability severity metric, evaluating what could happen in theory if a flaw is exploited. Risk-based alerting acts as a dynamic behavioral risk engine, evaluating real-time operational context.
The report illustrates this with a common enterprise sequence: a single system experiences a crashing PDF reader, a newly created user account and high outbound network traffic within a 24-hour window. Viewed individually, none of these low-level events justify a manual review, and an exhausted analyst would likely dismiss them as routine noise.
Under a risk-based alerting framework, however, those three events quietly add incremental risk points to the affected host. Once combined, the cumulative score crosses the risk threshold, triggering a single consolidated alert titled "High Risk Entity," complete with a linked chronological attack timeline.
Cutting through the noise
Vendors who pioneered risk-based alerting frameworks report massive gains in field deployments.
"It really depends on the customer's current detection and alert model, but typical alert reduction ranges from 50% to 80%," said Haylee Mills, security product specialist and risk-based alerting expert at Splunk, which offers products based on the risk-based alerting approach. "In my case as a customer, it was closer to 95%."
She added: "Reduction of a qualitative assessment like alert fatigue is hard to quantify, but because a risk alert is a dynamic, contextual set of events to investigate, there is much less investigative tedium the analyst is required to generate themselves with repetitive procedures for an alert in isolation."
Mills emphasized that effectively configuring these dynamic thresholds involves looking beyond simple risk scores.
"One option is to utilize the number of MITRE techniques observed by an entity over a larger period," she said. "One of my favorites is to group detections by their general purpose -- EDR, cloud, authentication, web, firewall, IDS and so on -- and then alert vertically when one entity has fired three cloud detections, or alert horizontally when one entity has fired one authentication detection, one cloud detection and one EDR detection."
Operational hurdles and the path forward
Despite the clear performance leap, transitioning an enterprise SOC to risk-based alerting carries distinct operational hurdles. The primary challenge isn't the underlying math, but data hygiene, tuning and analyst trust.
The biggest challenge with implementing risk-based alerting in production is getting the risk scoring right and making analysts trust it.
Anand SagarCybersecurity analyst at CGI
"The biggest challenge with implementing risk-based alerting in production is getting the risk scoring right and making analysts trust it," CGI's Sagar noted. "Risk-based alerting needs data from multiple sources, such as identity, endpoint, network, threat intelligence and user behavior, but that data is not always consistent or complete. Even after collecting the data, deciding how much risk each signal should add is difficult. If the scoring is too aggressive, we end up creating more false positives; if it is too low, we may miss real threats."
To ensure successful adoption, Mills advises security engineering teams to bridge the gap between detection logic and daily workflow early in the process.
"Ensure analysts are involved before the alerts start coming their way; you'd be surprised how often this does not happen," Mills said. "Have some weekly feedback where at least one analyst spends an hour working your preproduction alerts and giving honest feedback about what was hard, what they would like to have and so on."
As SOCs evaluate emerging AI- and LLM-driven alert-triage tools, research shows that a properly configured risk-based alerting pipeline provides a computationally lightweight baseline that alleviates analyst burnout without incurring significant overhead.
Beyond human analyst efficiency, Uetz sees risk-based alerting playing a vital role as security teams adopt AI-driven automation.
"Risk-based alerting could act as a prefilter for LLM-based alert triage," he said. "Particularly due to continuous risk scoring, this would enable an efficient use of limited amounts of LLM tokens -- just as with the limited resources of human analysts."
James Walker is lead editor at TechTarget Cybersecurity.
