All posts

EngineeringMar 202610 min read

Anatomy of a Detection: How Multiple Signals Converge on a Single Verdict

Every S3 event gets scored by 14 independent detectors in parallel. Here's the architecture behind turning CloudTrail metadata into security signals worth investigating.

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.

When a GetObject call hits your S3 bucket, AWS writes a CloudTrail event — a metadata record containing the principal, source IP, bucket, object key, timestamp, and response code. Within minutes, Entroptics has evaluated that event against multiple behavioral dimensions and produced a composite anomaly verdict. Here's the philosophy behind how that works.

Principle 1: Compress at the Edge, Analyze at the Core

CloudTrail events are verbose — each one carries kilobytes of JSON, most of which is irrelevant for behavioral analysis. Our edge component, deployed as a lightweight Lambda in your AWS account, extracts only the fields that matter for security analysis and applies aggressive compression before anything leaves your environment.

This has two benefits: it dramatically reduces data transfer costs, and it minimizes the data surface area in transit. Your raw CloudTrail logs stay in your account. We only see compressed behavioral metadata.

CloudTrailS3 data eventsEdge Lambdaparse · compressKinesis4 shardsWorkersper-tenant14 Detectorsparallel scoringAlertOCSF findingEVENT FLOW: CLOUDTRAIL TO ALERTend-to-end: event → alert in under 5 minutes
Event flow: CloudTrail → Edge compression → Kinesis sharding → 14 parallel detectors → OCSF alert

Principle 2: Multiple Independent Signals

No single detection method catches everything. An IP-based check won't catch an insider using their normal workstation. A timing-based check won't catch someone accessing new resources during business hours. A volume-based check won't catch slow, low-volume exfiltration.

That's why Entroptics runs 14 independent detectors in parallel, each analyzing a different behavioral dimension:

  • Network context — is this access coming from a familiar origin?
  • Temporal patterns — does this activity fit the actor's established schedule?
  • Volume and velocity — is the data movement rate consistent with historical patterns?
  • Access scope — is this actor touching resources they normally interact with?
  • Operation patterns — does the sequence of API calls match learned behavior?
  • Entity cardinality — is the breadth of resource access within normal bounds?
  • Lateral indicators — are there signs of cross-boundary movement?
  • Exfiltration signals — do volume, destination, and timing combine into a risk pattern?

Each detector operates independently. An attacker who avoids one signal (say, using a known IP) still gets flagged by the others (unusual prefix, unusual time, unusual volume). Evasion means beating all 14 at once.

All 14 detectors run on every event, in parallel. If one fails or times out, the rest continue. No single detector failure silences the system.

Principle 3: Context-Aware Baselines

The most important architectural decision in Entroptics is baseline granularity. A single baseline per AWS account is too coarse — it averages out meaningful differences between workloads. A baseline per individual API call is too fine — it overfits to noise.

We partition baselines along the dimensions that matter most for S3 security: the structural context of the access (where in your bucket hierarchy), the identity context (who is accessing), and the object context (what's being accessed). This multi-dimensional partitioning is what allows us to distinguish "normal for this context" from "anomalous for this context" with high precision.

4-LAYER BEHAVIORAL BASELINE MODELPREFIXlogs/ ≠ data/ ≠ config/ROLEadmin-role ≠ readonly-role ≠ svc-billingIDENTITY TYPEHUMAN ≠ SERVICE ≠ LAMBDA ≠ AI_AGENTFILEFileDNA fingerprint per S3 objecteach layer narrows what counts as "normal" — anomaly at ANY layer triggers scoring
Four baseline layers — each one narrows what counts as normal for this specific access

Principle 4: Ensemble Verdict, Not Threshold Alert

Individual detection signals are combined into a composite score using a weighted ensemble approach. Each vector contributes based on its confidence and relevance to the specific event context. The result is a single anomaly score that reflects the convergence of multiple independent signals.

A threshold says "alert if downloads exceed 100/hour." An ensemble says "this combination of timing, scope, velocity, and network context is collectively unusual for this actor." Fewer false positives, because convergence across multiple signals is much harder to trigger by accident than a single threshold.

Principle 5: Adaptive Learning

Environments change. New team members join. New automation scripts are deployed. Seasonal patterns shift workloads. A static baseline would generate increasing false positives over time as the environment drifts from the original training data.

Entroptics maintains both stable reference baselines and adaptive real-time context. The stable baseline captures long-term patterns. The adaptive layer incorporates recent activity to account for legitimate drift. This dual approach provides both stability (not alerting on gradual, legitimate changes) and sensitivity (catching sudden deviations from recent patterns).

  • Detection Engine
  • Architecture
  • Multi-Signal
  • Deep Dive