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

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

Raw Events (100+/hour) │ ├── 1. Time Window Grouping ──── Group by 5-minute windows │ ├── 2. Rule Matching ──────────── 15 rules checked in parallel │ ├── 3. Kill Chain Mapping ─────── Map to MITRE ATT&CK stages │ ├── 4. Alert Clustering ───────── DBSCAN reduces duplicates │ ├── 5. Severity Calculation ───── Max(event severities) + escalation │ └── 6. Incident Creation ──────── Unique incident with linked events Correlated Incidents (5-10/hour)

Built-in Rules

Multi-Stage Attack Rules

#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 from same source10mHIGH
5DORMANT_PAYLOAD_ACTIVATIONdormant_payload → any_high_severity30mCRITICAL

Cross-Sensor Rules

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

Temporal Pattern Rules

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

Lattice Rules

#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

TypeDescriptionExample
sequenceEvents in orderjailbreak → tool_abuse
countN events of type3+ tool_abuse
absenceExpected event missingNo auth within 5m of access
thresholdMetric exceeds valueGPS > 0.7

Matching Options

OptionDescription
withinTime window for correlation
same_fieldEvents must share this field value
different_sourceEvents must come from different sensors
min_confidenceMinimum confidence score per event

Alert Clustering

Problem

66 engines × incoming requests = hundreds of raw alerts per hour. Most are related to the same attack.

Solution: DBSCAN + MiniLM

100+ raw alerts │ ├── 1. Embed alert descriptions (MiniLM-L6) │ → 384-dimensional vectors │ ├── 2. DBSCAN clustering (ε=0.3, min_samples=3) │ → Group similar alerts │ ├── 3. Representative selection │ → Pick highest-confidence alert per cluster │ └── 4. Noise filtering → Isolated alerts 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:

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

Each incident displays:

  • Kill Chain Stage: Current attack phase
  • Progression: Visual timeline of stages
  • Prediction: GPS-based forecast of likely next stage

Incident Lifecycle

┌────────────────────────────────────────────────────┐ │ │ │ ┌──────┐ ┌───────────────┐ ┌──────────┐│ │ │ OPEN │────▶│ INVESTIGATING │────▶│ RESOLVED ││ │ └──┬───┘ └───────┬───────┘ └──────────┘│ │ │ │ │ │ │ ┌───────▼───────┐ │ │ └────────▶│ ESCALATED │ │ │ │ (Zero-G mode) │ │ │ └───────────────┘ │ │ │ └────────────────────────────────────────────────────┘
StatusDescriptionActions Available
OPENNew, unacknowledged incidentAcknowledge, escalate
INVESTIGATINGAnalyst working on itRun playbook, update, resolve
ESCALATEDRequires senior approvalZero-G mode actions
RESOLVEDHandled and documentedReopen (if needed)

Performance

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

Custom Rules

See the Custom Correlation Rules Tutorial for step-by-step guide on creating your own rules.


Next Steps