An Analysis of Insider Threat Detection: Detection Metrics and Coverage

Introduction

Hi, this is faper from Team H4C's D4C group.

The insight I want to share today is an insider threat detection methodology. I picked this topic because there don't seem to be many tech blogs in Korea that talk about how to think about insider threat detection and response in a structured way, so I wanted to share some lessons based on my own experience. I started my career in incident analysis and response, moved through several domains, and currently work in Detection Engineering and security event analysis. One thing up front: every scenario, number, and example in this post is generalized and unrelated to any specific organization's actual implementation.

The reason insider threat detection scenarios are rarely published is simple. Publishing the specifics of how you detect insider threats is itself a risk, and in a fundamentally locked-down environment, most of this gets blocked at the solution layer anyway. Just like companies prevent employees from installing KakaoTalk or Telegram on corporate machines, the dominant approach has been to enforce strict cyber hygiene.

But times have changed. We've moved past the stage of merely wanting to bring AI into the workplace; we're now at the point where not using it means falling behind on productivity. You can no longer cover this with a simple "this program is dangerous, so we block it." What is actually risky, what needs to be controlled, and how do you structure the coverage into a detection matrix to decide the level and scope of control? I want to share my thinking on these questions, and I hope it serves as a useful learning share for security teams everywhere that are designing insider threat detection.

1. DLP by Generation

Generation	Core question	Detection basis	Control point	Representative techniques	Limitations
Gen 1 (Pattern)	"Does this file contain a sensitive pattern?"	Regex, keywords, national ID / card number formats	Network perimeter, mail gateway	Pattern matching, proxies	False-positive explosion; helpless against encryption, compression, and screen capture
Gen 2 (Content)	"Is this file our company's data?"	Fingerprinting, classification labels, document signatures	Endpoint agents, USB/printers	EDM/IDM, file tagging	Labels are applied by humans → unlabeled data becomes invisible
Gen 3 (Context)	"Who is sending it, where, and why?"	User behavior baselines, channel risk	SaaS/cloud (CASB), collaboration tools	UEBA, CASB, risk scoring	You can see the behavior but not where the data came from → "something's off, but we can't say what left"
Gen 4 (Lineage)	"Where was this data born, and what transformations did it go through to get here?"	Data lineage + transformation history + behavioral context	The points where data is created/queried (DB query gateways, data warehouses, Git/Wiki/Drive APIs, internal service backends). Instrumentation lives at the source itself, not at the perimeter (network) or the endpoint	Source tagging (attaching origin identifiers to query results and documents), derivative tracking (tag inheritance across copy, compression, capture), partial matching of content fingerprints (identifying source fragments inside prompts and chat payloads), LLM proxies / AI gateways, graph-based propagation analysis (source → user → channel)	High instrumentation cost (every source needs a tagging pipeline); channels where tags don't inherit (personal phone photos, verbal transfer) remain blind spots

Let's start with a simple story. We want to stop internal data from being exfiltrated. What exactly is internal data, where does external begin, and what counts as exfiltration? And you said you want to stop it, but how exactly do you block it?

Gen 1 DLP is "pattern" based. You decrypt all traffic leaving your gateway and run regexes for national IDs, card numbers, and account numbers. On a match, you block or alert. It's intuitive, and from a compliance-audit standpoint it's still a valid approach today. The problems are threefold. First, false positives explode. Thirteen-digit numbers are everywhere, and a regex cannot tell test data from real customer data. Second, evasion is trivially easy. One encrypted archive neutralizes pattern matching, and a screen capture makes the text disappear entirely. Third, some sensitive data has no pattern. Source code, M&A review documents, and new-business strategy materials have no "format" a regex could catch.

That's where Gen 2, "content" based DLP comes in. The question shifts from "is there a pattern" to "is this our company's data." You fingerprint sensitive documents (EDM/IDM) and compare similarity, and you attach classification labels to documents and enforce controls based on those labels. It's a step forward, but it rests on a fatal assumption: labels are applied by humans. Unlabeled data is invisible to the system, and no real organization has accurate labels on every document. Also, copy a single table out of the original into a new document and the fingerprint breaks; the derivative slips outside your controls.

Gen 3 shifts the perspective from data to people. UEBA is the representative example. You build baselines per individual and per peer group and catch "behavior that differs from usual." Uploading 50x your normal volume to a personal cloud at 3 a.m. is suspicious even if you don't know the content. Detection coverage genuinely expanded a great deal with Gen 3. But a hole opens up on the other side: you can see the behavior, yet you don't know what the data is or where it came from. When an incident breaks, the first question from leadership is always the same: "So what exactly left?" With a Gen 3 stack, there comes a moment when you have to answer, "We're certain there was a bulk upload, but we can't identify the contents." Estimating breach scope, determining legal notification obligations, notifying affected customers: all of it hinges on "what left," and yet you can't answer it.

So the frame I'm proposing in this post is Gen 4, "lineage" based DLP. The core idea is to move the control point from the perimeter (network) or the endpoint to the source where data is born. The moment a DB query result, a Git repo, or an internal wiki document is accessed, you assign an origin identifier, and you instrument things so the tag is inherited even as the data is copied, compressed, or transformed. Then the question Gen 3 couldn't answer, "what exactly left," becomes answerable through the source key.

In the AI era, I believe this shift is close to mandatory rather than optional. The data that goes into an LLM prompt is not a "file" but a fragment. Copying 20 rows queried from a customer table and pasting them into a prompt is completely invisible to Gen 1 and Gen 2 DLP, which see the world in units of files, and to Gen 3 it only looks like "the user typed something into a browser." Only when partial matching of source fragments (identifying pieces of a source fingerprint inside a prompt payload) becomes possible does this channel enter your detection scope.

2. Insider Threat Detection Matrix (Gen 4 DLP)

2-1. Defining the Axes

Rows are threat scenarios; columns are the four stages of the data lifecycle plus actor context. Each cell records "which signal, from which log, and with how much confidence" you can capture.

Axis	Definition	Primary data sources
Origin	The point where data is first accessed or created	DB audit logs, Git/Wiki/Drive access logs, API gateways, DW query history
Transform	Actions that change the form of the original	Endpoint telemetry (file creation/rename/compression/encryption), clipboard events, screenshot API calls, print spools
Movement	The path by which data crosses a control boundary	Proxy/SWG, mail gateway, collaboration-tool sharing events, USB/Bluetooth, personal cloud uploads, LLM proxy
Destination	The nature of the final destination	External domain reputation, personal-account identification, competitor / unapproved SaaS lists, public repositories
Actor	The risk context of the person themselves	HR events (resignation notice, performance review, reorg), permission change history, working-hours/location baselines

2-2. The Matrix

Threat scenario	Origin	Transform	Movement	Destination	Actor	Source-tracking join key
S1. Bulk exfiltration by a departing employee	Browsing folders/repos not normally accessed; access volume spiking vs. a 30-day baseline	Bulk compression (zip/7z), encrypted archives, batch file renaming	Personal cloud / webmail uploads, USB mounts	Personal account domains, unapproved storage	Resignation-notice window of D-30 to D+7; right after performance results are delivered	File hash + source path tag → hash matching inside the archive
S2. Developer source code leak	Cloning repos outside one's responsibility, full org clones, bulk tag/branch fetches	Repackaging after deleting .git, copying code as plain text	Push to personal GitHub, Gist, pastebins, file transfer via messengers	Public repositories, personal accounts	Right after project handover; when job responsibilities change	Repo identifier + commit hash → code fingerprint in external repositories
S3. Leakage via AI tool input	LLM session starting right after querying customer data / source code	Clipboard copy → paste into browser/IDE, file attachment	Unapproved LLM domains; approved LLM but personal account; local model serving ports	External LLM providers; accounts without training opt-out configured	Productivity pressure; new hires unfamiliar with policy	Fingerprint of the source query result → partial matching against the prompt payload
S4. Privilege abuse / excessive lookups	Customer lookups unrelated to work (celebrities, acquaintances), abnormal lookups per hour, full-table SELECTs	Screen captures of query results, Excel exports	No exfiltration (the viewing itself is the incident), or captures sent via personal messenger	Personal messengers	Support/operations roles; recently expanded permissions	Looked-up subject identifier + the person looking → repetition/patterns
S5. External sharing via collaboration tools	Documents with sensitive labels, or documents whose source is a DB/repo	Changing link permission to "anyone with the link," inviting external guests	The sharing event itself is the movement	External-domain guests, personal email addresses	Users actively collaborating with partners (watch for false positives)	Document ID → whether the source data tag was inherited
S6. Screen / physical channels	Abnormal dwell time on sensitive screens, rapid pagination sweeps	Screenshot APIs, screen recording, printing	Carrying out printouts; personal phone photos (an undetectable zone)	Physical	Working remotely or off-site	Source-identifier watermarks rendered on screen
S7. Low & Slow exfiltration	Small daily volumes, deliberately kept under the baseline	Repeated creation of small files	Small daily mail attachments, chat files	The same external recipient, repeatedly	Long tenure, broad permissions	Cumulative totals of source tags (daily → weekly → quarterly rollups)
S8. Collusion / proxy exfiltration	A colleague querying data the person has no permission for	Colleague → internal transfer to the person, then exfiltration	Via internal messenger/drive, then external	External	Relationship between the two actors (not on the same team, sudden spike in communication)	The propagation graph of source tags crossing user boundaries

All of the threat scenarios here are exfiltration scenarios anyone could easily come up with. What do you think? Could every possible leak scenario in your organization be mapped onto this matrix?

2-3. Risk Scoring (How to Combine the Cells)

The power of the matrix comes not from any single cell but from cells being linked together by the source key. The formula I propose is:

Risk = Origin_Sensitivity × Transform_Suspicion × Channel_Risk × Actor_Context

Factor	0.5	1.0	2.0	3.0
Origin_Sensitivity	Public material	Internal, general	Customer PII / source code	Regulated data (financial transactions, credentials)
Transform_Suspicion	No transformation	Simple copy	Compression / renaming	Encrypted archives, captures, format conversion
Channel_Risk	Approved channel + corporate account	Approved channel + personal account	Unapproved channel	Detection-evading channel (personal hotspot, local LLM, etc.)
Actor_Context	Within baseline	Slight deviation	Within an HR event window	HR event + permission anomaly

Score	Response
< 2	Log only (retain source tags)
2 ~ 8	Analyst queue, triage within 24 hours
8 ~ 27	Immediate alert, user verification procedure
> 27	Session block + account isolation + Legal/HR engagement

The choice of multiplication is deliberate. In an additive model, "non-sensitive data sent through a strange channel" and "sensitive data sent through a normal channel" end up with similar scores. In a multiplicative model, if any single axis is at 0.5 (normal), the overall score gets suppressed, and the score only spikes when multiple axes are elevated at the same time. That is precisely the nature of insider threats: not a single event, but simultaneous deviation across axes. The weights and score bands in the tables above are illustrative examples; the real values must be redesigned around your organization's data classification scheme and response capacity.

3. From Matrix to Detection Rules

The matrix is a map, not a detection rule. This section covers the order of operations and implementation points for turning the map into actual SIEM rules.

3-1. A Reality Check on Data Sources

Filling every cell of the matrix would require nearly every log in the organization. That's not realistic, so you prioritize by coverage relative to acquisition difficulty.

Data source	Acquisition difficulty	Axes covered	Scenarios covered	Notes
Proxy/SWG	Low (most orgs already have it)	Movement, Destination	S1, S3, S7	The place you can start today
Mail GW / collaboration-tool audit logs	Low	Movement, Destination	S1, S5, S7	Collected via SaaS APIs; schema normalization required
Endpoint telemetry	Medium	Transform	S1, S2, S6	EDR events can be reused; clipboard needs separate instrumentation
Git/Wiki/Drive access logs	Medium	Origin	S2, S5	The audit logs often exist, but nobody looks at them
DB audit logs	High	Origin	S3, S4, S8	Performance concerns require negotiation with ops; far easier if traffic already flows through a query gateway
HR event feed	High (an organizational problem, not a technical one)	Actor	Weighting across everything beyond S1	A data-sharing agreement with Legal and HR comes first
LLM proxy	High (new build)	Movement	S3	Realistically, bundle it with an AI gateway rollout

Worth noting: the HR event feed is technically the easiest and organizationally the hardest. The very fact that the security team receives resignation-notice data is sensitive, so before any technical design you need to document and agree on data minimization (only whether someone is leaving and the D-day, never the reason) and access controls.

3-2. Implementing Source Tagging

Source tagging, the core of Gen 4, consists of three components.

(1) Tag issuance: At the gateway where data is accessed, attach an origin identifier to the result. For a DB, the query gateway issues a tag of the form {source: <source identifier>, query_id, user, ts} and stores a fingerprint of the result set alongside it. For Git, the repo identifier plus commit hash is already a natural tag.

(2) Fingerprint storage: A whole-file hash breaks the moment a single character changes, so you need a scheme that supports partial matching. The baseline approach is shingling: splitting the result set into fixed-size chunks and computing rolling hashes, with text normalization (unifying whitespace and encoding) applied before fingerprinting, without exception. The store grows quickly in query-heavy organizations, so apply it selectively starting from the most sensitive sources and set retention periods.

(3) Derivative inheritance: On the endpoint, when "a process that read a tagged file writes a new file," the tag is inherited. Using the EDR's file lineage events, you can follow the data through compression and renaming. The clipboard is where inheritance breaks, and from that point the partial fingerprint matching from (2) takes over.

3-3. Example: The S3 Rule (Leakage via AI Tool Input)

Taking S3 as an example, the correlation logic in SPL-style pseudocode looks like this. This is not a production rule; it's an example to show the structure, and the sensitivity threshold S, time window T, and alert threshold R are values each organization sets by policy.

spl

# Origin: query against a sensitive source
| tstats ... from datamodel=DB_Audit
    where DB_Audit.sensitivity >= S
    by DB_Audit.user, DB_Audit.query_id, _time

# Transform: clipboard copy followed by paste into a browser/IDE
| join type=inner user
    [ search index=endpoint sourcetype=clipboard_event
      | where match(dest_process, "browser|ide") ]

# Movement: LLM domain session (channel risk managed via a policy lookup)
| join type=inner user
    [ search index=proxy category=llm_provider
      | lookup llm_channel_policy domain OUTPUT channel_risk ]

# Time window: LLM session begins within T of the source query
| where llm_session_time - query_time < T

# Actor weighting and scoring
| lookup hr_events user OUTPUT actor_context
| eval risk = origin_sensitivity * transform_suspicion
              * channel_risk * actor_context
| where risk >= R

Three structural points to notice. First, the join key is the person (user), and the verdict key is the time window. A "sensitive query" and an "LLM session" are each normal work on their own, but the story changes when they connect within a short window. Second, adding the partial fingerprint matching from 3-2 makes confidence jump. If your LLM proxy can see the prompt payload, fragment matching between the payload fingerprint and the source fingerprint lets you determine "whether that data actually went in." This is the difference between temporal correlation (inference) and lineage tracking (evidence). Third, don't hardcode scoring factors into the rule; separate them into lookups. Sensitivity tables, approved LLM lists, and HR windows are values that keep changing, and separating rule code from policy data means you don't have to redeploy the rule every time policy changes.

3-4. Managing Rules as Code

Insider threat rules have stricter management requirements than ordinary threat detection rules. A single false positive becomes the experience of "the company suspected me," so change history and rationale must be preserved, and the rules themselves are sensitive information (what you detect and how). That's why a Detection-as-Code approach is necessary: rules version-controlled in Git, deployed through review and CI/CD, and regression-tested with test events. Access control on the rule repository must be as strict as it is for the data being monitored. I'll come back to this in Section 4, but the moment your detection logic leaks, it becomes an evasion manual.

4. The Three Walls You Hit in Operations

Operating the rules is harder than writing them. Based on commonly known operational pain points, here are three walls you will inevitably run into.

4-1. False Positives: Baseline Design, Not Exception Handling

Most false positives in insider threat detection are cases where "normal work overlaps with a threat pattern": a PM's external sharing while collaborating with a partner (S5), a data analyst's bulk queries (the Origin signals of S1/S4), access-pattern shifts during reorg season (contamination of the Actor axis). If your response is to add an exception to a list every time an alert fires, the exception list ends up larger than the rule itself.

The approach has to change: design baselines differently per job function and role. A data analyst's "bulk query" should be judged only as deviation from their peer group, and for users collaborating with partners, manage destination domains not as a whitelist but as a "collaboration counterpart domain list." Exceptions are only maintainable when they are defined at the level of context, not individual people. And if you feed a company-wide event calendar (reorgs, review seasons) into your rules' suppression conditions, you can pre-empt the wave of false positives that repeats every quarter.

4-2. Privacy and Labor Law: Data Protection, Not Surveillance

In this area, law comes before technology. In Korea, you should sort out at least three things before you start.

Notice and consent framework: The scope and purpose of employee monitoring must be clearly communicated through work rules, security pledges, and internal notices. Highly invasive telemetry such as clipboard or screen instrumentation in particular requires legal review before rollout and may be subject to labor-management consultation at the workplace.

Purpose limitation and data minimization: The logs your detection system collects constitute a personal-data processing system in their own right. The moment logs collected for the purpose of "data leak detection" are repurposed as grounds for attendance evaluation or HR action, that becomes out-of-purpose use. As mentioned earlier, the HR event feed should carry only the minimum required fields, with explicitly restricted access.

Legitimacy of investigation procedures: Document in advance the procedure for when a high-risk alert leads to investigating a specific person: who approves, how far the review may go, and how it is recorded. An investigation without procedure can lose evidentiary value in later legal disputes, and it destroys organizational trust.

The framing itself must narrow from "monitoring employees" to "protecting the movement of data." The Gen 4 frame is actually an advantage here. Rather than watching everything a person does (an extension of Gen 3 UEBA), a structure that tags sensitive data and tracks only the movement of those tags lets you scope collection around the data itself.

4-3. Securing the Detection System Itself

The paradox of insider threat detection is that the subject of detection may be an insider with access to the detection system. Someone who knows which sources are tagged and which thresholds trigger alerts can crawl underneath them (S7 is exactly this pattern). So you need the following.

Minimize access to rules, thresholds, and the list of tagged sources, even within the detection team
Separately audit administrator activity on the detection infrastructure itself (SIEM, tag store, LLM proxy)
Alongside threshold-based rules, run threshold-free cumulative rollup rules (the daily → quarterly aggregation of source tags from S7). Even someone who knows the thresholds cannot escape a cumulative total

This is also why this post shares only the structure and principles of the matrix, and not actual thresholds or production rules. The methodology can be a public good, but the parameters must remain each organization's secret.

Finally, you have to acknowledge the undetectable zone. Photographing a screen with a personal phone or passing information verbally cannot be caught by any instrumentation. This zone belongs to deterrence, not technology: on-screen watermarks (the mere fact that who viewed which screen and when can be traced afterward is itself a deterrent), explicit security pledges and legal liability, and security culture. The reason I deliberately included S6 in the matrix is so that the team and leadership share the understanding that "detection cannot stop this one."

5. Where to Start: A Maturity Roadmap

You can't build Gen 4 overnight. The order I recommend is as follows.

Phase	Goal	What you do	Scenarios covered
Phase 0. Inventory	Draw the map	Catalog sensitive sources (which DBs/repos/documents are regulated, PII, or crown jewels), map existing log sources to matrix cells, identify the empty cells	N/A
Phase 1. Movement first	Start with the logs you have	Rules based on proxy, mail GW, and collaboration-tool logs. Catalog personal cloud uploads, external sharing, LLM domains	S1 (partial), S5, S7 (partial)
Phase 2. Origin instrumentation	The sources become visible	Collect Git/Drive audit logs, negotiate DB audit logs or a query gateway, establish the HR feed agreement	S2, S4, S1 (complete)
Phase 3. Lineage connection	The heart of Gen 4	Source tagging + fingerprint store, derivative inheritance, LLM proxy payload matching, cross-user propagation graph	S3, S7 (complete), S8

The key is not skipping Phase 1. Once you're captivated by the Gen 4 frame, you'll want to build the tagging pipeline first, but if you start with source instrumentation before basic Movement-layer detection, you'll have no results to show for the investment and the project will stall midway. The realistic path is to build actual detection wins (and false-positive management experience) in Phase 1, then use those wins to drive the organizational negotiations of Phases 2 and 3 (DB team, HR, Legal).

6. Closing

To sum up a long post:

DLP has evolved through Pattern → Content → Context → Lineage, and now that AI is a work tool, you need the Gen 4 perspective of tracking the movement of "data fragments," not "files."
Detection design should be a matrix, not a list of scenarios. Lay your scenarios over the data lifecycle (Origin → Transform → Movement → Destination) and the actor axis, and the empty cells in your coverage become visible, along with the source keys that link the cells together.
Risk is multiplication, not addition, because insider threats are simultaneous deviation across multiple axes, not single events.
Operations are harder than rules. Baseline design, privacy and labor law, and the security of the detection system itself: don't start writing rules before you're ready to climb these three walls.

There is no perfect insider threat detection. Channels like S6 are undetectable in principle, and the denser your instrumentation, the greater the tension with privacy. That's why I think the real purpose of this matrix is not as a rule generator but as a tool for conversation: a shared language for telling leadership "what we can and cannot see," for telling Legal and HR "what we want to collect and why," and for deciding within the security team "which cells to fill next quarter."

I hope this post serves as a starting point for anyone designing insider threat detection. If you've adapted this matrix in your own environment or see things differently, I'd love to hear your feedback. Thanks for reading such a long post.