FACADE: High-Precision Insider Threat Detection Using Contrastive Learning

FACADE: High-Precision Insider Threat Detection Using Contrastive Learning

Speakers: Eli Verstein and Alex Katchilian, Research, Google

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=3CV1efZSHmQ

Reading Time: ~10 minutes

Type: Briefing

TL;DR

Google's FACADE system uses contrastive learning to score every user-resource access event across billions of activities per year, achieving detection of red team attackers within the top 0.01% most anomalous events. The system requires no labeled insider threat examples to train, instead bootstrapping from normal behavioral patterns, and is now publicly available as an open-source reference implementation on GitHub.

Introduction

Insider threats present a uniquely difficult detection problem. Unlike perimeter attacks that follow recognizable signatures, insider incidents involve legitimate credentials, authorized tools, and context-dependent behavior — making traditional intrusion detection systems almost useless. At Google, with over 180,000 employees and a culture of open collaboration, the problem is acute: an ad sales person accessing a TPU schematic is a red flag; a hardware engineer doing the same is completely normal. Context is everything.

FACADE (which stands for the system's approach to contextual anomaly detection) has been in production at Google since 2018 and processes over ten billion events per year to detect insider risk across Alphabet. At Black Hat 2025, Eli Verstein and Alex Katchilian presented the system's design, its novel training methodology, and a reference open-source implementation — making FACADE's architectural ideas accessible to the broader security community.

The Three Categories of Insider Threat

▶ Watch: Problem Framing (00:02)

FACADE is designed to catch three distinct forms of insider risk:

• Intentional threats — rogue employees abusing their access to exfiltrate trade secrets, such as accessing documents far outside their organizational role
• Unwilling threats — employees whose credentials and machines have been compromised by malware, with the attacker leveraging that legitimate access
• Accidental threats — well-meaning employees who inadvertently share sensitive data with parties not under NDA or through unapproved channels

The fundamental challenge is that all three categories involve actions that are often syntactically identical to legitimate behavior. There is no exploit signature to match, no malicious payload to block. A user querying a sensitive document in Google Workspace looks exactly the same whether they have a legitimate business reason or are staging an exfiltration.

System Architecture: User and Resource Embeddings

▶ Watch: How FACADE Works (08:02)

FACADE's core operation reduces to a single question: is it normal for this specific user to access this specific resource right now?

To answer that question at scale, the system maintains two types of dense vector representations:

Resource embeddings use what the team calls history-based featurization. Rather than analyzing document content (which would require expensive inference pipelines for each of billions of heterogeneous resources), FACADE represents each resource as the bag of user IDs that have previously accessed it. A TPU schematic accessed only by engineers in the hardware division produces a very different embedding than a widely shared company policy document. As new users access a resource, its embedding evolves automatically — no retraining required. The system handles the full spectrum of resource types: Google Docs, Sheets, Slides, SQL tables, RPC endpoints, URLs, and more, using a single universal scheme.

User embeddings capture both stable and unstable attributes. Stable attributes like job titles are handled via direct categorical featurization. High-cardinality, dynamic attributes — team assignments, project membership, meetings attended, code reviews — are represented using implicit social networks: a user's "project" feature is encoded as the bag of user IDs of everyone else assigned to the same project. This approach is naturally resilient to reorganizations, new employees, and shifting project landscapes, because the underlying vocabulary (user IDs) remains stable even as relationships change.

Both embedding types are then fed into a trained TensorFlow model that produces a compatibility score: high scores indicate anomalous access, low scores indicate normal behavior consistent with the user's role and history.

Training Without Labeled Examples: Contrastive Learning

▶ Watch: Training Strategy (10:02)

The most operationally significant innovation in FACADE is its training methodology. Almost all machine learning systems assume a labeled dataset of positive and negative examples. For insider threat detection, this is impossible: genuine insider incidents are vanishingly rare and often never formally confirmed.

FACADE sidesteps this problem entirely. The training dataset consists only of normal access events. The trick is in how pairs are constructed: a normal user embedding (hardware engineer) is paired with the correct resource embedding (TPU schematic) as a positive example; the same user embedding is then paired with an unrelated resource embedding (finance spreadsheet) as a synthetic negative example. By mixing and matching across the entire corpus of normal activity, the system generates an effectively unlimited balanced training dataset where the model learns to predict which user-resource pairs "make sense" given each entity's behavioral history — without ever needing to see a labeled insider event.

As Verstein explained, "We actually do not use at all any insider risk information. We only train with a very neat trick."

Aggregating Scores Across Activity Windows

▶ Watch: Score Aggregation (26:05)

Single-event scoring is necessary but not sufficient. Security analysts need to assess the cumulative risk of a user's entire activity window — a day or week of actions taken together. Naïve aggregation methods each have fatal flaws: averaging scores allows attackers to dilute malicious accesses with benign noise; summing rewards high-volume users regardless of behavior; taking the maximum ignores all but one event.

FACADE's solution is a two-step clustering approach. First, resource accesses within a scoring window are clustered in embedding space — similar resources (a presentation and a document in the same project area) fall into the same cluster. Then, the maximum score within each cluster is taken, and those cluster maxima are summed. This eliminates redundant anomalies (accessing ten files in the same sensitive project area shouldn't look ten times worse than accessing one), while ensuring attackers cannot dilute their score by performing large volumes of low-scoring accesses around a small number of high-scoring ones.

Red Team Evaluation Results

▶ Watch: Evaluation Design (30:05)

FACADE was evaluated against a structured red team exercise with 15 participants — all Google full-time employees familiar with internal tools — operating across three attack scenarios:

1. Media sharing platform scenario — attackers seeking YouTube's internal financial data, creator earnings, and ranking algorithms
2. Hardware product scenario — attackers seeking planning documents, design files, timelines, and schematics for the next Pixel phone
3. AI research scenario — attackers seeking unpublished papers, model weights, and source code for Google's next-generation AI systems

Participants were given only high-level playbooks and were free to use whatever internal access they could leverage. The operational budget was set at triaging only the top 10 users per day — a realistic constraint representing what a small analyst team could actually review.

Under these conditions, FACADE surfaced 4 of the 15 attackers within the daily top-10 list. More importantly, when the red team data was analyzed at the 0.01% threshold (the top most-anomalous events across millions of activities), nearly all red team actions were captured. The evaluation precision remains the explicit design target: FACADE is built to minimize false positives, ensuring that the cases analysts review are likely to be genuine.

Open Source Release

The team announced that a reference implementation of FACADE is now live on GitHub, including the featurization framework, embedding generation code, and training infrastructure. The researchers were explicit about scope: the system is designed for large-scale deployments and is unlikely to produce meaningful results on small datasets. "We don't believe that using FACADE on a small scale dataset is necessarily appropriate," Katchilian noted, but encouraged organizations with billions of events to experiment.

Notable Quotes

"There is no specific pattern to look for in the logs. There is no specific exploit signature to look out for because it's all about context." — Eli Verstein (04:01)

"We actually do not use at all any insider risk information. We only train with a very neat trick." — Eli Verstein (10:02)

"It's literally finding a needle in a haystack in a very accurate way, so the investigation team only have to look at a very, very few percentage." — Eli Verstein (06:01)

"Insider threats are low-incidence, high-impact attacks. They do require deep contextual analysis and understanding for detection." — Alex Katchilian (36:06)

Key Takeaways

• Context defeats signatures. Insider threat detection cannot rely on matching known-bad patterns; the same action is benign or malicious depending entirely on who performs it and why. Effective detection requires modeling behavioral expectations per user, not per action.
• Self-supervised training unlocks the approach. By using contrastive pairing of observed normal activity, FACADE eliminates the label scarcity problem that has historically made insider threat ML impractical.
• History-based featurization is the key primitive. Representing resources by who has accessed them, and users by who they work alongside, produces embeddings that are robust to distribution shift, naturally handle new entities, and require no content analysis.
• Score aggregation must be attack-resistant. Simple aggregations (average, sum, max) are all gameable by sophisticated attackers. The cluster-then-sum approach is explicitly designed to prevent score dilution.
• Scale matters. The authors are candid that anomaly detection of this type requires billions of events to produce reliable signal. Organizations considering the open-source reference implementation should calibrate expectations accordingly.

Slides are available via the QR code shown during the presentation. The reference implementation is available on Google's GitHub.