WE NEED YOU TO IMPLEMENT A STANDARD TAXONOMY AND ONTOLOGY
You were hired to stop intelligence dying at the boundaries between Kestrel Orbital's departments, and the taxonomy is SCOR's first move against it. It gives every part of a space platform one name across the four structural layers, from the Primary Capability Environment it operates in down to the Assets that implement its capabilities. It is real and already in the open: the implementation lives at machinetag.json as an MISP taxonomy. You will apply each layer and name your own platform with it in the days ahead.
Naming the parts is half the job; making those names connect is how you finish closing the gap, and that is the ontology. Every element anchors to its parent in the layer above, forming one chain from the most concrete Asset back to the Primary Capability Environment the platform operates in. Attach enrichment to any small part and it traces back through the chain to the larger part it concerns, so every defender you serve inherits structural context for free. You will walk the chain and write your own in the next modules.
WE NEED YOU TO IMPLEMENT RESILIENT CYBER OPERATIONS
This is how you make enrichment usable by every department: one published taxonomy for every kind of enrichment you produce. Six fixed categories cover the entire analytic surface, from what the adversary leaves behind through the response that holds. It lives in the same machinetag.json file as the structural taxonomy. You will apply each category to your own enrichment in the days ahead.
Enrichment is only useful if it points at a specific part of the platform. You attach each enrichment element to the structural elements it concerns through a target field, so every claim has structural ground to stand on. An enrichment element without a target is a free-floating note; with one, it belongs to a specific part of the platform every defender can locate. You will work with the target fields and attach your own enrichment in the days ahead.
WE NEED YOU TO TURN THE COST BACK ON 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.
WE NEED YOU TO START WHERE EACH DEPARTMENT ALREADY IS
- Adopt the shared taxonomy inside your existing Threat Intel Platform so confirmed enrichment reads the same way for every analyst, vendor, and partner. Federating with Space ISAC peers stands up the sharing channel Kestrel Orbital requires; what you federate stays selective.
- Align Security Operations, Satellite Operations, and Satellite Design & Engineering on the five-function process while the platform is being designed or rebuilt, so each department 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 departments build during the exercise graduate straight into production the moment it closes.
ACTIVATE
010203- Review the policy, procedure, and platform that govern how Kestrel Orbital handles cyber threat intel today.
- Update each so they reflect the framework's taxonomy for space threat intel.
- Update your Priority Intelligence Requirements (PIR), the questions your analysts are meant to answer, to cover space threats.
- Load the framework's shared taxonomy file into the CTI platform Kestrel Orbital 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 department speaks the same words.
- Establish internal sharing so everyone who touches the platform reads from the same single source.
- Stand up external sharing to Space ISAC, the channel Kestrel Orbital requires; push through it as policy supports.
- 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 enrichment 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 enrichment the program 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- Run 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 documentation, 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.
- 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.
- For each adversary profile from step 02, decide which analytic categories the exercise will exercise.
- Pre-position the framework's taxonomy 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.
- 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 taxonomy and tooling.
- Participants build detection rules and resilience measures in response to the adversary's actions.
- Validate every participant-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.
THE FIVE FUNCTIONS
No shared structural taxonomy across the operational stack.
Threats tracked as actor names with no link to the platform elements they target.
Detection rules written before attack paths and source inventory exist.
Vendor-locked signatures with no paired response playbook for the SOC.
The same adversary returns; the same flaw stays exposed; no shared posture.
Decompose Kestrel Orbital’s platform into enumerated elements all three departments read the same way.
Enumerate the threats against Kestrel Orbital’s platform and anchor each one to the elements it targets.
Map how an adversary would traverse Kestrel Orbital’s command path, and the data and signal sources needed to see each step.
Write the detection signatures and the response playbooks the Security Operations Center runs when they fire.
Shrink the attack surface the adversary keeps finding across Kestrel Orbital’s missions.