An alert comes in on a Thursday afternoon. A sales account manager downloaded the regional customer list, about 400 records, to her laptop. The alert is low severity. Employees pull customer lists all the time. She has legitimate access. Nothing about the download itself looks wrong.
Two weeks later, HR flags that she resigned. Her last day is in ten days. Nobody connects the two events, because nobody was looking at them together. The download closed as routine weeks ago. The resignation is a separate process in a separate system. By the time anyone asks whether those customer records left with her, she’s already gone, and so, most likely, is the answer.
This is the shape almost every insider case takes. Not one alarming moment, but a handful of unremarkable ones that only mean something when you look at all of them together, tied to the same person, in order.
Why insider cases don’t look like attacks
External attacks tend to announce themselves. A known bad IP. A signature that matches a public exploit. A process that shouldn’t exist talking to a domain that shouldn’t exist. Something about the artifact itself is wrong, and a platform built to catch wrong artifacts can usually find it.
An insider isn’t running an exploit. She has a badge, a laptop, valid credentials, and legitimate access to the thing she’s about to misuse. Every individual action she takes is something the system has already approved. The download isn’t a vulnerability. The email isn’t a phishing attempt. The login isn’t a credential compromise. Nothing in the case looks like an attack, because nothing in the case is technically against the rules.
What makes it a threat isn’t any single action. It’s the sequence, and the fact that the sequence only makes sense once you know it’s all the same person, moving toward the same end. A platform that scores each action on its own will keep scoring all of it low, because on their own, each action is exactly what it looks like. Fine.
The problem underneath: identity fragmentation
Here’s what actually breaks most insider threat detection, and it has nothing to do with the analytics. It’s that the same human being shows up as several different identities depending on which system logged the action.
The VPN log has a username. The endpoint agent has a device ID. The cloud storage service has an email address, possibly a personal one if she forwarded something. The badge system has an employee ID. The HR platform has a full legal name and a termination date. Each of these systems is confident about what it saw. None of them know they’re describing the same person, because nothing connects a device ID to an employee ID to an email address to a badge swipe.
So the download sits in one system’s logs. The after-hours badge entry sits in another. The email to a personal address sits in a third. The resignation sits in a fourth. Each one, read alone, is nothing. A human investigator, if she happens to pull all four logs and happens to notice they involve the same person, can put it together. But that requires someone to already suspect something and go looking. Nothing in the environment does that stitching automatically, which means the case only gets built after the fact, once it’s too late to matter.
Building the chain
The fix is conceptually simple to state and genuinely hard to do well. Resolve every identifier back to one actor, and place everything that actor did on a single timeline, regardless of which system logged it.
That means mapping the VPN username to the employee ID, the employee ID to the badge number, the badge number to the device the endpoint agent is watching, and the device to whatever email addresses have touched it. Once that mapping exists, every action any system logs about any of those identifiers gets attached to one identity instead of living in four separate silos.
Now the picture looks different. Same person: badge in at 7 p.m., after normal hours. Same person: VPN session from an unfamiliar device. Same person: downloaded the regional customer list. Same person: emailed two files to a personal address the following morning. Same person: resignation submitted the following week. Five entries across four systems, invisible to each other individually, become one continuous account of one person’s actions leading somewhere specific.
This is the part worth sitting with. None of the underlying data changed. The badge system logged the same swipe either way. What changed is that the swipe is now attached to the same actor as the download, instead of being a fact that sits alone in a badge log nobody was cross-referencing. The chain doesn’t discover new evidence. It reveals that the evidence you already had was describing one story the whole time.
From chain to verdict
Having the chain doesn’t hand you a verdict. It hands you something a human can actually reason about, which is different and more useful.
An analyst looking at the download alone has almost nothing to go on. An analyst looking at the chain, badge, VPN, download, personal email, resignation, in order, over three weeks, is looking at a pattern that has an obvious shape even before anyone proves intent. That doesn’t mean the verdict is automatically malicious. Plenty of chains that look exactly like this turn out to have an innocent explanation. Maybe she emailed the files to herself to reference during handoff, with her manager’s knowledge. Maybe the after-hours badge entry was a dentist appointment that ran long. The chain doesn’t replace the investigation. It gives the investigation a shape to test instead of forty unconnected facts to somehow notice all at once.
This is also where the stakes are different from a malware case. Getting a malware verdict wrong costs you an hour of wasted triage. Getting an insider verdict wrong, accusing an employee of data theft based on a chain that turns out to have an innocent explanation, can mean a wrongful termination claim, reputational damage, and an employee who never did anything wrong walking away from the company convinced it tried to destroy them. The chain has to be built carefully, shown to the analyst with its reasoning intact, and treated as the start of a human investigation, never as a conclusion a machine reached on its own.
What to ask
If you’re evaluating whether a platform can actually do this, the honest test isn’t whether it flags insider threats. Most platforms will point to some existing rule about mass downloads or off-hours access. The real question is whether it can build the chain.
Can the platform resolve a VPN username, a device ID, a badge number, and an email address to one identity automatically, or does that stitching still happen in someone’s head? When it builds a timeline, does it pull from HR events like resignations and role changes, or only from security telemetry? Can an analyst see why two actions were attached to the same person, or is the identity resolution invisible? And does the platform present the chain as evidence for a human to weigh, with the innocent explanation given equal room, or does it hand down a verdict dressed as a fact?
If the answer is a pile of separate alerts and a suggestion that the analyst correlate them manually, you have a detection tool, not an investigation tool. If the answer is a single identity, a full timeline across every system that touched her, and a clear account of how the chain was built, you have something an analyst can actually use to reach a verdict she can defend.
This is the piece Securaa focuses on for insider cases. Not flagging the download in isolation, but resolving the identity across every system it touched and laying out the timeline so the analyst is reasoning about a person’s actions, not a stack of disconnected logs.
The customer list, the after-hours badge swipe, and the resignation were always sitting in three different systems, waiting to be read as one story. The only question is whether anything connected them before she walked out the door.