💻 computer science

Cybersecurity Risk Assessment for CubeSat Missions: Adapting Established Frameworks for Resource-Constrained Environments

This paper proposes a tailored cybersecurity risk assessment framework for resource-constrained CubeSat missions that adapts established enterprise standards by introducing a vulnerability register, a Security-per-Watt heuristic, and a Distributed Security Paradigm to achieve significantly higher security efficiency than terrestrial transpositions.

Original authors: Jonathan Shelby

Published 2026-04-02

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Jonathan Shelby

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a tiny, budget-friendly robot to send to space. This robot, called a CubeSat, is the size of a loaf of bread and costs as little as a used car, compared to the millions it takes to launch a traditional satellite. Universities, startups, and even small countries use them to take photos of Earth or send data.

However, because these robots are so small and cheap, they have very little battery power (about as much as a lightbulb) and can only talk to Earth for a few minutes a day.

The Problem: The "Big House" Security Guard
Traditional cybersecurity rules (like those used by banks or governments) are like hiring a massive security team for a mansion. They assume you have unlimited electricity, a 24/7 security camera, and a team of experts watching the screens all day.

If you try to force these "mansion rules" onto your tiny "bread-sized" robot, two things happen:

The robot runs out of battery trying to run the heavy security software.
The robot gets confused because it can't talk to the security team fast enough when something goes wrong.

The Solution: A "Pocket-Sized" Security Plan
This paper proposes a new way to protect these tiny space robots. Instead of trying to copy the big rules, the author suggests building a security system that fits the robot's tiny size. Here are the three main ideas, explained with simple analogies:

1. The "Security-per-Watt" Score (The Battery Budget)

Imagine you have a very small wallet (your battery). You want to buy the best security possible, but you can't afford to spend your whole wallet on one thing.

Old Way: You buy a giant, expensive vault door (heavy encryption) that drains your wallet instantly, leaving you with no money for the actual mission (taking photos).
New Way: The paper introduces a score called Security-per-Watt (SpW). It asks: "How much safety do I get for every drop of battery I use?"
The Result: They found that using a specific type of digital lock (called Elliptic Curve Cryptography) is like buying a high-tech smart lock that costs pennies to run but is just as strong as the giant vault door. It saves 65% of the battery while keeping the robot safe.

2. The "Autonomous Bodyguard" (Distributed Security)

Imagine your robot is part of a flock of birds (a constellation).

Old Way: If one bird gets sick, it has to wait for the human zookeeper on the ground to notice, drive to the zoo, and tell the bird what to do. By the time the zookeeper arrives, the bird might have already crashed.
New Way: The paper suggests giving each bird a tiny, pre-programmed "instinct." If a bird senses something weird (like a hacker trying to take control), it immediately locks its own wings and goes into "safe mode" before it even asks the human.
The Result: This "Distributed Security" is like having a self-driving car that brakes automatically if it sees a pedestrian. It reacts 2x faster and uses half the energy of waiting for a human to give orders.

3. The "Supply Chain" Reality Check

CubeSats are built using parts bought from all over the world (like a Lego set).

Old Way: Governments demand a 50-page background check on every single Lego brick to ensure it wasn't tampered with. This is too expensive and slow for a student project.
New Way: The paper suggests a "Good Enough" approach. Instead of checking every brick, you just make sure the people selling the bricks sign a promise that they are real and will send updates if they find a flaw. It's like buying a used car: you don't need a military background check on the tires, but you do want a receipt and a warranty.

The Big Picture: Why This Matters

The author found that the biggest risks aren't inside the robot's brain; they are in the radio waves connecting it to Earth and the ground stations controlling it.

By using these new, lightweight rules:

Universities can build safe satellites without needing a team of cyber-experts.
Startups can launch missions without going bankrupt on security software.
Everyone gets safer space travel because the robots are smarter about how they use their tiny batteries.

In short: You don't need a fortress to protect a houseboat; you need a really good, lightweight anchor. This paper teaches us how to build that anchor for the future of space exploration.

1. Problem Statement

CubeSats have democratized space access but introduced unique cybersecurity challenges due to their severe resource constraints (1–2 W power budgets, limited storage, intermittent connectivity) and reliance on Commercial Off-The-Shelf (COTS) components.

The Gap: Established cybersecurity frameworks (NIST SP 800-37/53, ISO/IEC 27001/27005, NIST SP 800-161) assume abundant computational resources, continuous monitoring, and stable organizational governance. These assumptions are misaligned with the orbital reality of CubeSats, which operate autonomously for long periods with only minutes of contact time per orbit.
The Risk: Directly applying terrestrial frameworks leads to either infeasible implementations (overwhelming power/storage) or the abandonment of security controls, leaving CubeSats vulnerable to spoofing, jamming, and command injection.
Core Question: How can established risk frameworks be proportionately adapted for CubeSat missions without discarding their protective intent?

2. Methodology

The study employs a pragmatic mixed-methods design consisting of four interlocking phases:

Systematic Literature Review: Analyzed CubeSat architectures, threat landscapes, and existing standards (NIST, ISO, CCSDS) to identify gaps.
Structured Vulnerability Assessment: Developed a 42-entry vulnerability register specific to CubeSats.
- Taxonomy: Entries were coded using STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and mapped to MITRE ATT&CK tactics.
- Scoring: Each entry was assigned a CVSS v3.1 base score, with impact weighted toward mission-critical functions and orbital constraints.
Framework Adaptation: Reinterpreted control intents from NIST and ISO standards to fit sub-watt budgets. This involved extracting the intent of a control (e.g., confidentiality) and mapping it to feasible implementations (e.g., lightweight cryptography instead of TLS).
Scenario-Based Validation: Since attacking operational satellites is legally and ethically prohibited, the authors used analytical scenarios to test the framework's decision utility. Three scenarios were evaluated: cryptographic selection, constellation incident response, and supply-chain assurance.

3. Key Contributions

The paper introduces three primary technical constructs:

A. The CubeSat Vulnerability Register

A comprehensive catalog of 42 vulnerabilities revealing that risks are not uniform.

Concentration: Risks concentrate heavily in the Ground Segment and Communication Subsystems (Mean CVSS 8.0–8.2), rather than onboard computing (Mean CVSS 6.9).
Dominant Threats: Spoofing and Tampering are the primary threats in communications/ground segments, while Elevation of Privilege is more prevalent in onboard software.

B. Security-per-Watt (SpW) Heuristic

A decision-support metric to quantify the efficiency of security controls in power-constrained environments.

Formula: $SpW = \frac{SG}{P_{operational}}$ $S p W = \frac{S G}{P _{o p er a t i o na l}}$
- $SG$ (Security Gain): Calculated as $\sum (CVSS_i \times P_i \times M_i \times RRF_i)$ , where $P$ is exploitation probability, $M$ is mission criticality, and $RRF$ is the risk-reduction factor.
- $P_{operational}$ : Operational power consumption adjusted for duty cycles and environmental factors.
Purpose: Enables designers to compare controls based on risk reduction per unit of power, facilitating transparent trade-off decisions.

C. Distributed Security Paradigm (DSP)

A reconceptualization of incident response for intermittently connected systems.

Shift: Moves from a ground-centric, human-in-the-loop model to an autonomous, constellation-level function.
Mechanism: Satellites are equipped with pre-authorized containment actions (e.g., safe-mode entry, rate-limiting, subsystem isolation) triggered by local anomaly detection.
Principles: Includes per-node credential revocation, signed updates, rate-limiting on inter-satellite links, and strict separation of command vs. payload data paths.

4. Results and Validation

The framework was validated through three scenarios, demonstrating significant efficiency gains over "naive" terrestrial transpositions:

Scenario 1: Cryptographic Selection (ECC vs. RSA)
- Context: Selecting encryption for a 1U CubeSat with a 2W budget.
- Result: Elliptic Curve Cryptography (ECC) with AEAD achieved a 2.7× higher SpW than RSA-2048.
- Impact: ECC provided near-equivalent security while consuming only ~0.18W (vs. 0.52W for RSA), preserving critical power for payload operations.
Scenario 2: Constellation Incident Response (DSP vs. Centralized)
- Context: Responding to a compromised node in a 24-satellite LEO constellation.
- Result: The Distributed Security Paradigm achieved 1.98× higher SpW and consumed 55% less power than centralized ground-based response.
- Trade-off: While autonomous detection had a slightly lower Risk Reduction Factor (0.85 vs. 0.95), the Security Effectiveness Index (SEI) was more than double that of the centralized approach due to faster detection (65% faster) and elimination of single points of failure.
Scenario 3: Supply-Chain Assurance
- Result: Demonstrated that "baseline" contractual practices (firmware provenance, shared version registers) could achieve proportionate assurance without the heavy compliance burden of military-grade C-SCRM, making security accessible to academic and startup teams.

5. Significance and Implications

Methodological Shift: The paper establishes proportionality as a fundamental design principle for constrained cybersecurity. It argues against the "all-or-nothing" approach, showing that effective security can be achieved through systematic adaptation rather than resource-intensive maximalism.
Democratization of Security: By providing low-barrier, auditable tools (like the SpW heuristic and three-tier risk classification), the framework enables universities and emerging space nations to implement robust security without needing dedicated cybersecurity experts.
Regulatory Impact: The findings suggest that regulators should mandate baseline security (e.g., authenticated command links) that is feasible for small operators, rather than imposing standards designed for large satellites.
Broader Applicability: The principles of SpW and DSP are transferable to other resource-constrained cyber-physical systems, including IoT, edge computing, and autonomous vehicles, where intermittent connectivity and power limits are common.

Conclusion: The paper successfully demonstrates that established enterprise security frameworks can be adapted for CubeSats. By prioritizing the intent of controls over their implementation details and utilizing metrics like SpW, mission designers can achieve defensible, auditable security that respects the physical and economic realities of small satellite missions.