Hi, my name is Brandon Bailey. I work within the Cybersecurity Subdivision at the Airspace
Corporation and we're excited to be here today in conjunction with the Space ISAC and the
Airspace Village to be discussing the topic on some spacecraft research that we've been
working on specifically related to exploitation of some of the implementations upon the spacecraft.
So we'll jump right into it. I would like to refer people to the paper linked in the front
for more information about how you can apply certain cybersecurity controls for a spacecraft.
So from an introduction perspective, when you look at vulnerabilities in information systems,
particular satellites, they're often overlooked in the wider discussions when you talk about
critical infrastructure, but that's changing quite rapidly currently where there's a lot more
people discussing spacecraft vulnerabilities, ground system vulnerabilities, and how it relates
to our critical infrastructure as a country. So there's been a lot of misunderstanding and
somewhat complacency in this regard because there's been a lack of real-life events that's
known in the public space of attacks against space vehicles. But the space systems are similar to
other systems. One that you would kind of know about is the industrial control systems or
operational technology field. So you see some good parallels that can be drawn between the spacecraft
and the space systems arena with that. So malicious insiders, external threats,
splotching threats, those are all various threat factors that people can get in to affect
spacecraft from the sensors to the data being uplinked or downlinked. So there's a lot of
different areas where you could have impact that could disrupt military, government,
or even commercial activity for our day-to-day activities. So the threats are changing quite
rapidly in this arena. So there's a lot more knowledge about space and things of that nature.
And then when they would have happened, there'd be an absence of warning. So you know there's
not real-time consistent communication between ground and space a lot of times. So
there could be times where you're not aware that there's attacks ongoing. And attribution is
difficult in the IT world and it's even more difficult in the space world. And there definitely
needs to be more research in this area. And that's one of the reasons why we're
presenting this material. And I'm assuming one of the reasons why the Aerospace Village
exists is because there's a lot more collaboration and research that needs to happen
in this arena. And the CubeSat arena is just exploding as we all know. And the barrier to
entry into space is being reduced quite extensively. So the good thing is in recent years there's been
some open source technology that's been put out there that can help people learn more about space,
space protocols, things like that. So Cosmos, which is linked here, NASA's CoreFlight executive
or CoreFlight software, OpenSatKit was put out by NASA to help people get started with CubeSats.
NOS3 was put out by NASA's Independent Verification and Validation Program to help people build
simulators for space. So there's a lot of good open source material out there now. So people
can actually start researching this for themselves, which is great. But I will caveat that with
one thing is please change your default configs if you're pulling the CoreFlight executive or
CoreFlight software from GitHub and running it accordingly. You want to make sure that
you can change those default configs. So let's move on to some basics. So for people who aren't
necessarily living and breathing space communications and commanding and telemetry
and that terminology, here's just an introduction slide to kind of explain what we're talking about.
Command and Data Handling or referred to as CDH is essentially how data is relayed to and from
the spacecraft. So that's where the encoding and decoding happens for the commands and the
telemetry. There's kind of generically four pieces of a space system. You have the user
terminal where you do the commanding and the telemetry and process telemetry that runs
the ground software. There's some sort of front-end processor that does the conversions of the
information from the ground system to get it connected to a modem or an antenna that you can
send the information to the spacecraft and get it back down. So from a cyber perspective,
the attack surface is quite large because there's a lot of standard IT equipment in there. You know,
like with the ground terminals, the front-end processors, there's a lot of operational
technology, industrial control systems that operate within these facilities that run these
systems or control the antennas. And of course the RF link is the obvious one. So something to
note on this diagram is the bulk encryption component is kind of left out for people that are
more accustomed to satellite communication where you have cryptos on each end. So I left that out
just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle.
And this is just a quick animation of kind of what this looks like where
the user would say turn this heater on and then the software translates that to some, you know,
hex numbers and then it gets converted by the front-end processor to get framed appropriately
and sent to the modem to get modulated up to the bird and back down. So that's just a simple
animation to kind of articulate what we're talking about here. And slide five here is something, a
paper that was put out by NASIC, the National Air and Space Intelligence Center, which is a pretty
good resource if you want to understand the high-level architecture of space systems and
where cyber threats could have an impact and the types of cyber threats there are. So
in this diagram it's basically just outlining that you have the user segment where you have the
the ground software terminals and then the interacts with the ground segment where you
have the antennas at times or in the link segment with the RF and the space segment for space. So
vulnerabilities exist in all these segments and there's cyber threats within all these segments.
Obviously, you know, the user segment is the highest likelihood for a cyber attack given
that it may have some level of internet connection where it's operated by people and
we understand as being a security researchers or pin testers or red teamers that the people
are generally the weakest link in the cyber paradigm. So the user segment is one of the easier
areas to get in. But we're going to focus more on the space segment and the link segment
specifically because that's where there's less research and less publicized information. So we're
going to focus on three types of attacks today with some demonstration screenshots and to discuss
how they work, what they are, and how you can mitigate these things. So we're going to talk
about a replay attack, which is where you record the command signal and replay it to the vehicle
and see if it processes it. So we'll do that and we'll talk about command link intrusion where you
basically simulate modulating your own signal to a satellite and seeing if it processes
those commands. And then we'll do a denial of service where you could do some GPS jamming
to maybe cause the denial of service condition on a satellite depending on the implementation
for the satellite. So we'll jump in to the command replay first and discuss that attack
vector. So in the real world, which is not what we're operating with this demonstration, we're
operating within simulation, but in the real world you have your ground terminals antenna that
sends a RF signal to a satellite. So in the real world, if you were to do a command replay attack,
you would need some sort of sniffing device to sniff the RF signal from the ground antenna
while it's transmitting the uplink to the satellite. Well, in our simulated world,
because we're using some high fidelity simulation capabilities that have been built that we can use
simply UDP gets translated from the antenna to the satellite. So we're not,
you know, sending RF signals from a ground station to a simulated satellite. Although you could do
that, but for our purposes, we're going to use a simulator that just essentially takes the
TCP IP traffic from the front end processor and then it translates it to UDP and then sends it
to a spacecraft simulator that's running. So if we're doing that with UDP, then we can obviously
use something as simple as TCP for our research. So that's, that's, that's kind of how we're set
up. So this is the simulator that we're using, and it's, it's got some real components to it.
That's, you know, runs in operations today for various missions that are flying. So
there's a ground software component, there's a front end processor, there's the ground station
sim that is used to translate the information to UDP, and then that sends it to the spacecraft
that has a dynamic simulator with it. So we're using real ground software in this simulation.
We're using real front end processor software. None of these have been modified. They're using
the same software baselines as operational missions are using. It uses the same communication
protocols, CCSDS, TC and AOS. So you can google those if you want to learn more about it. We'll
get a little bit more into that detail later. But we aren't using any type of encryption,
so there's no point-to-point encryption or bulk encryption anywhere in this.
And we'll explain why, because that's the point of the demonstration is to show when you don't
have encryption what can happen. We have some real flight software that runs on several operational
missions currently, but it's cross-compiled for Linux. So it's not running on an embedded
processor, a power PC, or an arm, or some FPGA. It's running just in Linux for our purposes,
because we're just focused on the software testing at this point and not being too high fidelity.
But there are technologies that exist where you can get super high fidelity, and we've used those
in the past for several things. Things like Simix, or QEMU, or TCM. These are different
technologies that you can use to have higher fidelity simulations to run software compiled
for target. So those can be integrated in these simulators as well. So the ground station sim is
kind of what mimics the RF transmission for us, but for us it just translates to UDP as I said
earlier. So there's a simulation that's out there called 42 that's put out by NASA that helps do the
attitudes, orbit dynamics, and environmental models. So that helps us understand the orbit
and how we're progressing there. So here we go. And you can build your own one of these
with some sources from GitHub. So these are linked here, OpenSATKit and NOS3 have some great
components that you can construct something similar for yourself.
Okay, so for our specific demonstration for command replay, our satellite in this scenario
orbits the earth and is scheduled to uplink, downlink when it's over top of three different
ground sites. One in California, one in Spain, one in Australia. So one would be Australia's in
Canberra, Spain, Madrid, California, out near LA. So the point of our demonstration is we're going to
capture the UDP traffic with TCP dump as it's leaving the ground station during the uplink pass.
So this mimics an RF sniffing capture. And then we're going to replay that with TCP replay. So
we did a quick, you know, Google search on the internet looking for what type of hardware and
technologies needed to reproduce this type of an attack in real life. And basically it's
around $7,000 and you could get some equipment that could record, capture, and transmit signal
to a lower orbit. So it's definitely achievable for, you know, people who have a little bit of
money. But then with the advent of some of these new technologies that are coming out today, like
AWS Ground Station, the barrier could be much lower. So you may not need so much equipment,
you may need sniffing capabilities, but we're a little unsure on what practices are going to be
in place for AWS in the future. So to prevent, you know, these type of things from happening. But
with that being said, it's just trying to articulate that the barrier for doing, you know,
communications to a vehicle is getting less and less. Okay, so setting up the attack. So
in our simulation, the satellite is visible to the ground station over the Madrid ground station. So
it's there. And then in the bottom middle here, you see a signal lock in that window, it says,
okay, it's locked, it's acquired. So it's sending the connect message, and then it's uplinking the
command. So you see several commands being transmitted. You know, that's a bunch of
numbers there. But what that does is you look in the far right, you see the flight software
that's running. That's the, you know, that's kind of like the UART window of a flight software,
where you have the flight software responding. You see it processes these NOOP commands. So
in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know,
in our terminology. So just to see if the application running on board is alive. So
upon receiving that command, the flight software indeed does process that command and downloads
the event messages, and the command counters increment. So you see here in the ground,
you see that the event messages are processed. It says, hey, there was a NOOP command, and it's
downlinked to the ground. And then you see the command counters increment accordingly. So you
see that the CMDPC, which is short for command processed, for each of those applications that
were sent commands processed to increment to one was zero. So it goes to one. Now the satellite
in our scenario is in transit between Madrid and Canberra. And you see in the ground station
simulation that it's lost signal. So it's no longer in view. So now here's where we could actually
do our replay attack. So in a real world scenario, you would need equipment, obviously, in the Madrid
area to capture the RF traffic. And then somewhere over India, in this example, you would need
transmit capability to be able to send transmit the information to the satellite. So in our
scenario, it's a lot easier, obviously, because we're using just the TCP replay. And here's just
a simple command. It replays the PCAP file that was captured. And then you see the flight software
respond accordingly with the same event messages within the UART. But what you don't
see is any event messages on the ground station because you were in between passes at that point.
And the command counters, you notice when you establish the downlink again over Canberra that
the command counters went up. So the flight software is reporting, hey, I received another
command and, you know, in between ground passes, which would be odd. So from a, you know, defensive
cyber operations perspective on the ground or, you know, C&D perspective, if you're not
monitoring certain key telemetry points on your vehicle, you may not be aware that, you know,
someone has tried to make a connection or send commands. So it's very important to understand
what the telemetry values are that you could be monitoring that could provide you insight
into potential attack vectors. So there's a lot of telemetry points out there that could help with
that. So that wraps up the command replay. So essentially what we did was capture the command
link up and then we replayed it and we saw that it processes. So we'll move on to command
link intrusion, which is a little bit different. It's a slight different take on a command
command link attack. So since there's no encryption in our environment, our simulated
environment here, and there's no authentication, theoretically, the thought was, well,
if you just inspect the traffic and understand the packet structure and understand
what information is in there, theoretically, you could craft your own packet that matches that
structure and just send it up and see if it processes the command. So you're not really
replaying anything. You're just constructing your own raw command packet and then uplinking it and
seeing what happens. So let's try that out and see how it works. So once you've inspected the
traffic and understand there's no encryption, you see in one of the telemetry values, and you
can obviously do this with RF as well. You can record the RF on the downlink and record it as
well. But you see, once you have the information and you see here in the middle, you see CFE,
TBL, NOOP, CFE version 6.6.0.0. So you see that information there and that implies that they're
using CoreFlight executive or CoreFlight software. And so then you can say, well, that's available on
GitHub, I believe. So this is where that comment about default configs really comes into play.
So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol. So then you get
into this research study on command packet structures, which is a fun study.
I would not recommend it for people if they're not really interested in it because
it's a little bit of a read. So we're looking, we start to break down how
these systems work from a protocol perspective. So we have space packets and then we're
gonna get into some really space buzzword bingo here. So I apologize for that. But for the people
who know what this is, you'll get it. But for the people who don't know, forgive me
for kind of speaking in this lingo, but the space packets get wrapped in these transfer frames
and then the transfer frames are wrapped in what's called these command link
transmission units, CLTUs. So that's kind of how this structure works is CLTU, transfer frame
headers, space packet, and then the trailers. So then we start looking in the CCSDS protocol
and we understand, okay, this is the space packet. These are the octets that are there.
And then we start really diving into some of these documents and we say, okay, well, this is
what the primary header is. This is what a transfer frame looks like. This is what the transfer frame
primary header looks like. This is what the CLTU looks like. And then so we're kind of in this
overload of terminology, protocol breakdown, things like that. So it gets a little cumbersome
and confusing, but it's important to understand all these things. And it's also important to
realize that these protocols are open source protocols. So a lot of the, a lot of missions,
spacecraft that are out there today, leverage CCSDS because that is an international standard
that the CCSDS group is a consortium of many space agencies from across the world who get
together and standardize on protocols and things like that. So it's easy. You just kind of, you
can just Google the standards and find them and they'll have these diagrams in there and you can
break down, you know, the bit patterns and things. So from our transmission, since there's no encryption
on that, you just basically have the raw number structure. And to the, to the kind of uninformed,
this looks just like a bunch of gibberish, but what we're going to do is take the knowledge we
gained from reading the hundreds and hundreds of pages of those CCSDS protocols and see what
we can find out. So let's look here. We see the, the fives in our scenario is the acquisition
sequence. And then we've determined where the CLTU is. So we've now, we've got the CLTU. So let's
break that down and see what we can get. So then we take off the headers and trailers in this
example. And then now we have this subset, and then we have this code blocks and these check
bytes, and we take those out. So now we've identified the actual TC transfer frame, which is,
which is where the, the command information is stored on, on the uplink. So now we've got that.
So let's take out the header on that. And now we have the command packet. So this is the one
that we were looking for. So with all those numbers, this is really what we were looking
for. We're looking for this command packet, because it's going to tell us hopefully what
kind of command was sent up on that uplink. So from that, from the telemetry stream, we've kind
of discussed, we see this no op command that came down. So we've, we look on the GitHub repo, and
we've realized that in our example, that the spacecraft that's we're looking at seems to be
using these default command and telemetry IDs. So because if you look at the, the header file for
the message IDs, for the CFE table, command message ID, you see 1804. So that would indicate
like the high likelihood of actually the software's using these default message ID types.
So what that does is allow you to basically transmit information to the, you're going to
try to transmit information using this knowledge you've gained to the simulated spacecraft to see
kind of what will happen. So let's see if we can, we can reconstruct a packet with this knowledge
and see what we can do with it. So with this knowledge, let's play around a little bit and
see what we can do. So we've got our knowledge of the command structure from GitHub, and since we
can't construct a new command, maybe something else to see what happens, just to see if the
command, the spacecraft will actually process it. So you have to do a little digging and understand
the functionality of this software, but luckily all that information is open source. So
once you dig in a little bit, you see, you notice there's this functionality within
the CoreFlight software called ES. It's an ES application where you can potentially, you know,
have control over the applications on board. So we're going to see if we can reconstruct a packet
to do a reboot of a particular application. So in the real world, you know, you would have to
reverse engineer the packet structure of the RF signal. But in our scenario, we're going to
transmit the UDP packet with the following information and see if we can get a reset of
one of the applications. So we use that 1806 because that's the default message ID for the
ES application. So that tells the flight software, hey, this command is meant for the ES application
to process once it gets on the satellite. And then the rest of the numbers is just,
you know, understanding the... translating the command and telemetry database into this format,
which I won't bore you with all the details that had to happen for that to occur, but
you can get there, essentially. It just takes a while to figure out what the structure is and
what numbers need to go where and what those values need to be. So let's send this raw packet
up and see what we can do. So we send that raw packet up to the satellite and look at that. So
we see in the UR of the actual flight software that we have some sort of response. So you see
at the top of the window, you see CFE ES restart app initiated for HK. So it looks like it was
successful. So we essentially have reconstructed our own packet based on information that we've
gained from GitHub and then transmitted it to our spacecraft simulator and it indeed did process it.
So that's an example of, you know, a command-link intrusion where you've basically put your own
command structure and sent it up and got it to process. So that's kind of the response. So
the question is like, okay, why does the replay attack work? Why does this command-link intrusion
attack work? So part of it's the open sourceness of the information out there so you can pull
that data from GitHub and do your own research. But it really gets down to the protocols and some
of the protections. So in this example, there's a communications operational procedure that
typically runs on a satellite, at least ones that operate CCSDS called COP1. And that helps
with sequencing to make sure that the sequence of the commands and the packets received are
proper. On our example, COP1 wasn't turned on by design in our example, but
there's a lot of actual spacecraft who don't leverage COP1 for various reasons. So COP1 would
have provided some level of protection, but that can be fudged and gotten around if you know what
you're doing. So in example, I redid the same example for replay with COP1 enabled, and you see
here that the command is not processed because they were out of sequence. So I could have really
fudged the data around with sequencing and probably got the process, but we didn't
really want to get into that. But the point was just to articulate that there are sequencing
protections that you can put in to help with the replay. But the real control that
you want is encryption and authentication. So you really need to encrypt and authenticate
the command link. So it's not enough to just do encryption because you theoretically
could just replay an encrypted link and it would process accordingly. So you need the authentication
on the command link as well. So that's important. So you need both. So to properly protect
from a replay or an intrusion attack, like here are some just guidelines for
pseudo requirements, sample requirements about cryptography and authentication. So you need to
authenticate and you need to do cryptography to ensure that these attacks won't work. Okay, so now
we're going to jump into denial of service via GPS jamming. So the first two were particularly
to the command link. So those were intrusion and replay. This one's a little bit different
and it's going to use a different simulator, but we won't get into the specifics on the sim, but
it's a high fidelity simulator that has a lot of dynamics and a lot of command and data handling
and GNC capabilities. So what we're going to do is get the vehicle in an operational
state where it's doing a mission operations, and then we're going to simulate the
denial of service with GPS signal, which is basically cut off the GPS, and then we're going to see how the
system responds. So jamming, for those who aren't necessarily aware, is the intentional
or sometimes unintentional interference of the signal that prevents it from being received. So
it's relatively simple to do. It's easy to overpower at close range and jammers can be
on the ground, it could be in the ocean, airspace, jammers can be about anywhere. So in our scenario,
the spacecraft simulator is set up to be in what's called mission science mode or operational mode,
and once it reaches this mode, we're going to simulate the GPS signal by stopping the flow
on the space wire bus, which is where the GPS sends its data to the Singapore computer,
the flight software. So here is just a graphical representation of some of the telemetry and
dynamics data for this particular sim as it's operating. And we are, you know, it shows,
you see the attitude control mode previous to attitude control mode current, which is MSM,
which is the mission science, which is the operations mode. So what we're going to do here
is we're going to block that data from getting to the Singapore computer, the flight software
from the GPS sensors, and we're going to see what happens. So in the middle here, you see
the GPS data packet counts increasing. So you see it go from 920 to 944. So everything's optimal
here. We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine.
So here, now we're going to, in our simulation, we're going to basically leverage a capability
that was built into the simulator to block data across the Spacewire bus based on whichever
values we want. So we can block about anything that's flowing across the Spacewire bus,
or 5053 bus for that matter, and see what happens. So once you initiate this block sequence,
you see the ground telemetry values freeze. So you see, which indicates the gray background there.
So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore.
For some reason, it's not being downlinked. And that's because it's not being actually
provided to the Singapore computer for downlink. So you see that freeze. So, and you know,
for spacecraft, you know, one thing to understand is, you know, you can't, you can't go up there,
you can't like a, obviously a real computer, go, you know, hit the reset button. There's a lot of
autonomy built in, there's a lot of fault management, and a lot of testing goes around
fault management response. So what you should know is like, typically, when you have a
satellite in orbit, and some anomalous thing happens, the last-ditch effort to save it
basically is to go into what's called a sun pointer safe mode. So it basically takes the
solar arrays and points it to the sun and says, I'm just going to hang out here until I hear
from the people who control me in the ground station. So what we're going to do here is
see what the autonomous flight response is once the GPS signal is blocked. So safe mode
is an operational mode, where a lot of non-essential systems are shut down. It's very similar to
Windows, you know, when Windows goes in safe mode, it shuts off a lot of the features of
Windows from that perspective. So preservation of the spacecraft is the highest priority. So
here you see in the downlink telemetry, the flight software is starting to do its
autonomous fault management. It's running what are called RTSs, so relative time sequences.
So these are things, these are just automated flight responses that are there.
And it's starting to do various things, it's doing movements, it's stopping
antennas, it's transitioning to some point mode from an attitude control perspective. So it's
starting to safe itself. And in the telemetry you see from the attitude control mode perspective,
it's reached its desired some point state at this point. So why would you perform a denial
service, you know, like GPS jamming on something? So, you know, maybe you're just wanting to have
a little fun, maybe you're just trying to disrupt and degrade some sort of mission operations for
a specific time. Maybe you're wanting a mission to not achieve any objectives. But what if you're
a little bit smarter than that? And you understand the autonomous fault response
for satellites, and you understand the design and fault management a little bit more. So
a more strategic, you know, attacker understands that there's a lot of autonomous fault response
for a mission to put itself in a really safe state. So if you just think about the safe mode
for Windows, you know, a lot of the security features get disabled while you're in safe mode.
Similar things do happen for spacecraft. So forcing a spacecraft into safe mode
could potentially open up additional vectors that aren't there. So think about a, you know, maybe
if you've jammed the GPS signal, maybe your fault management response is to save yourself,
turn off cryptography, you know, and open up your command link for any signal that you can process.
Just depends on the fault management response. That's a design decision. But just think about
that as you're doing your design that you may not think through, like, hey, maybe adversaries may
know that I can be more vulnerable, get put in a more vulnerable state. So maybe I need to
design in something, you know, the terminology that we put in the paper that was linked in the
front, defending the spacecraft in the cyber domain paper. We talk about the cyber safe mode.
That's a slight transition from the traditional safe mode terminology. But it's basically
it's a safe mode that's cyber hardened to a degree. And you have a high integrity
mode that you're in, that you know you're in a good state and everything's valid,
and you still have authentication encryption going on. So that's a concept. That's a kind
of newer concept that's being discussed in the space sectors. But it should be there. Because
knowing, you know, more and more people that understand space and understand fault management
response may use that against you. So you may want to think about that a little bit more as
you do your design. So here's some recommendations for just generalized protection. This isn't
specifically GPS jamming because there's a whole there's papers upon papers out there that talk
about how to protect against jamming. But this is more in line with protecting against, you know,
leveraging fault management against you. So you need to really protect that documentation
because that's just basically providing an adversary a pathway to get you in a more
vulnerable state if your design is built that way. And other design considerations about always
encrypting information, especially on the downlink. So some people think that the downlink on the
telemetry side should not necessarily be encrypted because it's not, you know, it's not controlling
the vehicle. But there could be a lot of good information that is ascertained from telemetry.
So it could be you could have adversaries monitoring your telemetry stream looking for
various, you know, indicators that you are in a less secure state. And these are other
some design considerations that are that are here. I won't read them all to you. But basically
getting, you know, the cyber safe mode, getting, you know, only report error messages when needed
and encrypting it accordingly and getting make sure you have ability to recover and reconstitute
to a known state. So these are just some considerations to think about as you're
building your design for a spacecraft. So with that being said, those are just an example of
doing some protection. So let's talk about what it takes to let's transition the discussion a
little bit and talk about what it takes to just protect the overall ground system. So at this
point, we've talked about, you know, the command link intrusion. We've talked about command replay,
some denial of service. But let's talk more generically about space systems in general. So
I like to use defense in depth as a presentation material and discuss and a principle for design
as many people do. I mean, I think anyone in the security community really understands the
fits and depth. But with the fits and depth, I like to illustrate basically using an onion. So
in the typical, you know, IT sense, the onion diagram, you have, you know, the hardened server
configuration wrapped with intrusion prevention firewall type stuff. But in the space domain,
it's a little bit different, but it's somewhat similar. But so here's some graphics that I wanted
to provide that give you a representation of the fits and depth for both ground and space. So
this first graphic here is kind of the ground system. So it starts with the data that runs,
you know, on the endpoints, wrapped by software, supported by endpoints, connected by networks,
protected by intrusion detection and perimeter controls and physical controls. So there's,
you know, this isn't all inclusive, not every subcategory, you know, within each block is listed.
Due to space, but it provides a good list of things that you would expect to be at each
layer of the onion. So from a data perspective, you may have, you know, data at rest encryption,
you may have Tempest that you need to worry about. From a ground software perspective, you know,
SDLC, secure coding, common weakness enumeration prevention, things like that, binary analysis,
dynamic analysis, static code analysis, stuff like that. Your endpoints, your heads, your hips,
your AV malware, DLP, file integrity, things like that. So we won't dive into every one of these,
but it's kind of important to understand that you can pick and choose to apply controls at
each layer. And it's important to apply controls to each layer. So you don't want to just put all
your eggs in the perimeter basket and say, I'm going to stand up a good DLP, a good firewall,
and security zones on the perimeter. And then hope that gets me there because you have insiders,
you have other avenues where you need monitoring capability, you need protections.
So that's pretty common. You know, that's nothing groundbreaking from a ground perspective. But
similarly, you can do the kind of the exact same approach for the vehicle itself. So
this is a onion representation for the vehicle. So you have, you know,
similarly the data that's on board the vehicle, wrapped and processed by some sort of software
on board that has a single board computer or, you know, a processor and a bus,
hopefully protected by some sort of onboard intrusion detection prevention. So that's kind
of a new area. What's being researched today is kind of onboard cyber monitoring and intrusion
detection prevention. That's not typical on a lot of missions right now. What you see currently,
a lot of the focus on protecting space vehicles is really geared around the crypto comms area.
So, you know, the authentication encryption and the comms link, the transect, things like
that. But there are controls that you can apply and there are threat vectors that exist for
basically every one of these blocks on the vehicle as well as on the ground. So
since there's threats and vulnerabilities that can be exploited, that can happen on
kind of each block, it's important to put controls in each block, honestly,
so that you can have a better chance of protecting yourself. So in conclusion,
we've talked, you know, kind of three attack vectors, but those are just three
examples and there's many more that can be discussed. But it's kind of convenient,
to ignore security, honestly, because there's not been this, you know, windfall of
events that have happened that are cyber related on a vehicle. But it's not really an option moving
forward. Satellites are too critical to our everyday life or operations of our nation and
the world, honestly. And it's kind of important to understand that the barrier to entry into space
has been dramatically reduced in the last five, 10, 15 years. I mean, with small sats and launch
services, and AWS ground stations, it's getting real easy to get a lot cheaper to get information.
It's a lot cheaper to get assets into space. So, and defensive depth needs to be a big part
of the solution. So we need to design security at the beginning, which is kind of cliche, but
obvious. And it's going to be more and more important as we, you know, start to deploy all
these small sats in a peripheral-related constellation moving forward. So, you know,
from a defense in depth perspective, and, you know, understanding security, it's important. So
I mean, there's a little bit of a interesting parallel you can draw, you know, with space
systems, and in the industrial control system arena. So it's, you know, for years and years,
you see this at, you know, at the IoT village as well. For years and years, people have kind
of ignored security in the industrial control systems, OT, IoT arena. And it's not just been
the last few years, people have really started understanding that threat factor. And, and
mainly it's due to, there's been documented attacks, and a lot of bad things have happened
as a result of that. So let's try to learn from that lesson and not wait till something really bad
happens to make corrections. Because we know there are vulnerabilities, we know there are
corrections, we know there are things we can do. So we should be doing that. And the small set
marketplace, you know, and the embedded security community is evolving. There's a lot of commercial
things that are being put out, there's some open source solutions that are out there. And we need,
you know, accountability, we need people who are researching this to understand the security
ramifications of these things and, and need to be somewhat agile to get these things verified
and validated and accepted and put out in the community. As opposed to some niche areas,
niche markets, people doing things. So it's important for us to get, you know, leverage the
explosion in this market. But it's also, we need the security researchers and, you know, ethical
hackers and things like that to really, you know, hold people accountable for the things we're
putting out. Because, you know, the path of least resistance is often used. So if no one's looking
at your, looking at your work and understanding the security ramifications of your design and
what you're doing, you know, people kind of get lazy with their implementation at times. So it's
important that we all get out there and research this stuff and look, look into it to understand
the ramifications, some of these design choices that are being made. So we need to really, you
know, the government industry, I think we're coming to a very good, you know, agreement that
cybersecurity is super important for, for space programs. And there's a lot of investment that
needs an education, training and talent development and retention. So I, I feel like there's a huge
step forward this year at DEF CON with the hack-a-sat. I mean, that, that is a fantastic
event that, you know, that's ongoing within the Aerospace Village to, to, you know, hack into
to representative satellite systems. And it, you know, there's these open source technologies that
are put out that you can build your own ground-to-space simulation. You can start learning.
You know, five years ago, there was not that much out there to learn. So the, the activation energy
and the level of access to information was, wasn't there for the security community to get
into it. So I think it behooves us, you know, within the government, within the industry to start
getting this information out there and making this stuff available for the researchers so they can,
you know, we can find some of these vulnerabilities and get them fixed. And technology has evolved
from a simulation perspective so much in the last 10 years with the advent of, you know, digital twin
type technology for space. The embedded arena is getting there, you know, with open source,
things like QEMU, with commercial things like Simics or TCM, you can get really high fidelity
simulators running software. And that's, you know, built for target and running a lot of tests. You
don't have to buy these million dollar space platforms. And there, and also these, you know,
these CubeSats that you can buy, and these embedded processors, you can buy some of these
things kind of commercially off the shelf, start doing your own research if you have some of the
budget. But the last point is, you know, the reason I wanted to do this presentation
and be a part of the Aerospace Village and work with the Space Ice Act is information sharing
is a must. I mean, coming from the government arena, you really get into this compartmentalization
of information and the need to know and things like that. So, but we really need to have
information sharing, we need to do research, we need to have events like this, the Aerospace
Village, we need to come together as a community and start doing this research together. And we're
not trying to point fingers at people and, you know, say that, oh, your implementation is bad.
It's just we need to learn together and make things better and share what we learn and do
presentations like this. So, with that being said, that's about all I have to present. But I do have
here on slide 29 a link to some resources, the Space Ice Act, there for information on it,
the HackASAT link. Something that's going to be really cool is they, the HackASAT was,
you know, they had qualification rounds and they have the finals at DEF CON this year.
And they're going to open source a lot of those CTFs qualifications and things. So keep an eye
on the HackASAT URL to, you know, maybe pull down some of those CTFs once they get published
and give them a try yourself and learn. This is a really exciting exercises that were put together.
If you want to build some of your own simulators, these links are there with for OpenSATKit,
Noscubed, 42, things like that, Open Source Flight Software, CPCFS. And there's some info here on,
you know, jamming if you want to learn a bit more about that. And the paper that
was published in November 2019 is also linked here for your reference. So with that being said,
that is all I have to present. And thank you so much. And I'll take questions
in the offline session. Appreciate it.