Master Decomposition.
“The adversary suffers when you know your platform better than they ever can.”
You lead SCOR, Kestrel Orbital’s new Space Cybersecurity Operations and Resilience department, and today you drive the organization to understand its platform more deeply than the adversaries targeting it. Decomposition is the instrument you wield to make that understanding operational: every part of the platform named, placed inside one of four layers, anchored to its parent, and annotated so Security Operations, Satellite Operations, and Satellite Design & Engineering read the same platform the same way. The tree you build today feeds the asset management NIS2 requires, names the on-orbit and link segments Executive Order 14144’s command-and-control protections apply to, and produces elements the Space ISAC channel can share machine to machine.
DAY 1 START
Day one at Kestrel Orbital. SCOR’s first delivery starts with one task: decompose the telecommand path that keeps the satellite under control into shared enumerated elements, so Security Operations, Satellite Operations, and Satellite Design and Engineering can describe it the same way. Command and control is where Executive Order 14144 and the NIS2 Directive focus, so that is where your decomposition starts.
DAY 1
-
You will build Kestrel Orbital's new Space Cybersecurity Operations and Resilience (SCOR) department. Its mission is one unified view of the platform, context and enrichment together, shared by Security Operations, Satellite Operations, and Satellite Design & Engineering. You will give them one shared way to describe the command path of the platform, the scope Executive Order 14144 and the NIS2 Directive hold Kestrel Orbital to. You do not need to be the expert in each; your job is to build the team and give it a common language.
-
Today you decompose the telecommand path, the path that keeps the satellite under control, across the four layers from start to finish. That path is where the mandates focus, so it is where you start. You will leave able to name every part of it the same way, so all three departments can act on what you write. The model you use today already covers the environments Kestrel Orbital's business plan drives toward, maritime, aerial, and deep space, so nothing you name now needs renaming when those markets arrive.
-
Day 2 adds the threats to the command path you map today. Day 3 traces how an attacker would move against it, and what data you need to catch them. Day 4 turns that into the detections and response procedures the NIS2 reporting clocks assume. Day 5 builds the defenses that take options away from the attacker.
Data Model
One standard data model for the whole of Kestrel Orbital's platform. Every part resolves to a single element in one of four layers (PCE, SEG, SVC, AST), so Security Operations, Satellite Operations, and Satellite Design & Engineering describe the same platform the same way. This is the context half of SCOR's mission, the structure everything else attaches to.
ONE VOCABULARY FOR THREE DEPARTMENTS
-
The three departments are not aligned. Security Operations, Satellite Operations, and Satellite Design & Engineering each name the same element on the spacecraft differently, so what one department knows does not carry cleanly to the other two.
-
METEORSTORM gives all three departments one controlled vocabulary. Every part of the platform is named by exactly one element, sorted into four layers:
PCE,SEG,SVC,AST. -
Today you start explaining the vocabulary to each department in terms of what it gets back: Security Operations writes detections that target an exact element, Satellite Operations uses the same names on console to know what’s degraded, and Satellite Design & Engineering routes patches against the same vocabulary. Three departments, one description, no translation loss.
PCE
PRIMARY CAPABILITY ENVIRONMENT LAYER
Operational zone in which a capability primarily exists or is exercised.
SEG
SEGMENT LAYER
Service and asset enclaves that compose the system across environments.
SVC
SERVICE LAYER
Functional planes that organize control and data responsibilities.
AST
ASSET LAYER
Asset classes composing the system and its interfaces.
TAXONOMY AND ONTOLOGY
-
Pick names from the published list (Taxonomic Element Nomenclature, TEN). It’s the controlled list of compliant names. Invent your own and you break the deal with Security Operations, Satellite Operations, and Satellite Design & Engineering.
-
Every element links up to its parent. Each element says “this lives inside that.” The chain ends at the environment the platform operates in (
PCE). -
These two rules are what you teach each department first, because together they let any enrichment element inherit all the context above it for free. You show Security Operations how to pivot from indicator to element to service to segment to environment in one query, and you show Satellite Operations and Satellite Design & Engineering how to read the same chain from their own ends of it.
One controlled vocabulary, shared inside and outside your organization. Cyber, space ops, engineering, vendors, peer operators, and Space Information Sharing and Analysis Center (Space ISAC) members could all use the same words for the same things, no private dialects, no translation tax. At Kestrel Orbital that channel is not a nice-to-have: information sharing with Space ISAC is a company mandate, and this vocabulary is what makes it work machine to machine.
PCE · 5 elements: TE Terrestrial, AQ Aquatic, AE Aerial, OR Orbital, DS Deep Space.SEG · 10 elements: LA Launch, LI Link, GR Ground, US User, AQ Aquatic, LO Low Altitude, HI High Altitude, NE Near Space, SP Space, DE Deep Space.SVC · 3 elements: CP Control Plane, DP Data Plane, HY Hybrid.AST · 6 elements: HW Hardware, FW Firmware, SW Software, DA Data, SI Signal, HY Hybrid.Rules for how taxonomic elements relate. The four decomposition layers form a strict parent-child chain.
PCE is the root and has no link above it. Every other layer traces back to one or more PCE instances.SEG links up to one or more PCE instances.SVC links up to one or more SEG instances.AST links up to one or more SVC instances.ENVIRONMENT LAYER
Where a space system operates: Terrestrial, Aquatic, Aerial, Orbital, and Deep Space. When a symptom appears, operations often cannot tell an environmental effect (space weather, atmospheric drag, radiation) from a cyber-physical adversary action. This layer is the enrichment that deconflicts the two, so a natural anomaly is not chased as an attack and an attack is not written off as weather.
WHERE THE PLATFORM OPERATES
First layer, top of the chain. The Primary Capability Environment (PCE) records the environment our platform operates in. Every other layer points up to a PCE element, so getting this right matters because every downstream enrichment element inherits the context. The values you’ll see in the published taxonomy. Terrestrial, Aquatic, Aerial, Orbital, and Deep Space. For our satellite-control work today, two of these are in scope: Terrestrial (where the ground complex sits) and Orbital (where the bird flies). The others are reference for when you encounter the platforms that operate there. How the three departments use PCE. Security Operations inherits PCE context on every alert without re-deriving it. Satellite Operations reads PCE to know which regulatory regime and response posture applies. Satellite Design & Engineering reads it because the same hardware behaves differently on the ground than on orbit. With one shared PCE context, every alert, console call, and patch reads the same environment the same way, instead of three departments re-deriving it three different ways.
TERRESTRIAL
Definition. Surface-based operational zones on planetary bodies. This layer names the surface itself, the where. The ground stations, control centers, and other equipment that sit on it are named later, at the segment, service, and asset layers, not here.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Any portion of the platform, control center, antenna farm, data center, manufacturing facility, launch pad, sits on the ground of a planetary body. One PCE-TE-NN per distinct surface site. Geographic separation matters: a primary and a backup ground complex are typically separate ordinals so failover analysis stays clean.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
AQUATIC
Definition. Water-based operational zones, including but not limited to Earth’s maritime domains. This layer names the water itself, the where. The tracking ships, sea-launch platforms, and other equipment that operate on it are named later, at the segment, service, and asset layers, not here.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Elements of the platform sit on, in, or under water as a primary operating zone, not transiting. Subsea cabling, downrange recovery vessels, sea-launch barges, and undersea sensor networks all live here. Maritime jurisdiction, sea-state telemetry, and acoustic environment data attach to PCE-AQ elements.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this environment as a first phase, groundwork for the maritime market; Service and Asset tagging of the OSINT is the optional second stage.
AERIAL
Definition. Atmospheric operational zones spanning lower, upper, and near-space regions. This layer names the air itself, the where. The balloons, drones, and high-altitude aircraft that fly in it are named later, at the segment, service, and asset layers, not here.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Any portion of the platform operates within an atmosphere but not on or beneath a surface, drones, balloons, HAPS / LAPS, near-space vehicles, transit aircraft. Atmospheric weather, civil aviation jurisdiction, and electromagnetic propagation context all attach to PCE-AE.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this environment as a first phase, groundwork for the aerial and high-altitude market; Service and Asset tagging of the OSINT is the optional second stage.
ORBITAL
Definition. Operational zones within planetary or satellite orbits. This layer names the orbit itself, the where. The spacecraft and other equipment that operate there are named later, at the segment, service, and asset layers, not here.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the orbit a spacecraft flies in. One PCE-OR-NN per distinct orbital regime the platform uses.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
DEEP SPACE
Definition. Operational zones beyond planetary orbital regimes. This layer names that region itself, the where. The deep-space probes, distant observatories, and other equipment that operate there are named later, at the segment, service, and asset layers, not here. A simple test: when no single planet or moon controls the path, you are in deep space.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing operations beyond planetary orbit. One PCE-DS-NN per distinct deep-space regime the platform uses.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this environment as a first phase, groundwork for the deep-space market; Service and Asset tagging of the OSINT is the optional second stage.
CHECKPOINT
Five questions on what the Primary Capability Environment layer adds: naming the environment the platform operates in, the context every other element inherits. Answer to confirm the section landed before you move on to the Segment layer.
SEGMENT LAYER
The platform's segments: Launch, Link, Ground, User, Aquatic, Low Altitude, High Altitude, Near Space, Space, and Deep Space.
HOW THE PLATFORM IS DISTRIBUTED
Second layer, down from PCE. Adversaries don’t attack “the satellite”; they pick an enclave to operate against, like the link, the ground complex, the spacecraft bus, or the operator console. SEG records those enclaves so you can describe what you’re actually defending. For our satellite-control work today. Four SEG elements: Space (the bird), Link (the uplink/downlink), Ground (the command authority), User (the operator edge). Each one is a service-and-asset enclave bound to one or more PCE elements above. How the three departments use SEG. Security Operations scopes threat hunts to a SEG (“anything on the Link”). Satellite Operations holds the segmentation boundary. Satellite Design & Engineering owns the architecture decisions that put each asset inside the right enclave. The SEG boundary is the line your defenders hold.
SEG-LA
SEG:LA:Launch:00Surface-based services and assets for primary launch operations.
ELEMENT 1 OF 10
SEG-LI
SEG:LI:Link:00Services and assets enabling platform communications across signal paths.
ELEMENT 2 OF 10
SEG-GR
SEG:GR:Ground:00Surface-based services and assets for primary platform operations, serving as the primary locus of control plane activity.
ELEMENT 3 OF 10
SEG-US
SEG:US:User:00Services and assets for primary end-user operations.
ELEMENT 4 OF 10
SEG-AQ
SEG:AQ:Aquatic:00Water-based services and assets for primary platform operations.
ELEMENT 5 OF 10
SEG-LO
SEG:LO:Low Altitude:00Aerial services and assets in the lower atmosphere.
ELEMENT 6 OF 10
SEG-HI
SEG:HI:High Altitude:00Aerial services and assets above the lower atmosphere but below near space.
ELEMENT 7 OF 10
SEG-NE
SEG:NE:Near Space:00Aerial services and assets above high altitude and below orbital regions.
ELEMENT 8 OF 10
SEG-SP
SEG:SP:Space:00Services and assets operating in planetary or satellite orbits.
ELEMENT 9 OF 10
SEG-DE
SEG:DE:Deep Space:00Services and assets operating beyond planetary orbital regimes.
ELEMENT 10 OF 10
LAUNCH
Definition. Surface-based services and assets for primary launch operations. SEG-LA is the launch enclave: vehicle integration, propellant handling, range safety, launch control, and the surface-based procedures that take a payload from the ground to orbital insertion.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing pre-launch and launch-day operations: vehicle integration, range safety, propellant handling, launch control, and the brief but critical window when the platform is most exposed to physical and supply-chain attack. Typically parents to one PCE-TE instance.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for a launch campaign brought in-house; Service and Asset tagging of the OSINT is the optional second stage.
LINK
Definition. Services and assets enabling platform communications across signal paths. SEG-LI names the link enclave, the service-and-asset package that carries telemetry, command, and mission product between the space, ground, and user segments. The link spans both the orbital (PCE-OR) and terrestrial (PCE-TE) regimes.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the communication paths that carry commands and data between segments: the command uplink, the telemetry downlink, crosslinks, and ground backhaul. One SEG-LI-NN per distinct link path.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
GROUND
Definition. Surface-based services and assets for primary platform operations, serving as the primary locus of control plane activity. SEG-GR is the ground enclave that commands and configures the platform during operations, including the mission operations center, the network operations center, and the primary ground-station infrastructure.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the persistent control footprint, the antennas, racks, networks, and operators that fly the platform day-to-day. Primary and backup ground complexes are usually separate ordinals (SEG-GR-00, SEG-GR-01) so failover paths model cleanly.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
USER
Definition. Services and assets for primary end-user operations. SEG-US is the end-user enclave: the customer-facing terminals, receivers, and applications that consume the mission product the platform delivers. Examples are direct-to-device terminals, GPS/GNSS receivers in vehicles and handsets, customer ground terminals for satellite broadband, and end-user applications that read the downlinked product. Per the framework, the user segment may also issue requests or commands back to other segments (for example, a user requesting an on-demand capture or a tasking change), but the enclave’s primary identity is end-user consumption, not platform operation.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing where the mission output is consumed, operator terminals in the field, downstream tasking clients, end-user devices. Users may be internal (warfighter, scientist) or external (commercial subscriber); both attach as SEG-US with their PCE enumerated accordingly.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
AQUATIC
Definition. Water-based services and assets for primary platform operations, not limited to Earth's maritime domains. SEG-AQ is the aquatic enclave that occupies a PCE-AQ regime: telemetry vessels, sea-launch platforms, undersea cables, and other water-based infrastructure the platform depends on.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing portions of the platform that perform their primary operational role in or under the water, subsea cabling, recovery vessels, ocean-deployed sensors. Treats maritime as a first-class segment type instead of forcing it into a Ground or Link analogue.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for the maritime market; Service and Asset tagging of the OSINT is the optional second stage.
LOW ALTITUDE
Definition. Aerial services and assets in the lower atmosphere. SEG-LO is the lower-atmosphere aerial enclave: drones, low-altitude relay aircraft, chase aircraft, and tethered platforms operating in the lower-atmosphere band. The framework defines the band relationally, not by absolute altitude.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing platform elements that fly within civil aviation altitudes and inherit civil aviation jurisdiction (FAA, EASA, etc.). Adversary considerations: GPS denial, cellular interference, ATC deconfliction.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for the aerial market; Service and Asset tagging of the OSINT is the optional second stage.
HIGH ALTITUDE
Definition. Aerial services and assets above the lower atmosphere but below near space. SEG-HI is the upper-atmosphere aerial enclave: high-altitude balloons, long-endurance solar UAVs, and stratospheric observation aircraft operating above the lower atmosphere and below near space. The framework defines the band relationally, not by absolute altitude.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing high-altitude platforms that operate above commercial flight ceilings but still within an atmosphere. Adversary considerations: long persistence, restricted access for kinetic intercept, sensitivity to upper-atmosphere weather.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for the high-altitude market; Service and Asset tagging of the OSINT is the optional second stage.
NEAR SPACE
Definition. Aerial services and assets above high altitude and below orbital regions. SEG-NE is the near-space aerial enclave: HAPS (high-altitude pseudo-satellites), persistent stratospheric relays, and suborbital sensor platforms operating above the upper atmosphere and below orbital regions. The framework defines the band relationally; above this band is PCE-OR territory.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing near-space platforms that act as quasi-orbital relays without orbital mechanics, persistent station-keeping over a target region, low latency to ground, no need to wait for a satellite pass. Increasingly relevant as commercial HAPS comes online.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for the near-space market; Service and Asset tagging of the OSINT is the optional second stage.
SPACE
Definition. Services and assets operating in planetary or satellite orbits. SEG-SP is the space enclave: spacecraft and on-orbit platforms executing the mission within the orbital regime. Per the framework, the space segment coincides with the Space Vehicle (SV).
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing on-orbit platform elements and the services they deliver, satellite buses, payload modules, on-orbit servicing vehicles, formation-flying companions. Distinguish bus, payload, and supporting craft as separate ordinals when their threat exposure differs.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
DEEP SPACE
Definition. Services and assets operating beyond planetary orbital regimes. Captures mission elements that live in interplanetary space, at Lagrange points, or beyond lunar orbit, where long communication latency and onboard autonomy dominate operations.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing platform elements operating beyond cislunar orbit. Long round-trip light times mean these segments lean heavily on autonomous decision-making, expanding the attack surface for command-spoofing and onboard-AI manipulation.
No instance on the command path today. You worked with the Security Operations Center to start OSINT collection against this segment as a first phase, groundwork for the deep-space market; Service and Asset tagging of the OSINT is the optional second stage.
CHECKPOINT
Five questions on the Segment layer: the enclaves the platform is distributed into and how each links up to its environment. Answer to confirm the section landed before you move on to the Service layer.
SERVICE LAYER
What runs on the platform: Control Plane, Data Plane, and Hybrid.
WHAT THE PLATFORM DELIVERS
Third layer, down from SEG. Two enclaves tagged identically can still do completely different jobs. SVC records the function an enclave delivers, so you can say what’s actually at risk when something happens. Three values in the published taxonomy. Control Plane (the part that commands the platform). Data Plane (the part that moves mission product). Hybrid (services that do both, like Command and Data Handling). Services that span more than one segment set DISTRIBUTED to Y and list every participating SEG in PARENT, which is exactly the case for our cross-segment telecommand service. How the three departments use SVC. Security Operations writes detection rules at the SVC layer so the rule fires against the function, not the specific box (survives hardware refreshes). Satellite Operations writes the continuity plan at SVC (“telecommand authentication is offline, fall back to…”). Satellite Design & Engineering owns the SVC interface contract that every AST must implement.
SVC-CP
SVC:CP:Control Plane:00Services for managing and orchestrating platform control functions.
ELEMENT 1 OF 3
SVC-DP
SVC:DP:Data Plane:00Services for managing and orchestrating mission product functions.
ELEMENT 2 OF 3
SVC-HY
SVC:HY:Hybrid:00Services integrating both control and data plane functionalities.
ELEMENT 3 OF 3
CONTROL
Definition. Services for managing and orchestrating platform control functions. SVC-CP is the functional plane that moves command and platform state, distinct from SVC-DP which moves mission product. A control-plane service has PARENT = one or more segments and a DISTRIBUTED flag indicating whether it spans segments.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the services that command and control the platform: commanding, mission planning, flight dynamics, and health monitoring. One SVC-CP-NN per distinct control service.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 17 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
DATA
Definition. Services for managing and orchestrating mission product functions. SVC-DP services move mission product, imagery, ephemeris, sensor outputs, and downstream data deliveries, distinct from SVC-CP services that manage command and platform state.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing capabilities whose purpose is to process, store, or deliver mission product, not to manage the platform itself. The data plane is the most attractive integrity-attack surface, the same data may underwrite operational decisions worth far more than the spacecraft.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 3 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
HYBRID
Definition. Services integrating both control and data plane functionalities. SVC-HY services combine command (control plane) and mission product (data plane) functions in a single operational stack, such as the spacecraft Command and Data Handling subsystem (C&DH).
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
A service genuinely owns both responsibilities and a forced split would create two phantom elements that re-merge in operations, edge mission processors, integrated tasking + downlink stacks, convergent cloud-native ground segments. Default to CP or DP first; reach for HY only when the integration is real.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 3 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
CHECKPOINT
Five questions on the Service layer: the function each enclave delivers and how services link up to segments. Answer to confirm the section landed before you move on to the Asset layer.
ASSET LAYER
The individual parts: Hardware, Firmware, Software, Data, Signal, and Hybrid.
PLATFORM ASSETS
Fourth layer, bottom of the chain. Enrichment that names a service or a segment can’t be acted on by the people who actually patch, monitor, replace, or quarantine. Satellite Design & Engineering doesn’t patch “the control plane,” they patch a specific firmware image on a specific box at a specific site. AST is where the work happens. Six values in the published taxonomy. Hardware, Firmware, Software, Data, Signal, and Hybrid. Each AST element takes one or more SVC parents and an optional SUBSYSTEM tag (one physical asset often serves several services on space platforms). How the three departments use AST. Security Operations targets its work at specific AST instances rather than at abstract services. Satellite Operations logs incidents at AST resolution (“HSM #3 in the user segment is offline”). Satellite Design & Engineering owns the asset inventory, the patch pipeline, and the vulnerability management work at this layer. AST is where your three departments converge.
AST-HW
AST:HW:Hardware:00Physical elements supporting platform operations.
ELEMENT 1 OF 6
AST-FW
AST:FW:Firmware:00Embedded control code governing hardware functions.
ELEMENT 2 OF 6
AST-SW
AST:SW:Software:00Applications and logic executing operational tasks.
ELEMENT 3 OF 6
AST-DA
AST:DA:Data:00Information generated, processed, or consumed by the platform.
ELEMENT 4 OF 6
AST-SI
AST:SI:Signal:00Communication channels and transmission frequencies.
ELEMENT 5 OF 6
AST-HY
AST:HY:Hybrid:00Composite elements combining multiple asset types.
ELEMENT 6 OF 6
HARDWARE
Definition. Physical hardware assets supporting platform operations. AST-HW assets are tangible parts of the platform that can be inventoried, photographed, and physically touched: antennas, consoles, on-board computers, sensors, actuators, power chains.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing physical assets that exist in space or on the ground. Granularity is a judgment call: enumerate at the level where a different make/model or vendor would change the threat picture, not at the level of individual screws.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 8 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
FIRMWARE
Definition. Embedded control code governing hardware functions. AST-FW assets are low-level code that ships with hardware, runs at boot, and lives below the operating system: bootloaders, microcontroller firmware, FPGA bitstreams, signed boot ROMs.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing code that is installed on or with hardware, BIOS / UEFI, FPGA bitstreams, baseband modems, peripheral controllers. Enumerating firmware separately from the host hardware makes vendor-supplied vulnerabilities (and patch cadence) visible at the data-model level.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 3 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
SOFTWARE
Definition. Applications and logic executing operational tasks. AST-SW assets are higher-level code that runs above firmware: applications, services, operating system software, container images, microservices, and other logic the platform depends on.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing distinct software elements a defender would patch, monitor, or replace independently, mission planning app, payload processor, telemetry parser, web console. Granularity should map to upgrade boundaries: if it ships and patches separately, it’s its own asset.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 8 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
DATA
Definition. Information generated, processed, or consumed by the platform. Data is an AST element type in its own right. Mission product, configuration, key material, and ephemeris all enumerate alongside hardware and software.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the data products themselves and the operational data the platform handles, mission product files, configuration baselines, key material, ephemeris, customer ground truth. Treating data as an asset is what makes integrity-first detection engineering possible.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 5 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
SIGNAL
Definition. Communication channels and transmission frequencies. AST-SI assets are the carrier signals, waveforms, and frequency allocations the platform uses to move command and data, including telecommand uplinks, telemetry downlinks, mission-data carriers, and inter-satellite links.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
Capturing the RF, optical, or wired signals that carry command and product, uplink frequencies, downlink bands, optical inter-satellite links, fiber backhaul circuits. Each major signal path is its own asset so signal-level threats correlate cleanly to it.
Satellite Operations brought the operational view and Satellite Design & Engineering the build view; reconciled, they yielded these 1 of the 54 enumerated elements. Open the enumeration outcome on the left to read each one; every later function attaches its work to them.
HYBRID
Definition. Composite elements combining multiple asset types. AST-HY assets are sealed appliances or integrated subsystems where hardware, firmware, and software are delivered as one unit and cannot be cleanly separated for inventory: programmable cryptographic appliances, integrated avionics packages, vendor-delivered turnkey subsystems.
Recorded the standard way. This element is named from the published taxonomy and slotted into the layer chain as a machine-readable identifier, so tools can query, correlate, and automate across all three departments instead of anyone re-translating by hand.
An asset’s hardware, firmware, software, data, and signal cannot be usefully separated for the purpose at hand, e.g. a sealed crypto module, a delivered ground rack, a black-box payload. Default to the specific asset class first; reach for HY only when the integration genuinely cannot be decomposed.
The collective answer from the engagements: no integrated hardware-firmware asset on the command path today. The element stands ready in the model for the day a platform change brings one into scope.
CHECKPOINT
Five questions on the Asset layer: the concrete elements that implement each service and how they link up. Answer to confirm the section landed before you move on to naming and enumeration.
Read and apply the data model
One standard taxonomy (how every element is named) and ontology (how each element links to the layer above), so the same element reads the same way to every department.
At Kestrel Orbital this is now working practice, not a proposal. Satellite Operations and Satellite Design & Engineering enumerated the platform together, and all three departments now name every element and link it upward by the same rules: the five fields every element carries, the two written forms it is cited in, and the parent chain that connects each asset to its service, segment, and environment.
READ THE DATA MODEL
Reading the data model means reading an element’s published type name, its Taxonomic Element Nomenclature (TEN). The framework writes it; you look it up and never invent it.
-
A TEN is written
LAYER-TAG-LABEL-Definition. Example:PCE-OR-Orbital-Operational zones within planetary or satellite orbits. -
A TEN names a category of element, not one specific thing, and carries the framework’s canonical Definition for that category. That Definition reads the same on every platform.
-
Every TEN is published in the controlled vocabulary. Class-level talk (“every
SVC-CPis in scope”) uses the TEN. To name one real instance on your platform, you move to the ETEN on the next slide.
The Taxonomic Element Nomenclature (TEN). Written LAYER-TAG-LABEL-Definition in 4-field hyphenated form. The Definition is the framework canonical text from Tables 8.1–8.5; the same on every instantiation.
PCE-OR-Orbital-Operational zones within planetary or satellite orbits.
Class-level talk about orbital environments in general: “Every PCE-OR instance needs a conjunction-risk feed.”
SEG-SP-Space-Services and assets operating in planetary or satellite orbits.
Class-level talk about the space segment: “SEG-SP assets share the orbital safety boundary.”
SVC-CP-Control Plane-Services for managing and orchestrating platform control functions.
“Every SVC-CP service is in scope for command-link integrity.”
AST-SW-Software-Applications and logic executing operational tasks.
“AST-SW elements must enter SBOM tracking.”
APPLY THE DATA MODEL
Applying the data model means producing an element’s Enumerated Taxonomic Element Nomenclature (ETEN): the five-field form that names one specific instance on the platform you operate. Your department writes it by walking the enumeration procedure once per in-scope element.
-
An ETEN is written
LAYER:TAG:LABEL:ORDINAL:Description. Example:PCE:OR:Orbital:00:The orbital regime in which the Space Vehicle operates. -
LAYER, TAG, and LABEL come straight from the published TEN. You add the two-digit
ORDINAL(00, 01, 02) that tells instances apart and the per-instanceDescriptionthat scopes this exact item. -
TEN is what the framework gives you; ETEN is what you output. Anything that names a specific instance on the platform you operate is cited as an ETEN, on tickets, diagrams, and detections alike.
LAYER
SEG
TAG
GR
LABEL
Ground
ORDINAL
00
DESCRIPTION
“Primary mission-operations ground complex at the inland continental site. Hosts the ground access-control and patch services (SVC:CP:Control Plane:09, SVC:CP:Control Plane:12); operates from PCE:TE:Terrestrial:00.”
LAYER
Which of the four decomposition layers this enumerated element sits in: PCE (environment), SEG (segment), SVC (service), or AST (asset).
Field 1 of 5 · required on every enumerated element.
TAG
The two-letter code that names the element within the layer (for example TE for Terrestrial, GR for Ground, CP for Control Plane, HW for Hardware, SW for Software). Always picked from the published list, never invented.
Field 2 of 5 · required on every enumerated element.
LABEL
The plain-English name that goes with the two-letter code, for example, Terrestrial for TE, Ground for GR, Software for SW.
Field 3 of 5 · required on every enumerated element.
ORDINAL
A two-digit number, starting at 00, that tells multiple instances of the same element apart. The first ground station is SEG-GR-00, the second is SEG-GR-01, and so on.
Field 4 of 5 · required on every enumerated element.
DESCRIPTION
A short, free-text note about this specific instance: what it is, where it is, what role it plays, and anything later work will need to know. The description is what turns a generic code into a concrete piece of your platform.
Field 5 of 5 · required on every enumerated element.
CONOPS Review
The mandates set your scope: Executive Order 14144’s protections attach to command and control of the space system, and the NIS2 Directive binds the ground infrastructure that carries it. The telecommand path is now decomposed end to end, from the operator console to the spacecraft, every element enumerated across the four layers. Review the CONOPS below before Day 2.
CONOPS TELECOMMAND
The decomposition is complete. Across Day 1, Kestrel Orbital’s three departments, the Security Operations Center, the Satellite Operations Center, and Satellite Development and Engineering, enumerated the telecommand path together: the command-and-control scope Executive Order 14144 and the NIS2 Directive hold the organization to. What you review now. For each layer (PCE → SEG → SVC → AST), the procedure the departments followed and the in-scope elements they produced, so you can confirm the work and prepare it for presentation. The deliverable. Two PCE elements, four SEG elements, twenty-three SVC elements, and twenty-five AST elements: fifty-four ETENs in canonical form, every parent link populated, one shared vocabulary all three departments can act on, ready to present and carry into Day 2.
L1 ✓
L2 ✓
LAYER:TAG:LABEL:ORDINAL:Description that every enumerated element carries.
A1 →
A2 →
S1 →
CONCEPT OF OPERATIONS · ENVIRONMENT
Whose input. Satellite Operations and Satellite Design and Engineering set the scope with the Security Operations Center: the command-and-control mission Executive Order 14144 and the NIS2 Directive hold Kestrel Orbital to, which on the telecommand path spans two environments, Terrestrial and Orbital. Output. One ETEN of the form PCE:TAG:LABEL:ORDINAL:Description per environment in scope. Five steps, fixed order. Set LAYER (always PCE). Set TAG (published two-letter code). Set LABEL (published English name). Set ORDINAL (00 for the first instance). Write the per-instance Description. Constraints. PCE elements have no PARENT; only what is in scope was enumerated. Review. Confirm each field follows the procedure before presenting the environments; because every department reads the same five-field form, no one has to re-translate it.
TE, AQ, AE, OR, DS, matching the operating environment in which this instance of the platform exists or is exercised.00; increment for each additional instance of the same element. Two terrestrial sites become PCE:TE:Terrestrial:00 and PCE:TE:Terrestrial:01.ENVIRONMENTS
-
Telecommand starts at a ground operator and ends at a spacecraft. Two physical regimes are in play. Aquatic, aerial, and deep-space are out of scope for this example. We’d enumerate them only if the platform actually operated there.
-
Five PCE tags exist in the framework (
TE,AQ,AE,OR,DS). We don’t invent.TEapplies because the operator and ground systems are terrestrial.ORapplies because the spacecraft is in orbit. That gives us two PCE elements to enumerate. -
One Continental US ground footprint →
PCE:TE:Terrestrial:00. One orbiting spacecraft →PCE:OR:Orbital:00.ORDINAL = 00because each is the first (and only) of its kind in this scope. A second ground site would have been01. Descriptions anchor the generic vocabulary to this specific platform.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
PCE-TE |
PCE:TE:Terrestrial:00:Continental US surface operational regime where the platform ground stations, mission operations centers, and launch facilities are located. |
PCE-OR |
PCE:OR:Orbital:00:The orbital regime in which the Space Vehicle operates and executes uplinked commands. |
| In scope | 2 PCE elements |
CONCEPT OF OPERATIONS · SEGMENTS
Whose input. The environments are already enumerated. With the Security Operations Center, the two build-and-operate departments scoped the enclaves on the telecommand path: four segments, Space and Link (the segments EO 14144 covers at minimum) and Ground and User (the ground-based infrastructure NIS2 binds). Output. One ETEN of the form SEG:TAG:LABEL:ORDINAL:Description per enclave. Six steps, fixed order. Set LAYER (always SEG). Set TAG. Set LABEL. Set ORDINAL. Write Description. Set PARENT to one or more PCE ETENs. Constraints. Every SEG element names at least one PCE in PARENT; existing segment diagrams were imported and tagged rather than redrawn. Review. Confirm each segment links up to its environment before presenting; the shared vocabulary is what lets all three departments read the same enclave the same way.
LA, LI, GR, US, AQ, LO, HI, NE, SP, DE, matching the segment role this instance plays in the mission architecture.00; increment for each additional instance of the same element. Primary and backup ground segments become SEG:GR:Ground:00 and SEG:GR:Ground:01.PCE:TE:Terrestrial:00). Multiple parents are enumerated as a comma-separated list when the segment spans environments.SEGMENTS
-
Telecommand crosses four operational enclaves: an operator console (User), the ground mission-ops authority (Ground), the RF/optical uplink (Link), and the spacecraft executing the command (Space). Four enclaves on the path; four SEG elements to enumerate.
-
Ten SEG tags exist in the framework (
LA,LI,GR,US,AQ,LO,HI,NE,SP,DE). We don’t invent. Four apply:SP,LI,GR,US. Launch, aquatic, low/high altitude, near-space, and deep-space don’t touch this telecommand path. -
Each SEG element takes
ORDINAL = 00and names its PCE parent.SEG:SP:Space:00→PCE:OR.SEG:GR:Ground:00andSEG:US:User:00→PCE:TE.SEG:LI:Link:00spans both physical regimes, so it lists two parents,PCE:OR + PCE:TE, the first cross-environment link in the decomposition.
| Element | Links to | Full ETEN |
|---|---|---|
SEG-SP |
→ PCE:OR:Orbital:00 | SEG:SP:Space:00:Space-segment enclave: platform and payload subsystems on orbit. |
SEG-LI |
→ PCE:OR + PCE:TE | SEG:LI:Link:00:Link-segment enclave: the RF/optical signal path between Space and Ground. |
SEG-GR |
→ PCE:TE:Terrestrial:00 | SEG:GR:Ground:00:Ground-segment enclave: mission operations, command authority, cryptography, launch control. |
SEG-US |
→ PCE:TE:Terrestrial:00 | SEG:US:User:00:User-segment enclave: operator consoles and end-user applications that consume mission product and originate commands. |
| In scope | 4 SEG elements | |
CONCEPT OF OPERATIONS · SERVICES
Whose input. The segments are already enumerated. Satellite Operations named the services it runs and Satellite Design and Engineering the services it built: on the telecommand path, the twenty-three services that authorize, encrypt, carry, and execute commands, including the cryptography and command-acceptance (ACA) services the mandates’ duties land on. Output. One ETEN of the form SVC:TAG:LABEL:ORDINAL:Description per service. Seven steps, fixed order. Set LAYER (always SVC). Set TAG. Set LABEL. Set ORDINAL. Write Description. Set PARENT to one or more SEG ETENs. Set DISTRIBUTED to Y if cross-segment, otherwise N. Constraints. Cross-segment services list every participating SEG in PARENT and stay one service element, not duplicates. Review. Confirm the function each service delivers before presenting; naming the function, not the box, is what lets the Security Operations Center write detections that survive a hardware refresh.
CP (Control Plane), DP (Data Plane), or HY (Hybrid), matching the functional capability this service delivers.00; increment for each additional instance of the same element.SEG:GR:Ground:00, SEG:SP:Space:00).Y if the service runs across more than one segment (PARENT lists two or more SEG elements); N if it runs on a single segment.SERVICES SPACE SEGMENT
-
The space segment must control the platform (attitude, crypto, power, flight termination, thermal), move data (mission downlink/uplink, payload), and handle commands that cross both worlds (C&DH receives every uplinked command and routes mission data). Three kinds of capability mean we will need all three SVC tags.
-
Three SVC tags exist (
CP,DP,HY). We use 5× CP for ADCS, space-side crypto, EPS, FTS, and TCS. 2× DP for mission and payload data planes. 1× HY for C&DH because it both commands the bus and routes mission data, that mix is what HY exists for. -
Each instance gets its own ORDINAL within its tag:
CP:00…04,DP:00…01,HY:00. PARENT =SEG:SP:Space:00for all eight.DISTRIBUTED = Nbecause each lives in this single segment. C&DH is HY for its capability mix, not for spanning segments.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
SVC-CP |
SVC:CP:Control Plane:00:Attitude determination and control service (ADCS) orchestrating platform attitude. |
SVC-CP |
SVC:CP:Control Plane:01:Cryptographic service, space-side. |
SVC-CP |
SVC:CP:Control Plane:02:Electrical power management service (EPS) on the spacecraft. |
SVC-CP |
SVC:CP:Control Plane:03:Flight termination service (FTS) on the spacecraft. |
SVC-CP |
SVC:CP:Control Plane:04:Thermal control service (TCS) on the spacecraft. |
SVC-DP |
SVC:DP:Data Plane:00:Mission downlink and uplink data plane on the SV. |
SVC-DP |
SVC:DP:Data Plane:01:Payload data plane. |
SVC-HY |
SVC:HY:Hybrid:00:Command and Data Handling service (C&DH) combining bus commanding and mission-data routing; receives every uplinked telecommand. |
| In scope | 8 SVC elements in SP |
SERVICES LINK SEGMENT
-
The link must authenticate every uplinked command (ACA), detect and recover from attack on the channel, and route payload commands. It also has to keep the channel itself working: error correction (FEC/ECC) and tracking/telemetry (T2), both of which mix control signaling with data integrity.
-
3× CP for the three command-control services (ACA, attack det/recovery, payload command). 2× HY for FEC/ECC and T2 because each genuinely fuses control and data. FEC corrects data bits using control logic; T2 tracks position while telemetering platform state. No DP: the link doesn’t host a standalone data plane separate from these hybrids here.
-
Ordinals continue the global counter inside each tag:
CP:05, CP:06, CP:07;HY:01, HY:02(HY:00 was C&DH on the space side). PARENT =SEG:LI:Link:00for all five.DISTRIBUTED = N, these services live entirely on the link enclave, not across segments.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
SVC-CP |
SVC:CP:Control Plane:05:Authentication and command-acceptance service (ACA) on the link; gates every uplinked command. |
SVC-CP |
SVC:CP:Control Plane:06:Attack detection and recovery service on the link. |
SVC-CP |
SVC:CP:Control Plane:07:Payload command service on the link. |
SVC-HY |
SVC:HY:Hybrid:01:Error handling (FEC/ECC) on the uplink and downlink. |
SVC-HY |
SVC:HY:Hybrid:02:Tracking and telemetry (T2) service on the link. |
| In scope | 5 SVC elements in LI |
SERVICES GROUND SEGMENT
-
The ground is where command authority lives. Five capabilities for telecommand: cryptography (ground-side), authentication and command-acceptance (ground ACA), launch control, autonomous flight safety (AFSS), and the patch update pipeline. All of these are governance-and-control work.
-
All five services here are pure Control Plane: they authorize, gate, schedule, and supervise. No DP because mission product is consumed at the User segment, not produced here. No HY because none of these services mixes control work with data routing.
-
Ordinals continue the global CP counter:
CP:08, CP:09, CP:10, CP:11, CP:12. PARENT =SEG:GR:Ground:00for all five.DISTRIBUTED = N, each ground service is bounded to this segment, not coordinated across multiple SEGs.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
SVC-CP |
SVC:CP:Control Plane:08:Cryptographic service, ground-side. |
SVC-CP |
SVC:CP:Control Plane:09:Authentication and command-acceptance service (ACA) on the ground. |
SVC-CP |
SVC:CP:Control Plane:10:Launch control service. |
SVC-CP |
SVC:CP:Control Plane:11:Autonomous flight safety service (AFSS). |
SVC-CP |
SVC:CP:Control Plane:12:Patch update pipeline service. |
| In scope | 5 SVC elements in GR |
SERVICES USER SEGMENT
-
The user segment is where commands originate and where mission product is consumed. Five capabilities for telecommand: satellite console operations, cryptography and key management (user-side), authentication and command-acceptance (user ACA), satellite-ground command transport, and the end-user application that consumes mission product.
-
4× CP for console, key management, user ACA, and command transport, all control-side work. 1× DP for the end-user application that consumes mission product (pure data plane). No HY: each service has a clean control-or-data role here, no mixed cases.
-
Ordinals continue the global counters:
CP:13, CP:14, CP:15, CP:16;DP:02(DP:00 and DP:01 were on the space side). PARENT =SEG:US:User:00for all five.DISTRIBUTED = N, each service is bounded to the user segment.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
SVC-CP |
SVC:CP:Control Plane:13:Satellite console operations service. |
SVC-CP |
SVC:CP:Control Plane:14:Cryptographic and key-management service, user-side. |
SVC-CP |
SVC:CP:Control Plane:15:Authentication and command-acceptance service (ACA) on the user side. |
SVC-CP |
SVC:CP:Control Plane:16:Satellite-ground command transport service. |
SVC-DP |
SVC:DP:Data Plane:02:End-user application data plane consuming mission product. |
| In scope | 5 SVC elements in US |
CONCEPT OF OPERATIONS · ASSETS
Whose input. The services are already enumerated. Satellite Design and Engineering supplied the concrete assets from its inventory lists, BOMs, and CMDB exports: on the telecommand path, the twenty-five hardware, software, firmware, data, and signal assets that implement the command-path services, ACA software and credentials among them. Output. One ETEN of the form AST:TAG:LABEL:ORDINAL:Description per element. Seven steps, fixed order. Set LAYER (always AST). Set TAG. Set LABEL. Set ORDINAL. Write Description. Set PARENT to one or more SVC ETENs (comma-separated when the asset serves several services). Set optional SUBSYSTEM tag. Constraints. Ordinals were used aggressively so unit-level detections resolve to the exact instance. Review. Confirm each asset traces up to its service before presenting; this is the resolution at which a detection fires and a patch lands, and where all three departments converge.
HW, FW, SW, DA, SI, HY, matching the category of the concrete element this instance represents.00. Use a distinct ordinal for every physical or logical unit so unit-level detections resolve to the right instance.SVC:CP:Control Plane:00, SVC:DP:Data Plane:00 for an antenna that carries both telecommand and payload data).ASSETS SPACE SEGMENT
-
Eight space services need concrete elements behind them: ADCS sensors and flight software, EPS power chain, FTS hardware and firmware, thermal hardware, OBC and OBDH bus with boot firmware, C&DH flight software, payload electronics and payload repeater firmware. Eleven physical or coded things to enumerate.
-
Six AST tags exist (
HW,FW,SW,DA,SI,HY). We use 6× HW for the physical hardware (sensors, power chain, FTS receiver, thermal, OBC, payload electronics), 2× SW for flight software (ADCS, C&DH), 3× FW for firmware in microcontrollers (FTS, OBC boot, payload repeater). No DA, SI, or HY at this segment. -
Each AST tag carries its own ordinal counter. Each element names one or more SVC parents, the OBC hardware, for example, hosts the C&DH hybrid AND every CP service running on the bus, so its PARENT is a comma-separated list. SUBSYSTEM tag groups related assets that form a coherent unit (Bus, Payload).
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
AST-HW |
AST:HW:Hardware:00:ADCS sensors (star trackers, gyros, magnetometers). |
AST-SW |
AST:SW:Software:00:ADCS flight software. |
AST-HW |
AST:HW:Hardware:01:Electrical power chain hardware (solar arrays, battery, PCDU). |
AST-HW |
AST:HW:Hardware:02:FTS receiver and ordnance hardware. |
AST-FW |
AST:FW:Firmware:00:FTS firmware governing flight-termination logic. |
AST-HW |
AST:HW:Hardware:03:Thermal control hardware (heaters, radiators, MLI). |
AST-HW |
AST:HW:Hardware:06:On-board computer (OBC) and OBDH bus hardware. |
AST-FW |
AST:FW:Firmware:01:OBC boot firmware and bus-controller firmware. |
AST-SW |
AST:SW:Software:06:C&DH flight software handling command processing and data routing. |
AST-HW |
AST:HW:Hardware:07:Payload electronics hardware. |
AST-FW |
AST:FW:Firmware:02:Payload repeater firmware. |
| In scope | 11 AST elements in SP |
ASSETS LINK SEGMENT
-
Five link services need elements behind them. The uplink waveform itself, a physical signal that carries every command. The authentication credentials the ACA service consumes, a stored data object. The payload command encoder software. Three concrete things.
-
1× SI for the uplink waveform. Signal is the only tag that fits a transmitted RF/optical waveform as a first-class element. 1× DA for the ACA credentials (session keys and certificates stored at the link). 1× SW for the payload command encoder. No HW or FW: the link is the channel itself; the physical transmitters/receivers belong to the Space and Ground segments at the endpoints.
-
SI:00(first signal element),DA:00(first data element),SW:01(continuing the global SW counter). PARENT names the link SVCs each asset implements, the credentials are read by ACA (CP:05) and may also be referenced by error handling (HY:01), a legitimate multi-parent case. No SUBSYSTEM grouping needed at this segment.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
AST-SI |
AST:SI:Signal:00:TC uplink waveform on the link. |
AST-DA |
AST:DA:Data:00:Link ACA credentials including session keys and certificates. |
AST-SW |
AST:SW:Software:01:Payload command encoder software. |
| In scope | 3 AST elements in LI |
ASSETS GROUND SEGMENT
-
Five ground services need elements behind them. Ground ACA software performing authentication. The credential store the ACA reads. Patch binaries staged for uplink. The patch deployment pipeline software that builds, signs, and pushes them. Four concrete things.
-
2× SW for ground ACA and the patch pipeline (two distinct code bases). 2× DA for the credential store and the patch binaries (two stored data artifacts with different sensitivity profiles). No HW at this scope, server hardware is consolidated with the services hosted on it rather than enumerated separately. No FW, SI, or HY.
-
SW:02, SW:03(continuing the global SW counter).DA:01, DA:02(continuing past link DA:00). PARENT links each AST to the ground SVC it implements, the credential store may serve both ground ACA (CP:09) and ground cryptography (CP:08), a legitimate multi-parent case under the new framework cardinality.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
AST-SW |
AST:SW:Software:02:Ground ACA software performing command authentication on the ground. |
AST-DA |
AST:DA:Data:01:ACA credential store (master keys, certificate authority data). |
AST-DA |
AST:DA:Data:02:Patch binaries for firmware and software updates. |
AST-SW |
AST:SW:Software:03:Patch deployment pipeline software. |
| In scope | 4 AST elements in GR |
ASSETS USER SEGMENT
-
Five user services need elements behind them. The operator console (hardware and the software running on it). The user HSM hardware and the cryptographic keys held inside it. The user-side ACA software. The end-user application and the mission product data it consumes. Seven concrete things.
-
2× HW for operator console hardware and the HSM. 3× SW for console operator software, user ACA software, and the end-user app. 2× DA for the cryptographic keys (held in the HSM) and the mission product data (consumed by the app). No FW, SI, or HY at this segment.
-
HW:04, HW:05(continuing past space HW:00–03).SW:04, SW:05, SW:08(skipping space-side SW:06–07).DA:03, DA:04. PARENT links each AST to the user SVC(s) it implements, the HSM hardware serves both crypto/key-management (CP:14) and user ACA (CP:15), one of several legitimate multi-parent cases on this segment.
| Element | Full ETEN (LAYER:TAG:LABEL:ORDINAL:Description) |
|---|---|
AST-HW |
AST:HW:Hardware:04:Operator console hardware (workstation, peripherals). |
AST-SW |
AST:SW:Software:04:Console operator software. |
AST-HW |
AST:HW:Hardware:05:User-side hardware security module (HSM). |
AST-DA |
AST:DA:Data:03:Cryptographic keys held by user-side HSM. |
AST-SW |
AST:SW:Software:05:User-side ACA software for outbound command signing. |
AST-SW |
AST:SW:Software:08:End-user application software. |
AST-DA |
AST:DA:Data:04:Mission product data consumed by end-user application. |
| In scope | 7 AST elements in US |
CONOPS Presentation
You present the validated telecommand decomposition to the three departments: every asset traces to a service, a segment, and an environment, with no orphans. An unbroken parent chain is what makes the decomposition usable as evidence, enrichment on any element carries its full structural context, and the elements EO 14144 and NIS2 concern can be produced on demand.
ONE SHARED CONOPS
-
Fifty-four ETENs across four decomposition layers, every parent link populated, scoped to satellite command and control, the scope Executive Order 14144 and the NIS2 Directive set. Formalized and downloadable behind the
CONOPSbutton. This is the work product you walk into the next meeting carrying. -
Each department already knew its own pieces in depth. What changes today is that Security Operations, Satellite Operations, and Satellite Design & Engineering all now refer to those pieces with the same names. The CONOPS is the shared dialog, not a new inventory for any one department. The translation tax between rooms is gone.
-
With the taxonomy and ontology in place, Module 02 (Contextualized Threat Modeling) attaches threats to these named elements. The CONOPS is the shared taxonomy and ontology every later function writes against, and the same procedure transfers to the platform you operate at your work center.
PCE + SEG + SVC + AST).
DAY 1 COMPLETE
You built the thing the whole program hangs on. Not notes, not a diagram: a working CONOPS of the telecommand path that three departments can act on together, the foundation every later function attaches to.
-
A 54-element CONOPS of the telecommand path, run end to end: 2 PCE, 4 SEG, 23 SVC, 25 AST, every
PARENTlink populated, no orphans. Signed and downloadable, scoped to the command-and-control mission Executive Order 14144 and the NIS2 Directive hold Kestrel Orbital to. -
Yesterday the three departments described the same platform three different ways. Today Security Operations, Satellite Operations, and Satellite Design & Engineering share one. The translation tax between rooms is gone, and enrichment on any element now carries its full chain of context.
-
Pass the end-of-module exam (10 questions, 90% to qualify). Then Day 2 puts the CONOPS to work: Module 02 attaches real, contextualized threats to the exact elements you named today. Every element you enumerated becomes something an adversary has to get through.
DAY 1 COMPLETE
You decomposed the telecommand path, the command-and-control scope Executive Order 14144 and the NIS2 Directive set, into shared enumerated elements the whole organization reads the same way. Tomorrow, Day 2 anchors real adversary threats to the elements you enumerated.
CONTEXTUALIZED
THREAT MODELING.
Decomposition done. Contextualized Threat Modeling attaches threats to the elements you just built.
End-of-module exam: 10 multiple-choice questions aligned with the decomposition discipline’s KSAT areas (Knowledge, Skills, Abilities, Tasks). Score 90% to qualify. Save your results as a PDF when you finish.