Too Many Findings? What Happened in Splunk ES 8.0 and How 8.1 Resolved It
Dave Cheever, Team Lead, MDR Advanced Services and Jon Walthour, Senior Technical Architect
Overview
Splunk Enterprise Security (ES) 8.0 was first announced at .conf in June 2024 and officially released in October. While the update drew a lot of attention, many teams quickly noticed a significant spike in “findings” (previously known as “notables”) after updating. This unexpected increase in volume generated redundant findings, contributing to excessive alert fatigue and placing additional, unnecessary pressure on SOC teams.
Earlier this month, Splunk addressed these challenges with the release of ES 8.1, which introduced greater flexibility in output handling to help reduce noise. In this article, we will break down how output behavior has evolved from version 7.3 to 8.1, and what those changes mean for optimizing your detection strategy.
Legacy Output Settings up to ES 7.3
We felt it appropriate to give some context for some of the changes in the transition from earlier versions to 8.x. Up to Splunk ES 7.3, you could select “Notable” and “Risk” as separate adaptive response actions within a correlation search. These were distinct choices in the “Adaptive Response Actions” dropdown menu when configuring or editing a correlation search, allowing each component to be managed independently.
This flexibility gave granular control over how detections were triggered, whether focused on immediate alerting through notables, risk-based scoring for broader behavioral analysis, or both.
Output Type Constraints in ES 8.0
Beginning in ES 8.0, Splunk revised its terminology by renaming “correlation searches” as “detections.” These detections come in two types: Event-Based Detections (EBD), which analyze event data to generate findings or intermediate findings, and Finding-Based Detections (FBD), which build on those outputs to generate high-confidence finding groups.
When configuring an EBD in Splunk ES 8.0, the “Output Type” setting required you to select either “Finding” or “Intermediate Finding”.
The selected output type was applied across all risk entities listed in Section 4, following a blanket approach assigning this output type to each entity identified. Note that specifying at least one risk entity in this section was required to save the detection.
This meant that if you selected “Finding” as your output type, Splunk would generate a separate finding for every individual Risk Entity. For example, if an admin added 25 users to a security group, this would result in 26 findings; one for the source user and one for each of the 25 destination users, instead of a single finding that summarized the entire event.
Unlike ES 7.3 and previous, these additional intermediate findings were written to the “notable” index alongside the proper finding, and it was impossible to distinguish one from the other as all were designated “risk-events”. The result was a significant increase in the volume of findings, creating many duplicates that could overwhelm your incident response process.
Improved Output Type Flexibility in ES 8.1
In Splunk ES 8.1, the challenge with EBD output types has been resolved by introducing the ability to assign a distinct output type to each risk entity.
Note that if multiple entities are set to “Finding”, a warning appears stating:
“When output type ‘Finding’ is selected for multiple risk entities, a separate Finding is generated for each risk entity. Best practice is to output a Finding for the primary risk entity and use Intermediate Findings for the others.”
Version-by-Version Breakdown
Avoid Additional Surprises When Upgrading to ES 8.1
When creating a new Event Based Detection in Splunk ES 8.1, the output type for the first risk entity defaults to null, requiring manual selection. Any additional entities added afterward will default to “Intermediate Finding”. This gives users more control but also requires careful configuration to avoid unintended output behavior.
However, when migrating existing detections to ES 8.1, all previously defined risk entities will automatically default to “Finding”. To prevent alert volume issues, it is important to review migrated detections to explicitly set output types for each entity.
Behind the Scenes in Savedsearches.conf
Alongside the visual and functional changes in the UI, each version introduced configuration-level updates within savedsearches.conf, which helped to explain the behavioral differences between versions.
- From 7.3 to 8.0
- Added: action.correlationsearch.detection_type = ebd
- Removed: action.risk and action.risk.param._risk_score
This reflected the move to Event Based Detections (EBD) and the removal of separately defined risk actions in favor of the new output type system.
- From 8.0 to 8.1
- Added: action.notable.param._entities
- Restored: action.risk (previously removed in 8.0)
- Modified: In 8.0, action.risk.param._risk included all risk entities. In 8.1, it lists only those entities configured as intermediate findings.
These updates brought back risk handling flexibility and aligned the configuration more closely with the per-entity control introduced in the 8.1 UI.
Conclusion
Splunk’s revamped detection framework in Enterprise Security 8.0, encompassing both event-based and finding-based detections, represented a major evolution by placing Risk Based Alerting (RBA) at the core of modern cybersecurity monitoring. Although the initial rollout in version 8.0 encountered some hurdles, the improvements introduced in 8.1 underscore Splunk’s dedication to enhancing this impactful approach. The latest update offers increased flexibility and control, empowering security teams to better manage alerts and reduce noise. By staying informed and proactive with these changes, users can fully unlock the advantages of RBA to strengthen their overall security posture.
Explore TekStream’s Splunk Services here.
About the Authors
Dave Cheever is a seasoned cybersecurity professional with more than a decade of industry experience. Over the past six years he has specialized in Splunk, applying his expertise across both analysis and engineering roles. Beyond his civilian career, Dave serves part time in the Air Force National Guard, where he supports critical national cyber missions for organizations such as the NSA and USCYBERCOM. He holds a master’s degree in Cybersecurity from the University of Massachusetts and maintains several respected certifications, including the CISSP. He is also a certified Splunk Core Consultant and holds accreditation in Enterprise Security implementations. Dave resides near historic Plymouth, Massachusetts, America’s hometown.
Jon Walthour is an experienced IT professional with over 25 years of experience in administering servers, databases and applications, including over five years of experience helping customers discover success with Splunk as a Splunk Certified Consultant and Enterprise Security Administrator. Jon holds a Bachelors in Psychology from Wright State University in Dayton, Ohio, and a Masters in Divinity from Louisville Presbyterian Theological Seminary. Jon currently resides in Lafayette, Indiana.