The S3 Insider Threat Your SIEM Won't Catch

This article describes the product at the time of publication. Historical examples may use earlier workflows. See the current Shield capabilities and plans for the latest product information.

Insider threats don't look like attacks. They look like work. A disgruntled employee, a compromised contractor, an over-privileged service role — every API call is authorized. Every action is within IAM policy. Signature-based tools see nothing wrong because technically nothing is wrong. The only signal is behavioral.

Pattern 1: The Slow Exfiltration

A data engineer with read access to production datasets starts downloading files at a slightly elevated rate. Not a burst — just 20% more GetObject calls per day than their 30-day average. They're accessing the same areas they always access. The files are the same size range. Nothing triggers a threshold.

But the rhythm of the requests has changed. Instead of the irregular, human-driven pattern of their normal work (click, read, think, click), the requests are arriving at suspiciously regular intervals — the signature of a script, not a human.

Entroptics encodes timing and velocity into every behavioral assessment. The same sequence of operations can be normal at human speed and anomalous at scripted speed. This is why count-based thresholds miss slow exfiltration — the counts look fine, but the rhythm is wrong.

Timeline visualization showing normal vs anomalous access patterns — Timeline view: normal human access pattern (top) vs scripted exfiltration (bottom) — same operations, different timing

Pattern 2: The Scope Creep

A contractor's IAM role is scoped to one area of your data. Over three weeks, they start accessing adjacent areas: first something plausible (they might need related data), then something less plausible, then something clearly outside their scope. Each step is a small lateral move. No single access triggers an alert.

Entroptics catches this because baselines are context-specific. Each new area accessed by this role is scored as a first-time access — a strong anomaly signal. As the scope expands over days, the accumulating signals cross the alert threshold. The system sees the pattern that no individual rule would catch.

A traditional SIEM would need a hand-written rule: "alert if role X accesses area Y." But you'd need to write that rule for every role and every area. With behavioral baselines, the system learns the boundaries automatically.

Pattern 3: The Off-Hours Dump

An employee who just gave their two-week notice starts working late. Their badge swipes show them in the office until 11 PM — nothing unusual for a dedicated employee wrapping up projects. But their S3 access pattern tells a different story.

Between 10 PM and midnight, they download thousands of objects from a bucket they normally access during business hours. Multiple detection dimensions converge: unusual hour for this actor, unusual volume for this time window, and unusual velocity compared to their historical pattern. Three independent signals point to the same conclusion.

Investigation page showing multi-signal convergence — Investigation view: multiple independent signals flagging the same actor — convergence is the key to high-confidence alerts

Why SIEMs Miss This

Traditional SIEMs are log aggregation tools with rule engines. They're excellent at correlating events across sources and matching known patterns. But they have three fundamental limitations for insider threat detection:

No behavioral context — a SIEM sees "GetObject on bucket X" but doesn't know if this actor has ever accessed this area before
Threshold-based, not baseline-based — rules fire at fixed thresholds (>100 downloads/hour) that don't account for per-context norms
Reactive rule authoring — you have to anticipate the attack pattern and write a rule for it. Insider threats are creative and don't follow playbooks

Behavioral detection inverts this model. Instead of defining what's bad, you learn what's normal. Everything else is a candidate for investigation.

Building an Insider Threat Program for S3

If you're responsible for S3 data security, here's a practical starting point:

Enable CloudTrail S3 data events (if you haven't already — many organizations only have management events enabled)
Establish behavioral baselines that are granular enough to distinguish normal from anomalous per context
Monitor for the three patterns above: timing anomalies, scope expansion, and off-hours bulk access
Integrate alerts with your incident response workflow — speed of response is critical for insider threats
Review and tune sensitivity regularly — as your environment evolves, baselines should adapt automatically