How do I get actionable alerts, not just 'user is anomalous'?

Absolutely hit the nail on the head about generic alerts. We had the same wall of noise.

The biggest shift for us was moving entirely to custom rules built from Chronicle queries. We disabled a ton of the default behavioral ones. The trick was to start with a known-bad action from our threat intel or past incidents, model that as a rule, and *then* layer on the UEBA risk score as just one component of the alert logic. So the alert fires because "user X did bad thing Y," and the anomaly score is supporting context, not the main event.

For example, we built a rule that only fires if a service account makes a first-ever outbound RDP connection *and* its session anomaly score is high. That's a direct finding. You still have to do the upfront work of defining "bad," but the output is immediately actionable for the team.

You're describing the exact turning point we faced. The generic alerts become background noise so fast. We didn't disable *all* the default anomaly rules, but we put them on a very long leash - they only escalate to a ticket if they combine with a specific, tagged event from our core SIEM.

Our concrete step was building "enrichment rules" that watch for those vague "User Anomalous" alerts and then immediately query for specific high-risk actions that user took in the last 60 minutes. If it finds one, like a first-time access to a sensitive share, the rule overwrites the alert title and description to state that exact action. If it doesn't find a tagged action within that window, the anomaly alert gets suppressed entirely. It forces the system to answer "what did they do?" before it's allowed to bother an analyst.

The key was accepting that the baseline anomaly is just a signal, not the alert. The actionable finding has to come from a separate process that correlates that signal with actual log data. It adds a small processing delay, but the alert quality improved dramatically.

You're spot on about needing the concrete "what." We took a hybrid approach - kept the generic anomaly alerts but completely changed their destination.

We created a dedicated "Anomaly Queue" that only senior analysts can see. Those vague alerts go there to die, unless they meet a secondary condition within 10 minutes. That condition is almost always a specific Watchlist match.

For example, the "User Anomalous" alert sits quiet. But if that same user triggers a "Sensitive File Access to Watchlist Folder" event within the next 10 minutes, the system auto-closes the generic alert and creates a *new*, consolidated alert titled: "Anomalous User [Name] copied files from [Watchlist Folder Path]." It includes both the risk score *and* the exact action.

This way you're not drowning Tier 2 in noise, but you're still letting the UEBA engine flag users for scrutiny when they do something definitively bad shortly after acting weird. The upfront work is in building a solid set of "watchlist" rules for actions you truly care about.

You're expecting the tool to build the story. That's the wrong starting point.

The generic alerts are a feature, not a bug - they're raw material. Your job is to define what a bad story looks like in your environment. Then you write correlation rules that *consume* those anomalies.

My specific step: I scrapped all the default alerting rules day one. Built a new rule set that only fires when an anomaly coincides with a tagged high-risk event from our data sources.

Example rule logic:
* Event: First-time access to crown-jewel S3 bucket (tagged by our CloudTrail parser)
* Condition: AND user's session anomaly score > 85
* Alert: "High-risk first access to [BucketName] by anomalous user [User]"

The anomaly becomes context, not the alert. If there's no tagged high-risk event, there's no alert for the SOC. The "User Anomalous" event just sits in the timeline for an investigator to find later.

Thanks for laying out the problem so clearly - it really resonates. Your point about "constructing the actual story" is exactly right. We're a smaller team, and we took a path similar to what user64 mentioned.

Our specific step was to never let a raw anomaly alert live by itself. We built a small Python service that subscribes to those generic "Anomalous User" alerts via the API. When one fires, it immediately queries Exabeam's data lake for that user's raw session logs from the anomalous period, looking for a handful of very specific, pre-defined actions we consider high-risk (like a first-time PowerShell execution on a server).

If it finds one, it uses the API to update the alert title and description to something like "Anomalous user executed first-time PowerShell on [Hostname]." If it doesn't find a match, it auto-closes the alert. This forced the system to answer your "what did they do?" question before we ever saw it.

It's a bit of a hack, but it turned the noise into a handful of clear actions per week.

The API-driven enrichment approach you describe is operationally smart, but I'm concerned about the latency overhead you're adding to the alert lifecycle. Querying the data lake for session logs on every anomaly alert introduces a variable delay. Have you benchmarked the end-to-end time from the initial anomaly detection to your enriched alert being actionable?

In our environment, that added 45 to 90 seconds, which pushed certain automated response actions past their viable window. We had to move the "specific action" lookup into the initial rule logic itself, using Chronicle queries that could run concurrently with the anomaly model, not sequentially after its alert fires. The principle is identical to yours, but the order of operations matters for time-sensitive threats.

You've got the right idea, but you're starting too late. The generic alerts should never reach your analysts at all.

I cut them off at the source. Went into the Exabeam rule engine and deleted every default "User Anomalous" alert. Every single one. Then I built new composite rules that can only fire if a high anomaly score coincides with a specific event my team already knows how to investigate.

For example: a rule that triggers only when a high session anomaly score AND a first-time access to a critical network segment happen within five minutes. The alert title is that exact finding. The anomaly score is just a field in the details.

If there's no concrete bad action, there's no alert. It forces the system to answer your question before it's allowed to make noise.

You're right to focus on tuning the rules themselves, as that's where the alert narrative is defined. I agree with the approach of disabling default alerts, but I'd add a caveat: before you delete them, export their underlying Chronicle queries. Those queries often contain useful, pre-built logic for detecting specific anomalous actions (like 'first-time RDP from a non-RDP server') that you can repurpose as the concrete event in your new composite rules.

My specific step was to build a mapping table outside of Exabeam. I listed every generic anomaly alert the system could generate, and for each one, I defined one to three concrete, high-risk events that would justify an alert. For the "User Anomalous (Session)" rule, the mapped events were "first-time sensitive file access" and "execution of a watchlisted binary." I then rebuilt the rule to only trigger if the anomaly score was above threshold **and** one of those mapped events was found in the user's session within a 5-minute lookup window. The alert title becomes "Anomalous session with first-time access to [File]," which is immediately actionable. The key is performing that event lookup inside the rule logic, not in a downstream process, to avoid the latency issue others have noted.

You're absolutely right about the latency penalty. We hit a similar wall where the enrichment delay meant automated account lockouts were often chasing ghosts. Our solution was a compromise: we still use the API for enrichment, but only for a subset of "tier 2" anomalies that don't have a pre-defined critical action. For the high-severity, time-sensitive stuff, we followed your path and embedded the concrete event logic directly into the Chronicle query powering the rule.

The key was realizing we had to split our rule logic into two categories: immediate threats requiring sub-minute response, and contextual anomalies for deeper investigation. The latter can tolerate that 90-second lookup. Trying to apply one enrichment pattern to all alerts just reintroduced the noise problem we were trying to solve.

Your example about *Rule Tuning* is exactly where to start. I did disable most default anomaly alerts, but the real trick was using Chronicle to build a logic loop inside the new composite rules.

My specific step was a rule that triggers on a high anomaly score, but then immediately performs a sub-query for that user's activity in the anomalous session. It looks for a specific pattern, like 'first-time access to a server tagged "PCI" followed by a registry edit.' Only if it finds that sequence does it fire an alert titled exactly that. The anomaly score is just the entry ticket.

This way, the "what did they do?" question is answered before the alert even exists. It cut our actionable alert volume by about 80%, because the system now has to articulate a specific bad action, not just a deviation.

Your rule tuning approach is the only way forward. I disabled all the default anomaly alerts on day one.

My specific step was to build Chronicle queries that look for the high-risk event first, then check the anomaly score. For example: a rule that triggers on "first-time execution of a specific sensitive command-line tool" and only fires if the user's session anomaly is above 70.

The alert title is exactly that concrete event. The anomaly score is just a secondary detail field for the analyst. If the bad event isn't present, no ticket gets created. This forced the system to answer the "what" before it could generate noise.

That's the right order of operations - concrete event first, anomaly as secondary filter.

My only addition: we had to set a different threshold for our service accounts versus human users. A service account's "first-time execution" of a tool is almost always part of a deployment, so we filter those out entirely unless paired with multiple other flags. The anomaly score threshold for a human was 75, but for a service account we set it to 95.

That approach makes total sense, cutting the noise off before it starts. But I'm new to this and that feels like a huge step to take all at once.

How did you decide what those concrete events were? I'd be worried about deleting everything and then missing something because we didn't think to build a rule for it. Did you run the old and new systems side-by-side for a while to catch what you might have filtered out?

Agreed, cutting them off at the source is the only way to get peace. The key is your phrase "specific event my team already knows how to investigate." That's the filter.

Where people go wrong is trying to guess those events in a vacuum. You build the list from your own real incident history and analyst pain. Start with the last 50 generic anomaly alerts you got. For each one, you ask your team: "If you could only know one specific thing to decide if this is a real investigation, what is it?" That's your concrete event for the new rule. If you can't answer that, the scenario isn't actionable and shouldn't alert.