Exabeam Guide: Tuning Correlation Rules, Behavioural Analytics and Access

An Exabeam tenant only finds real threats when its parsers, correlation rules and behavioural models are tuned, owned and protected by the security team. This guide explains how to run the Exabeam New-Scale Security Operations Platform well: keeping log parsing healthy in Log Stream, building and testing correlation rules, tuning the behavioural analytics risk engine, controlling noise in Threat Center, and restricting who can see and change detections. It is written for SOC leads, detection engineers and platform owners who run Exabeam or are taking over a tenant. For behavioural analytics concepts in general, see the UEBA Guide; for SIEM fundamentals, see the SIEM Guide.

This is an independent guide from NHI Mgmt Group, based on Exabeam's public documentation as of November 2026. It is not sponsored or reviewed by Exabeam. Product features change, so confirm settings against Exabeam's current documentation.

Key takeaways

• Two detection engines, one queue. Correlation Rules surface well-defined, fact-based events; Advanced Analytics scores anomalies against behavioural models; both feed alerts and cases in Threat Center.
• Test mode before outcomes. A correlation rule in Test Mode runs and writes rule-trigger-test events but creates no Threat Center alert, so every new rule should spend time there first.
• Know the auto-disable limits. A rule is set to Stopped when its sequences match more than 500 times in five minutes or it triggers more than 50 times in five minutes, so noisy rules switch themselves off.
• Notable means a session score of 90 by default. Users and assets are listed as notable when a session score meets the configured threshold (default 90), and models are rebuilt every 16 weeks by default.
• Restrict data and detection editing. Use Universal Role-Based Access, Secured Resources queries, MFA, IP-based access and audit logs so only detection owners can change rules and analysts see only the data their role needs.

How the platform fits together

The New-Scale documentation groups the platform into collection, security management, detection and investigation, and platform insights. Knowing which application owns which decision avoids tuning in the wrong place.

The decision rule is simple. If a threat can be written as a precise condition (a specific event, a count over time, an ordered set of events), it belongs in Correlation Rules. If it can only be described as "unusual for this user, peer group or host", it belongs in Advanced Analytics. The SIEM vs UEBA guide covers that distinction in general terms.

Keeping parsing and enrichment healthy

Both detection engines depend on parsed fields. A correlation rule grouped on user or a behavioural model keyed on a host name does nothing if the parser leaves that field empty. Log Stream is where this is controlled.

• Parser Health Status: review Enabled Parser Health Status, Parser Health Status Over Time and Individual Parser Health Status after every new source and after parser updates. A drop in a parser's health usually means the source changed its format.
• Customise, do not overwrite: Log Stream supports creating a custom parser, customising a default parser, duplicating a parser and enabling or disabling parsers. Keep custom parsers exported (Export Parsers) so they can be re-imported and reviewed like code.
• Event builders: use Add Event Builder Rules and Multi-Log Event Building for sources that split one action across several log lines, so rules see a single event.
• Enrichments: custom enrichers run after the default enrichers. Use enrichment rules (for example Host to IP enrichment) to add the context that rules and models need, rather than repeating lookups inside each rule.
• Live Tail: use it to see log volumes, processing latency and analysis status when onboarding a source or chasing a missing alert.
• Log Stream permissions: read-only Log Stream permissions exist; give parser editing only to the platform engineers who own it.

Use the SIEM Log Source Onboarding Checklist as the gate for each new source: parsed, enriched, healthy and visible in Search before any rule depends on it.

Building correlation rules that hold up

Exabeam offers four ways to create a rule: the Exabeam Nova Rule Creator, the Manual Rule Creator, a template, or from a Search query. Whichever path you use, the rule ends up with the same parts.

Absent events and Smart Timeline

The docs describe detecting absent events or fields with correlation rules, which suits "a log source went quiet" or "a backup job did not run" cases. For a rule to contribute to a Smart Timeline, the triggering event needs values in user, src_host and dest_host, and at least one sequence must group by one of those fields. Design identity-centred rules with that in mind.

Sharing and version control

Rules can be exported and imported, and Sigma rules can be converted through the Share Correlation Rules feature. Keep exported rules in a repository with review, as described in the Detection as Code Guide, so a rule change has an author, a reason and a rollback point.

Controlling noise: suppression and auto-disable

Exabeam gives three noise controls on each correlation rule, plus an automatic safety net. Use them in this order.

1. Fix the logic first: narrow the query or raise the count threshold if most triggers are benign.
2. Suppress Repeating Trigger: set a suppression period so repeated triggers within it are suppressed. Good for conditions that persist for hours once true.
3. Granular Suppression: suppress repeats per value of selected grouping fields (it requires Group by Field or common properties), so one noisy host does not hide the same pattern on a different host.
4. Know the safety net: the auto-disable option sets a rule to Stopped above 500 sequence matches or 50 triggers in five minutes. Treat any Stopped rule as an incident for the detection team: it means the rule was too broad, or something genuinely large is happening.

Record a reason and an owner for every suppression and review them quarterly. The Alert Fatigue Reduction Guide covers the triage-side practices that go with these settings.

Tuning behavioural analytics

Advanced Analytics profiles users, hosts, machines and applications with histogram-based statistical models, and its Risk Engine adds risk from anomalies and from fact-based inputs such as privilege levels, security alerts and threat intelligence. Asset criticality also factors into risk.

• Sessions: a user session closes after 5 hours of inactivity or 24 hours maximum; an asset session covers one 24-hour period from midnight to midnight UTC. Scores accumulate per session, so review risk by session, not by single event.
• Notable threshold: users and assets are notable when a session score meets or exceeds the configured threshold, default 90. Notable assets need Entity Analytics. Change the threshold only with evidence from closed cases, and record why.
• Model aging: Advanced Analytics cleans up and rebuilds models every 16 weeks by default. Expect behaviour change after reorganisations, mergers and large migrations; plan extra review after those events rather than suppressing new alerts.
• Rule editing: default and cloned rules are edited in the Advanced Editor, which shows the rule code from rules.conf. Exabeam warns that changes can significantly affect the Analytics Engine and recommends the Advanced Editor only for those who understand the rule syntax. SAVE validates logic; SAVE & RELOAD ALL validates and reloads all rules.
• Prefer disable and revert to rewriting: rules can be disabled, enabled, cloned, reprocessed and reverted to out-of-the-box versions. Default rules may be deprecated in later updates, and an edited rule that depends on a deprecated default rule is disabled automatically, so keep a list of every edited default.
• Context tables: out-of-the-box, Azure Active Directory and Threat Intelligence Service context tables exist, and custom tables can be created or loaded from CSV. Accurate context (privileged groups, executives, service accounts, critical assets) is the single largest tuning lever, because it changes risk without touching model logic.
• Watchlists: Executive Users and Service Accounts watchlists are populated automatically. Analyst-created user or asset watchlists (asset watchlists hold up to 100 assets) can be set Public, Based on Role or Only Me.

Where identity fits

Most behavioural detections are identity detections: unusual logons, new hosts, odd hours. Two identity inputs decide their quality. First, account-to-person mapping: if service accounts and personal accounts are not distinguished, service account activity either floods the queue or is silently treated as normal. Keep the Service Accounts watchlist and context tables accurate, and give each service account an owner, as set out in How to assign owners to orphaned service accounts. Second, the platform's own identities: API keys used by integrations ("Connect Using API Key") and webhooks used by rule outcomes are machine credentials. Scope them, rotate them and review them alongside human administrator accounts. The Identity Threat Hunting Guide covers how to hunt the same signals manually.

Securing the tenant

A detection platform is a high-value target: whoever can edit a rule or a suppression can blind the SOC. Treat the tenant as a privileged system, as described in Securing the SIEM itself.

Note that Secured Resources restricts rather than grants: a role with no secured resources has unlimited data access, and only an Administrator with full access to the subscription can manage them.

Rolling out and changing detections

1. Baseline coverage: list priority sources, confirm parser health in Log Stream and check field population in Search.
2. Enable context: load context tables for privileged groups, executives, service accounts and critical assets before judging behavioural alerts.
3. Pilot rules in Test Mode: enable new correlation rules in Test Mode, review rule-trigger-test events for at least one business cycle, then turn on outcomes.
4. Promote with outcomes: start with Threat Center alerts only; add cases, email or webhooks once the rule has proven fidelity.
5. Measure and tune: use View Correlation Rules Metrics and Threat Center dashboards to track triggers and closures.
6. Roll back cleanly: disable (not delete) a misbehaving rule, revert edited out-of-the-box Advanced Analytics rules, and re-import the last known good export.

For the wider programme, see the Detection Engineering Guide.

Detection and measurement

• Parser health: share of enabled parsers in a healthy state, and the time from a parser health drop to fix.
• Rule fidelity: true positive rate per correlation rule over 30 days, from case closure reasons.
• Stopped rules: count of rules auto-disabled per month (target: falling).
• Suppression hygiene: percentage of suppressions with an owner, reason and review date.
• ATT&CK coverage: share of enabled rules carrying at least one MITRE ATT&CK technique tag.
• Notable review: share of notable users and assets reviewed within one working day.

Framework mapping

Common failure patterns

• Rules built on unparsed fields: a rule groups on a field the parser never fills, so it never triggers and nobody notices. Check Test Last 15 mins and parser health first.
• Evaluation delay too short: late-arriving sources miss the default 7 minute window and multi-sequence rules fail silently. Use the Log Delay Dashboard.
• Stopped rules left stopped: auto-disabled rules sit in Stopped status for weeks. Alert on rule status changes.
• Blanket suppression: Suppress Repeating Trigger used where Granular Suppression was needed, hiding the same pattern on other hosts or users.
• Service accounts treated as people: missing or stale service account context makes behavioural scores noisy, so analysts raise thresholds instead of fixing context.
• Edited defaults forgotten: heavily edited default rules are disabled automatically when the default they depend on is deprecated.

Practitioner checklist

• Review Parser Health Status weekly and after every new source.
• Put every new correlation rule in Test Mode before it creates alerts.
• Tag each rule with ATT&CK techniques, severity, owner and use case.
• Set Delay rule evaluation per source latency using the Log Delay Dashboard.
• Use Granular Suppression with a reason and review date instead of broad suppression.
• Alert on rules moving to Stopped status.
• Maintain context tables and the Service Accounts watchlist; assign owners to service accounts.
• Record every edit to default Advanced Analytics rules and any change to the notable threshold.
• Enforce MFA, IP-based access, custom roles and Secured Resources; forward audit logs.
• Export rules and parsers to a reviewed repository for rollback.

Standards and references

• Exabeam: New-Scale Security Operations Platform documentation
• Exabeam: Create a Correlation Rule from Scratch Using the Manual Rule Creator
• Exabeam: How Exabeam Models Work
• Exabeam: Advanced Analytics homepage, notable users and watchlists
• Exabeam: Log Stream Guide
• Exabeam: Secured Resources
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: UEBA Guide · SIEM Guide · SIEM vs UEBA · Detection Engineering Guide · Securing the SIEM itself