MODULE 1
CONCEPT OF OPERATIONS
METEORSTORM™ Function One
Define the platform’s mission, architecture, and structural elements
40 Slides | ~50 Minutes
FULL SPECTRUM SPACE CYBERSECURITY PROFESSIONAL
OUTLINE
- M1: Concept of Operations
- M2: Contextualized Threat Modeling
- M3: Converged Detection Engineering
- M4: Incident Response Preparedness
- M5: Adversary Management
- M6: Space Operations Exercise
- M7: Guidance Modes Exercise
- M8: Payload Operations Exercise
- M9: Contested Space Operations
- M10: Incident Response Exercise
1 / 40
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
2
Why METEORSTORM Exists
Space is no longer a sanctuary. Modern mission platforms face a converged threat landscape spanning kinetic, cyber, electronic warfare, and environmental domains.
Adversaries don’t confine operations to a single domain. Traditional frameworks—ATT&CK, SPARTA, SPACE-SHIELD, ATLAS, FiGHT—each address specific domains, but no single framework spans all environments.
METEORSTORM bridges these worlds with a shared vocabulary and a five-function process that operates across every domain simultaneously.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
3
The Evolution of Platform Complexity
Modern satellite communications = an interconnected ecosystem: ground control stations, user terminals, RF link paths, flight software, onboard processors, data relays, and terrestrial networks.
Each component operates in a distinct physical environment, serves a different operational role, and carries its own vulnerabilities.
KEY INSIGHT
Traditional IT-centric documentation is insufficient for platforms that span orbital, terrestrial, RF, and cyber domains simultaneously.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
4
Why Traditional Frameworks Fall Short
SPARTA
Space segment TTPs — but orbital-only. No ground, no RF link, no user segment coverage.
SPACE-SHIELD
European space segment + comm links. Regional focus, limited asset-level granularity.
ATLAS
AI/ML adversarial techniques. Not designed for physical environments or mission architecture.
FiGHT
5G telecommunications focus. Does not address mission-level architecture or orbital operations.
ATT&CK
Enterprise IT foundation. No RF, orbital, or multi-domain convergence capabilities.
METEORSTORM
Converged analytical layer that ingests ALL of these frameworks into a unified, mission-grounded taxonomy.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
5
The Convergence Imperative
Convergence = the merging of cyber, physical, electromagnetic, and space into a single operational reality.
Adversaries think in terms of MISSION disruption, not domain. Defenders must adopt the same cross-domain perspective.
CRITICAL GAP
A detection architecture that monitors ground station network traffic but ignores RF signal quality will miss entire classes of attacks.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
6
The Five Exposure Domains
KINETIC
ASAT weapons, kill vehicles, orbital debris, physical ground attacks
NON-KINETIC
Directed energy, lasers dazzling sensors, microwave weapons, EMP
ELECTRONIC WARFARE
Jamming, spoofing, meaconing, SIGINT collection
CYBER
Command injection, supply chain compromise, malware, insider threats
ENVIRONMENTAL
Solar events, radiation, thermal cycling, debris microimpacts
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
7
Threat Domain Interactions
The most dangerous scenarios combine multiple domains.
Example: An adversary conducts cyber recon of a ground station, times RF jamming to a critical command window, and launches social engineering against ops personnel simultaneously.
No single-domain defense detects this.
METEORSTORM ANSWER
The METEORSTORM taxonomy correlates indicators and analytics across domain boundaries, enabling detection of multi-vector attack campaigns.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
8
Unique Challenges of Space Platform Defense
| Challenge | Description | METEORSTORM Response |
|---|---|---|
| No Physical Access | Remote-only operations | F4: Remote response playbooks |
| Comm Windows | LEO ~15-min contact windows | F3: Inter-pass telemetry gaps, store-and-forward alerting |
| Resource Constraints | Limited processors/bandwidth | Detection on ground-based telemetry |
| Long Lifetimes | 5–20 year missions | F4: Feedback loop to resilience engineering |
| Shared Infrastructure | GSaaS shared dependencies | F3: Multi-operator CDL signatures |
| Hostile Environment | Radiation, debris mimic attacks | F2: Environmental correlation |
| Attribution Difficulty | Multiple causes for anomalies | Multi-domain correlation |
| International Jurisdiction | Cross-border signals/infra | F5: Strategic adversary assessment |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
9
The Operational Imperative
The space threat landscape is NOT theoretical.
- Nation-state ASAT tests — demonstrated and documented
- GPS jamming — documented in active conflict zones
- Viasat KA-SAT cyberattack (2022) — bricked thousands of modems across Europe
THE QUESTION
The question is no longer WHETHER to implement structured space cybersecurity, but HOW to do it effectively and affordably. METEORSTORM provides that answer.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
10
INTRODUCTION TO METEORSTORM™
The Framework, Taxonomy, and Five Functions
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
11
What METEORSTORM Is
Multiple Environment Threat Evaluation Of Resources, Space Threats Operational Risk to Missions
- A converged threat modeling and detection engineering framework
- Structured, five-function process
- Platform-agnostic but space-designed
- Published as an official open-source taxonomy
- Open source (MIT license)
- GitHub repository maintained by eHs®
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
12
Core Design Principles
1. MISSION FIRST
Analysis begins with the platform’s mission purpose. Always.
2. STRUCTURAL TRACEABILITY
Every element gets a structured identifier linked to platform architecture.
3. VENDOR AGNOSTICISM
Detection logic in vendor-neutral formats via roota.io.
4. CONTINUOUS ADAPTATION
Five functions as a continuous cycle, not a one-time assessment.
5. CONVERGENCE BY DEFAULT
Integrates all domains from the outset—not as an afterthought.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
13
The METEORSTORM™ Taxonomy
Hierarchical naming convention. Every element classified using five components:
Layer
→
Tag
→
Category
→
Ordinal
→
Description
Example: AST: HA: Hardware: 01 — Ground station antenna
Layers: PCE (Environment), SEG (Segment), SVC (Service), AST (Asset), AN (Analytic)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
14
The Five Layers
L1
PCE
Primary Capability Environment — WHERE the platform operates
L2
SEG
Segment — WHAT operational groupings exist
L3
SVC
Service — HOW functionality is delivered
L4
AST
Asset — WHICH concrete elements implement services
L5
AN
Analytic — Security-specific overlays (threats, detections, IOAs, IOCs, resilience)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
15
How the Five Functions Relate
| Function | Name | Purpose |
|---|---|---|
| One | Concept of Operations | Define mission, architecture, structural elements |
| Two | Contextualized Threat Modeling | Overlay threat logic onto CONOPS |
| Three | Converged Detection Engineering | Engineer mission-specific detection capabilities |
| Four | Incident Response Preparedness | Operational dashboards, controls, playbooks |
| Five | Adversary Management | Structured adversary profiles, defensive alignment |
Each function’s outputs feed into the next. Function Five feeds back into Function One = continuous cycle.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
16
The Continuous Improvement Cycle
The five functions are NOT sequential one-time activities. They form a continuous cycle.
When new assets deploy, services change, threats evolve, or adversary behavior shifts — the entire cycle re-engages.
Each iteration deepens understanding and strengthens defensive posture.
F1: CONOPS
→
F2: Threat Model
→
F3: Detection
→
F4: IR
→
F5: Adversary
→
F1: CONOPS
The framework builds a cumulative analytical baseline with every iteration.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
17
FUNCTION ONE: CONOPS DEVELOPMENT
Building the Structural Foundation
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
18
Function One Purpose
Establishes the mission-grounded structural foundation for ALL subsequent analysis.
Before threats can be identified, detections engineered, or adversaries profiled — the organization must first document:
- WHAT its platform is
- WHERE it operates
- WHAT it does
- WHAT it is made of
Output: A fully documented CONOPS in METEORSTORM taxonomy.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
19
Function One Key Activities
- Define platform’s mission purpose and requirements
- Enumerate Primary Capability Environments (PCE)
- Identify Segments (SEG) by operational role
- Define Services (SVC) — control plane vs data plane
- Catalog Assets (AST) — hardware, software, firmware, data, signals
- Document every element using METEORSTORM nomenclature
7. Create a CONOPS diagram showing all relationships between layers.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
20
Why Function One Matters
Without a clearly defined CONOPS, threat modeling and detection engineering lack both relevance and fidelity.
Every security decision made later depends on an accurate understanding of:
- What the platform IS
- Where it operates
- What it does
- How it is built
FUNCTION ONE GUARANTEE
Function One ensures this understanding is documented, structured, and shared across all disciplines.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
21
LAYER 1: PRIMARY CAPABILITY ENVIRONMENT (PCE)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
22
PCE Overview
Physical domains in which the platform operates. Establishes what threats are possible and what telemetry is available. Without environmental context, impossible to distinguish between interference and deliberate attack.
| Tag | Name | Description |
|---|---|---|
| PCE-TE | Terrestrial | Surface-based operational zones |
| PCE-AQ | Aquatic | Water-based operational zones (future-proofed for other planets) |
| PCE-AE | Aerial | Atmospheric zones (lower, upper, near-space) |
| PCE-OR | Orbital | Planetary or satellite orbits (not “Space” — avoids confusion with Space Segment) |
| PCE-DS | Deep Space | Beyond planetary orbital regimes |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
23
PCE Enumeration Example: STARCOM-LEO
TWO PCEs IDENTIFIED
PCE: OR: Orbital: 00
LEO (~550 km altitude) operating environment for all 48 constellation satellites, including vacuum, radiation, thermal, and orbital mechanics conditions.
PCE: TE: Terrestrial: 00
Planetary surface operating environment for ground control stations, gateway stations, mission operations center, and user terminals.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
24
LAYER 2: SEGMENT (SEG)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
25
Segment Overview
Group platform components by operational role. Designed to accommodate evolving threat landscape including oceanic cable attacks and rogue aerial platforms.
| Tag | Name | Description |
|---|---|---|
| SEG-LA | Launch | Primary launch operations |
| SEG-LI | Link | Communication signal paths |
| SEG-GR | Ground | Primary platform operations, control plane locus |
| SEG-US | User | End-user operations |
| SEG-SP | Space | Planetary/satellite orbit operations |
| SEG-AQ | Aquatic | Water-based operations |
| SEG-LO/HI/NE | Low/High Alt, Near Space | Aerial segments |
| SEG-DE | Deep Space | Beyond planetary orbits |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
26
Segment Enumeration Example: STARCOM-LEO
FOUR SEGMENTS IDENTIFIED
SEG: SP: Space: 00
Orbital constellation — 48 LEO satellites, communications relay, inter-satellite routing, telemetry.
SEG: GR: Ground: 00
Ground infrastructure — 2 primary control stations, 4 gateway stations, mission ops center.
SEG: US: User: 00
Fixed and portable end-user terminals for broadband service.
SEG: LI: Link: 00
All RF and optical paths — uplink/downlink, feeder links, inter-satellite optical links.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
27
LAYER 3: SERVICE (SVC)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
28
Service Overview
Describe what the platform DOES in functional terms. Grounding into Control Plane, Data Plane, and Hybrid provides standardization while allowing organization-specific nesting.
| Tag | Name | Description |
|---|---|---|
| SVC-CP | Control Plane | Managing and orchestrating platform control functions (commanding, telemetry, health monitoring, configuration) |
| SVC-DP | Data Plane | Managing and orchestrating mission product functions (user data relay, payload downlink, sensor data) |
| SVC-HY | Hybrid | Integrating both control and data plane functionalities |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
29
Service Enumeration Example: STARCOM-LEO
TWO PRIMARY SERVICES
SVC: CO: Control Plane: 00
Constellation command, telemetry, health monitoring, orbital maneuver planning, software update distribution. Distributed: spans ground and space segments.
SVC: DA: Data Plane: 00
End-user broadband traffic relay through constellation, including inter-satellite routing via optical links and ground gateway backhaul. Distributed: spans all four segments.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
30
LAYER 4: ASSET (AST)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
31
Asset Overview
Concrete, tangible elements implementing services. Granular enough for detection engineering, flexible enough for space diversity.
| Tag | Name | Description |
|---|---|---|
| AST-HW | Hardware | Physical components (antennas, transceivers, processors) |
| AST-FW | Firmware | Embedded control code governing hardware |
| AST-SW | Software | Applications and logic executing operations |
| AST-DA | Data | Information generated, processed, or consumed |
| AST-SI | Signal | Communication channels and transmission frequencies |
| AST-HY | Hybrid | Composite elements combining multiple asset types |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
32
Asset Enumeration Example: STARCOM-LEO
| Identifier | Description | Service |
|---|---|---|
| AST: HA: Hardware: 00 | Satellite onboard Ku/Ka-band transceiver | SVC: CO, DA |
| AST: HA: Hardware: 01 | Optical inter-satellite link terminal | SVC: DA |
| AST: HA: Hardware: 02 | Ground control station antenna array | SVC: CO, DA |
| AST: SO: Software: 00 | Satellite flight software (command processing, telemetry, fault mgmt) | SVC: CO |
| AST: SO: Software: 01 | Ground constellation management software | SVC: CO |
| AST: DA: Data: 00 | Satellite telemetry and health data streams | SVC: CO |
| AST: DA: Data: 01 | Command and software update packages | SVC: CO |
| AST: SI: Signal: 00 | RF uplink/downlink signals Ku/Ka-band | SVC: CO, DA |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
33
LAYER 5: ANALYTIC (AN)
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
34
Analytic Layer Overview
Security-specific overlay. Categories answer critical analyst questions.
| Tag | Name | Analyst Question |
|---|---|---|
| AN-ATT | Attack Path | “Is there a disclosed attack path?” |
| AN-IOC | Indicator of Compromise | “Has this been compromised?” |
| AN-IOA | Indicator of Attack | “Is this under attack?” |
| AN-THR | Threat | “Is this being targeted by a specific threat?” |
| AN-DET | Detection Signature | “Do we have a detection?” |
| AN-RES | Resilience Measure | “Is there a resilience measure available?” |
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
35
The Complete CONOPS Diagram
Visual representation of relationships between environments, segments, services, and assets.
For STARCOM-LEO:
- Orbital and terrestrial environments as context boundaries
- Four segments spanning the environments
- Two services (Control Plane + Data Plane) distributed across segments
- Individual assets supporting each service
REFERENCE ARTIFACT
This diagram becomes THE reference artifact for all subsequent functions (Two through Five).
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
36
GETTING STARTED WITH FUNCTION ONE
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
37
Step-by-Step CONOPS Development
- Assemble cross-functional team (mission ops, cybersecurity, RF engineering, software engineering, platform architecture)
- Define mission purpose and requirements (clear language, no jargon, understandable across disciplines)
- Walk through taxonomy layers — enumerate PCE → SEG → SVC → AST using METEORSTORM nomenclature
- Create CONOPS diagram — visual representation of all relationships between environments, segments, services, and assets
- Validate completeness — confirm every mission requirement traces to at least one service and every service traces to specific assets
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
38
STARCOM-LEO: Complete CONOPS Summary
The STARCOM-LEO constellation CONOPS provides a complete, structured representation of the mission architecture: two environments, four segments, two services, and fourteen assets, all documented in METEORSTORM taxonomy with full traceability from mission purpose to individual components.
MISSION REQUIREMENTS
- Maintain continuous broadband coverage over designated service regions
- Accept and execute commands from authorized ground control stations
- Transmit satellite telemetry and health data with sufficient frequency
- Relay end-user traffic with ≤50ms one-way latency
- Maintain inter-satellite optical links for constellation-wide routing
WHY THIS MATTERS
This structured baseline feeds directly into Function Two, where threat logic will be overlaid onto these exact elements. Every threat identified in Module 2 will be linked to specific PCEs, segments, services, and assets documented here — creating analytically traceable, mission-anchored security analysis rather than abstract risk registers.
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
39
Platform Coverage Beyond Traditional Space
METEORSTORM’s taxonomy was deliberately future-proofed. While space platforms are the primary focus, the data model supports any complex, multi-domain system:
Legacy Space Systems
PCE-OR
Traditional GEO/MEO/LEO satellites with established ground infrastructure
Traditional GEO/MEO/LEO satellites with established ground infrastructure
New Space Constellations
PCE-OR, PCE-TE
Modern LEO broadband and IoT constellations with distributed networks
Modern LEO broadband and IoT constellations with distributed networks
Non-Terrestrial Networks
PCE-OR, PCE-AE
Direct-to-device satellite services and high-altitude platform systems
Direct-to-device satellite services and high-altitude platform systems
Deep Space Missions
PCE-DS, PCE-OR
Interplanetary probes, lunar infrastructure, and cislunar operations
Interplanetary probes, lunar infrastructure, and cislunar operations
Subsea Cable Infrastructure
PCE-AQ, PCE-TE
Undersea fiber optic networks and shore-based landing stations
Undersea fiber optic networks and shore-based landing stations
Autonomous Aerial Platforms
PCE-AE, PCE-TE
UAVs, HAPS, stratospheric platforms providing communications or ISR
UAVs, HAPS, stratospheric platforms providing communications or ISR
Module 1 — Concept of Operations
OPERATOR: —
SCORP² Practitioner | eHs® | TLP-GREEN
40
Module 1 Summary
- Function One establishes the structural foundation for ALL subsequent analysis
- The METEORSTORM taxonomy provides the shared language across disciplines
- Five layers (PCE, SEG, SVC, AST, AN) decompose any platform into traceable elements
- The CONOPS diagram is THE reference artifact for Functions Two through Five
Next: Module 2 — Contextualized Threat Modeling
VIDEO
MISSION STATUS
STUDENT—
SECTIONSession 1 — Foundations
START00:00
REMAINING—