UEBA Insider Threat Detection: Splunk UBA and Exabeam Deployment, Behavioral Baselining, and Risk Scoring
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Deployed a Splunk UBA instance last year in a 3,000-employee environment with what seemed like sufficient data sources: Active Directory authentication, Windows Security events, and web proxy logs. After the 30-day baseline period, the platform generated 40+ risk score alerts on the first day of live alerting — nearly all of them false positives caused by legitimate but unusual work patterns: the security team's own scanning activity appearing as reconnaissance, late-night deployments from the DevOps team appearing as anomalous after-hours access, and the help desk's cross-system access appearing as lateral movement.
The root causes were two deployment mistakes: the peer group configuration had placed all IT staff in a single group rather than separate groups for security, DevOps, and help desk (very different behavioral profiles), and the DLP data source was not connected (making the data movement model run on incomplete information that created spurious anomalies from normal file access patterns). Both issues were correctable, but they illustrate why UEBA deployments that produce noisy alerts for the first 90 days are the norm rather than the exception. The fixes are not difficult — they require accurate peer group definition and complete data source coverage — but they require understanding why the noise is happening before tuning.
Data source integration: building the behavioral baseline from the right inputs
UEBA behavioral models are only as good as the data they learn from. Missing data sources create blind spots in the behavioral profile that cause two problems: genuine insider threat indicators are not detected (because the relevant activity type has no data), and the behavioral models compensate with spurious correlations from available data that generate false positives. The data source integration phase is the most important phase of UEBA deployment and should not be rushed to get the platform into active alerting faster.
Prioritize DLP and file access data sources even if they require additional deployment effort
DLP policy violation events and file access logs are the highest-signal data sources for insider threat detection because they directly measure data handling behavior rather than inferring it from proxy indicators. If a DLP solution is not yet deployed in the environment, connect the cloud storage activity logs (Microsoft 365 purview audit, Google Workspace Drive audit) as a partial substitute that captures the most common cloud-based exfiltration channels. For file server access, enable Object Access auditing on Windows file servers for the file shares containing sensitive data (not all shares — the event volume from full file server auditing is prohibitive), configure them to forward to the SIEM, and connect the SIEM log source to UEBA. The combination of DLP events, cloud storage uploads, and file server access provides the three channels most commonly used for insider data exfiltration and enables the multi-indicator correlation that distinguishes genuine exfiltration from normal file access variation.
Connect badge access data for after-hours physical and logical correlation if your badge system supports log export
Physical badge access correlated with logical system access is a high-specificity insider threat indicator because the combination (working late and accessing sensitive systems with no physical presence on-site) is genuinely rare in normal work patterns. Many UEBA platforms support badge access log integration if the physical access control system can export events in a standard format (CSV, syslog, or API). Connect badge reader entry/exit events to UEBA and enable the after-hours logical access anomaly model, which flags users who access sensitive systems from unusual locations without corresponding badge records showing physical office presence. The false positive rate on this model is typically very low because the combination of anomalies is genuinely unusual — legitimate remote access from authorized WFH employees is recognized by the VPN context, distinguishing it from post-termination access using retained credentials.
Alert management: risk score tuning and investigation workflow
A UEBA platform that generates 40 alerts per day in a team of three analysts is as ineffective as no UEBA at all — the alert volume exceeds analyst capacity and trains responders to ignore or batch-close alerts without investigation. Alert volume management through threshold tuning, peer group refinement, and exclusion rules is an ongoing operational process that requires structured feedback from analysts into the model configuration. Most UEBA platforms reach a stable, useful alert cadence after 90 days of tuning from the initial go-live.
Implement a recurring risk score review meeting where analysts classify each high-score user as true positive, false positive, or monitoring
Structure the UEBA alert workflow as a recurring risk score review meeting where security analysts review all users who crossed the alert threshold in the recent period, classify each as true positive (escalate to HR and legal for investigation), false positive (document the benign explanation and tune the model), or monitoring (behavior is anomalous but context suggests a benign explanation — watch for additional indicators in the next cycle). This structured review approach is more effective than individual analyst alert triage for UEBA because insider threat indicators often require knowledge of organizational context (a user with a resignation submitted, a pending M&A event, a specific project deadline) that is not visible in the UEBA data alone. The security analyst who identified the alert and the HR business partner assigned to the relevant department should both attend the review meeting so that UEBA data is interpreted with full organizational context rather than in isolation.
Configure risk score decay to prevent stale anomalies from keeping users in high-risk status indefinitely
Configure the UEBA risk score decay rate to reduce a user's composite risk score over time when no new anomalous behavior is detected, preventing false positives from a one-time unusual event (working late on a product launch, accessing a new file share for a cross-departmental project) from keeping a user in high-risk status for weeks. Most UEBA platforms allow decay rate configuration as a half-life in days: a 7-day half-life means a risk contribution from a single anomaly decays to 50% after 7 days and to below 10% after 23 days. Set the decay rate based on the insider threat investigation SLA — if the team reviews high-risk users on a 7-day cadence, a 7-day decay ensures that stale anomalies age out within one review cycle. A user who returns to baseline behavior after a single unusual event should not remain on the analyst radar for more than two to three weeks without new supporting indicators.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
UEBA insider threat detection is effective when three conditions are met: complete data source coverage including DLP, file access, authentication, communication metadata, and ideally physical badge access; a 30-60 day behavioral baseline period before alerting goes live; and structured feedback-driven threshold tuning for the first 90 days of active operation. Peer group configuration based on actual job function rather than org chart hierarchy is the single most impactful configuration decision for reducing false positive rates. Connect watchlist management to HR processes so that elevated-risk employees are monitored at lower thresholds without requiring analysts to track HR events manually. Build an investigation playbook reviewed by legal counsel before the first true positive alert arrives, so that evidence collection is legally defensible and investigation procedures are consistent. UEBA is a detection tool, not a conviction tool — its output is an investigation trigger, not a disciplinary action.
Frequently asked questions
What data sources does UEBA require for effective insider threat detection?
Effective UEBA insider threat detection requires a minimum of four data source categories to establish meaningful behavioral baselines. Identity and access data: Active Directory authentication events (Windows Event IDs 4624, 4625, 4648, 4768), VPN authentication logs, and privileged access management (PAM) session logs provide the who-logged-in-from-where behavioral baseline. File and data activity: DLP solution logs with data movement events, Windows file share access logs (Event ID 5145), and cloud storage activity logs (Microsoft 365 audit logs, Google Workspace admin logs, Box/SharePoint logs) provide the what-data-was-accessed behavioral baseline. Communication data: email metadata (sender, recipient, attachment size — not content), collaboration platform activity (Teams, Slack message volume patterns), and web proxy logs with category and upload volume data provide communication behavioral baselines. Physical access: badge reader entry and exit logs correlated with logical system access provide the working-hours and location baseline. Missing any of these categories significantly reduces UEBA detection coverage — a UEBA deployment with only authentication logs will detect account compromise but miss data exfiltration patterns.
How do I configure peer group analysis to reduce UEBA false positives?
Configure peer group analysis in UEBA by defining groups of users with similar behavioral profiles based on job function, department, seniority, and location rather than relying on organization chart hierarchy alone. In Splunk UBA, import Active Directory organizational unit and group membership data to automatically assign peer groups, then review and adjust the group assignments to ensure each group contains users with genuinely similar work patterns. A developer who works late nights and accesses multiple code repositories is behaving normally within a peer group of developers, but would appear as a high-anomaly outlier in a peer group of sales representatives. For users who are outliers within their peer group (executives, security researchers, system administrators), create small peer groups or exempt them from specific behavioral models that are not meaningful for their role — an administrator's access to many systems across the domain is expected, not anomalous. Review peer group assignments when users change roles or departments, since a recently promoted employee may appear anomalous in their old peer group while their new role access patterns develop.
How long should the UEBA behavioral baseline period be before enabling alerting?
Allow a minimum of 30 days of data collection before enabling UEBA risk score alerts to give the behavioral models sufficient historical data to distinguish normal individual variation from genuine anomalies. During the baseline period, ingest data from all required data sources but keep risk score alerting disabled — the UEBA platform is learning what normal looks like for each user rather than flagging anomalies. After 30 days, run a baseline quality check: pull the risk score distribution for all users and verify that fewer than 5% of users have scores above 60 without manual investigation showing a genuine concern. A normal risk score distribution in a stable environment should be right-skewed with most users below 30 and a small number of users between 30-60. If more than 10% of users are above 60 after 30 days of baseline, the scoring thresholds or peer groups need adjustment before enabling active alerting. For environments with high staff turnover or frequent role changes, extend the baseline period to 60 days to reduce the noise from new employee behavioral profiles that appear anomalous during their first weeks on the job.
How do I build a UEBA watchlist for high-risk individuals?
Build a UEBA watchlist for individuals who represent elevated insider threat risk based on non-technical indicators that HR or management have flagged, without requiring specific behavioral evidence of malicious activity. Common watchlist trigger events: employees who have submitted resignation or been notified of termination (heightened risk of data exfiltration in the two weeks before departure), employees under active HR investigation for policy violations or misconduct, employees who have received negative performance reviews and expressed dissatisfaction, and employees with access to particularly sensitive data (crown jewels systems, M&A target information, customer financial data). Adding an employee to the UEBA watchlist lowers the risk score threshold at which analysts are notified (e.g., alert at score 40 rather than 60) and may activate additional behavioral models (USB monitoring, email recipient anomaly detection) that are not run for all users. Watchlist management must have strict access controls — only HR, legal, and designated security personnel should be able to view or modify watchlist status — and a documented legal review process to ensure monitoring of specific individuals complies with local employment law and privacy regulations.
How do I configure Splunk UBA for data exfiltration detection?
Configure Splunk UBA for data exfiltration detection by ensuring the three primary exfiltration data sources are connected and the multi-event correlation model is active. Connect DLP solution logs with UBA's DLP connector (Symantec DLP, Forcepoint, Microsoft Purview) to provide policy violation events including data classification, volume, and destination. Connect Windows file share access logs (Security Event ID 5145 for Detailed File Share) to detect users accessing file shares they do not normally use or accessing unusually high volumes of files. Connect web proxy logs with upload volume data to detect large HTTP/HTTPS POST transfers to cloud storage sites (Dropbox, Google Drive, personal OneDrive, SendSpace). In Splunk UBA, enable the data exfiltration anomaly model which correlates: DLP violations this week vs. baseline DLP violation rate for this user and peer group, file server access volume this week vs. baseline, web upload volume this week vs. baseline, and whether the user is on the watchlist or approaching a role change date. A user who triggers all four indicators simultaneously generates a high risk score even if each individual indicator is borderline, because the combination is significantly more anomalous than any single data point.
How do I tune UEBA alert thresholds to reduce false positive rates?
Tune UEBA alert thresholds through an empirical feedback process rather than accepting vendor default thresholds, which are calibrated for average environments rather than yours. Start by reviewing the first two weeks of alerts after enabling alerting (after the baseline period): for each alert, classify it as a true positive (genuine anomalous behavior worth investigating), a false positive (normal behavior for this specific user or role), or uncertain. For false positives, identify the specific behavioral models and data sources that contributed most to the risk score and adjust the model weights for those inputs downward, or add the user's normal behavior pattern as an exclusion if it is role-specific. For a threshold tuning cycle: if more than 30% of alerts in a week are classified as false positives, lower the model weight for the contributing models or raise the alert threshold by 5-10 points. If true positive alerts are below 1 per analyst per week, the threshold may be set too high and should be lowered incrementally. Most mature UEBA deployments reach a steady state of 3-8 high-quality alerts per analyst per week after 90 days of threshold tuning.
How do I build an insider threat investigation playbook for UEBA alerts?
Build a UEBA insider threat investigation playbook that standardizes the investigation steps for high-risk-score alerts while protecting employee privacy and maintaining legal defensibility. The playbook should define: alert triage (who receives the initial alert — security analyst, not HR or manager), initial review steps (examine the risk score contributors in the UEBA timeline, assess whether the behavioral anomalies have a plausible benign explanation based on known context), escalation criteria (what risk score, finding type, or combination of indicators requires escalating to HR and legal versus continuing technical investigation), evidence collection steps (SIEM log queries to gather supporting evidence, which systems' logs to pull, how to preserve chain of custody for potentially relevant evidence), and case closure criteria (what constitutes a true positive requiring HR action, a false positive requiring only model tuning, or an inconclusive finding requiring ongoing monitoring). The playbook must be reviewed by legal counsel to ensure investigation procedures comply with local employment law, particularly around monitoring notice requirements and data retention limitations. Without a playbook, UEBA alerts become investigation free-for-alls where different analysts take different approaches and evidence that might be needed for HR action is not properly preserved.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.