TLP:GREEN Limited Disclosure · SCORP² community members only

Exported by: verifying identity… Exported at: …

Distribution notice. This document is for active SCORP² community members only. Unauthorized distribution will result in revocation of community membership.

METEORSTORM Data Model · Layer 1 to Layer 5

Use Case 01 · Operational Deployment · Real-world confirmed only

Every element in the framework belongs to one of five layers. Each element identifier is written the same way: LAYER : TAG : LABEL : ORDINAL. Every analytic finding at Layer 5 attaches back to the structural element on your platform that it concerns. Use Case 01 covers operational deployment, so every entry catalogued, internal or external, is a real-world confirmed observation, never a hypothetical.

Use Case 01 · Real-world confirmed only Every element catalogued under this use case must be a confirmed, real-world observation on your platform. The same bar applies to entries kept internally and entries shared externally with peers through Space ISAC: real-world validated, never hypothetical, never a “what-if”. That discipline is what makes both organisational sharing and community sharing low-volume and high-impact, every entry is high-confidence, actionable, and worth a peer's attention.

How to use this document

This reference is designed to drop straight into your CTI programme. It has four primary uses:

CTI procedure appendix. Attach as an appendix to your written cyber-threat-intelligence procedure so analysts can reach the canonical taxonomy from the procedure they already follow.
CTI policy citation. Cite this document by name in your CTI policy as the controlled vocabulary your team uses for space threat intelligence.
Analyst training. Use as the onboarding reference for new analysts: the five layers, the identifier format, the enumeration steps, and the worked examples in one place.
Taxonomy activation validation. Use as the checklist when activating the METEORSTORM taxonomy in your CTI platform: every element below must be present, parent-linkable, and exposed to analysts before activation is considered complete.

Element identifier format

LAYER : TAG : LABEL : ORDINAL

Read the identifier left-to-right. All four fields are required, including the LABEL, which must be written in full and exactly as published. Do not abbreviate the label or omit it; the LABEL is part of the canonical identifier.

LAYER, one of five: PCE, SEG, SVC, AST, AN.
TAG, the published 2-3 letter tag code (e.g. OR, SP, HW, IOC).
LABEL, the published human-readable label, written in full (e.g. Orbital, Space, Hardware, Indicator of Compromise).
ORDINAL, a numeric instance counter starting at 00. Each new real-world instance on your platform takes the next ordinal in sequence; ordinals are not re-used.

Worked example. PCE : OR : Orbital : 00 identifies the first orbital environment your platform operates in. AN : IOC : Indicator of Compromise : 00 identifies the first confirmed indicator of compromise observed on your platform.

Element enumeration process · step-by-step criteria

Apply these eight steps to every element catalogued. Skip none.

Identify the layer. Which of the five layers does this finding belong to: PCE, SEG, SVC, AST, or AN?
Pick the tag code. Within that layer, which published tag code applies (e.g. OR for orbital, IOC for indicator of compromise). Use the tables below as the source of truth.
Write the label in full. Use the published human-readable label exactly as it appears in the tables (e.g. Orbital, Indicator of Compromise). The label is required and must not be abbreviated, paraphrased, or omitted.
Assign the ordinal. Ordinals are scoped to the (LAYER, TAG) pair: PCE : TE : Terrestrial has its own counter, PCE : OR : Orbital has its own counter, AN : IOC has its own counter, and so on. Use 00 for the first instance of that tag on your platform; each new instance of the same tag takes the next ordinal. Ordinals are never re-used, even after retirement. The same numeric value appearing under two different tags (for example SEG : SP : Space : 00 and SEG : GR : Ground : 00) is not a collision, because the tag codes differ.
Name the parent (Layers 2 to 4 only). Every SEG names its PCE parent, every SVC names its SEG parent, every AST names its SVC parent. No orphans.
Attach the TARGET (Layer 5 only). Every AN element attaches via the correct target field, TOE, TDM, or TRE, to the real structural element on your platform that the finding concerns. The target must be a real enumerated element, not an example.
Capture the description. One concise sentence describing what was observed, validated, or built. Real-world only; if the description includes “could”, “might”, or “hypothetical”, the entry does not qualify under Use Case 01.
Cite the source. Forensic ticket, SIEM alert, red-team report, government brief, Space ISAC bulletin, vendor advisory, test result. If no source exists, the finding is not real-world validated and must not be catalogued.

Ontology rule. Read the model top-down to break a platform into its parts (PCE → SEG → SVC → AST). Every child element names its parent, so any finding on an asset traces back through service, segment, and environment to the platform context it concerns. Layer 5 (Analytic) attaches to whichever structural element it describes via its TARGET field.

L1Primary Capability Environment (PCE)

Five environments. Where the platform operates.

Code	Label	Description	Parent
PCE-TE	Terrestrial	Land-based operating environment.	(top)
PCE-AQ	Aquatic	Surface or sub-surface water environment.	(top)
PCE-AE	Aerial	Atmospheric environment, low-altitude through near-space.	(top)
PCE-OR	Orbital	In-orbit environment within the gravitational regime of the parent body.	(top)
PCE-DS	Deep Space	Beyond the gravitational regime of the parent body.	(top)

L2Segment (SEG)

Ten segments. Operational role within an environment. Every segment names its PCE parent.

Code	Label	Description	Parent
SEG-LA	Launch	Launch operations, ending at vehicle separation.	PCE-TE
SEG-LI	Link	Communication path between segments. Signal asset is enumerated at L4.	PCE-TE / OR
SEG-GR	Ground	Ground stations, mission ops centres, control facilities.	PCE-TE
SEG-US	User	End-user equipment, terminals, identities.	PCE-TE
SEG-AQ	Aquatic	Maritime operations segment.	PCE-AQ
SEG-LO	Low Altitude	Low-altitude aerial operations.	PCE-AE
SEG-HI	High Altitude	High-altitude aerial operations.	PCE-AE
SEG-NE	Near Space	Near-space, between high altitude and orbital.	PCE-AE
SEG-SP	Space	On-orbit space segment, the operational constellation.	PCE-OR
SEG-DE	Deep Space	Deep-space mission segment.	PCE-DS

L3Service (SVC)

Three services. Capability the segment delivers. Every service names its SEG parent.

Code	Label	Description	Parent
SVC-CP	Control Plane	Command, control, configuration, and management of the platform.	SEG-*
SVC-DP	Data Plane	Mission product, payload data, and the data flows it produces.	SEG-*
SVC-HY	Hybrid	Service that spans both control and data plane responsibilities.	SEG-*

L4Asset (AST)

Six asset classes. The concrete elements that implement a service. Every asset names its SVC parent and may carry an optional SUBSYSTEM grouping.

Code	Label	Description	Parent
AST-HW	Hardware	Physical components, boards, buses, mechanical assemblies.	SVC-*
AST-FW	Firmware	Code burned to non-volatile memory; operates close to hardware.	SVC-*
AST-SW	Software	Operating systems, runtimes, applications, flight-software images.	SVC-*
AST-DA	Data	Mission data, telemetry, configuration, credentials.	SVC-*
AST-SI	Signal	RF/EM signal as an enumerated asset, distinct from the link segment.	SVC-*
AST-HY	Hybrid	Asset that spans more than one of the five primary asset classes.	SVC-*

L5Analytic (AN)

Six analytic categories. Confirmed real-world findings produced by defenders and attached via a TARGET field to the structural element on your platform that the finding concerns.

Code	Name	Definition (real-world only)	Target
AN-IOC	Indicator of Compromise	Confirmed artifact left by an adversary on the platform: file hash, C2 address, malicious registry key, suspicious URL, observed in your environment.	TOE
AN-IOA	Indicator of Attack	Confirmed adversary behaviour pattern observed in motion: anomalous authentication, lateral movement, abnormal process spawning.	TOE
AN-ATT	Attack Path	Validated traversal sequence the adversary actually took or attempted across the platform, from initial access to objective.	TOE
AN-THR	Threat	Confirmed adversary group or actor with demonstrated targeting of platforms like yours.	TOE
AN-DET	Detection Signature	Tested rule (RootA, Sigma, Yara) that fires on an IOC, IOA, or attack-path pattern; deployed and tested on a specific structural element.	TDM
AN-RES	Resilience Measure	Tested defensive capability that withstands or recovers from a confirmed threat: failover, defence-in-depth, hot-standby, hardened boot.	TRE

Target fields

Every analytic finding attaches to the structural element it actually concerns. Three target fields, one per analytic role.

TOE

Target of Exploitation. Used by AN-IOC, AN-IOA, AN-ATT, AN-THR. The structural element the adversary actually exploited or targeted.

TDM

Target of Detection Method. Used by AN-DET. The structural element the signature is actually deployed against and tested on.

TRE

Target of Resilience Enhancement. Used by AN-RES. The structural element the resilience measure actually protects.

Worked examples · full LAYER : TAG : LABEL : ORDINAL form (real-world only)

Single coherent incident scenario across the analytic layer. Ordinals show realistic catalogue position (a mature programme, not the first finding ever). Same structural elements (the same software, the same control plane) are referenced consistently across rows; the AN-DET cites the AN-IOA it was written to cover, ordinal to ordinal.

Category	Enumerated identifier	Target attachment + source
AN-THR	AN : THR : Threat : 03	TOE → PCE : OR : Orbital : 00 · APT group with demonstrated targeting of orbital platforms. Source: government brief and Space ISAC bulletin 2026-Q1.
AN-IOC	AN : IOC : Indicator of Compromise : 14	TOE → AST : SW : Software : 03 · malicious payload hash observed in flight-software image during forensic review. Source: incident ticket INC-2026-0142.
AN-IOA	AN : IOA : Indicator of Attack : 07	TOE → SVC : CP : Control Plane : 00 · anomalous authentication from non-whitelisted source observed in SIEM 2026-02-03. Source: SIEM alert ID 88421.
AN-ATT	AN : ATT : Attack Path : 02	TOE → AST : SW : Software : 03, SVC : CP : Control Plane : 00, SEG : SP : Space : 00 · full path validated in red-team exercise; ties `AN : IOC : Indicator of Compromise : 14` and `AN : IOA : Indicator of Attack : 07` to `AN : THR : Threat : 03`. Source: red-team report RT-2026-Q1.
AN-DET	AN : DET : Detection Signature : 09	TDM → AST : SW : Software : 03 · RootA rule covering `AN : IOA : Indicator of Attack : 07`; tested with FP rate < 1%. Source: rule pack v2.4 + test results TS-2026-Q2.
AN-RES	AN : RES : Resilience Measure : 05	TRE → SEG : GR : Ground : 00 · hot-standby ground station; goal: Recover; addresses recurrence of the path captured in `AN : ATT : Attack Path : 02`. Source: resilience test report RT-GR-2026-Q2.

Discipline. Every analytic identifier is anchored to a specific structural element on your platform. No floating findings. No hypotheticals. That discipline is what makes community sharing low-volume and high-impact: every entry is high-confidence, actionable, and worth a peer's attention.