Taxonomic Element Nomenclature (TEN)
The Analytic Layer is the fifth layer of the METEORSTORM data model, built on the four structural layers that enumerate the platform itself. The layer contributes three mechanisms. Its taxonomy classifies analytic knowledge into six elements, each carrying its published definition verbatim. Its ontology anchors every enumerated analytic element through a fixed target field to the exact platform elements it concerns, so a finding recorded against an asset is reachable from the service, the segment, and the environment above it. Its normalization is the innovation: intelligence and peer-framework content, whatever its origin, is normalized into the same six elements and attaches to the same decomposition in one shared vocabulary, so the catalogue keeps pace with the ecosystem without re-architecting the data model. This card is the taxonomic dictionary for the analytic layer; the organizational enumeration is the companion analytic ETEN reference.
The analytic layer was developed for front-line space collective defense. The intent of the layer: entries move operator to operator as machine-to-machine exchange across a trusted network, and a peer acts on an entry without renegotiating its provenance. Every entry declares its SOURCE at the gate before enumeration.
The four structural layers classify what the platform is. The analytic layer classifies what the analyst knows about it, in a form every participating organization reads identically. Its six elements answer the six questions an analyst asks in the order a situation unfolds: has a platform been compromised, is an attack confirmed, is an attack path active, is a threat confirmed, is a detection signature available, and can the threat be engineered out of the platform. A platform means the organization’s own or a trusted community member’s.
The six-element structure is also the layer's intake surface. Peer frameworks evolve on their own timelines; their content normalizes into these six elements without changing the data model. The ingestion structure is fixed, the contents refresh continuously, and evolution in the peer ecosystem becomes a taxonomy update, not a re-architecting.
METEORSTORM Data Model Fields
Every element below carries its published fields. To record one real analytic element on your platform, switch to the colon ETEN nomenclature in the companion analytic ETEN reference.
The Gate
The analytic layer was developed for front-line space collective defense. The intent of the layer: entries move operator to operator as machine-to-machine exchange across a trusted network, and a peer acts on an entry without renegotiating its provenance. That intent holds only if every entry declares its SOURCE before enumeration:
SOURCE=observable · Built on a real-world report: a signal or data captured from a system. The standard for Indicator of Compromise, Indicator of Attack, Attack Path, and Threat.SOURCE=synthetic · Authored data for system resilience engineering and operational exercises.Predicate: “Analytic constructs for threat, detection, and resilience.” The ENRICHMENT layer. Every AN element is an enrichment element; it anchors to the platform element it concerns through its target field.
METEORSTORM Data Model Fields
The target field is fixed by the element; it is never chosen freely. It references platform elements in any layer, PCE, SEG, SVC, or AST, so a threat can anchor to the environment itself; it never references another enrichment element.
Question 01 · Has an organizational or trusted community member platform been compromised?
Indicator of Compromise
The highest priority analytic element: backward-looking evidence of a confirmed platform breach, traceable to an actual incident or live operator telemetry, and acted on by a peer operator without further analysis.
Question 02 · Is there a confirmed attack against an organizational or trusted community member platform?
Indicator of Attack
Present-tense evidence that adversary activity is in progress against the platform. The compromise may or may not have completed; the response window is open. Past and present stay separate elements so each question gets its own decision path.
Question 03 · Is there an active attack path against an organizational or trusted community member platform?
Attack Path
A documented sequence of adversary actions that could traverse the platform from entry to impact. An exposure, not an observation: recorded in enough detail for another analyst to evaluate it against their own platform.
Question 04 · Is there a confirmed threat against an organizational or trusted community member platform?
Threat
A known adversary capability or campaign directed at the platform, built on attributed activity: threat-intelligence reporting, government attribution, or a peer-shared adversary profile. Where the Attack Path records what the platform exposes, the Threat records who is likely to exercise it.
Question 05 · Is there a confirmed detection signature available for a confirmed threat?
Detection Signature
The written commitment to see a specific behavior, expressed in the open RootA format so a signature written by one operator deploys in another operator's stack; the native vendor query rides along as enrichment. A threat or attack path with no matching signature is a detection gap, and the gap is itself an enumerable analytic product.
Question 06 · Is there a means to engineer the threat out of the platform?
Resilience Measure
The forward-looking element: a protective capability serving one of the four resiliency goals of NIST SP 800-160 Volume 2, Anticipate, Withstand, Recover, Adapt. Applied in place at the cadence the technology supports, or captured as input to the next generation of platform design when the vehicle is on orbit.
The catalog is what the layer produces: the organized, running collection of analytic elements that results from enumerating the organization's own intelligence and normalizing peer-framework content into the six elements, expressed in this nomenclature and anchored to the structural decomposition of the platform being defended. The catalog is not a separate product; it is what an organization ends up with after applying the method consistently. METEORSTORM does not replace the source frameworks below; it provides a way for organizations to normalize the fluid and broad range of reference frameworks into one reliable lens, so every framework contributes to the same catalog without forcing its vocabulary on the others.
Different source types feed different elements, and the element tags in the SOURCE column are recommendations, not restrictions: they name the elements each source most naturally supplies. Threat-intelligence feeds carrying observations from real incidents feed the two indicators; an indicator entry is never drawn from an architectural framework, because an indicator cannot be theoretical. Adversary-behavior catalogues feed Attack Path and Threat. Control and defensive-technique frameworks feed Detection Signature and Resilience Measure.
| Framework | Publisher | SOURCE |
|---|---|---|
| Trusted threat-intelligence feeds (Space ISAC Exchange, vendor and government reporting, own telemetry) | Various | IOC · IOA · ATT · THR · DET · RES |
| MITRE ATT&CK | The MITRE Corporation | ATT · THR · RES |
| MITRE FiGHT | The MITRE Corporation with the U.S. DoD 5G Cross-Functional Team | ATT · THR · RES |
| MITRE ATLAS | The MITRE Corporation | ATT · THR · RES |
| MITRE CAPEC | The MITRE Corporation | ATT |
| Aerospace SPARTA | The Aerospace Corporation | ATT · THR · DET · RES |
| ESA SPACE-SHIELD | European Space Agency | ATT · THR · RES |
| MITRE EMB3D | The MITRE Corporation | ATT · THR · RES |
| MITRE D3FEND | The MITRE Corporation, funded by the NSA | DET · RES |
| CSA AI Controls Matrix | Cloud Security Alliance | RES |
| CSA Cloud Controls Matrix | Cloud Security Alliance | RES |
| CSA Shared Security Responsibility Model | Cloud Security Alliance | RES |
| NIST SP 800-160 Volumes 1 and 2 | National Institute of Standards and Technology | RES |
| NIST SP 800-53 | National Institute of Standards and Technology | RES |