Investigating the Effectiveness of Zero–Trust Architecture for Satellite

Cybersecurity

Masrur Masqub Utsash

1 a

, Georgios Kavallieratos

1,2 b

, Konstantinos Antonakopoulos

3,4

and

Sokratis Katsikas

1 c

Department of Information Security and Communication Technology (IIK), Norwegian University of Science and

Technology, Gjøvik, Norway

Department of Technology Systems, University of Oslo, 2007 Kjeller, Norway

Testify SA, Oslo, Norway

Bitrezus PC, Athens, Greece

{ﬁrstname.lastname}@ntnu.no, {ﬁrstname.lastname}@its.uio.no, ka@bitrezus.com

Keywords:

Satellite, Cybersecurity, Zero–Trust Architecture.

Abstract:

The increasing adoption of edge computing platforms poses signiﬁcant challenges to traditional perimeter-

based security architectures. Zero–Trust architecture has gained traction and is now widely utilized as the

preferred security architecture in critical infrastructures. However, even though the advantages of using such

architecture towards improving the cybersecurity posture of satellites have been analyzed, very little has been

done in demonstrating such advantages by experimenting with an implementation of the architecture. In

this paper, we experimentally investigate the effectiveness of Zero–Trust architecture in improving satellite

cybersecurity by analyzing two critical attacks against satellites. We describe the experimental setup and the

experimentation process, and we present and discuss our ﬁndings, that demonstrate that zero-trust architecture

is successful in mitigating attacks that would otherwise disrupt the operations of the satellite.

1 INTRODUCTION

Satellites are leveraged by several critical sectors to

facilitate the provision of services such as earth ob-

servation, communication, and navigation. As of May

4, 2024, there were 3135 satellites dedicated to com-

munication, 1052 for earth observation, and 154 for

navigation, among others (Ieva, 2024). According to

the satellite tracking website ‘Orbiting Now’ there are

10807 active satellites in various Earth orbits as of

September 24, 2024 (Orbiting now, 2024). The emer-

gence of New Space era, and the conﬂuence of sev-

eral challenges, such as the single point of failure sys-

tems, the highly complex supply chain, and the pro-

longed system life cycle, have exposed a unique vul-

nerability: enormous attack-surface and insufﬁcient

focus on the cybersecurity of satellites (Kavallieratos

and Katsikas, 2023). The intricacies and sensitivity

of satellite operations render them prime targets for

malicious actors. Several attacks in space infrastruc-

https://orcid.org/0009-0007-7613-4354

https://orcid.org/0000-0003-1278-1943

https://orcid.org/0000-0003-2966-9683

ture have been reported in the past few years (Black,

2023; Singh, 2023; Corﬁeld, 2023). These incidents

underscore the urgent need to prioritize satellite cy-

bersecurity.

In the face of such evolving cybersecurity land-

scape, the conventional perimeter-based defenses, of-

ten employed in other domains, proves to be inad-

equate for satellites (Syed et al., 2022). This moti-

vates transcending these limitations by introducing a

more robust and adaptive security framework. Zero–

Trust Architecture (ZTA) has gained momentum and

is increasingly emerging as the security architecture

of choice (Rose et al., 2020). This shift is due to

the inherent limitations of perimeter–based security

models, which struggle to adapt to the decentralized

and diverse network landscape of edge computing and

space industry scenarios (Han et al., 2021). As the

space industry increasingly relies on edge computing

platforms, adopting ZTA reﬂects a strategic response

to the evolving threat landscape, enhancing resilience

against cyber threats and protecting critical assets and

infrastructures.

Although several research works have explored

the application of ZTA to secure satellites, its effec-

Utsash, M. M., Kavallieratos, G., Antonakopoulos, K. and Katsikas, S.

Investigating the Effectiveness of Zero–Trust Architecture for Satellite Cybersecurity.

DOI: 10.5220/0013103200003899

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 11th International Conference on Information Systems Security and Privacy (ICISSP 2025) - Volume 2, pages 133-140

ISBN: 978-989-758-735-1; ISSN: 2184-4356

133

tiveness in doing so has only partially been discussed,

let alone demonstrated. The focus of this work is

to experimentally assess the effectiveness of ZTA in

safeguarding the cybersecurity of a satellite. Given

the critical nature of such infrastructure, it is imprac-

tical to use actual, real-world systems for analyzing

cybersecurity attacks, as this could disrupt regular op-

erations. Consequently, specialists often recommend

employing simulation environments that closely re-

semble real-world scenarios. This approach allows

us to understand the potential impact of cybersecurity

attacks on actual infrastructure while maintaining on-

going operations.

The contributions of this work are as follows:

• Propose a ZTA solution for satellite cybersecurity;

• A laboratory environment designed to allow the

implementation of and experimentation with the

proposed ZTA solution towards assessing its ef-

fectiveness against selected cyberattacks;

• Demonstration of the effect that replay attacks and

malicious software injection attacks have on the

operational capacity of a satellite.

The structure of the remaining of this paper is as

follows; Section 2 discusses related work. Section 3

presents our proposal of a ZTA for satellites and Sec-

tion 4 describes the experimental setup, process and

the effectiveness of the proposed ZTA in satellites.

Section 5 summarizes our conclusions.

2 RELATED WORK

There are several approaches in the literature focusing

on the cybersecurity of satellites. Zatti (Zatti, 2020)

analyzed unauthorized operation of satellites, launch-

ers, or ground satellite facilities. Amin et al. (Amin

et al., 2016) identiﬁed two main threats to satellite

communications, namely jamming interference and

spooﬁng attacks. Fowler (Fowler, 2016) discussed

several threats to satellite systems such as unautho-

rized operations, eavesdropping, jamming, hijacking,

and control. Hasan et al. (Hasan and Hasan, 2022)

presented a systematic threat model and security anal-

ysis of a satellite system using the STRIDE technique.

Falco (Falco, 2020) delves into cyber attacks originat-

ing from one satellite and targeting another. Breda et

al. (Breda et al., 2022) focused on the use of artiﬁcial

intelligence (AI) in space operations, focusing on vul-

nerabilities such as lack of transparency, vulnerability

in input data, inherent weaknesses in mathematical

procedures, and the potential for exploitation by ad-

versaries. Unal (Unal, 2019) discussed replay attacks

in space infrastructure considering NATO’s space-

based strategic assets. Falco (Falco, 2018) provided

a comprehensive framework for enhancing security

measures in space infrastructure. NASA (Ofﬁce of

Inspector General, 2021) leveraged the NIST cyberse-

curity framework to deﬁne security controls for their

operations. Baker et al. (Baker et al., 2019) discussed

the security beneﬁts of software-deﬁned networking

(SDN) in space communication networks, focusing

on its elastic networking, resource distribution, and

network conﬁgurability.

The adoption of Zero-Trust security systems in

the space industry is also gaining momentum (Qui-

quet, 2023) (White and White, 2024). Thangavel et

al. (Thangavel et al., 2022) highlighted the advan-

tages of ZTA in space cybersecurity. Protik (Protik,

2023) proposed an updated standard for secure satel-

lite communications and space data systems based on

Zero-Trust. Khamvilai et al. (Khamvilai and Pak-

mehr, 2023) explored the application of Zero-Trust

across various components of complex cyber-physical

systems. Schalk et al. (Schalk and Brown, 2023)

highlighted the advantages of implementing a ZTA

in space network software bus architectures. Fu et

al. (Fu et al., 2022) introduced an architecture and

scheme for continuous authentication in satellite net-

works. Lowdermilk et al. (Lowdermilk and Sethu-

madhavan, 2021) discussed the importance of min-

imizing trust in satellite processors. Driouch et al.

(Driouch et al., 2023) discussed the challenges and

risks of securing new space missions. Gvozdev et al.

(Gvozdev and Vorobev, 2020) highlighted the advan-

tages of a Zero-Trust Network in a multi-satellite sys-

tem for Earth remote sensing. Based on the above

ﬁndings, a research gap on the implementation of a

ZTA solution in a satellite system, towards exploring

its effectiveness in improving the security posture of

the satellite is identiﬁed. This paper aspires to con-

tribute towards partially bridging this gap.

3 A PROPOSED ZTA FOR

SATELLITES

The core features of Zero Trust Architecture (ZTA),

as deﬁned by NIST (Rose et al., 2020), include strict

identity veriﬁcation, least privilege access, micro-

segmentation

, continuous monitoring, endpoint se-

curity, and automated threat detection.This work uti-

lizes the OpenZiti (Ziti) framework, an open-source

project dedicated to integrating Zero-Trust network-

ing principles into any application seamlessly (Open

resources are segmented into smaller, protected zones

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

134

Source Zero Trust Networking, 2023). It offers

a comprehensive toolkit for implementing a Zero-

Trust overlay network

, including controllers, edge

routers

, and fabric routers

. Additionally, Ziti pro-

vides various software development kits (SDKs) to

facilitate the integration of Zero-Trust directly into

applications. It also offers tunneling applications for

granting Zero-Trust access to applications where di-

rect integration is not feasible. As per NIST guide-

lines (Rose et al., 2020), the components within a

ZTA are not always distinct systems. Given the dis-

tinct characteristics of the space system and the ob-

jectives of this work, we have chosen to adopt a hy-

brid approach that combines elements from both the

Device Agent/Gateway Model and the Resource Por-

tal Model. In this setup, the PEP functions as a

singular gateway through which all subject requests

pass, while our assets utilize a device agent to estab-

lish connections with the gateways. This hybrid ap-

proach to ZTA offers a secure method for implement-

ing Zero-Trust in our experimental setup, described in

the next section.

4 EXPERIMENTAL SETUP

In the experimental setup (Figure 1), the components

in green represent the elements and entities within

the Zero-Trust environment, while the components in

red represent the outsider entities. This facilitates the

clariﬁcation of the boundaries of the ZTA and high-

lights the different roles and interactions of each com-

ponent within the experimental setup.

Figure 1: Experimental Setup.

We established a Zero Trust design setup with

multiple computers on the same network. A Kali

Linux computer represents the satellite and runs the

state machine. This machine is the primary target for

ensures the characteristics of zero-trust for every com-

ponent no matter where they are on the network

secures trafﬁc between internal and external systems

by verifying identities and enforcing access controls

securely manages trafﬁc between devices by ensuring

all connections are authenticated and authorized

both the attacker and the security mechanisms. An-

other Kali Linux computer is used to deploy our Zero-

Trust solution enabling the Policy Enforcement Point

(PEP) and acting as the gateway through which all

connections to the satellite must pass, as part of the

ZTA. This machine also houses the policy engine and

the policy administrator, allowing it to control all net-

work trafﬁc as a single gateway point. At the bot-

tom right of the ﬁgure, a Windows 11 client is used

by the authorized user as a mission operation termi-

nal. The client is equipped with all necessary agents

and certiﬁcates to securely access the satellite within

the Zero-Trust network. A Kali Linux machine is uti-

lized as the attacker due to its extensive pre-installed

penetration testing tools. This simpliﬁed, yet compre-

hensive, setup allows us to simulate a space mission

operation center where both legitimate and malicious

activities are executed. This provides a robust envi-

ronment to test the effectiveness of our Zero-Trust de-

sign.

4.1 The Zero-Trust Network

Establishing a connection to the satellite is possible

either directly or via a ground station. Accordingly,

our experimental setup involves two distinct scenar-

ios. In the ﬁrst scenario, we anticipate direct com-

munication between the clients and the satellite. The

second scenario assumes communication between the

clients and the satellite through the ground station.

In this section, we outline the network models for

both scenarios. The conﬁguration of the network is

achieved by leveraging several computer devices run-

ning different operating systems to create an environ-

ment closely resembling real-world conditions.

Figure 2 illustrates the network architecture for

communication with the satellite via the Ziti overlay.

In this setup, a Windows 11 client establishes a con-

nection to the Ziti Controller through the Ziti Desk-

top Edge using a tunneler. Simultaneously, the satel-

lite environment, simulated on a Kali Linux machine,

is connected to the Ziti Controller through another

tunneler. This conﬁguration enables direct commu-

nication between the client and the satellite environ-

ment facilitated by the Ziti overlay network. The in-

ternal communication between these components uti-

lizes the standard TCP protocol.

Figure 3 depicts the network architecture where

clients must communicate with the satellite through

the ground station. In this setup, the Ziti Controller is

deployed at the ground station, facilitating the con-

nection between the clients and the satellite. The

satellite is linked to the ground station through a

dedicated edge router connection (OpenZiti virtual

Investigating the Effectiveness of Zero–Trust Architecture for Satellite Cybersecurity

135

Figure 2: Client-satellite communication network.

router) assuming that the spacecraft has the capabil-

ity to switch between authorized ground stations. Ad-

ditionally, a public edge router is established to al-

low authorized entities to access the ground station

and communicate with the satellite. This conﬁgura-

tion ensures secure and controlled communication be-

tween clients and the satellite via the Ziti overlay net-

work through the ground station. The edge routers are

equipped with Ziti capabilities and are registered as

distinct router entities via the Ziti console. They en-

able connections with the Ziti controller at the ground

station via a tunneler, thereby creating a secure com-

munication channel for all established connections. In

a real-world operational environment with real satel-

lites running in orbit and having ground operations,

the CCSDS (Consultative Committee for Space Data

Systems) Space Packet Protocol

would be used.

Since for this work we use an IP-network of emu-

lated satellites, communications utilize the standard

TCP protocol.

Figure 3: Client-satellite communication network through

ground station.

4.2 Deploying Openziti

The ﬂexibility of the OpenZiti solution has signiﬁ-

cantly facilitated our experiment by providing all the

necessary options to create and maintain the compo-

nents of our chosen ZTA. For this work, a local envi-

ronment is using Kali Linux with 8 vCPU cores and

16GB of RAM.

https://public.ccsds.org/Pubs/133x0b2e1.pdf

4.3 Deﬁning the State Machine

A state machine can effectively portray the activities

of a satellite. In our state machine, we have outlined

several states to signify both the operational health

status of the satellite and its mission-related activities.

The state machine initiates at an initial mode and con-

cludes with the de-orbit mode. Each state represents a

speciﬁc condition or stage in the satellite’s operation,

and transitions between states occur based on prede-

ﬁned events or conditions. The state machine changes

its state upon receiving valid event commands, other-

wise the satellite disregards the command.

Figure 4: State machine for satellite.

Concerning Fig. 4, we start at the Initial Mode

state, the starting point for our system’s journey. As

the system switches to the Active/Orbit Mode, rep-

resenting regular operational state, like when a satel-

lite is smoothly orbiting Earth, performing its tasks.

However, if something goes wrong, like a glitch or

malfunction, the system enters Error Mode, similar

to when any device malfunctions or displays an er-

ror message. In such cases, the system shifts to

Safe Mode, a protective fallback, shutting down non-

essential functions to maintain stability. For our satel-

lite, this might involve conserving power or reducing

activity. Eventually, when the mission concludes or a

critical problem arises, the system moves into DeOr-

bit Mode, facilitating a graceful exit strategy, like, for

example, concluding the orbit and returning the satel-

lite safely to Earth. In this setup, we assume that the

attacker will primarily target the active/orbit mode, as

this represents the regular state of a satellite.

4.4 Attacks

The Space Attack Research and Tactic Analysis

(SPARTA)

framework provides information on Tac-

tics, Techniques, and Procedures (TTP) that may be

used to compromise spacecraft. In this work, we con-

ducted further analysis to prioritize risks by employ-

ing a simpliﬁed 4x4 risk matrix (Figure 5), compared

to the more detailed approach used by Bailey in the

SPARTA framework

. Further threat and risk descrip-

https://sparta.aerospace.org/

https://aerospace.org/paper/cybersecurity-protections-

spacecraft-threat-based-approach

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

136

tions for the risk matrix (Figure 5) can be found in

(Bailey, 2022).

Figure 5: 4x4 risk matrix for ranking cyber threats.

In our analysis, we assigned to each threat a likeli-

hood of occurrence score ranging from 1 to 10. Addi-

tionally, we used an impact score, also ranging from

1 to 10. The likelihood score assessed the probability

of the threat occurring based on factors like histori-

cal trends, system vulnerabilities, and the resources

needed for the attack. The impact score measured

the potential damage the attack could cause, including

operational disruption, ﬁnancial losses, data breaches,

and overall disruption of space mission. The accor-

dant risk value is estimated based on the formula: Risk

Score = Likelihood score × Impact score. This work

focuses on the most critical attacks as these are iden-

tiﬁed in the aforementioned analysis. These are; (1)

Replay of recorded authentic communications trafﬁc

at a later time with the hope that the authorized com-

munications will provide data or some other system

reaction, and (2) Introduction of malicious software

such as a virus, worm, Distributed Denial-Of-Service

(DDOS) agent, rootkit, or Trojan Horse.

4.4.1 Replay Attack

Figure 6: Attack Model: Replay Attack.

We assume a scenario where an attacker intercepts

a genuine command intended to alter a state within the

satellite, as depicted in Figure 6. In this experiment,

we are using tools like Wireshark

and Ettercap

for

Wireshark: https://www.wireshark.org/

Ettercap: https://www.ettercap-project.org/

snifﬁng and capturing original communication pack-

ets. For sending the packet back to the satellite we

are using tcpreplay

. To simulate a replay attack on

a satellite system, we followed a structured approach

as outlined in Figure 7.

Figure 7: Replay attack simulation steps.

Initially, we assume that the Zero-Trust approach

is not yet implemented and the attack is simulated by

trying to capture communication between the satel-

lite (Kali Linux state machine) and the windows client

computer. In the controlled environment, the infras-

tructure for implementing the attack involved setting

up various software tools on our testing machines. In

a real-world scenario, this preparation phase would

also include procuring the necessary hardware com-

ponents, such as antennas and other communication

devices, to target the satellite.

Next, a speciﬁc satellite is targeted for the at-

tack, represented by a state machine running on a Kali

Linux computer. The attacker gathers information to

target the satellite, scanning the network to identify

connected components. Using Ettercap, we launch

a man-in-the-middle (MITM) attack, placing the at-

tacker’s computer between the satellite and the client

to capture trafﬁc in real-time. Wireshark is used to in-

tercept and store data packets during communication.

We then modify the captured packets with a Python

script, changing any ’event’ variable to ’error’ and

saving the altered packet. The modiﬁed packet is sent

back to the satellite using the rcpreplay command. In

this controlled environment, we capture packets for

10 seconds, ensuring at least one event command is

intercepted and modiﬁed before being resent to the

satellite.

After executing the replay attack, we observed the

following results. Initially, the state machine was

operating in the active/orbit mode. However, upon

launching the replay attack, the state machine tran-

sitioned to the error mode. This experiment demon-

strates that such an attack can effectively compromise

the satellite’s operational state, leading to mission dis-

ruptions. The response to a replay attack can vary de-

pending on the sent command and the current state of

Tcpreplay: https://github.com/appneta/tcpreplay

Investigating the Effectiveness of Zero–Trust Architecture for Satellite Cybersecurity

137

our state machine representing the satellite. Follow-

ing the successful execution of the attack in a non-

ZTA environment, we proceeded to test the same at-

tack within a Zero-Trust environment. The simulation

steps are depicted in Figure 8.

Figure 8: Replay attack simulation steps with Zero-Trust

implemented.

The initial steps - preparing the infrastructure, tar-

geting the satellite, setting up snifﬁng tools, and cap-

turing packets - were conducted as before. How-

ever, due to the data encryption inherent in the ZTA,

the captured packets could not be analyzed or modi-

ﬁed. Despite this, we attempted to resend the origi-

nal captured packet to the state machine, to determine

whether it would cause some disruption within the

satellite system. Once again, the ZTA proved its ef-

fectiveness. As the external attacker lacked a speciﬁc

agent necessary for communication within the Zero-

Trust environment, the packet could not be delivered

to the state machine. During the attempt to send the

modiﬁed packet, the PEP tried to verify the identity of

the attacking computer and could not ﬁnd any valid

certiﬁcate; as a result the PEP disregarded the con-

nection request. As an attacker, we also tried to by-

pass this issue by capturing the communication packet

with the certiﬁcate. While trying to replay the com-

munication of the authentication command, the PEP

tried to validate the certiﬁcate and could not match

the entity with the already enlisted entities within the

Zero-Trust network, eventually disregarding the con-

nection request. Consequently, no changes occurred

in the state transition, and the state machine remained

in its original state. This result demonstrates the ro-

bustness of ZTA in preventing unauthorized access

and maintaining the integrity of the satellite’s oper-

ational state.

4.4.2 Malicious Software Injection Attack

We assume a scenario where an attacker sends a ma-

licious script to the satellite (Fig. 9). Our primary

objective was to explore the feasibility and relevance

of employing a malicious software injection attack

against a satellite. We aimed to identify an approach

that would not only be impactful but also pertinent to

the unique challenges of securing space systems.

Figure 9: Attack Model: Malicious Software Injection At-

tack.

By focusing on this speciﬁc type of attack, we

sought to gain insights into both its potential impact

and its practicality within the satellite landscape. We

used an online resource named fakelib.sh

. Fake-

lib.sh (Bl

azquez, 2021) is a streamlined tool designed

for generating Linux shared libraries, particularly for

use in library hijacking scenarios. It enables the

creation of empty libraries with embedded payloads,

which can be executed using LD PRELOAD. Though

fakelib.sh was originally developed for research and

practice purposes for strengthening the security pos-

ture, it could be used in real-life by the attacker to pur-

sue malicious objectives. This tool operates by ana-

lyzing a shared library binary, extracting its functions

and symbols, and subsequently generating another li-

brary that closely resembles the original one. How-

ever, this fabricated library contains a payload spec-

iﬁed by the user. For employing the fakelib.sh tool,

we initially analyze the library ﬁles using readelf

Readelf is a versatile command-line tool used for dis-

playing detailed information about ELF (Executable

and Linkable Format) ﬁles, which are commonly used

for executables, object code, shared libraries, and core

dumps in Unix-based systems. To simulate this at-

tack, we followed the procedure outlined in Figure 10.

Figure 10: Malicious Software Injection attack simulation

steps.

Initially, from the attacker’s machine, we sent the

fakelib.sh script to the Kali Linux computer repre-

senting the satellite. We then analyzed the library

ﬁles to identify the most suitable target for the attack.

fakelib: https://github.com/eblazquez/fakelib.sh

readELF: uxhint.com/readelf-linux-command/

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

138

After selecting the library ﬁle, we analyzed the exe-

cutable in order to identify its functionalities and ex-

tract function names, utilizing the readelf command.

Fakelib.sh offers attackers the capability to designate

a speciﬁc function as the injection point, where the

payload code will be inserted. The attacker retains

the ﬂexibility to select an appropriate function for in-

jecting their malicious code. The fakelib.sh script

offers multiple execution options, including a basic

echo command, running code in a shell environment,

or executing custom shellcode. For our experiment,

we used the echo command to demonstrate the poten-

tial for injecting and executing malicious code. We

selected a target library ﬁle and executed the fake-

lib.sh script to duplicate the original library, embed-

ding the malicious code. The script allows for either

overwriting an existing library or creating a duplicate

in a different directory; we chose the latter for greater

control and evasion of detection. We blocked the orig-

inal ﬁle path and introduced the path to the malicious

ﬁle, ensuring its use during program execution. The

attack was conﬁrmed to be successful by the execu-

tion of the injected echo command, validating its ef-

fectiveness in compromising the satellite system.

In a separate test scenario, the injection of mali-

cious code resulted in the corruption of the executable

ﬁle of our state machine. This outcome underscores

the potential real-world risk wherein an attacker could

disable a satellite. After successfully executing the

attack, we proceeded to evaluate the effectiveness of

Zero-Trust in securing the satellite by simulating the

same attack scenario within a Zero-Trust environment

(Figure 11).

Figure 11: Malicious Software Injection attack simulation

with Zero-Trust implemented.

In attempting to execute the same attack within

the Zero-Trust environment, we encountered a signif-

icant barrier at the very ﬁrst step i.e., when sending

the fakelib.sh script to the satellite environment. Since

the attacker’s computer is an external entity within

the Zero-Trust environment and lacks authorization

with a speciﬁc agent to communicate with the envi-

ronment, the script could not be delivered to the satel-

lite. During the attempt to send the modiﬁed packet,

the PEP tried to verify the identity of the attacker

computer and could not ﬁnd any valid certiﬁcate; as

a result the PEP disregarded the connection request.

To further test the robustness of the Zero-Trust so-

lution, we attempted to bypass this restriction by as-

suming that the script could be sent to the satellite

through an exploited connection via the ground sta-

tion. In this scenario the ground station also refused

the connection of the attacker as the ground station

is also secured within the Zero-Trust environment.

However, due to the micro-segmentation inherent in

the Zero-Trust environment, it was impossible to an-

alyze the existing ﬁle system, thus preventing the ex-

ecution of fakelib.sh as the target library could not be

deﬁned. Consequently, no modiﬁcations were made

to the original library ﬁle, and no malicious ﬁle was

created. As a result, when the program was executed,

it utilized the original library ﬁle, rendering the attack

unsuccessful.

5 CONCLUSIONS

The increased reliance of everyday, often critical, ser-

vices on satellites brings both enormous beneﬁts, at

the cost of serious cybersecurity risks. In this work

we explored how ZTA can be effectively implemented

to enhance cybersecurity in satellites. We proposed a

ZTA-based solution and developed a controlled envi-

ronment using multiple computers on the same net-

work to simulate a satellite system in order to exper-

imentally assess its effectiveness. We experimentally

demonstrated that the proposed solution constitutes a

robust framework for addressing security challenges

and effectively mitigates two types of critical attacks.

Thus, our approach to ZTA has promising potential

to secure satellites. In future work, we will explore

the implementation of Zero-Trust principles in satel-

lite constellations to ensure comprehensive security

across the entire network and all connected satellites.

REFERENCES

Amin, M. G., Closas, P., Broumandan, A., and Volakis, J. L.

(2016). Vulnerabilities, threats, and authentication

in satellite-based navigation systems [scanning the is-

sue]. Proceedings of the IEEE, 104(6):1169–1173.

Bailey, B. (2022). Cybersecurity Protections for spacecraft:

A Threat Based approach — The Aerospace Corpora-

tion.

Baker, D. Z., Liu, H., and Roberts, C. (2019). Ensuring

ﬂexibility and security in sdn-based spacecraft com-

munication networks through risk assessment. In 2019

IEEE International Symposium on Technologies for

Homeland Security (HST), pages 1–6. IEEE.

Black, D. (2023). Japan’s JAXA space agency

Investigating the Effectiveness of Zero–Trust Architecture for Satellite Cybersecurity

139

admits cyberattack. Cybernews. url:

https://cybernews.com/news/japan-jaxa-space-

agency-cyberattack/, Accessed: 24-09-2024.

azquez, E. (2021). GitHub - fakelib.sh: Simple

tool/script for generating malicious Linux shared li-

braries. url: https://github.com/eblazquez/fakelib.sh,

Accessed 24.09.2024.

Breda, P., Markova, R., Abdin, A., Jha, D., Carlo, A., and

Mantı, N. P. (2022). Cyber vulnerabilities and risks of

ai technologies in space applications. In 73rd Interna-

tional Astronautical Congress (IAC), Paris, France.

Corﬁeld, G. (2023). Russian spy agencies

targeting Starlink with custom malware,

Ukraine warns. The Telegraph. url:

https://www.telegraph.co.uk/business/2023/08/12/russian-

spy-agencies-targeting-elon-musk-starlink-malware/,

Accessed: 24-09-2024.

Driouch, O., Bah, S., and Guennoun, Z. (2023). A holistic

approach to build a defensible cybersecurity architec-

ture for new space missions. New Space, 11(4):203–

218.

Falco, G. (2018). The vacuum of space cyber security. In

2018 AIAA SPACE and Astronautics Forum and Ex-

position, page 5275.

Falco, G. (2020). When satellites attack: Satellite-to-

satellite cyber attack, defense and resilience. In AS-

CEND 2020, page 4014.

Fowler, B. W. (2016). Cyber vulnerabilities in space sys-

tems. PhD thesis, Utica College.

Fu, P., Wu, J., Lin, X., and Shen, A. (2022). Ztei:

Zero-trust and edge intelligence empowered continu-

ous authentication for satellite networks. In GLOBE-

COM 2022-2022 IEEE Global Communications Con-

ference, pages 2376–2381. IEEE.

Gvozdev, O. and Vorobev, V. (2020). The concept of in-

formation infrastructure of a multi-satellite system for

earth remote sensing. International Multidisciplinary

Scientiﬁc GeoConference: SGEM, 20(2.2):275–283.

Han, R., Bai, L., Jiang, C., Liu, J., and Choi, J. (2021). A

secure architecture of relay-aided space information

networks. IEEE Network, 35(4):88–94.

Hasan, R. and Hasan, R. (2022). Towards a threat model and

security analysis of spacecraft computing systems. In

2022 IEEE International Conference on Wireless for

Space and Extreme Environments (WiSEE), pages 87–

92. IEEE.

Ieva (2024). How Many Satellites are in

Space? Kongsberg nanoavionics. url:

https://nanoavionics.com/blog/how-many-satellites-

are-in-space/, Accessed: 24-09-2024,.

Kavallieratos, G. and Katsikas, S. (2023). An exploratory

analysis of the last frontier: A systematic literature re-

view of cybersecurity in space. International Journal

of Critical Infrastructure Protection, page 100640.

Khamvilai, T. and Pakmehr, M. (2023). Zero trust avion-

ics systems (ztas). In 2023 IEEE/AIAA 42nd Digi-

tal Avionics Systems Conference (DASC), pages 1–8.

IEEE.

Lowdermilk, J. and Sethumadhavan, S. (2021). Towards

zero trust: An experience report. In 2021 IEEE Se-

cure Development Conference (SecDev), pages 79–85.

IEEE.

Ofﬁce of Inspector General (2021). NASA’s Cyber-

security Readiness. Report IG-21-019 (A-20-009-

00), National Aeronautics and Space Administra-

tion. url: https://oig.nasa.gov/docs/IG-21-019.pdf,

Accessed 24.09.2024.

Open Source Zero Trust Networking (2023). Open-

Ziti - Open Source Zero trust Networking.

url:https://openziti.io/, Accessed 24.09.2024.

Orbiting now (2024). Active Satellite orbit data. Orbiting

now. url: https://orbit.ing-now.com/, Accessed: 24-

09-2024.

Protik, R. C. (2023). Updated standard for secure satellite

communications: Analysis of satellites, attack vec-

tors, existing standards, and enterprise and security ar-

chitectures. arXiv preprint arXiv:2310.19105.

Quiquet, F. (2023). Reaching for the Stars with Zero Trust:

Space Domain Applications.

Rose, S., Borchert, O., Mitchell, S., and Connelly, S.

(2020). Zero trust architecture. NIST Special Publica-

tion 800-207, National Institute of Science and Tech-

nology.

Schalk, A. and Brown, D. (2023). Detection and mitigation

of vulnerabilities in space network software bus archi-

tectures. In 2023 IEEE Aerospace Conference, pages

1–10. IEEE.

Singh, K. J. (2023). The ﬁrst satellite hacking by

Russian hackers to Ukraine. Linkedin. url:

https://www.linkedin.com/pulse/ﬁrst-satellite-

hacking-russian-hackers-ukraine-kamal-jeet-singh-

jjdic/, Accessed: 24-09-2024,.

Syed, N. F., Shah, S. W., Shaghaghi, A., Anwar, A., Baig,

Z., and Doss, R. (2022). Zero trust architecture (zta):

A comprehensive survey. IEEE Access, 10:57143–

57179.

Thangavel, K., Plotnek, J. J., Gardi, A., and Sabatini, R.

(2022). Understanding and investigating adversary

threats and countermeasures in the context of space

cybersecurity. In 2022 IEEE/AIAA 41st Digital Avion-

ics Systems Conference (DASC), pages 1–10. IEEE.

Unal, B. (2019). Cybersecurity of NATO’s Space-based

Strategic Assets. Chatham House. The Royal Institute

of International Affairs.

White, E. and White, E. (2024). A zero-trust approach to

space cybersecurity could be the answer.

Zatti, S. (2020). Space and cyber threats. Handbook of

Space Security: Policies, Applications and Programs,

pages 245–263.

ICISSP 2025 - 11th International Conference on Information Systems Security and Privacy

140