INTELLIGENCE WITHOUT CONTEXT IS NOISE
A controlled, published vocabulary names every part of a space platform. Four structural categories cover the whole platform, from the environment it operates in down to the concrete elements that implement its capabilities. The real-world implementation lives at machinetag.json, distributed as an open-source MISP taxonomy. You will learn each element and how to name your own platform with it in the next modules.
A controlled, published vocabulary names every part of a space platform. Four structural categories cover the whole platform, from the environment it operates in down to the concrete elements that implement its capabilities. Each name is fixed, machine-readable, and carries a stable identifier so two operators describing the same kind of thing always write the same words.
The real-world implementation lives at meteorstorm/machinetag.json, distributed as an open-source MISP taxonomy. Point your Threat Intel Platform at the namespace and the vocabulary is available immediately, identical across every operator that does the same.
You will learn each structural category and how to enumerate your own platform’s elements against it in the next modules. The point of this overview is the pattern: a single open vocabulary, published and machine-readable, that every operator and partner can read without translation.
Every name in the vocabulary points up to its parent in the layer above, forming a single chain from the most concrete asset back to the environment the platform operates in. A finding on any small part traces back through the chain to the larger part it concerns, so every defender inherits structural context for free. You will walk the chain and write your own in the next modules.
PCE) layer is the root. Every Segment element names one or more Primary Capability Environment instances as its PARENT. Every Service element names its parent Segment. Every Asset element names its parent Service. This chain is what makes a finding traceable: a detection that fires on the asset element AST : HW : Hardware : 03 follows the parent chain back to its Service, then its Segment, and finally its Primary Capability Environment. Top-down, the model decomposes a complex platform; bottom-up, the same model gives every defender automatic structural context for any observation.
WITHOUT NORMALIZED ANALYTICS, CONTEXT DOES NOT TRAVEL
A controlled, published vocabulary names every kind of analytic finding defenders produce. Six fixed categories cover the entire analytic surface, from what the adversary leaves behind through the response that holds. The real-world implementation lives in the same machinetag.json file as the structural vocabulary. You will walk this example and learn each category in the next modules.
AN). The Analytic Layer does not describe the platform; it describes what defenders observe and what defenders are building to protect the platform. Six sub-categories cover the full analytic surface. AN-IOC enumerates an Indicator of Compromise, AN-IOA enumerates an Indicator of Attack, AN-ATT enumerates an Attack Path, and AN-THR enumerates a Threat. AN-DET enumerates a Detection Signature, and AN-RES enumerates a Resilience Measure. Six analytic verbs that every function in the framework speaks fluently.
Each analytic finding attaches to the structural elements it concerns through a target field, so every analytic claim has structural ground to stand on. A finding without a target attachment is a free-floating note; with one, the finding belongs to a specific part of the platform every defender can locate. You will learn the target fields and how to attach your own findings in the next modules.
PARENT. They attach to the structural layers through one of three TARGET fields, depending on which analytic verb the element is using. The four threat-side categories (Indicator of Compromise, Indicator of Attack, Attack Path, and Threat) all use the TOE field, the Target of Exploitation, enumerating the structural elements the analytic element was observed on or applies against. Detection Signature elements use the TDM field, the Target of Detection Method, enumerating the structural elements the signature observes. Resilience Measure elements use the TRE field, the Target of Resilience Enhancement, enumerating the structural elements the measure protects. An analytic tag without a target reference is free-floating noise; the Concept of Operations exists so every analytic claim has structural ground to stand on.
WITHOUT FOCUS, DEFENSE FAVORS THE ATTACKER
Master Decomposition
"The adversary suffers when you know your platform better than they ever can."
Organizations must have a deeper understanding of their platforms than the adversaries targeting them, from development to decommissioning.
Master Contextualized Threat Modeling
"The adversary suffers when every strike they imagine is already prepared for."
Develop attack-to-defend capability across kinetic, non-kinetic, electronic warfare, cyber warfare, and natural-threat domains.
Master Converged Detection Engineering
"The adversary suffers when they cannot hide, and every move is seen."
Evolve into a converged data and signals approach to illuminate complex attack patterns and reduce adversary dwell time.
Master Exposure Management
"The adversary suffers when every path they take ends in a trap."
Continually enumerate the attack paths created by both exposed and isolated platform elements and work toward platform deception techniques.
Master Adversary Management
"The adversary suffers when their plans are known, broken, and turned against them."
Align the prior four masteries with real-world adversary profiles to detect, disrupt, and deter adversaries targeting the platform.
ONE ENTRY POINT STALLS MOST TEAMS
- Adopt the shared vocabulary inside your existing Threat Intel Platform so every confirmed finding reads the same way for every analyst, vendor, and partner. Federating with Space ISAC peers is a recommended next step, not a prerequisite.
- Align Security Operations, Satellite Operations, and Satellite Design & Engineering on the five-function process while the platform is being designed or rebuilt, so each team runs the framework as part of daily work rather than alongside it.
- Run exercises in an environment fully separate from production with Security Operations, Satellite Operations, and Satellite Design & Engineering, using synthetic adversary data, so the detection signatures, response playbooks, and resilience measures the three teams build during the exercise graduate straight into production the moment it closes.
ACTIVATE
010203- Review the policy, procedure, and platform that govern how your team handles cyber threat intel today.
- Update each so they reflect the framework's vocabulary for space threat intel.
- Update your Priority Intelligence Requirements (PIR), the questions the team is meant to answer, to cover space threats.
- Load the framework's shared vocabulary file into the CTI platform your team already runs.
- Make sure activation follows the policy and procedure you just validated.
- From this moment, every analyst dropdown shows the same labels and every team speaks the same words.
- Establish internal sharing so every team that touches the platform reads from the same single source.
- Consider external sharing to the established space-sector channel, Space ISAC, when policy supports it.
- All sharing stays in alignment with the CTI policy, procedure, and platform you validated in step one.
INTEGRATE
F01F02F03F04F05- Decompose only what your mission scope requires; you do not have to model the entire platform.
- Capture the parent of each part you enumerate so any later finding traces back through the chain you decomposed.
- Output: a scoped tree where every part you enumerated has a name, a parent, and a place in the design.
- For every part of the platform, ask which threats actually apply to that specific part.
- Anchor each threat to the part it would target, not in the abstract; an orbital threat is not the same as a ground-site threat.
- Output: a threat catalogue where every entry points back at a real piece of your design.
- For each cataloged threat, trace how an adversary could move through the platform to make it real.
- For each step on each path, enumerate the data and signal sources needed to observe it; where no source exists yet, the gap is itself a finding the team must close before launch.
- Output: a map of every path plus the data and signal source inventory Incident Response Preparation will use to write signatures and playbooks.
- For every step on every attack path, write the detection signature that fires on the data/signal source CDE delivered.
- For every signature, write the response playbook the Security Operations runs the moment the signature fires.
- Output: tested detection signatures in an open format and the playbooks they trigger, each tied back to the attack path it covers.
- Identify the parts of the platform that show up across many threats and many attack paths.
- Build resilience measures that shrink, harden, or eliminate those parts before launch.
- Output: a portfolio of measures, each tied to one of four resilience goals: anticipate, withstand, recover, adapt.
ENGAGE
0102030405- Walk the Concept of Operations process to enumerate the structural elements the exercise will operate on.
- Pull the platform decomposition from an existing platform’s CONOPS records, or model an in-design platform from scratch. The exercise environment runs on this structural model only, never on the live system.
- Output: the structural model that every synthetic adversary input will attach back to.
PCE → SEG → SVC → AST, with parents and labels, exactly as the framework requires. The decomposition becomes the structural model the exercise environment runs against; the live operational platform never participates in the exercise. The adversary inputs in step 04 will attach via TOE, TDM, and TRE back to these structural elements; without that anchor, exercise findings cannot be reasoned about.
- Choose one or more adversary archetypes the scenario will pit against the platform.
- Profile each adversary using the framework's adversary profile template: capabilities, motivation, demonstrated TTPs, source.
- Output: a small adversary catalogue the participants will recognize and respond to in step 05.
AN-THR your operations team already tracks; the exercise then tests muscle memory against an actual adversary the platform faces. Where the adversary is invented for training, mark the profile clearly as a teaching archetype so it never contaminates the operational threat catalogue.
- For each adversary profile from step 02, decide which analytic categories the exercise will exercise.
- Pre-position the framework's controlled vocabulary so participants speak the same words operations does.
- Output: a normalized analytic catalogue, anchored to the step 01 structural model, ready to populate in real time.
AN-IOC), Indicator of Attack (AN-IOA), Attack Path (AN-ATT), Threat (AN-THR), Detection Signature (AN-DET), Resilience Measure (AN-RES). Pre-position the controlled vocabulary in the exercise platform so the team enumerates findings using the same labels and the same target fields (TOE, TDM, TRE) they would in operations. Decide ahead of time which analytic categories the scenario covers, and whether participants will produce findings across all six or focus on a subset.
- Deploy the exercise on a custom virtual machine, container stack, or partner ecosystem; never on production infrastructure.
- Pre-load synthetic telemetry data, synthetic signals, and a METEORSTORM-tagged CTI catalogue so the platform behaves like operations from day one.
- Output: an exercise environment isolated from production but identical in vocabulary and tooling.
AN-IOC, AN-IOA, AN-ATT, and AN-THR entries that drive the scenario. The CTI platform itself is a real instance of the same platform operations runs (OpenCTI, ThreatConnect, Anomali ThreatStream, or whichever TIP the team runs), pointed at the synthetic catalogue. Participants experience the same tools and the same vocabulary they use every day.
- Participants build detection rules and resilience measures in response to the adversary's actions.
- Validate every team-crafted output against the actual adversary actions the exercise scripted: did the rule fire, did the measure hold?
- Output: production-grade detection and resilience that graduate to the operational catalogue once the exercise closes.
AN-DET rules, validated against the synthetic adversary inputs from step 04. Resilience measures the team designs are real engineering work captured as AN-RES elements, validated against the path the adversary actually traversed in the scenario. Every team-crafted output is scored against adversary actions: did the AN-DET signature fire on the synthetic AN-IOC and AN-IOA the scenario produced; did the AN-RES measure prevent or recover from the AN-ATT path the adversary took. Outputs that pass validation graduate to the operational catalogue when the exercise closes; outputs that fail validation become the next exercise's training material.
A SECOND PASS THROUGH THE FIVE FUNCTIONS
Problem No shared structural vocabulary across the operational stack.
Solution Decompose the platform tailored to your requirements.
Problem Threats tracked as actor names with no link to the platform elements they target.
Solution Enumerate the threats that apply to each part.
Problem Detection rules written before attack paths and source inventory exist.
Solution Map attack paths and the data and signal sources needed to detect each step.
Problem Vendor-locked signatures with no paired response playbook for the SOC.
Solution Write the detection signatures and response playbooks.
Problem The same adversary returns; the same flaw stays exposed; no shared posture.
Solution Shrink the attack surface the threats keep using.
CONCEPT OF OPERATIONS
Three operating domains have no published structural vocabulary in the space sector. Aquatic operations, sea-launched, sea-recovered, and submarine endpoints, get invented names per operator. Aerial platforms in the high-altitude, near-space, and stratospheric regimes sit between ground and orbital frameworks with no agreed parent-child relationships. And lunar, cislunar, and Mars-class deep-space missions have no formal decomposition at all, so findings on those platforms cannot be compared across missions or operators.
METEORSTORM gives every part of the platform a published name across four layers: where it operates, the operational role of each enclave, the capability delivered, and the concrete elements that implement it. The water, atmosphere, and beyond-orbit gaps from earlier vocabularies are all named; every domain decomposes the same way under one parent-child rule. Tap More for the full layer-by-layer map.
- Decompose only what your mission scope requires; you do not have to model the entire platform.
- Capture the parent of each part you enumerate so any later finding traces back through the chain you decomposed.
- Output: a scoped tree where every part you enumerated has a name, a parent, and a place in the design.
CONTEXTUALIZED THREAT MODELING
Space-sector threat modeling has three structural gaps. Teams import generic threat catalogues, IT lists or unmapped actor profiles, that do not anchor to specific orbital, aerial, or aquatic platforms. Threats are tracked as actor names without naming the structural elements they actually target, so an orbital threat looks identical to a ground-site threat. And risk decisions cannot cite the platform model, so “we accept this threat” comes from intuition rather than from which structural elements are actually exposed.
Every threat is enumerated against your own platform decomposition; the threat names the real structural elements it targets, not generic categories. Each threat enumerates its target chain explicitly, so an orbital threat and a ground-site threat carry distinct attachments and are prioritized accordingly. Prioritization follows from structural exposure, how many services and assets the threat touches, weighted by criticality, with a traceable rationale leadership can read.
- For every part of the platform, ask which threats actually apply to that specific part.
- Anchor each threat to the part it would target, not in the abstract; an orbital threat is not the same as a ground-site threat.
- Output: a threat catalogue where every entry points back at a real piece of your design.
CONVERGED DETECTION ENGINEERING
Most teams jump from threat directly to detection rules without mapping how the adversary would actually traverse the platform, so attack paths are never enumerated. Adversary movement that crosses ground, link, space, and user boundaries is rarely modeled because the structural ontology does not connect domains, leaving cross-domain paths as blind spots. Even when paths exist, the data and signal sources needed to detect each step are never inventoried, so signatures get written against sources the platform may not even produce. And when the platform evolves, nobody re-walks either the paths or the source inventory, so both go stale together.
Every attack path enumerates the ordered chain of structural elements the adversary touches from initial access to objective. For each step on that chain, the data and signal sources required to observe it are inventoried alongside the path. The same parent-child rule applies in every domain, so paths that cross ground, link, space, user, or deep-space boundaries enumerate naturally. Paths and source inventory are versioned and re-walked when their cited structural elements change, and the combined map drives detection-engineering work directly.
- For each cataloged threat, trace how an adversary could move through the platform to make it real.
- For each step on each path, enumerate the data and signal sources needed to observe it; where no source exists yet, the gap is itself a finding the team must close before launch.
- Output: a map of every path plus the data and signal source inventory Incident Response Preparation will use to write signatures and playbooks.
INCIDENT RESPONSE PREPARATION
Detection signatures sit in proprietary vendor rule languages, so a signature written for one platform must be re-implemented for the next and community sharing breaks at the format boundary. Signatures ship as a flat catalogue with no back-reference to the attack-path step they cover or the data and signal source they observe, so coverage gaps per attack path are invisible. And signatures ship without paired response playbooks, so the Security Operations fires the alert and improvises the response, stretching adversary dwell time while responders rebuild the playbook from scratch.
Detection signatures are written in RootA.io, the open vendor-neutral language, so the same signature moves across OpenCTI, ThreatConnect, Anomali ThreatStream, and the major SIEM platforms without rewrite. Every signature back-references the attack-path step it covers and the data or signal source it observes (both inherited from Converged Detection Engineering’s catalogue), making coverage measurable per attack path. Every signature ships paired with a response playbook so the Security Operations has a documented action the moment the signature fires.
- For every step on every attack path, write the detection signature that fires on the data/signal source Converged Detection Engineering delivered.
- For every signature, write the response playbook the Security Operations Center runs the moment the signature fires.
- Output: tested detection signatures in an open format and the playbooks they trigger, each tied back to the attack path it covers.
ADVERSARY MANAGEMENT
Top-tier adversaries are tracked as point incidents, not as durable profiles, so when the same actor returns with new tooling the team has no rolling picture of who they are or what techniques are currently succeeding. The structural weaknesses adversaries are successfully exploiting are never connected across incidents, so the same flaw stays exposed while resilience work chases the latest finding. And nobody coordinates short-term compensating controls with long-term engineering remediation, so the platform is either exposed for years waiting for re-engineering or accumulates compensating controls as permanent technical debt with no path to a real fix.
Each cataloged threat carries a durable top-tier adversary profile (aliases, TTPs, target sectors, what is currently succeeding) updated in place rather than rebuilt per incident. Structural elements with the highest TOE recurrence across AN-THR and AN-ATT are surfaced as the weaknesses the adversary keeps finding leverage on, and those go to the front of the resilience queue. Each AN-RES splits into two timelines: immediate compensating controls Security Operations and Satellite Operations deploy in days or weeks, and engineering remediation Satellite Design and Engineering owns over months or years. Both reference the same target structural element so the bridging control retires the moment the long-term fix lands.
- Identify the parts of the platform that show up across many threats and many attack paths.
- Build resilience measures that shrink, harden, or eliminate those parts before launch.
- Output: a portfolio of measures, each tied to one of four resilience goals: anticipate, withstand, recover, adapt.