Insider Threat & UEBA Architecture That Survives Review

Q: What is UEBA and how is it different from DLP or SIEM correlation rules?

User and entity behaviour analytics builds per-entity and per-peer-group baselines of normal behaviour — working hours, systems touched, data volumes moved, authentication patterns — and scores deviations from those baselines, accumulating risk per entity over time. DLP and SIEM rules fire on actions matching a predicate: a file over a size threshold, a login from a blocked country. The difference matters for insider risk because the signature of an insider incident is usually a change of pattern by a fully authorised account rather than a single prohibited action; every gate that asks "is this user allowed?" answers yes. UEBA is architecturally four layers — entity resolution, baseline modelling, anomaly scoring, and risk aggregation over time — and the last layer is what separates it from plain anomaly detection: it is designed to catch the slow exfiltration where no single day crosses any threshold.

Q: Why do insider threat programmes so often fail?

Because they are bought as tools rather than built as programmes. The recurring failure sequence is: procurement of a monitoring platform without governance, response ladders or HR and legal integration; deployment with wall-to-wall scope that fails proportionality review and reads as distrust to employees; alert volume that overwhelms the analysts assigned to it; and quiet abandonment after the first year, usually just before or just after the incident it was bought to prevent. The two engineering gaps underneath are false-positive economics — genuine malicious-insider incidents are so rare that even good detectors produce overwhelmingly false alerts, and nobody priced the investigation load — and privacy architecture, without which the programme never gets sustainable access to the behavioural data it needs. Carnegie Mellon SEI's Common Sense Guide, the field's longest-running evidence base, puts organisational practices before technical ones for exactly this reason.

Q: What data sources does a UEBA deployment actually need?

Identity provider and authentication logs, SaaS and cloud audit logs, endpoint and DLP events, VPN and CASB telemetry — and, most importantly and most often omitted, the HR joiner-mover-leaver feed with resignation dates, role changes and offboarding state. Documented insider data-theft cases cluster in the window between resignation and departure, so leaver status is the single highest-value piece of context a risk-aggregation engine can hold. Entity resolution across these sources is the unglamorous foundation: accounts, devices and service principals must stitch into one identity, including contractors and non-human identities, or baselines fragment and score against the wrong history. Content capture — keystrokes, screen recordings, file contents — is not on the list: behavioural metadata catches the cases that matter at a fraction of the privacy exposure, and minimisation at emit is what keeps the telemetry itself from becoming a breach target.

Q: How should the false-positive load of a UEBA programme be estimated?

With arithmetic before procurement, not dashboards after. Take the monitored population, multiply by the expected weekly anomaly-surfacing rate, and multiply by investigation time: 10,000 identities at a well-tuned 0.5% weekly rate is roughly 50 investigations, at about 45 minutes each — approaching one full-time analyst — for a detection class whose true positives arrive quarterly. An untuned deployment surfacing 3–5% of entities buries the function entirely. The design responses are to price every detection concept in weekly analyst-hours and make an owner accept that cost; to tier the response so low scores decay silently and medium scores trigger automated context-gathering (leaver status, legitimate access changes, related tickets) that resolves the majority without a human; and to feed every benign resolution back into the baseline so the same on-call engineer is not re-investigated monthly forever.

Q: How does pseudonymised triage work and why does it matter?

Analysts investigate entity tokens — scores, event patterns, peer comparisons for entity E-4c19 — without seeing a name, photo or org-chart position. Unmasking the identity is a separate, governed step requiring two-person approval from security plus HR or legal, a recorded justification, and an audit log of every unmasking that is itself reviewed quarterly. This matters on three axes at once. Legally, it operationalises proportionality and data-minimisation requirements under GDPR-class regimes and supports works-council negotiations. Organisationally, it converts "security watches everyone" into "security investigates evidence", which is the difference between a programme employees consider fair and one that corrodes the trust the security function depends on. And analytically, it removes bias: the investigation proceeds on behavioural evidence rather than on what the analyst assumes about a named colleague.

Q: Can UEBA detect compromised accounts as well as malicious insiders?

Yes — and in most deployments the compromised account is the more frequent catch. When an external attacker operates with stolen valid credentials, every authorisation check passes, MFA may already have been defeated at session level, and signature-based detection has nothing to match; what remains anomalous is behaviour: access at unusual hours from unusual network paths, movement into systems the account never touched, data volumes outside the baseline. Service accounts and machine identities are a special case worth prioritising: their legitimate behaviour is far more regular than a human's, so their baselines are tighter, deviations are more significant, and their blast radius is often larger. A service principal that suddenly enumerates storage buckets it has never read is close to the cleanest signal behavioural analytics can produce, which is why the E in UEBA — entity, not just user — earns its place.

Q: Should UEBA run in the SIEM or on a security data lake?

Behavioural baselines need long lookback — ninety days minimum for stable baselines, a year to capture seasonality like quarter-end or annual-review patterns — and long lookback inside an ingest-priced SIEM is precisely the cost structure that pushes teams toward the security data lake pattern. Running UEBA over the lake also avoids duplicating a year of identity, SaaS and endpoint telemetry into a second proprietary store with its own retention pricing, and it puts the behavioural scores next to the DNS logs, cloud audit events and detection outputs they need to be correlated with during an investigation. The counterargument for SIEM-native UEBA is integration convenience: entity pages, watchlists and case management arrive prebuilt. A defensible middle path is scoring over the lake with results forwarded to the SIEM as enriched events, keeping the raw behavioural history out of ingest pricing while triage stays in the tooling analysts already use.

Q: What privacy and legal constraints govern employee behavioural monitoring?

In the EU, GDPR requires a lawful basis, proportionality, and usually a data protection impact assessment, while national labour law frequently adds works-council co-determination over monitoring systems; covert monitoring is legally fragile almost everywhere. In India, the DPDP Act's purpose-limitation and minimisation principles apply to employee data, and sectoral regulators add their own retention expectations. NIST SP 800-53's privacy and insider-threat control families treat these not as constraints on the programme but as part of its control set. The practical architecture that satisfies all of them: announced monitoring with documented scope, minimisation at the point of telemetry emission, pseudonymised analytics with governed unmasking, risk-tiered depth so the general population gets coarse signals while privileged and leaver-window accounts get full coverage, fixed retention with automatic deletion and a legal-hold exception path, and a governance body including HR and legal that reviews unmask logs and detection ROI on a schedule.