MODULE 3
CONVERGED DETECTION ENGINEERING
METEORSTORM™ Function Three
Transform threat models into operationally actionable detection capabilities
40 Slides | ~50 Minutes
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
2
Function Three Purpose
Function Three transforms the threat model from Function Two into operationally actionable detection capabilities.
It establishes the detection architecture for converged platforms by integrating threat-aligned indicators of attack, converged detection signatures, and platform-specific telemetry.
This is the most technically intensive function in the METEORSTORM process.
KEY QUESTION
How do you turn a structured threat model into deployable detection logic across all exposure domains?
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
3
Why Converged Detection Matters
Single-domain monitoring misses converged threats entirely.
A detection architecture that monitors ground station network traffic but ignores RF signal anomalies will miss jamming attacks.
An incident response plan for cyber intrusions without playbooks for EW will leave operators scrambling when a jammer activates.
KEY PRINCIPLE
METEORSTORM ensures detection capabilities span ALL exposure domains — cyber, EW, kinetic, environmental, and physical.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
4
The Seven Key Activities
PIRs
→
Attack Paths
→
Telemetry
Inventory
→
Collective
Defense Lang
→
IOAs
→
Validation
→
Resilience
Baseline
Each activity builds on the previous, creating a complete detection architecture that spans all exposure domains.
The output: a validated, resilience baseline ready for Function Four operational readiness.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
5
STEP 1: PRIMARY INTELLIGENCE REQUIREMENTS
Governing the Intelligence-to-Detection Pipeline
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
6
Establishing PIRs
PIRs are formal governance structures defining how intelligence questions are generated, validated, prioritized, and operationalized.
Configure a Threat Intelligence Platform (MISP) using the METEORSTORM taxonomy to structure and manage PIRs.
KEY PRINCIPLE
PIRs ensure detection engineering is driven by mission needs, not ad hoc analysis.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
7
STARCOM-LEO: PIRs from Threat Model
PIR-01 (from THR:00)
Are constellation RF links under deliberate interference?
PIR-02 (from THR:01)
Are unauthorized commands being injected into the control plane?
PIR-03 (from THR:02)
Is telemetry data being intercepted or manipulated in transit?
PIR-04 (from THR:03)
Is the data plane experiencing deliberate denial of service?
PIR-05 (from THR:04)
Are inter-satellite optical links being disrupted?
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
8
PIR Prioritization and Management
- PIRs are prioritized by mission criticality, not threat severity alone
- Regular review cycle: quarterly minimum, triggered by incidents or platform changes
- Each PIR maps to specific threats, CONOPS elements, and detection requirements
- PIR ownership assigned to named analysts with clear escalation paths
MISSION QUESTION
Which intelligence questions on YOUR platform would change first after an architectural modification?
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
9
STEP 2: MAP ATTACK PATHS
Tracing Adversary Progression Through the Platform
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
10
System-Specific Attack Paths
Map attack paths by integrating the taxonomy into the TIP. Standardize representation of assets, services, segments, and analytical indicators.
For each path, identify expected artifacts within the platform.
Attack paths are AN-ATT elements in the METEORSTORM analytical layer.
KEY INSIGHT
Attack paths describe HOW an adversary moves through your platform — not just WHAT they target.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
11
STARCOM-LEO: Attack Path Mapping
Path:Ground station network compromise → command injection via control plane
Targets:Control plane, command authority
Path:RF uplink jamming → loss of command authority during pass window
Targets:RF uplink, pass window availability
Path:Supply chain firmware implant → persistent access to flight software
Targets:Flight software, satellite bus
Path:Gateway saturation → data plane denial of service
Targets:Data plane, user traffic relay
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
12
Attack Paths on the CONOPS Diagram
Attack paths trace through specific PCEs, segments, services, and assets in the CONOPS architecture.
Visual overlay shows adversary progression through the platform architecture.
Each path identifies where detection opportunities exist along the route.
The CONOPS diagram from Function One becomes the attack surface map when overlaid with AN-ATT paths. Every junction is a potential detection point.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
13
STEP 3: INVENTORY CONTEXTUALIZED TELEMETRY
Mapping Data Sources to Detection Requirements
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
14
What Data Supports Detection
Comprehensive survey of data, signal, and sensor sources required to detect each mapped attack path.
Validate each source for:
- Availability — Is the data consistently accessible?
- Schema conformity — Does it follow expected formats?
- Retention period — How long is data kept?
- Fidelity — Is the data accurate and complete?
Critical for converged platforms: telemetry spans network logs, RF measurements, orbital telemetry, and physical sensors.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
15
STARCOM-LEO: Telemetry Inventory
| Source | Type | Attack Paths | Availability |
| Ground station firewall logs | Cyber | ATT:00 | Continuous |
| RF signal strength measurements | EW | ATT:01 | During pass windows |
| Satellite health telemetry | Environmental | ATT:02 | Periodic downlink |
| Gateway traffic flow records | Cyber | ATT:03 | Continuous |
| Command authentication logs | Cyber | ATT:00, ATT:02 | Continuous |
| Inter-satellite link metrics | Physical | ATT:01 | Continuous |
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
16
Telemetry Gaps and Blind Spots
- Orbital environments: telemetry only available during ground station passes (LEO contact windows)
- Deep space: extreme latency makes real-time detection impossible
- Aquatic segments: limited bandwidth for undersea cable monitoring
- Environmental data: space weather sensors may not correlate with platform telemetry timestamps
MISSION QUESTION
Where on YOUR platform does telemetry go dark? What compensating detection strategies can fill the gap?
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
17
Telemetry Validation
Four validation criteria for each telemetry source:
Is the data consistently accessible? Identify intermittent sources and document access constraints.
Does it follow expected formats? Non-conforming data requires normalization before detection logic applies.
How long is data kept for forensic analysis? Short retention limits historical correlation and root-cause analysis.
Is the data accurate and complete enough for detection? Low-fidelity sources increase false positive rates.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
18
STEP 4: COLLECTIVE DEFENSE LANGUAGE
Vendor-Agnostic Detection Signatures
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
19
Vendor-Agnostic Detection Signatures
Detection logic must be expressible in vendor-neutral formats — authored once, deployed across multiple SIEM platforms.
This is what enables machine-to-machine defensive operations.
Without vendor agnosticism, detection logic is locked to a single tool — creating fragile, non-portable defense.
KEY PRINCIPLE
Write once, deploy everywhere. Detection logic should never be trapped inside a single vendor’s ecosystem.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
20
Introduction to roota.io
roota.io enables organizations to author detection signatures in a vendor-agnostic format.
Automatically translates into native query languages for:
Elasticsearch Query DSL / Lucene syntax
Search Processing Language (SPL)
Kusto Query Language (KQL)
Ariel Query Language (AQL)
When combined with METEORSTORM taxonomy, roota.io creates a complete intelligence-to-detection pipeline. Tagged threat intelligence artifacts become deployable detection logic without manual porting.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
21
Writing Detection Logic
Detection signatures reference METEORSTORM taxonomy elements.
Each signature links to:
- Specific threats (AN-THR)
- Attack paths (AN-ATT)
- Assets (AST)
- Telemetry sources
Signatures tagged with AN-DET identifiers for full traceability.
Example: DET:00 — Anomalous command authentication failure rate on ground station control interface
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
22
Deploying Across SIEM Platforms
roota.io
Signature
→
ELK Query
/
Splunk SPL
/
Sentinel KQL
/
QRadar AQL
Single authoring effort, multiple deployment targets.
Organizational flexibility: teams using different tools share the same detection logic.
Critical for organizations with heterogeneous security tool environments.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
23
STARCOM-LEO: Sample Detection Signatures
Description:Anomalous command authentication failure rate on ground station control interface
Supports:ATT:00, THR:01
Telemetry:Command authentication logs, ground station firewall logs
Description:RF signal-to-noise ratio deviation beyond 2σ during pass window
Supports:ATT:01, THR:00
Telemetry:RF signal strength measurements
Description:Unexpected firmware hash mismatch on satellite bus
Supports:ATT:02, THR:05
Telemetry:Satellite health telemetry
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
24
STEP 5: DERIVE INDICATORS OF ATTACK
Behavior-Based Detection Across All Domains
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
25
System-Specific IOAs
IOAs are operationally actionable indicators derived using the taxonomy.
They connect environmental awareness with mission context.
Unlike generic IOCs (IP addresses, hashes), IOAs describe adversary BEHAVIOR specific to YOUR platform.
Tagged as AN-IOA elements in the METEORSTORM analytical layer.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
26
STARCOM-LEO: IOA Derivation
IOA:00
Command upload attempts outside scheduled pass windows
IOA:01
Simultaneous RF degradation across multiple ground stations
IOA:02
Telemetry values deviating from orbital mechanics predictions
IOA:03
Gateway traffic patterns inconsistent with user population models
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
27
IOA vs IOC in Converged Environments
IOCs (Traditional)
- Hashes, IPs, domains
- Cyber-specific and ephemeral
- Easily rotated by adversaries
- No equivalent for RF jamming
IOAs (METEORSTORM)
- Adversary behavior patterns
- Span ALL domains
- Harder for adversaries to change
- Kinetic, EW, cyber, environmental
MISSION QUESTION
What adversary behaviors on YOUR platform have no traditional IOC?
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
28
STEPS 6-7: VALIDATE AND ESTABLISH BASELINE
Testing Coverage and Building the Resilience Dashboard
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
29
Testing Detection Coverage
Validate through simulated or replayed attack-path telemetry.
Measure: true positive rate, false positive rate, mean time to detect.
Each detection signature must be tested against realistic scenarios.
Purple team exercises combine offensive simulation with detection validation — the most effective way to stress-test converged detection architectures.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
30
Detection Performance Metrics
| Metric | Target | Why It Matters |
| True Positive Rate | >90% | Detections must fire on real threats |
| False Positive Rate | <5% | Analyst fatigue degrades response |
| Mean Time to Detect | <pass window | Must detect before contact window closes |
| Coverage Ratio | 100% of mapped paths | Every attack path needs at least one detection |
In space operations, mean time to detect is bounded by orbital mechanics — if you miss the pass window, the next detection opportunity may be hours away.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
31
Resilience Baseline Visualization
SIEM-based visualization overlaying threats, detections, and anomalies across all taxonomy layers.
- Highlights unpatchable architectural vulnerabilities
- Shows which platform areas are monitored vs blind
- The resilience baseline becomes the operational dashboard for Function Four
KEY INSIGHT
The resilience baseline is not a static document — it is a living, continuously updated operational view of your detection posture.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
32
STARCOM-LEO: Detection Coverage Matrix
| DET:00 | DET:01 | DET:02 | DET:03 | DET:04 | DET:05 |
| THR:00 | Partial | Covered | — | — | Covered | — |
| THR:01 | Covered | — | — | — | — | Partial |
| THR:02 | — | — | Covered | — | — | Covered |
| THR:03 | — | — | — | Covered | — | — |
| THR:04 | — | Partial | — | — | Covered | — |
| THR:05 | — | — | Covered | — | — | Gap |
| THR:06 | — | — | — | Partial | — | Gap |
Gaps in the coverage matrix drive prioritized detection engineering work. Red cells are immediate action items.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
33
Resilience Baseline Dashboard
Conceptual dashboard layout for operational awareness:
Alerts organized by taxonomy layer: PCE, SEG, SVC, AST. Enables rapid triage by architectural zone.
Real-time status of all telemetry sources across segments. Alerts when sources go offline or degrade.
Red indicators for attack paths without active detections. Drives continuous detection engineering prioritization.
IOAs and detection signatures currently firing, mapped to CONOPS elements for operational context.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
34
Identifying Architectural Vulnerabilities
Some vulnerabilities cannot be patched — spacecraft hardware in orbit is a prime example.
Detection must compensate for what engineering cannot fix.
METEORSTORM identifies these through coverage matrix gaps.
KEY PRINCIPLE
Compensating controls from Function Four address unpatchable exposures — but only if the detection architecture identifies them first.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
35
DETECTION ARCHITECTURE SUMMARY
Tagging, Coverage, and Machine-to-Machine Defense
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
36
AN-DET Tagging
Every detection signature gets an AN-DET tag in MISP.
- Links to specific threats (AN-THR)
- Links to attack paths (AN-ATT)
- Links to assets (AST)
- Enables machine-to-machine correlation across the detection ecosystem
When a detection fires, analysts immediately know which threats, assets, and segments are involved — no manual lookup required.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
37
Complete Coverage Matrix
Three-dimensional mapping: Threats × Detections × Telemetry
Shows the complete detection architecture at a glance.
Gaps visible immediately — drives continuous improvement.
This matrix is the primary output feeding Function Four: Incident Response Preparedness. Every gap here becomes a risk that Function Four must address.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
38
Machine-to-Machine Defense
Structured taxonomy + vendor-agnostic signatures + automated deployment = machine-speed defense
- Intelligence automatically correlated via shared METEORSTORM tags
- Detections automatically deployed via roota.io
- Adversary profiles automatically synchronized with detection engineering
- Critical in space operations where adversary decision cycles may exceed human response time
KEY INSIGHT
When adversaries operate at machine speed, your detection and correlation must also operate at machine speed.
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
39
Detection Engineering Quality Checklist
- PIRs established and mapped to threats
- Attack paths mapped with AN-ATT identifiers
- Telemetry inventory complete with gap documentation
- Detection signatures authored in vendor-agnostic format
- IOAs derived for each attack path
- Coverage validated through simulation/replay
- Resilience baseline established and visualized
- All signatures tagged AN-DET in MISP
Module 3 — Converged Detection Engineering
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
40
Module 3 Summary
- Function Three transforms the threat model into deployable detection capabilities
- Seven activities build from intelligence requirements to a resilience baseline
- Vendor-agnostic signatures via roota.io enable cross-platform deployment
- The detection architecture feeds directly into Function Four operational readiness
Next: Module 4 — Incident Response Preparedness