Alright, let's cut through the usual vendor slideshow about "actionable risk." I've been poking at the Risk Analysis dashboard in Splunk ES for the past quarter, trying to use it to actually prioritize our patching queue instead of just chasing CVSS scores. Spoiler: it's useful, but only after you tear out half the default assumptions.
The core idea is solid: it aggregates risk events (like brute force attempts, malware signatures, vulnerability scans) and attaches risk objects (users, systems) with scores. The problem? Out-of-the-box, it often just amplifies noise. A system with a dozen failed logins gets scored similarly to one with a successful exploit attempt. You need to tweak the risk rules and their scores heavily.
Here’s a snippet from the `risks.conf` file I modified to weight actual compromise over mere detection:
```properties
[Risk Rule - Successful Exploit]
risk.rule = successful_exploit
risk.score = 50
risk.category = exploitation
[Risk Rule - Vulnerability Scanner Detection]
risk.rule = vulnerability_scanner_detection
risk.score = 15
risk.category = vulnerability
```
The dashboard then lets you pivot by:
* Highest risk objects (systems)
* Most common risk contributing factors
* Risk over time
The real prioritization comes from layering vulnerability scan data (ingested via, say, Tenable) as an asset lookup. Then you can sort systems by:
1. Highest dynamic risk score (from actual observed events)
2. Known critical vulnerabilities present
3. Business criticality (from your asset database)
Suddenly, that Windows server with a moderate CVE but under active attack jumps to the top of the list, while a system with a critical patch but no observable malicious activity drops down. It moves you from "patch everything critical" to "patch what's actually being targeted."
Of course, this requires maintaining decent asset context. If your CMDB is a spreadsheet from 2019, forget it. Garbage in, gospel out—the dashboard will just give you a beautifully visualized false sense of security.
Tom W.
This is really helpful, thanks for posting. I've been told we need to start using our Splunk ES dashboards more for actual decisions like patching, but the noise problem is exactly what I'm worried about. When you say you tweaked the risk rules, did you find a good baseline for the scores, or was it just trial and error? I'm nervous about setting something too high and missing actual critical events.
One step at a time
Trial and error is inevitable, but starting with your asset inventory and incident history gives you a baseline. If you've had ransomware incidents from unpatched internet-facing systems, weight those associated risk events much higher than, say, an internal port scan.
The real trap is setting scores globally. You need to adjust them based on asset criticality - a failed login on a public web server should score differently than on a developer's workstation. Splunk's adaptive response framework can tie into CMDB data for this, but it's extra configuration work.
If you're nervous about missing events, set up a separate alert for the raw detections (like the exploit attempt) while you tune the risk scores. That way you've got a safety net while you turn down the noise. Blindly following the default risk scores is how you end up patching a test server while a critical database is exposed.
- Nina
That worry about setting scores too high and missing something is completely valid. user427's advice about a safety net alert for raw detections is spot on. It gives you the confidence to experiment.
I'd add one more layer: consider using your patching cadence itself as a guide. Start by heavily weighting risk events you *know* are tied to vulnerabilities you patch on an emergency basis. If you drop everything for a specific exploit chain, make detection of that activity a high-score event. That creates a direct line from the dashboard to your existing "hair on fire" response.
It's less about finding a perfect universal baseline and more about aligning the scores with your team's actual gut feel for urgency. The tuning then becomes translating that gut feel into numbers the system can use.
Stay factual, stay helpful.
The trial and error is real, but you can minimize it by anchoring to your past incidents. Pull a report of your last 6-12 months of critical security events. Look for the common patterns that preceded them - was it always a specific vulnerability scan ID, a particular malware signature, or traffic from a certain geo?
Use those patterns to establish your baseline scores. If you've never had a business impact from a generic port scan, set that score low (maybe 5-10). If every ransomware case started with a specific Excel macro detection, set that score high (40+). Start there, and then adjust based on what bubbles to the top of the dashboard over the next few weeks. It's less about finding a perfect number and more about calibrating the system to your unique threat history.
Your point about weighting successful exploitation higher than detection is the critical move. That differential scoring is what turns a noisy list into a prioritized one.
One caveat based on my own tuning: you might find that even a score of 50 for a successful exploit gets diluted if the system accrues many low-score events. We had to implement a decay function on older, lower-category risks to ensure a single high-severity event would actually propel an asset to the top.
Have you seen any issues with risk score aggregation masking those critical single events?
Data never lies, but it can be misleading