Detecting Insider Threat With Ueba

Detecting Insider Threat with UEBA

Overview

User and Entity Behavior Analytics (UEBA) moves beyond static rule-based detection to model normal behavior for users, hosts, and applications, then flag statistically significant deviations that may indicate insider threats. Using Elasticsearch as the analytics backend, this skill covers building behavioral baselines from authentication logs, file access events, and network activity, computing risk scores using statistical deviation and peer group comparison, and correlating multiple low-confidence indicators into high-confidence insider threat alerts.

When to Use

Trigger phrases:

• "detecting insider threat with ueba"

• "Implement User and Entity Behavior Analytics using Elasticsearch/OpenSearch to b"

• When investigating security incidents that require detecting insider threat with ueba

• When building detection rules or threat hunting queries for this domain

• When SOC analysts need structured procedures for this analysis type

• When validating security monitoring coverage for related attack techniques

Prerequisites

• Elasticsearch 8.x or OpenSearch 2.x cluster with security audit data
• Log sources: Active Directory authentication, VPN, DLP, file server access, email
• Python 3.9+ with elasticsearch client library
• Baseline period of 30+ days of normal user activity data
• Defined peer groups based on department, role, or job function

Steps

# Example: IOC detection
import re

IOC_PATTERNS = {
    "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
    "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
    "hash_md5": r"\b[a-f0-9]{32}\b",
    "hash_sha256": r"\b[a-f0-9]{64}\b",
}

def extract_iocs(text: str) -> dict:
    return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}

1. Scope the task — define objectives, boundaries, and success criteria
2. Gather information — collect all necessary data and context before proceeding
3. Execute the core workflow — follow the domain-specific steps methodically
4. Validate results — verify outputs against expected outcomes or baselines
5. Document findings — record results, anomalies, and recommendations

Step 1: Ingest and Normalize Activity Logs

Configure log pipelines to ingest authentication, file access, email, and network logs into Elasticsearch with a unified user identity field.

Step 2: Build Behavioral Baselines

Calculate per-user baselines for login times, data volume, application usage, and access patterns over a rolling 30-day window using Elasticsearch aggregations.

Step 3: Calculate Anomaly Scores

Compare current activity against baselines using z-score deviation and peer group comparison to generate per-user risk scores.

Step 4: Correlate and Alert

Combine multiple anomalous indicators (unusual hours + large downloads + new system access) into composite risk scores that trigger SOC investigation workflows.

Expected Output

JSON report containing per-user risk scores, anomalous activity details, peer group deviations, and recommended investigation actions.

When NOT to Use

• You need to perform the attack to test detection (use performing-* skills)
• Task is about analyzing past incidents (use analyzing-* skills)
• You need to implement detection rules (use implementing-* skills)
• Task is about threat hunting proactively (use hunting-* skills)
• You don't have access to logs or monitoring data
• Task requires incident response (use IR skills)

Red Flags

• Performing actions without explicit written authorization from the asset owner
• Testing against production systems without a defined scope and rules of engagement
• Acting on threat intelligence without validating source reliability
• Sharing classified or sensitive indicators without proper handling procedures
• Alerting threat actors to detection capabilities through visible response actions

Process

1. Reconnaissance — Gather target information, identify attack surface, enumerate services
2. Analysis/Exploitation — Execute the technique, analyze results, document findings
3. Reporting — Document IOCs, write findings, provide remediation recommendations

Verification

• All steps executed successfully against a test environment before production use
• Output documented with screenshots or logs demonstrating expected behavior
• Results validated against known-good baselines or reference implementations
• Documentation complete enough for another analyst to reproduce findings

Anti-Rationalization Table