Module 01
Concept of Operations

CH 1 The Day in One Page

You are building SCOR, the department that delivers its mission by giving the three departments, Security Operations, Satellite Operations, and Satellite Design & Engineering, one unified view of the platform, context and enrichment together. You do not need to be the expert in each; your job is to build the team and give it a shared framework.

Three mandates set the scope, one duty per line:

• EO 14144: SCOR writes a detection for each command-and-control protection Executive Order 14144 requires.
• NIS2: SCOR executes the incident-sharing thresholds the directive sets: early warning within 24 hours, incident notification within 72.
• Space ISAC: SCOR shares a redacted alert on a confirmed command-and-control attack, machine to machine.

Why telecommand first. Because the mandates land on it. Executive Order 14144 sets requirements Kestrel Orbital must meet on the command and control of the space system: encrypt the commands, protect their integrity, authenticate the source, and reject unauthorized commands. The NIS2 Directive puts the ground-based infrastructure that carries it under mandatory cybersecurity risk-management and reporting duties. The path that keeps the satellite under control is the path you must be able to show is protected, so that is where your decomposition starts.

Today, Day 1. Today you decompose the telecommand path, the path that keeps the satellite under control, across the four layers from start to finish. 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.

What you build. A 44-element CONOPS of the telecommand path, run end to end: 4 PCE, 4 SEG, 15 SVC, 21 AST, every PARENT link populated, no orphans. Chapter 6 prints the whole deliverable.

The week ahead. 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. Module 02 consumes exactly what you finish today: it anchors real, contextualized threats to the exact elements you named, so a threat with no anchor in this CONOPS has nothing on the platform to attack until the CONOPS adds the element.

CH 2 One Data Model for Three Departments

Reading notes, before anything else. Identifiers ahead use the two forms orientation taught, hyphens for a type (TEN), colons plus a two-digit ordinal for an instance (ETEN); you will formalize both later today, and chapter 4 prints the full lesson. The walkthrough ahead runs fourteen enumeration steps across the four layers, one per in-scope element type; a step can produce several elements, and the running tally tracks all forty-four.

The silo problem. Ask the three departments about the same box and you get three answers in three vocabularies. A finding written in one dialect has to be re-keyed before the next department can act on it, and every re-keying loses precision and time. METEORSTORM gives all three departments one shared data model, a taxonomy and an ontology. Every part of the platform is named by exactly one element, sorted into four layers: PCE, SEG, SVC, AST.

What each department gets back. Security Operations writes detections that target an exact element. Satellite Operations uses the same names on console to know what is degraded. Satellite Design & Engineering routes patches against the same data model. One name, three uses, no translation.

The taxonomy: the words

One taxonomy, shared inside and outside the organization, so cyber, space ops, engineering, vendors, peer operators, and Space ISAC members all use the same words for the same things. The full element list per layer:

• 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.

The ontology: the relationships

Every element links up to its parent, forming one strict chain: Asset to Service to Segment to Environment. Every element traces up to a PCE; nothing floats.

• 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.

Why both. Named by the taxonomy, placed by the ontology, every element carries its full context. Enrichment attaches to one element and inherits every layer above it in a single query, the same chain all three departments read from their own end.

CH 3 The Four Layers

Four sub-chapters, one per structural layer, in decomposition order. Each opens with the layer’s verbatim definition, then carries the per-element depth: every type in the published taxonomy, its full TEN, and, for the types this scenario does not enumerate, why they are out of scope. Deep dive deck, slides 10 through 36; mirrors the full-taxonomy reference slides 13 and 20.

3.1 · PCE, where the platform operates

Layer 1, the root of the parent chain. Every other layer anchors to a PCE element through the ontology, so getting this right matters: every element beneath inherits that context. PCE is also the layer that deconflicts nature from adversary. When a symptom appears, operations often cannot tell an environmental effect (space weather, atmospheric drag, radiation) from a cyber-physical adversary action, and naming the environment keeps a natural anomaly from being chased as an attack and an attack from being written off as weather.

The scope rule that governs the column above: you enumerate a type only when the platform actually operates there. The out-of-scope types complete the taxonomy so you can read any platform, and Step 01 of the ETEN Process (chapter 5) is what keeps them out of this CONOPS.

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.

3.2 · SEG, how the platform is distributed

Layer 2, anchored to PCE. Adversaries do not 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 are actually defending. The SEG boundary is the line your defensive cyber operators hold. Tiebreak for the recurring trap: PCE and SEG share several tag names; zone means PCE, group of services and assets means SEG.

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.

3.3 · SVC, what the platform delivers

Layer 3, anchored to SEG. Two enclaves tagged identically can still do completely different jobs. SVC records the function an enclave delivers, so you can say what is actually at risk when something happens. Services that span more than one segment set DISTRIBUTED to Y and list every participating SEG in PARENT.

All three service types earn a place on the telecommand path, so no SVC type is out of scope in this scenario; scope at this layer is enforced per instance, not per type. Only the services that authorize, protect, carry, or execute commands on the path are enumerated.

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, and 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.

3.4 · AST, where the work happens

Layer 4, anchored to SVC. Enrichment that names a service or a segment cannot be acted on by the people who actually patch, monitor, replace, or quarantine. Satellite Design & Engineering does not patch “the control plane”; they patch a specific firmware image on a specific box at a specific site. AST is where the work happens, and where your three departments converge.

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. Satellite Design & Engineering owns the asset inventory, the patch pipeline, and the vulnerability management work at this layer. Each AST element takes an optional SUBSYSTEM tag, because one physical asset often serves several services on space platforms.

CH 4 How Elements Are Named

Two forms, one lesson. The TEN names a type and is read from the published taxonomy; the ETEN names one real instance on your platform and is what you produce. Reading the data model means reading TENs; applying it means writing ETENs.

The TEN, four hyphenated fields

A TEN is written LAYER-TAG-LABEL-Definition. It 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 taxonomy: you look it up and never invent it. Four worked walkthroughs, one per layer:

In every row the fourth field, the Definition, is framework canon and is the same on every platform.

The ETEN, five colon-delimited fields

An ETEN is written LAYER:TAG:LABEL:ORDINAL:Description. LAYER, TAG, and LABEL come straight from the published TEN. You add the two-digit ORDINAL that tells instances apart and the per-instance Description that scopes this exact item. All five fields are required on every enumerated element. Field by field:

• LAYER. The structural layer the element belongs to: PCE, SEG, SVC, or AST. Field 1 of 5.
• 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.
• 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.
• ORDINAL. A two-digit number, starting at 00, that tells multiple instances of the same element apart. The first ground segment is SEG:GR:Ground:00, the second is SEG:GR:Ground:01, and so on. Ordinals are scoped to the (LAYER, TAG) pair, continue across segments rather than restarting, and are never re-used. Field 4 of 5.
• 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.

One complete worked ETEN

Kestrel Orbital’s Reston mission-operations ground segment, written out as a five-field enumerated element:

Read together: SEG:GR:Ground:00:The Reston, Virginia mission-operations enclave: the control, crypto, access-control, patch, and console services that command the constellation. Its PARENT names the environments it operates from, PCE:TE:Terrestrial:00 and PCE:TE:Terrestrial:01, so parents exist before children and nothing floats.

CH 5 The ETEN Process, Once, Then the Deltas

The normative ETEN Process is printed once below, in full, as it is applied at the PCE layer, the first walk. After it come the three per-layer deltas, side by side, so the one thing each layer changes reads as the headline instead of being buried in identical framing.

The same eight steps, in the same fixed order, run at every layer. What follows is everything that actually changes.

The SEG delta

The delta. Segments add the first PARENT links: every element names at least one PCE above it; three segment types in scope.

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: three segment types, Space and Link (the segments EO 14144 covers at minimum) and Ground (the ground-based infrastructure NIS2 binds); the User customer edge is a taxonomy type but out of scope for this platform, so it is not enumerated. Output. One ETEN of the form SEG:TAG:LABEL:ORDINAL:Description per enclave. Constraints. Every SEG element names at least one PCE in PARENT at Step 06; existing segment diagrams were imported and tagged rather than redrawn. Review. Confirm each segment links up to its environment before presenting.

The SVC delta

The delta. Services can span segments: one element, DISTRIBUTED Y, every participating SEG in PARENT.

Whose input. The segments are already enumerated. Satellite Operations named the services it runs and Satellite Design & Engineering the services it built: on the telecommand path, the fifteen 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. Constraints. Cross-segment services list every participating SEG in PARENT at Step 06, set DISTRIBUTED to Y at Step 07, 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.

The AST delta

The delta. Assets take one or more SVC parents each, with ordinals used aggressively for unit-level resolution.

Whose input. The services are already enumerated. Satellite Design & Engineering supplied the concrete assets from its inventory lists, BOMs, and CMDB exports: on the telecommand path, the twenty-one 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. Constraints. Every AST element names at least one SVC in PARENT at Step 06, never zero, and every service a shared asset actually carries; 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.

In every walk, at every layer, the constants are the same: eight steps in fixed order, tags read from the published taxonomy and never invented, the Step 02 gate applied twice (once selecting the layer, again writing the description), and the loop line: repeat for the next instance until none remain.

CH 6 The Telecommand Decomposition, Complete

Every element of the Day-1 CONOPS, in deck order by layer, with its identifier, canonical description, parent, and source reference. Nothing here lives behind a click: this chapter is the full catalogue the deck pages through. The full ETEN of any row is its identifier joined to its description: LAYER:TAG:LABEL:ORDINAL:Description.

6.1 · PCE, 4 elements

Stage 1 of 4 · 4 of 44 elements · environments only

Four environments, and nothing under them yet. The rest of the figure is dimmed because it is not enumerated yet, not because it does not exist.

Why only four environments. Kestrel operates in more places than this. This pass enumerates the telecommand path, so it enumerates the environments that path crosses and no others. The taxonomy still carries Aquatic, Aerial and Deep Space, and they take ordinals the day the business flies there. Enumerating an environment the platform does not use would be padding, and padding is what makes a model impossible to maintain.

SCOR convenes the departments that own where the platform lives: Satellite Operations, which flies the constellation, and Satellite Design & Engineering, which built it, with the Security Operations Center sitting in. The room finds two distinct terrestrial sites and two orbital regimes, so Terrestrial takes two ordinals and Orbital takes two. PCE is the only layer with no parent: these four elements are the anchors the rest of the CONOPS hangs from.

6.2 · SEG, 4 elements

Stage 2 of 4 · 8 of 44 elements · environments and segments

Four segments attach to the environments. Notice the link: it is the one element that belongs to more than one environment type, so it is drawn outside the bands and tied to each.

Why four segments and not more. A real operator has segments this pass does not touch: user terminals, a corporate estate, a launch chain. They are out because the command path does not run through them, not because they are safe. The User segment type is in the taxonomy and deliberately unenumerated here, which is the honest way to record a boundary.

The room traces the actual command flow: an operator originates a command at a console, mission operations authorizes it on the Ground, the Link carries it as an RF or optical signal, and the spacecraft executes it in Space. Four enclaves are enumerated on the path; the User customer edge is a taxonomy type but out of scope for this platform, and Launch and the physical regimes AQ, LO, HI, NE, and DE drop out at Step 01.

6.3 · SVC, 15 elements

Stage 3 of 4 · 23 of 44 elements · services added

Fifteen services fill the segments. This is where the decomposition starts to look like a platform rather than a diagram.

Why fifteen services. Three departments in one room, working a fixed time box, resolved the command path to fifteen services. A second pass would find more, and would split some of these where a distinct owner or a distinct patch path appears. Fifteen is what this pass earned; claiming it is exhaustive would be the dishonest part, not the number itself.

Satellite Operations named the services it runs and Satellite Design & Engineering the services it built. Ordinals continue across segments inside each tag, so no ordinal repeats anywhere in the layer: Space consumed Control Plane 00 to 04 and Hybrid 00, the Link took Control Plane 05 to 07 and Hybrid 01 and 02, and the Ground took Control Plane 08 to 13 and Hybrid 03. All twenty run inside a single segment, so DISTRIBUTED is N for each.

6.4 · AST, 21 elements

Stage 4 of 4 · 44 of 44 elements · complete

Twenty-one assets close every branch. Every element now traces to an environment, so nothing in the model is unowned.

What this is, and what it is not. This is a complete, parented decomposition of the telecommand path, not a complete model of Kestrel Orbital. It is a first pass on one platform under a real time constraint. Some assets group several physical units where those units share an owner, a build and a patch path; where any of those diverge, the element splits and takes the next ordinal. The gaps in the ordinal sequence are elements the register still tracks outside this scope. Say all of this out loud when you present it: a decomposition presented as finished invites a reviewer to find the missing thing, while one presented as a scoped first pass invites them to fund the next one.

Satellite Design & Engineering supplied the concrete assets from its inventory lists, BOMs, CMDB exports, and console inventories. Every asset names every service it carries in PARENT, at least one; ordinals continue per tag across the whole platform, so unit-level detections resolve to the exact instance. This is the resolution at which a detection fires and a patch lands.

Assets are the leaf layer of the CONOPS. Each one names the SVC it implements as its PARENT, and each of those services already traces up through its SEG to a PCE, so every asset closes a branch that runs from PCE to asset. With all 44 elements enumerated, the CONOPS is complete and ready to hand off for threat attachment on Day 2.

CH 7 Deploying the Taxonomy in the SOC

The same model you enumerated by hand this morning is published as the meteorstorm namespace in the public MISP (Malware Information Sharing Platform) taxonomies repository, live and open source. Your organization adopts it with no re-architecture: tag the threat intel, alerts, and events you already produce, and the structural context travels with every finding to each department and every Space ISAC partner.

The machine tag

A machine tag is a triple: namespace:predicate="value". Two worked examples:

• meteorstorm:SEG="SEG-GR" · a finding on the Ground segment.
• meteorstorm:AST="AST-FW" · a firmware asset.

The predicate is the layer, the value is the TEN tag, so a tagged event carries its structural context in machine-readable form. The finding itself cites the exact instance by its ETEN, and the parent chain above that element rides along without being restated.

The three deployment steps

1. RETRIEVE the namespace; it ships with MISP.
2. ENABLE it in taxonomies/index.
3. APPLY it to every event.

The three doors

Deploying the taxonomy into the Security Operations Center’s MISP-based Threat Intel Platform is the Activate entry point from orientation, executed: the first of the three doors opened. Satellite Design & Engineering takes the Integrate door when the next platform leaves the drawing board, and all three departments meet at Engage on the exercise floor later this week.

What deployment closes the loop on: information sharing with Space ISAC is a company mandate, and this taxonomy is what makes it work machine to machine. A confirmed command-and-control attack becomes a redacted, tagged event whose structural context any partner running the same namespace reads without translation.