See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/353909968

CubeSat Security Attack Tree Analysis

Conference Paper · July 2021

DOI: 10.1109/SMC-IT51442.2021.00016

CITATIONS READS
30 2,060

3 authors, including:

Gregory Falco Arun Viswanathan

Cornell University California Institute of Technology
75 PUBLICATIONS 892 CITATIONS 15 PUBLICATIONS 242 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Gregory Falco on 15 August 2021.

The user has requested enhancement of the downloaded file.

 CubeSat Security
Attack Tree Analysis
Gregory Falco Arun Viswanathan
Department of Civil and Systems Engineering Jet Propulsion Laboratory
Institute for Assured Autonomy California Institute of Technology
Johns Hopkins University
Baltimore, USA arun.a.viswanathan@jpl.nasa.gov
falco@jhu.edu
Abstract—Once a novelty, small satellites, often referred to as
CubeSats, have become important tools for a variety of space
activities ranging from exploration to defense. Their relative
affordability and short development timeline have made them
attractive options to complement larger space vehicles, conduct
reconnaissance and other finite tasks. The specialized nature of
many CubeSat missions do not make their security any less
important as their missions could easily be matters of national
security. This paper demonstrates the use of attack tree analysis
to assess vulnerabilities of a CubeSat. First, we abstract and
build an architectural model of an operational CubeSat. We then
create a series of attack trees for the abstracted architecture to
illustrate a series of potential attack vectors for small satellites.
We conclude by discussing some strategies that could be employed
to improve CubeSat resilience.
Index Terms—CubeSat, Small Satellites, NanoSat, CubeSat
Security, Satellite Security, Space System Security, Attack Trees,
Space Cybersecurity, Mission Resilience
I. I NTRODUCTION
CubeSats are cost-efficient, small space vehicles. In some
cases they are engaged to augment the capabilities, oversight
or communications of larger space mission systems, as was the
case with NASA Jet Propulsion Laboratory’s (JPL) Mars Cube
One (MarCO) [1]. Other times they are used for early edu-
cation projects to encourage emerging scientists [2]. Despite
their small size, they often hold strategic mission importance.
CubeSats are not toys. They must be engineered with safety
and security in mind - as should be the case for any space
system.
The security of space vehicles has increasingly become a
topic of technical and policy discussion [3]. While cybersecu-
rity is not a new issue for space systems engaged in defense or
intelligence operations, the burgeoning ‘new space’ economy
has brought hundreds of new small satellites into orbit, without
regard for their security. Complicating security matters further
is the lightly regulated landscape [4], [5] for launching such
assets.
While most small satellites have different use cases and pay-
loads, their components, system architecture and configuration
is largely consistent. This is partially because of the growing
open-source documentation and associated communities for
space system design and development [6], [7]. For example,
Andrew Santangelo
sci Zone
Holland, USA
Pasadena, USA andrew santangelo@sci-zone.com
while not a CubeSat, the autonomous Mars helicopter designed
and built by NASA JPL was powered by the Linux operating
system [8]. Like the Mars helicopter, CubeSats use commercial
off-the-shelf (COTS) sensors, software and chipsets that are
installed and configured in predictable ways. Such consistency
affords developers the ability to quickly and inexpensively
build CubeSats, but there are hidden costs in exchange for the
relatively straightforward design process. The tradeoff, not at
all unlike the issue with internet of things (IoT) devices, is
that these inexpensive components and their standard commu-
nications mechanisms are not designed with security in mind
[9].
The current security posture of CubeSats offers opportuni-
ties for attackers to compromise their operations in a variety of
ways. In this paper we begin by contextualising the security
challenge through previous space system security incidents,
discussing potential attacker motivations for compromising
CubeSats, and describing a methodology for enumerating
attacks against CubeSats. We then describe three potential
attacker goals for disrupting a CubeSat’s operations: denial of
service (DoS), data tampering and disabling the CubeSat. Each
will be accompanied with a methodology for achieving the
attacker’s goal, represented using attack trees. The attacks are
designed based on an abstracted CubeSat system architecture.
The CubeSat architecture is based on a real mission system
that is currently operating in space.
II. BACKGROUND
The industrial control systems (ICS) and critical infrastruc-
ture security communities have long employed the “security
by obscurity” approach to securing their systems, which relies
heavily on secrecy to protect assets from attackers [10].
While relatively successful as a strategy in the early years
of ICS, it became significantly less effective as open, standard
communication protocols came into use and the volume of
connected devices increased. Space systems - especially in
civil space - have equally relied on security by obscurity in
past decades [11], but, similar to ICS, the proliferation of space
systems and their increased connectivity has and will continue
to reduce the efficacy of this strategy.
 Like ICS, most satellites suffer from constrained memory
and processing power. This restricts space systems from us-
ing traditional security solutions such as antivirus tools or
memory-intensive intrusion detection and prevention systems.
CubeSat space vehicles are even more memory and processing
constrained than their typical satellite counterparts, making
many security products and solutions infeasible. Instead, their
security relies on the thoughtful design of their system archi-
tecture along with careful monitoring of the asset.
Unlike currently deployed CubeSats, future P-LEO con-
stellations will feature significant computing power as is the
case for the La Jument constellation embedded with Lockheed
Martin’s SmartSat™ software-defined satellite architecture.
SmartSat™ will allow for applications to be run on the edge
and facilitate dual tenancy [12]. Security will be equally, if
not more, important given the increased attack surface and the
potential for attackers to move laterally across applications.
With increased interest and investment in the militarization
of space, senior U.S. military officials have explicitly described
cyberattacks being the most likely space threat [13]. Such
attacks are far from science fiction.
A. Space System Security Incidents
There has been a clear upward trend in cyberattacks against
space systems over the past decades, ranging from ones
compromising ground control stations, to disrupting commu-
nications signals to those targeting the satellite itself [14].
Among the earliest recorded cyberattack against space systems
may have been in 1998 against the ROSAT X-Ray Satellite.
Shortly after a known cyber intrusion at the NASA Goddard
Space Flight Center where ROSAT source code was stored, the
US-German satellite turned its solar panels towards the sun,
frying the sensors and rendering the satellite inoperable [15].
While details of what actually happened are contested [16],
the failure epitomizes the appeal of cyberattacks against space
assets because they can easily look like naturally occurring
failures [17].
1) Ground Station Attacks: The NASA Goddard Space
Flight Center was certainly not the last ground station or
NASA center to be hacked. In April 2018, NASA JPL was
attacked via an unauthorized and unsecured Raspberry Pi
device that was connected to the JPL network [18]. The lack
of segmentation of the JPL network gateway allowed the
attacker to perform lateral movement and collect data from
mission systems [18]. While it is not clear if the theft of
this data had direct impact on any mission operations, as a
result of the attack, NASA Johnson Space Center disconnected
their systems in May 2018 from JPLs network gateway until
November 2018, for fear that missions run out of Johnson
Space Center may also be attacked [18].
2) Communication Signal Attacks: Communication chan-
nels between ground stations and satellites are also frequently
subject to attack through both jamming and spoofing [14].
Jamming attacks against satellite signals have been around
for decades - most commonly discussed in the context of
global navigation satellite systems (GNSS) [19]. Given the low
power of GNSS signals, interference is relatively common and
can be caused unintentionally by amateur radio enthusiasts or
by adversaries using a range of devices (some sold over the
internet on sites like eBay) [19]. Interference can result in
the inability to receive a signal (jamming) and is a functional
denial of service (DoS) attack.
More concerning are GNSS spoofing attacks, which causes
an operator to believe that a navigation device is accurately re-
flecting coordinates, however an attacker is tricking the device
into displaying fake data. The first highly publicized spoofing
attack was against an RQ-170 Sentinel US surveillance drone
in 2011. Iranian operatives were able to spoof its GPS signal
and trick the drone into landing unharmed in Iranian territory
[20]. Such attacks have been made easier and achievable by
script kiddies through the use of inexpensive software defined
radios such as the HackRF One [17]. The ease of spoofing and
jamming have caused concern for military operators reliant on
satellite communication signals. While discussed in academic
literature in 2000 [21], anti-spoofing and anti-jamming GPS
technology named M-Code only become operational at the end
of 2020 [22].
3) Space Vehicle Attacks: While less common, cyberattacks
can target satellites in orbit. ROSAT was perhaps one example
of such an attack, but if there is any doubt about ROSAT,
there are other confirmed attacks of this nature. Described in
the 2011 Report to Congress of the U.S.-China Economic and
Security Review Commission, on October 20, 2007 and then
again on July 23, 2008, what is described as “interference” was
experienced by Landsat-7, a U.S. Earth observation satellite
for 12 minutes each time [23]. More seriously, the report
describes an attack against the Terra Earth observation satellite
on June 20, 2008 and October 22, 2008 where the attacker
achieved all steps to command and control the satellite for at
least 2 and 9 minutes respectively [23]. These attacks were
thought to be achieved by China given the attack techniques
were consistent with Chinese military writings on the topic
[23]. As technology for communicating with satellites be-
comes more accessible and less expensive, it is conceivable
that these attacks will become increasingly common [17].
Notably, the above examples are not specific to CubeSats.
Details regarding attacks against satellite systems are often
hidden from public view so it is not surprising that private
owners of CubeSats or military operations using CubeSats
have not publicized attacks against their assets. However, at
AIAA ASCEND 2020, we ran an attack demonstration on
an operational CubeSat to demonstrate the security challenges
with these systems [24]. Based on this demonstration, it is
reasonable that the attacks described above are achievable and
applicable for CubeSats.
B. CubeSat Overview
According to Nanosats.eu, a database that tracks the sta-
tus of launched nanosatellites (another term for small satel-
lites/CubeSats), as of January 1, 2021 there were 801 nanosats
in orbit [25]. Their popularity is largely a function of their low
cost and high value. Cost estimates to build CubeSats range
between $25,000-40,000 for components and about $40,000
for launch services [26]. Given ride-sharing agreements for
rocket launches, launch costs will likely continue to decrease
in coming years. Some companies such as bluShift Aerospace
which is powered by biofuel, even discuss the prospects of
highly customized launches just for CubeSats [27].
1) Proliferated Low Earth Orbit (P-LEO) CubeSats: As
described previously, there is a proliferation of small satellites
being launched into LEO - in fact, it is so common that the
term proliferated low earth orbit or P-LEO is widely used. P-
LEO specifically refers to large constellations of small satel-
lites. Some P-LEO like the DARPA Blackjack program, are
designed for multiple uses, ranging from distributed processing
for military applications to providing networking capabilities
[28]. In the commercial sector, P-LEO companies like Planet
Labs focuses on Earth monitoring and imagery [29].
As P-LEO constellations are launched, there will be in-
creased concern of both physical and RF collision and in-
terception. While the operating landscape of space is vast,
with each incremental CubeSat that is part of a P-LEO
constellation, the attack surface of the constellation increases
making it easier for attackers to target and compromise [17]. In
some P-LEO as is the case for Project Blackjack, the satellites
function and network autonomously, which adds additional
complexity to the system. On top of existing security issues
with space systems, autonomous space systems have distinct,
additional security considerations [30].
C. Security Assessments
To identify security challenges for various systems, re-
searchers build threat models that outline an attacker’s goals
and subsequent approach for disrupting a system. A method
for assessing security risks for a given system architecture is
attack tree analysis.
Such threat models have been developed previously for
space systems [31], but none have focused on CubeSats.
The primary difference between previously completed space
system security assessments and our own is that CubeSat
space vehicles have less attack surface, given their resource
constraints and fewer components attached to the satellite bus.
This limits the options that attackers have to compromise
the device. Further, the low-power nature of CubeSats results
in their greater susceptibility to attacks that would drain a
CubeSat’s power, rendering it useless. While subtle differences
may exist, threat models for a CubeSat and a larger satellite’s
ground station would be similar given they could ostensibly
use the same systems. A CubeSat’s threat model may be
considered to be more generalizable to other satellite architec-
tures given their components consist of the basic requirements
for operations. In effect, CubeSats reflect the least common
denominator components across space systems; hence the
value of conducting threat assessments on such systems.
1) Attack Tree Analysis: Attack tree analysis was first
published in 1999 [32] as an approach to enumerate various
attack pathways to achieve an attack goal. The attack goal is
stipulated at the top of the tree and sub-goals are enumerated
beneath which are called branches. Each branch contains a
series of leaf nodes which are actions required to achieve the
sub-goals and ultimately the attack goal. Leaf nodes that must
be performed together to achieve a sub-goal are joined by an
arc representing “AND” logic, whereas leaf nodes representing
separate choices to achieve a sub-goal are not joined thereby
representing “OR” logic.
Attack trees are a derivation of fault tree analysis, an
approach used in the aerospace community to determine faults
in complex systems. Fault trees were developed in 1962 at Bell
Telephone Laboratories while devising a method to determine
failure modes and risks for intercontinental ballistic missiles
(ICBMs) [33], [34].
While highly useful for a cursory risk assessment, attack
trees have been criticized for being static and subjective [35].
To reduce the subjectivity of attack trees, researchers have
standardized their components, which facilitates comparison
across different systems, their scalability across many systems
and the automation of attack trees using AI planning logic
[36]. Figure 1 depicts a template for building an attack tree as
described. There are, however, many structural permutations
of attack trees that would be entirely acceptable and useful for
security evaluations.
The proposed attack methodology encourages the use of
existing security frameworks and taxonomies to enable con-
sistency and completeness [36]. It also assumes a multi-stage
process is required to achieve the attacker goal, following the
stages of attack as described by Lockheed Martin’s Cyber
Kill Chain [37]. Given the inherent complexity of CubeSats,
a multi-stage process to achieve an attacker’s objective is
realistic.
III. C UBE S AT S YSTEM A RCHITECTURE
For purposes of this study, we abstracted a CubeSat system
architecture from an operational mission system. Below we
describe the abstracted CubeSat architecture we worked with
in the context of a generic CubeSat system depicted in Figure
2. There are three aspects of any CubeSat mission system -
the ground station, the communication signal and associated
infrastructure and the CubeSat space vehicle.
A. Ground Station
The ground station is responsible for satellite operations and
support. This ranges from issuing controls to the CubeSat,
monitoring weather and atmospheric conditions relating to
launch and providing support services to the CubeSat by
way of data collection, management and storage. The ground
station is historically where data centers and servers relating
to the operations of the CubeSat are housed along with the
operator’s terminal. An operator’s command terminal may
consist of a desktop computer, a web-browser and a user
interface (UI) where communications from the satellite are
viewed.
Historically, satellites were operated primarily from the
operator’s terminal, but with the advent of cloud-based ground
stations-as-a-service offered by Amazon Web Services and
 Figure 1. Attack Tree Analysis Methodology.
Microsoft Azure, the operator may log into their service
provider and control or offer data to the CubeSat from the
cloud. A cloud-based ground station is increasingly common
for CubeSat missions. The CubeSat we worked with “pushes”
and “pulls” data to and from the ground. The ground terminals
cannot push data to the satellite.
B. Communication Signal and Supporting Infrastructure
Regardless of whether the control system is pushing data
to the CubeSat or the CubeSat is requesting data from the
control center, the ground station relays commands via a
network router to a satellite dish transceiver. The transceiver
then communicates with the CubeSat’s radio network at a
pre-determined time during the transceivers alignment with
the CubeSat’s orbit. The transceiver may additionally require
communication with a satellite network to communicate to the
CubeSat. The satellite transceiver infrastructure for CubeSats
is generally rented using a time-sharing system. Such a time-
sharing system is used extensively for cloud-based CubeSat
communications, where there are limited transceivers for a
wide range of operators.
C. Space Vehicle
When the transceiver is aligned with the CubeSat’s orbit, a
communications signal will be sent to the CubeSat’s antenna
radio network. The CubeSat’s radio network will download
the signal into a database onboard the space vehicle where it
will be parsed and analyzed depending on the functionality
of the CubeSat and the purpose of the communication. The
CubeSat we studied had several basic components including a
GPS radio, an attitude determination and control system and a
series of Earth observing sensors. Commands processed by this
satellite primarily related to determining which data should be
sensed, captured and delivered back to the ground station.
IV. C UBE S AT ATTACK T REES
Given the system architecture presented, we selected a
series of attack goals relevant to the CubeSat. Each attack
goal selected intended to target different components of the
CubeSat.
First, we describe an attacker’s goal and their process for
preventing users from accessing CubeSat data. We describe a
denial of service attack against the CubeSat, representing an
attack against the system that enables communications.
The second goal and associated attack method we describe
is tampering with sensitive CubeSat sensor data stored in a
database. We characterize this as an attack on the ground
station’s servers.
Finally, we describe an attacker’s goal of causing the
CubeSat to pull a “kill radio” command from the ground
station, thereby rendering the CubeSat useless. This would be
a direct attack against the space vehicle.
The attack trees are described in sequence starting with the
attack tree for the communications and ending with the attack
tree for the space vehicle. Some of the information collected
by an attacker after completing one tree can be used in the
process of completing a subsequent attack goal on a different
part of the CubeSat system. The attack trees described are not
necessarily the easiest attacks to complete, but are informative.
A. Denial of Service
To achieve a denial of service attack as the “goal”, we
followed the attack tree methodology described above that
guides the attack tree development process using a series of
questions that cover: the stage of the cyber kill chain; the
attack surface targeted; the action on the attack surface; and
the method used to achieve the action. The starting assumption
for purposes of the exercise is that the attacker knows the
domain name of the CubeSat provider. Moving through the
 Figure 2. A Notional CubeSat System Architecture.
attack tree methodology from the top left to bottom right, we
answered each question posed in the context of the attack goal
- denying communications to the end user.
For example, Figure 3 should be read as follows: to achieve
a “denial of service” (attack goal), the attacker begins with
“reconnaissance”, which should be completed on the “web
interface”, where an attacker should “collect and analyze
information” by using tools like “Shodan”. Completing the
“reconnaissance” branch of the attack tree yields outcomes
including knowledge of: the target IP address, what services
are running on the system, and usernames and email addresses
for a user. With this knowledge, the attacker can proceed to
the next branch of the tree which begins with “weaponiza-
tion” and continue to work their way through the attack tree
methodology in this way.
Executing each branch of the tree as described, attackers
will reach the final stage of the attack to “execute” commands
by accessing the “administrative panel”, “performing actions
via the UI” and “changing the configuration settings” along
with “deleting items on the CubeSat” to deny service to
operators. The two kill chain stages that are shaded in the
attack tree are not necessary to complete the attacker’s goal.
Ultimately, the attack goal of denying service to users of
the CubeSat can be achieved in multiple ways, where only
one method is described in our attack tree. The approach
depicted in Figure 3 involves compromising the space vehicle
where a command log is represented to the operator via a UI.
In this case, the ambition of the attacker is not to flood the
communication channel, but to back up the CubeSat command
queue with unnecessary processes, functionally blocking the
execution of actually necessary commands for the CubeSat’s
function. This could either delay time-critical commands or
be a method to diffuse the limited power available on the
space vehicle. Another approach to denying service could be
achieved more simply by either jamming the communications
signal or flooding the communications network. A jamming
attack could have been represented on our attack tree by
adding an “OR” logic branch that provided another option
under the “Execute” stage, but was omitted to streamline the
figure.
Determining what the attacker is optimizing for during the
attack is essential when designing attack trees. In this case,
the attack tree optimizes for maximum information gathering,
whereas if the attack tree aimed to optimize for speed, a
jamming attack would have been preferable. While a jamming
attack would be easier to accomplish, it would not have yielded
the same reconnaissance insight that will enable the next attack
goal.
B. Data Tampering Attack
The attack tree for the data tampering attack is shown in
Figure 4. In the course of conducting a denial of service, the
attacker performed reconnaissance thereby learning about the
CubeSat system’s assets. They also would have collected the
username and password of a user after a successful phishing
attack. These insights can be used for the next attack goal:
tampering with data collected from the CubeSat stored at the
ground station.
Given the attacker’s existing knowledge of the credentials,
the data tampering attack is streamlined, hence the shaded
stages of reconnaissance, weaponization and deliver. Control
and maintain are also excluded stages as they are not necessary
for the data tampering goal. The attack tree focuses on the
stages of exploit and execute, starting with the user and
administrative interface as the attack surface. Four actions
 Figure 3. Attack tree for a denial-of-service attack on a CubeSat.
are enumerated to achieve the entire goal across exploit and
execute where each has subsequent instructions to achieve the
associated actions. The actions include:
1) Login to the database server;
2) Steal admin credentials to the database;
3) Gain access to the database admin interface; and
4) Modify database tables.
Addressing each relevant stage of the kill chain and the
associated questions throughout the tree will lead to the attack
goal’s completion - data tampering, achieved by “changing
data logged in the flight database”.
C. Disabling the CubeSat
The final attack goal is to disable the CubeSat by killing
the radio on the CubeSat space vehicle (see Figure 5.
The attack tree begins with the assumption that the attacker
knows the following information after successfully achieving
the previous attack goals: knowledge of assets to attack,
username and password of phished user an admin credentials
to the ground station. Also, given this information, the attacker
would have insight to the unique CubeSat configuration where
an operator cannot push commands from the ground station,
but instead commands must be pulled by the CubeSat. This
presents unique challenges as an attacker who seeks to disable
the CubeSat given the attacker will need to issue the kill
command from the CubeSat itself.
The attacker still must begin with the reconnaissance stage
of the kill chain, also necessarily achieving weaponization,
deliver, exploit and execute. As with the other attack goals, the
attack methodology describes the steps required in sequence
where ultimately six actions enable the attacker to disable the
CubeSat. These actions include:
1) Collect and analyze information: find documentation
about the CubeSat, determine how to request commands
and find template scripts to issue the command;
2) Develop client application: craft a malicious script to
execute the kill command based on the template found;
3) Upload malicious application to server: login remotely
using the stolen user credentials and upload the mali-
cious kill radio script to the ground station server;
4) Gain access to the database admin interface: login to
the admin interface for the CubeSat space vehicle from
the ground station using the stolen credentials;
5) Add command to upload application: add command
to pre-scheduled database table for CubeSat to pull
malicious script uploaded
6) CubeSat pulls the kill command: CubeSat pulls mali-
cious script and executes kill radio command.
After the CubeSat executes the kill radio command, the
CubeSat is rendered useless to the ground as it can no longer
communicate sensor data collected nor can it retrieve new
commands. Some commands the CubeSat would pull are vital
to its survival. For example, commands relating to attitude
determination and control would no longer be pulled, which
could cause the CubeSat to eventually deorbit.
V. D ISCUSSION
As with any security evaluation, attack trees are not a perfect
method to assess CubeSat security risks. There are several
 Figure 4. Attack tree for tampering data received from a CubeSat.
limitations to attack tree’s use amidst their benefits. Also,
attack trees offer a starting point to discuss opportunities to
improve system defense and resilience.
A. Attack Tree Findings and Limitations
Not all CubeSats would be rendered useless after such
attacks - especially if they had autonomous network con-
figuration capabilities such as the P-LEO Project Blackjack
constellation. Attack trees are not broadly applicable - an
attack tree for one CubeSat is not likely to be accurate for
another that has different configurations or capabilities. Attack
trees do however offer insights to classes of risks for assets.
Importantly, the attack trees described above are not com-
prehensive and do not reflect all potential attack vectors to
achieve the stated CubeSat attack goals. They also do not
represent the wide variety of potential goals an attacker may
pursue. The three attack goals described are a small sampling
of the creative destruction an attacker can unleash on a
CubeSat system. The attacks discussed in this paper do not
necessarily reflect an increased likelihood for them to occur
over other attacks.
The attack trees discussed provide the space system com-
munity with thoughtful attack plans that could be informative
when considering their CubeSat’s security posture. Despite
their small size, CubeSats are still prone to cyber risks and
developers should be cognizant of these during the design,
launch and operation phases of a CubeSat’s lifecycle.
B. CubeSat Resilience Considerations
CubeSats are developed and launched to achieve a specific
mission. The mission may be one relating to education, dis-
covering new science, or even military applications. Therefore,
mission success is critical for CubeSats - necessitating that
cyber risk management approaches for CubeSats should all
support mission resilience in light of an attack.
The attacks described against CubeSat system communica-
tions, ground stations and space vehicles all had credential
compromise as a common denominator. Given each attack
would have hindered the CubeSat’s mission, it is prudent to
recommend robust credential management techniques includ-
ing dual-factor authentication for CubeSat system resilience.
This would enable an extra layer of challenges for an attacker
to break should credentials be easily discovered or stolen.
Another common attack feature was the single-point-of-
failure for how the CubeSat communicated with the op-
erator. To improve mission resilience, installing a backup
 Figure 5. Attack tree for disabling the CubeSat.
radio antenna (perhaps of a different make and model to
add heterogeneity) and employing a separate transceiver to
engage with the backup radio antenna could be valuable. This
will certainly add cost to the cubesat, but the extra $5,000
could save the roughly $80,000 in cumulative expenses from
components and launch fees.
A lower cost solution to minimize the single-point-of-failure
challenge is to segment the components of the CubeSat so that
they are not all reliant on the same bus. Thereby, should one set
of CubeSat features be compromised, the segmented counter-
part can continue to function properly, potentially preserving
the mission.
While it is not possible to install traditional antivirus soft-
ware on CubeSats, system health monitors that may already
be employed on the satellite could double as security anomaly
detectors. For example, internal thermometers that judge the
health of components could equally be engaged to determine
if the CPU is overheating due to extraneous processing caused
by an attacker running a botnet on the system. This may not
be an architectural security solution, but could help operators
quickly detect issues so that they can be remedied before the
mission is in jeopardy.
None will fully eliminate the cyber risk of operating a
CubeSat, but used together, the suggestions could enable the
resilience of a CubeSat’s mission in the face of a cyberattack.
VI. C ONCLUSION
CubeSat systems, encompassing ground stations, commu-
nication signals and CubeSat space vehicles are prone to
a variety of cyberattacks. The CubeSat attack trees offer
a sampling of the security risks faced by these systems.
Future work requires the dynamic assessment of CubeSat
threat models using automated tools such as AI planners so
that operators can generate security evaluations before launch,
without extensive human resource requirements. Identifying
the attack vectors that can be used to compromise CubeSat
systems will help to inform the CubeSat community of cyber
risks - thereby encouraging developers to design satellites for
mission resilience.
ACKNOWLEDGEMENT
A portion of this research was carried out at the Jet Propul-
sion Laboratory, California Institute of Technology, under a
contract with the National Aeronautics and Space Adminis-
tration (80NM0018D0004). A portion of this research was
funded by the National Science Foundation and the Icelandic
Fulbright Commission.
R EFERENCES
[1] S. W. Asmar and S. Matousek, “Mars cube one (marco) shifting
the paradigm in relay deep space operation,” in 14th International
Conference on Space Operations, 2016, p. 2483.
[2] S. Loff, ““cubesats overview,” NASA, February, vol. 14, 2018.
[3] G. Falco, “Job one for space force: Space asset cybersecurity,” Belfer
Center, Harvard Kennedy School, Belfer Center for Science and Inter-
national Affairs, Harvard Kennedy School, vol. 79, 2018.
[4] A. de Waal Alberts, “The degree of the lack of regulation of space debris
within the current space law regime and suggestions for a prospective
legal framework and technological interventions,” in Space Security and
Legal Aspects of Active Debris Removal. Springer, 2019, pp. 93–106.
[5] G. Falco, “Cybersecurity principles for space systems,” Journal of
Aerospace Information Systems, vol. 16, no. 2, pp. 61–70, 2019.
 [6] C. Spivey and E. Gizzi, “A modular, open source cubesat structure,” in [35] L. Piètre-Cambacédès and M. Bouissou, “Beyond attack trees: dynamic
AIAA Scitech 2021 Forum, 2021, p. 1256. security modeling with boolean logic driven markov processes (bdmp),”
[7] A. Scholz and J.-N. Juang, “Toward open source cubesat design,” Acta in 2010 European Dependable Computing Conference. IEEE, 2010,
astronautica, vol. 115, pp. 384–392, 2015. pp. 199–208.
[8] E. Ackerman, “How nasa designed a helicopter that could fly au- [36] G. Falco, A. Viswanathan, C. Caldera, and H. Shrobe, “A master attack
tonomously on mars,” IEEE Spectrum, 2021. methodology for an ai-based automated attack planner for smart cities,”
[9] B. Nussbaum and G. Berg, “Cybersecurity implications of commercial IEEE Access, vol. 6, pp. 48 360–48 373, 2018.
off the shelf (cots) equipment in space infrastructure,” Space infrastruc- [37] E. M. Hutchins, M. J. Cloppert, R. M. Amin et al., “Intelligence-driven
tures: From risk to resilience governance, pp. 91–99, 2020. computer network defense informed by analysis of adversary campaigns
[10] W. Knowles, D. Prince, D. Hutchison, J. F. P. Disso, and K. Jones, and intrusion kill chains,” Leading Issues in Information Warfare &
“A survey of cyber security management in industrial control systems,” Security Research, vol. 1, no. 1, p. 80, 2011.
International journal of critical infrastructure protection, vol. 9, pp. 52–
80, 2015.
[11] G. Falco, “The vacuum of space cyber security,” in 2018 AIAA SPACE
and Astronautics Forum and Exposition, 2018, p. 5275.
[12] Lockheed Martin, “Lockheed martin and university of southern califor-
nia build smart cubesats, la jument,” PR Newswire, 2019.
[13] T. Hitchens, “Cyber attack most likely space threat: Maj. gen. whiting,”
Breaking Defense, 2020.
[14] J. Pavur and I. Martinovic, “Sok: Building a launchpad for impact-
ful satellite cyber-security research,” arXiv preprint arXiv:2010.10872,
2020.
[15] K. Epstein and B. Elgin, “Network security breaches plague
nasa,” Business Week Online–http://www. businessweek.
com/magazine/content/08 48, 2008.
[16] J. McDowell, “Jonathan’s space report, no. 649,” 2011.
[Online]. Available: https://www.planet4589.org/pipermail/jsr/2011-
October/000021.html
[17] G. Falco, “When satellites attack: Satellite-to-satellite cyber attack,
defense and resilience,” in ASCEND 2020, 2020, p. 4014.
[18] Office of the Inspector General, Office of Audits, “Final report - ig-
19-022 - cybersecurity management and oversight at the jet propulsion
laboratory,” 2019.
[19] A. Ruegamer, D. Kowalewski et al., “Jamming and spoofing of gnss
signals–an underestimated risk?!” Proc. Wisdom Ages Challenges Mod-
ern World, vol. 3, pp. 17–21, 2015.
[20] S. Peterson, “Exclusive: Iran hijacked us drone, says iranian engineer
(video). the christian science monitor,” 2011.
[21] B. C. Barker, J. W. Betz, J. E. Clark, J. T. Correia, J. T. Gillis, S. Lazar,
K. A. Rehborn, and J. R. Straton, “Overview of the gps m code signal,”
in Proceedings of the 2000 National Technical Meeting of the Institute
of Navigation, 2000, pp. 542–549.
[22] T. Cozzens, “Gps military code receives operational acceptance for early
use,” GPS World Magazine, 2020.
[23] U.-C. Economic and S. R. Commission, 2011 Report to Congress of the
US-China Economic and Security Review Commission. US Government
Printing Office, 2011.
[24] A. Viswanathan, A. Santangelo, G. Falco, S. Lee, J. Straub, and
M. Ingham, “Cubesat cybersecurity challenge,” in ASCEND.
[25] Nanosats.eu, “Present status of launched nanosatellites,” 2021.
[26] L. David, “Cubesats: tiny spacecraft, huge payoffs,” Space. com, vol. 8,
2004.
[27] J. O’Brien, “Groundbreaking biofuel rocket could be ’uber for space’,”
BBC News, 2021.
[28] T. T. Office, “Project blackjack,” 2018.
[29] C. Foster, H. Hallam, and J. Mason, “Orbit determination and
differential-drag control of planet labs cubesat constellations,” arXiv
preprint arXiv:1509.03270, 2015.
[30] G. Falco, “Autonomy’s hierarchy of needs: Smart city ecosystems
for autonomous space habitats,” in 2021 55th Annual Conference on
Information Sciences and Systems (CISS). IEEE, 2021.
[31] M. Bradbury, C. Maple, H. Yuan, U. I. Atmaca, and S. Cannizzaro,
“Identifying attack surfaces in the evolving space industry using refer-
ence architectures,” in 2020 IEEE Aerospace Conference. IEEE, 2020,
pp. 1–20.
[32] B. Schneier, “Attack trees,” Dr. Dobb’s journal, vol. 24, no. 12, pp.
21–29, 1999.
[33] T. W. DeLong, “A fault tree manual,” Army Materiel Command
Texarkana TX Intern Training Center, Tech. Rep., 1970.
[34] W.-S. Lee, D. L. Grosh, F. A. Tillman, and C. H. Lie, “Fault tree analysis,
methods, and applications a review,” IEEE transactions on reliability,
vol. 34, no. 3, pp. 194–203, 1985.

View publication stats