Skip to content
Architecture Reference

Correlation Engine v3

The Correlation Engine transforms raw security events into actionable incidents by detecting multi-stage attacks, cross-sensor patterns, and temporal anomalies.


Overview

Scroll horizontally to see all columns when needed.

MetricValue
Built-in rules15
Correlation window5 minutes (configurable)
Alert clusteringDBSCAN + MiniLM embeddings
Noise reduction100+ alerts/hour → 5-10 incidents
Lattice integrationTSA, GPS, MIRE primitives

How correlation works

Code example
Raw events (100+/hour)
    │
    ├── 1. Group by time window ──────────── 5-minute windows
    │
    ├── 2. Match against rules ───────────── 15 rules in parallel
    │
    ├── 3. Map to the kill chain ─────────── MITRE ATT&CK stages
    │
    ├── 4. Cluster alerts ────────────────── DBSCAN removes duplicates
    │
    ├── 5. Compute severity ──────────────── Max(severity) + escalation
    │
    └── 6. Create the incident ───────────── Unique incident + links

Correlated incidents (5-10/hour)

Built-in rules

Multi-stage attack rules

Scroll horizontally to see all columns when needed.

#Rule IDTrigger eventsWindowSeverity
1MULTI_STAGE_JAILBREAKjailbreak → tool_abuse5mHIGH
2EXFILTRATION_CHAINpii_detected → exfiltration → network_alert5mCRITICAL
3INJECTION_TO_EXECinjection → tool_abuse (file/exec)3mCRITICAL
4CRESCENDO_ATTACK5+ low-severity events from one source10mHIGH
5DORMANT_PAYLOAD_ACTIVATIONdormant_payload → any_high_severity30mCRITICAL

Cross-sensor rules

Scroll horizontally to see all columns when needed.

#Rule IDTriggerWindowSeverity
6BYPASS_SHIELD_THEN_INJECTshield_block → core_detect30sHIGH
7CROSS_SENSOR_ESCALATIONshield_bypass + core_detect1mCRITICAL
8IMMUNE_KERNEL_PLUS_COREimmune_alert + core_alert2mHIGH

Temporal rules

Scroll horizontally to see all columns when needed.

#Rule IDTriggerWindowSeverity
9REPEATED_TOOL_ABUSE3+ tool_abuse from one IP10mHIGH
10ALERT_FLOOD100+ events from one sensor60sMEDIUM
11BRUTE_FORCE_PATTERN10+ auth_bypass attempts5mHIGH

Lattice rules

Scroll horizontally to see all columns when needed.

#Rule IDTriggerPrimitiveSeverity
12TSA_VIOLATIONTemporal Safety Automata violationTSACRITICAL
13GPS_HIGH_DANGERGoal Predictability Score > 0.7GPSHIGH
14MIRE_CONTAINMENTModel containment triggeredMIRECRITICAL
15IRM_HIDDEN_INTENTIntent Revelation divergence > 0.5IRMHIGH

Rule definition format

Rules are defined in YAML:

YAML
rules:
  - id: MULTI_STAGE_JAILBREAK
    name: "Multi-Stage Jailbreak Attack"
    description: "Jailbreak followed by tool_abuse within 5 minutes"
    enabled: true

    conditions:
      - sequence:
          - category: jailbreak
            min_confidence: 0.7
          - category: tool_abuse
            min_confidence: 0.5
        within: "5m"
        same_field: "source_ip"

    action:
      create_incident: true
      severity: HIGH
      kill_chain_stage: "exploitation"
      playbook: "auto_block_jailbreak"

    metadata:
      mitre_atlas: ["AML.T0054", "AML.T0040"]
      owasp_llm: ["LLM01", "LLM07"]

Condition types

Scroll horizontally to see all columns when needed.

TypeDescriptionExample
sequenceEvents in orderjailbreak → tool_abuse
countN events of a type3+ tool_abuse
absenceAn expected event is missingNo auth within 5m of access
thresholdA metric exceeds a valueGPS > 0.7

Matching parameters

Scroll horizontally to see all columns when needed.

ParameterDescription
withinTime window for correlation
same_fieldEvents must agree on this field
different_sourceEvents come from different sensors
min_confidenceMinimum confidence per event

Alert clustering

The problem

Every engine × incoming requests = hundreds of raw alerts per hour. Most of them are about the same attack.

The solution: DBSCAN + MiniLM

Code example
100+ raw alerts
    │
    ├── 1. Embed alert descriptions (MiniLM-L6)
    │       → 384-dimensional vectors
    │
    ├── 2. DBSCAN clustering (ε=0.3, min_samples=3)
    │       → Group the similar ones
    │
    ├── 3. Select a representative
    │       → The highest-confidence alert in the cluster
    │
    └── 4. Filter noise
            → Isolated alerts are kept as standalone events

5-10 incident-worthy clusters

Configuration

YAML
correlation:
  clustering:
    enabled: true
    algorithm: "dbscan"
    min_cluster_size: 3        # Minimum events per cluster
    similarity_threshold: 0.7  # Cosine similarity threshold
    embedding_model: "all-MiniLM-L6-v2"

Kill chain mapping

Correlated incidents are mapped to attack stages:

Code example
┌────────────┐  ┌────────────┐  ┌────────────┐  ┌────────────┐
│   Recon    │→ │  Delivery  │→ │Exploitation│→ │   Action   │
│            │  │            │  │            │  │            │
│ injection  │  │ shield_blk │  │ jailbreak  │  │exfiltration│
│ probe      │  │ evasion    │  │ tool_abuse │  │ pii_leak   │
└────────────┘  └────────────┘  └────────────┘  └────────────┘

Each incident shows:

  • Kill chain stage: the current phase of the attack
  • Progression: a visual timeline of the stages
  • Forecast: the GPS prediction of the likely next stage

Incident lifecycle

Code example
┌────────────────────────────────────────────────────┐
│                                                    │
│   ┌──────┐     ┌───────────────┐     ┌──────────┐  │
│   │ OPEN │────▶│ INVESTIGATING │────▶│ RESOLVED │  │
│   └──┬───┘     └───────┬───────┘     └──────────┘  │
│      │                 │                           │
│      │         ┌───────▼───────┐                   │
│      └────────▶│   ESCALATED   │                   │
│                │ (Zero-G mode) │                   │
│                └───────────────┘                   │
│                                                    │
└────────────────────────────────────────────────────┘

Scroll horizontally to see all columns when needed.

StatusDescriptionAvailable actions
OPENNew, unacknowledgedAcknowledge, escalate
INVESTIGATINGAn analyst is working on itRun playbook, update, resolve
ESCALATEDNeeds a senior analystZero-G actions
RESOLVEDHandled and documentedReopen (if needed)

Performance

Scroll horizontally to see all columns when needed.

MetricValue
Rule evaluation<5ms for all 15 rules
Clustering<50ms for 100 alerts
End-to-end correlation<100ms
Memory usage~50MB for the rule engine
Max concurrent correlations1000

Custom rules

See Custom rules for the rule format and the current public guidance.


Next steps

Correlation Engine v3 | Spectorn