Skip to main content

 

Splunk Lantern

Detecting insider threats with RBA in Enterprise Security 8.x

A Security Operations Center (SOC) is overwhelmed by high volumes of generic detections, making it difficult to spot subtle insider threats. By implementing the Splunk Risk Based Alerting (RBA) framework, the SOC shifts its focus from individual detections to the holistic risk posture of identities and assets, leveraging contextual enrichment and scoring to drive more effective investigations and outcomes.

The information in this article applies to Splunk Enterprise Security (ES) versions 8.x.

Prerequisites

  • Access to Splunk Enterprise Security version 8.0 or later
  • Risk Analysis Framework enabled in the Splunk platform
  • Ingested data from at least one identity provider (for example, Active Directory, Okta) and endpoint monitoring solution
  • Permissions to view and tune finding-based detections and intermediate findings in Splunk ES
  • Familiarity with basic SPL (Search Processing Language)
  • Optional: Asset and identity enrichment configured

How to use Splunk software for this use case

As a SOC analyst, "alert fatigue" from generic detections often leads to missing subtle signs of insider threats. Risk-based alerting (RBA) in Splunk Enterprise Security allows you to focus on the identities and assets truly at risk by using context and scoring to surface the findings that matter most.

Step 1: Understand the RBA model and analyst workflow

The RBA model reframes alerting by focusing on risk objects (identities, assets) and risk events (individual behaviors).

  • Pre-RBA: Analysts triage individual, noisy detections.
  • With RBA: Analysts review findings—aggregated, context-enriched events triggered when risk scores surpass defined thresholds.

Step 2: Best practices for SOC analysts using RBA

  • Start simple, iterate rapidly: Deploy core high-value risk rules and iterate based on effectiveness.
  • Align with threat scenarios: Build rules mapping to insider threat TTPs (for example, unusual data access, privilege escalation). Configure MITRE ATT&CK tactics in the detection editor so they appear in findings to speed up triage.
  • Enrich with context: Use asset criticality, user role, and business unit to increase fidelity (for example, higher weight for executive accounts).
  • Leverage Threat Intelligence Management (TIM) and User & Entity Behavior Analytics (UEBA): Use TIM to validate findings against external data and UEBA to establish baselines for normal activity to catch anomalies like impossible travel.
  • Trigger automation with risk incident rules: Use SOAR automation to initiate playbooks (for example, isolating an endpoint) when a risk score exceeds a critical threshold.
  • Monitor and tune regularly: Use the Risk Analysis dashboard to monitor trends and eliminate noise.
  • Document and share feedback: Maintain a feedback loop with detection engineers to refine risk logic.

Step 3: Actionable daily steps for SOC analysts

  1. Review the Analyst Queue: Focus on identities/assets with the highest accumulated risk scores.
  2. Prioritize Investigations: Use context like roles and recent behavior to assess legitimacy.
  3. Collaborate and tune: Flag missed or noisy detections for tuning.
  4. Leverage aggregation: Use the Intermediate Findings view to see a timeline of correlated risk events, helping spot the "death by a thousand cuts" patterns common in insider threats.

Step 4: Continuous improvement and metrics

  • Measure What matters: Track Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), and false positive rates.
  • Post-incident reviews: Identify detection gaps and refine risk rules after incidents.
  • Iterative tuning: Adjust rules and risk weights based on real-world results.

Additional resources

The following resources might help you understand and implement this guidance: