start	end	text
4920	9380	Hi, my name is Brandon Bailey. I work within the Cybersecurity Subdivision at the Airspace
9380	15300	Corporation and we're excited to be here today in conjunction with the Space ISAC and the
15300	19680	Airspace Village to be discussing the topic on some spacecraft research that we've been
19680	26540	working on specifically related to exploitation of some of the implementations upon the spacecraft.
26540	31880	So we'll jump right into it. I would like to refer people to the paper linked in the front
31880	37800	for more information about how you can apply certain cybersecurity controls for a spacecraft.
37800	44740	So from an introduction perspective, when you look at vulnerabilities in information systems,
44740	51220	particular satellites, they're often overlooked in the wider discussions when you talk about
51220	57380	critical infrastructure, but that's changing quite rapidly currently where there's a lot more
57380	62800	people discussing spacecraft vulnerabilities, ground system vulnerabilities, and how it relates
62800	66900	to our critical infrastructure as a country. So there's been a lot of misunderstanding and
66900	73260	somewhat complacency in this regard because there's been a lack of real-life events that's
73260	81160	known in the public space of attacks against space vehicles. But the space systems are similar to
81160	87560	other systems. One that you would kind of know about is the industrial control systems or
87560	93160	operational technology field. So you see some good parallels that can be drawn between the spacecraft
93160	100680	and the space systems arena with that. So malicious insiders, external threats,
100680	106920	splotching threats, those are all various threat factors that people can get in to affect
106920	113800	spacecraft from the sensors to the data being uplinked or downlinked. So there's a lot of
113800	119660	different areas where you could have impact that could disrupt military, government,
119660	127180	or even commercial activity for our day-to-day activities. So the threats are changing quite
127180	134140	rapidly in this arena. So there's a lot more knowledge about space and things of that nature.
134780	140820	And then when they would have happened, there'd be an absence of warning. So you know there's
140820	145560	not real-time consistent communication between ground and space a lot of times. So
145560	151660	there could be times where you're not aware that there's attacks ongoing. And attribution is
151660	156860	difficult in the IT world and it's even more difficult in the space world. And there definitely
156860	160360	needs to be more research in this area. And that's one of the reasons why we're
161240	165400	presenting this material. And I'm assuming one of the reasons why the Aerospace Village
165960	170080	exists is because there's a lot more collaboration and research that needs to happen
170080	176720	in this arena. And the CubeSat arena is just exploding as we all know. And the barrier to
176720	183500	entry into space is being reduced quite extensively. So the good thing is in recent years there's been
183500	190080	some open source technology that's been put out there that can help people learn more about space,
190080	196620	space protocols, things like that. So Cosmos, which is linked here, NASA's CoreFlight executive
196620	203840	or CoreFlight software, OpenSatKit was put out by NASA to help people get started with CubeSats.
204560	210360	NOS3 was put out by NASA's Independent Verification and Validation Program to help people build
210360	215060	simulators for space. So there's a lot of good open source material out there now. So people
215060	220060	can actually start researching this for themselves, which is great. But I will caveat that with
220060	225680	one thing is please change your default configs if you're pulling the CoreFlight executive or
225680	230640	CoreFlight software from GitHub and running it accordingly. You want to make sure that
230640	237400	you can change those default configs. So let's move on to some basics. So for people who aren't
237400	242660	necessarily living and breathing space communications and commanding and telemetry
242660	247240	and that terminology, here's just an introduction slide to kind of explain what we're talking about.
247240	253940	Command and Data Handling or referred to as CDH is essentially how data is relayed to and from
253940	258340	the spacecraft. So that's where the encoding and decoding happens for the commands and the
258340	264580	telemetry. There's kind of generically four pieces of a space system. You have the user
264580	271020	terminal where you do the commanding and the telemetry and process telemetry that runs
271020	275640	the ground software. There's some sort of front-end processor that does the conversions of the
275640	281880	information from the ground system to get it connected to a modem or an antenna that you can
281880	287820	send the information to the spacecraft and get it back down. So from a cyber perspective,
288660	294720	the attack surface is quite large because there's a lot of standard IT equipment in there. You know,
294720	298480	like with the ground terminals, the front-end processors, there's a lot of operational
298480	302860	technology, industrial control systems that operate within these facilities that run these
302860	309980	systems or control the antennas. And of course the RF link is the obvious one. So something to
309980	315560	note on this diagram is the bulk encryption component is kind of left out for people that are
315560	322960	more accustomed to satellite communication where you have cryptos on each end. So I left that out
322960	330700	just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle.
331440	335640	And this is just a quick animation of kind of what this looks like where
335640	341660	the user would say turn this heater on and then the software translates that to some, you know,
341660	347180	hex numbers and then it gets converted by the front-end processor to get framed appropriately
347180	352640	and sent to the modem to get modulated up to the bird and back down. So that's just a simple
352640	359440	animation to kind of articulate what we're talking about here. And slide five here is something, a
359440	364800	paper that was put out by NASIC, the National Air and Space Intelligence Center, which is a pretty
364800	370880	good resource if you want to understand the high-level architecture of space systems and
371440	377160	where cyber threats could have an impact and the types of cyber threats there are. So
377730	384150	in this diagram it's basically just outlining that you have the user segment where you have the
384750	389490	the ground software terminals and then the interacts with the ground segment where you
389490	395010	have the antennas at times or in the link segment with the RF and the space segment for space. So
395730	399730	vulnerabilities exist in all these segments and there's cyber threats within all these segments.
400090	404050	Obviously, you know, the user segment is the highest likelihood for a cyber attack given
404630	408990	that it may have some level of internet connection where it's operated by people and
408990	415150	we understand as being a security researchers or pin testers or red teamers that the people
415150	421890	are generally the weakest link in the cyber paradigm. So the user segment is one of the easier
421890	426950	areas to get in. But we're going to focus more on the space segment and the link segment
426950	432590	specifically because that's where there's less research and less publicized information. So we're
432590	439450	going to focus on three types of attacks today with some demonstration screenshots and to discuss
439450	444590	how they work, what they are, and how you can mitigate these things. So we're going to talk
444590	452990	about a replay attack, which is where you record the command signal and replay it to the vehicle
452990	459130	and see if it processes it. So we'll do that and we'll talk about command link intrusion where you
459130	464630	basically simulate modulating your own signal to a satellite and seeing if it processes
464630	469530	those commands. And then we'll do a denial of service where you could do some GPS jamming
470230	474270	to maybe cause the denial of service condition on a satellite depending on the implementation
474270	481970	for the satellite. So we'll jump in to the command replay first and discuss that attack
481970	487430	vector. So in the real world, which is not what we're operating with this demonstration, we're
487430	493650	operating within simulation, but in the real world you have your ground terminals antenna that
493650	498790	sends a RF signal to a satellite. So in the real world, if you were to do a command replay attack,
498790	504530	you would need some sort of sniffing device to sniff the RF signal from the ground antenna
504530	509990	while it's transmitting the uplink to the satellite. Well, in our simulated world,
509990	515710	because we're using some high fidelity simulation capabilities that have been built that we can use
515710	520350	simply UDP gets translated from the antenna to the satellite. So we're not,
520350	525730	you know, sending RF signals from a ground station to a simulated satellite. Although you could do
525730	531650	that, but for our purposes, we're going to use a simulator that just essentially takes the
531650	538230	TCP IP traffic from the front end processor and then it translates it to UDP and then sends it
538230	544050	to a spacecraft simulator that's running. So if we're doing that with UDP, then we can obviously
544050	549370	use something as simple as TCP for our research. So that's, that's, that's kind of how we're set
549370	556250	up. So this is the simulator that we're using, and it's, it's got some real components to it.
556930	562590	That's, you know, runs in operations today for various missions that are flying. So
562590	567530	there's a ground software component, there's a front end processor, there's the ground station
567530	573710	sim that is used to translate the information to UDP, and then that sends it to the spacecraft
574410	581510	that has a dynamic simulator with it. So we're using real ground software in this simulation.
581510	585190	We're using real front end processor software. None of these have been modified. They're using
585190	590290	the same software baselines as operational missions are using. It uses the same communication
590290	598070	protocols, CCSDS, TC and AOS. So you can google those if you want to learn more about it. We'll
598070	602850	get a little bit more into that detail later. But we aren't using any type of encryption,
602850	606530	so there's no point-to-point encryption or bulk encryption anywhere in this.
606810	611110	And we'll explain why, because that's the point of the demonstration is to show when you don't
611110	617610	have encryption what can happen. We have some real flight software that runs on several operational
617610	623910	missions currently, but it's cross-compiled for Linux. So it's not running on an embedded
623910	631050	processor, a power PC, or an arm, or some FPGA. It's running just in Linux for our purposes,
631050	638070	because we're just focused on the software testing at this point and not being too high fidelity.
638070	642350	But there are technologies that exist where you can get super high fidelity, and we've used those
642350	651130	in the past for several things. Things like Simix, or QEMU, or TCM. These are different
651130	657710	technologies that you can use to have higher fidelity simulations to run software compiled
657710	662630	for target. So those can be integrated in these simulators as well. So the ground station sim is
662630	667690	kind of what mimics the RF transmission for us, but for us it just translates to UDP as I said
667690	674430	earlier. So there's a simulation that's out there called 42 that's put out by NASA that helps do the
674430	679870	attitudes, orbit dynamics, and environmental models. So that helps us understand the orbit
679870	686830	and how we're progressing there. So here we go. And you can build your own one of these
686830	692310	with some sources from GitHub. So these are linked here, OpenSATKit and NOS3 have some great
693170	696370	components that you can construct something similar for yourself.
697010	702510	Okay, so for our specific demonstration for command replay, our satellite in this scenario
702510	708370	orbits the earth and is scheduled to uplink, downlink when it's over top of three different
708370	714650	ground sites. One in California, one in Spain, one in Australia. So one would be Australia's in
714650	721950	Canberra, Spain, Madrid, California, out near LA. So the point of our demonstration is we're going to
721950	727090	capture the UDP traffic with TCP dump as it's leaving the ground station during the uplink pass.
727090	733590	So this mimics an RF sniffing capture. And then we're going to replay that with TCP replay. So
734470	741450	we did a quick, you know, Google search on the internet looking for what type of hardware and
741450	747250	technologies needed to reproduce this type of an attack in real life. And basically it's
747250	753550	around $7,000 and you could get some equipment that could record, capture, and transmit signal
753550	759190	to a lower orbit. So it's definitely achievable for, you know, people who have a little bit of
759190	763090	money. But then with the advent of some of these new technologies that are coming out today, like
763090	768150	AWS Ground Station, the barrier could be much lower. So you may not need so much equipment,
768150	774550	you may need sniffing capabilities, but we're a little unsure on what practices are going to be
774550	779490	in place for AWS in the future. So to prevent, you know, these type of things from happening. But
780270	786670	with that being said, it's just trying to articulate that the barrier for doing, you know,
786670	794450	communications to a vehicle is getting less and less. Okay, so setting up the attack. So
794450	801510	in our simulation, the satellite is visible to the ground station over the Madrid ground station. So
801510	808470	it's there. And then in the bottom middle here, you see a signal lock in that window, it says,
808470	812810	okay, it's locked, it's acquired. So it's sending the connect message, and then it's uplinking the
812810	817690	command. So you see several commands being transmitted. You know, that's a bunch of
817690	822690	numbers there. But what that does is you look in the far right, you see the flight software
823390	827990	that's running. That's the, you know, that's kind of like the UART window of a flight software,
827990	833050	where you have the flight software responding. You see it processes these NOOP commands. So
833050	839070	in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know,
839070	845650	in our terminology. So just to see if the application running on board is alive. So
845650	849910	upon receiving that command, the flight software indeed does process that command and downloads
849910	854490	the event messages, and the command counters increment. So you see here in the ground,
854490	859830	you see that the event messages are processed. It says, hey, there was a NOOP command, and it's
859830	864130	downlinked to the ground. And then you see the command counters increment accordingly. So you
864130	870630	see that the CMDPC, which is short for command processed, for each of those applications that
870630	877510	were sent commands processed to increment to one was zero. So it goes to one. Now the satellite
877510	883550	in our scenario is in transit between Madrid and Canberra. And you see in the ground station
883550	889050	simulation that it's lost signal. So it's no longer in view. So now here's where we could actually
889050	894710	do our replay attack. So in a real world scenario, you would need equipment, obviously, in the Madrid
894710	901130	area to capture the RF traffic. And then somewhere over India, in this example, you would need
901130	906650	transmit capability to be able to send transmit the information to the satellite. So in our
906650	912390	scenario, it's a lot easier, obviously, because we're using just the TCP replay. And here's just
912510	918310	a simple command. It replays the PCAP file that was captured. And then you see the flight software
918310	925610	respond accordingly with the same event messages within the UART. But what you don't
925610	931730	see is any event messages on the ground station because you were in between passes at that point.
931730	938130	And the command counters, you notice when you establish the downlink again over Canberra that
938130	942990	the command counters went up. So the flight software is reporting, hey, I received another
942990	949910	command and, you know, in between ground passes, which would be odd. So from a, you know, defensive
949910	955790	cyber operations perspective on the ground or, you know, C&D perspective, if you're not
955790	962430	monitoring certain key telemetry points on your vehicle, you may not be aware that, you know,
962430	969550	someone has tried to make a connection or send commands. So it's very important to understand
970110	976190	what the telemetry values are that you could be monitoring that could provide you insight
976190	980910	into potential attack vectors. So there's a lot of telemetry points out there that could help with
980910	988410	that. So that wraps up the command replay. So essentially what we did was capture the command
988410	995710	link up and then we replayed it and we saw that it processes. So we'll move on to command
995710	1000950	link intrusion, which is a little bit different. It's a slight different take on a command
1002250	1008010	command link attack. So since there's no encryption in our environment, our simulated
1008010	1013850	environment here, and there's no authentication, theoretically, the thought was, well,
1013850	1019250	if you just inspect the traffic and understand the packet structure and understand
1019770	1023590	what information is in there, theoretically, you could craft your own packet that matches that
1023590	1027390	structure and just send it up and see if it processes the command. So you're not really
1027390	1033490	replaying anything. You're just constructing your own raw command packet and then uplinking it and
1033490	1040250	seeing what happens. So let's try that out and see how it works. So once you've inspected the
1040250	1044670	traffic and understand there's no encryption, you see in one of the telemetry values, and you
1044670	1051030	can obviously do this with RF as well. You can record the RF on the downlink and record it as
1051030	1056130	well. But you see, once you have the information and you see here in the middle, you see CFE,
1056130	1066770	TBL, NOOP, CFE version 6.6.0.0. So you see that information there and that implies that they're
1066770	1072910	using CoreFlight executive or CoreFlight software. And so then you can say, well, that's available on
1072910	1079210	GitHub, I believe. So this is where that comment about default configs really comes into play.
1079210	1086730	So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol. So then you get
1086730	1093790	into this research study on command packet structures, which is a fun study.
1093790	1099090	I would not recommend it for people if they're not really interested in it because
1099090	1105370	it's a little bit of a read. So we're looking, we start to break down how
1105370	1110750	these systems work from a protocol perspective. So we have space packets and then we're
1110750	1117550	gonna get into some really space buzzword bingo here. So I apologize for that. But for the people
1117550	1123770	who know what this is, you'll get it. But for the people who don't know, forgive me
1123770	1128390	for kind of speaking in this lingo, but the space packets get wrapped in these transfer frames
1128390	1131750	and then the transfer frames are wrapped in what's called these command link
1131750	1137730	transmission units, CLTUs. So that's kind of how this structure works is CLTU, transfer frame
1137730	1144630	headers, space packet, and then the trailers. So then we start looking in the CCSDS protocol
1145470	1151130	and we understand, okay, this is the space packet. These are the octets that are there.
1151130	1156750	And then we start really diving into some of these documents and we say, okay, well, this is
1156750	1161170	what the primary header is. This is what a transfer frame looks like. This is what the transfer frame
1161170	1165590	primary header looks like. This is what the CLTU looks like. And then so we're kind of in this
1165590	1172810	overload of terminology, protocol breakdown, things like that. So it gets a little cumbersome
1172810	1178610	and confusing, but it's important to understand all these things. And it's also important to
1178610	1183610	realize that these protocols are open source protocols. So a lot of the, a lot of missions,
1183610	1189590	spacecraft that are out there today, leverage CCSDS because that is an international standard
1189590	1196470	that the CCSDS group is a consortium of many space agencies from across the world who get
1196470	1203710	together and standardize on protocols and things like that. So it's easy. You just kind of, you
1203710	1207470	can just Google the standards and find them and they'll have these diagrams in there and you can
1207470	1213650	break down, you know, the bit patterns and things. So from our transmission, since there's no encryption
1213650	1220750	on that, you just basically have the raw number structure. And to the, to the kind of uninformed,
1220750	1225970	this looks just like a bunch of gibberish, but what we're going to do is take the knowledge we
1225970	1234010	gained from reading the hundreds and hundreds of pages of those CCSDS protocols and see what
1234010	1241130	we can find out. So let's look here. We see the, the fives in our scenario is the acquisition
1241130	1248210	sequence. And then we've determined where the CLTU is. So we've now, we've got the CLTU. So let's
1248210	1252770	break that down and see what we can get. So then we take off the headers and trailers in this
1252770	1260430	example. And then now we have this subset, and then we have this code blocks and these check
1260430	1266050	bytes, and we take those out. So now we've identified the actual TC transfer frame, which is,
1266050	1272350	which is where the, the command information is stored on, on the uplink. So now we've got that.
1272350	1277890	So let's take out the header on that. And now we have the command packet. So this is the one
1277890	1282770	that we were looking for. So with all those numbers, this is really what we were looking
1282770	1286690	for. We're looking for this command packet, because it's going to tell us hopefully what
1286690	1292550	kind of command was sent up on that uplink. So from that, from the telemetry stream, we've kind
1292550	1299770	of discussed, we see this no op command that came down. So we've, we look on the GitHub repo, and
1299770	1307230	we've realized that in our example, that the spacecraft that's we're looking at seems to be
1307230	1313530	using these default command and telemetry IDs. So because if you look at the, the header file for
1313530	1322010	the message IDs, for the CFE table, command message ID, you see 1804. So that would indicate
1322010	1329210	like the high likelihood of actually the software's using these default message ID types.
1329210	1333790	So what that does is allow you to basically transmit information to the, you're going to
1333790	1338470	try to transmit information using this knowledge you've gained to the simulated spacecraft to see
1338470	1344470	kind of what will happen. So let's see if we can, we can reconstruct a packet with this knowledge
1344470	1348990	and see what we can do with it. So with this knowledge, let's play around a little bit and
1348990	1353590	see what we can do. So we've got our knowledge of the command structure from GitHub, and since we
1353590	1357650	can't construct a new command, maybe something else to see what happens, just to see if the
1357650	1362570	command, the spacecraft will actually process it. So you have to do a little digging and understand
1362570	1367850	the functionality of this software, but luckily all that information is open source. So
1367850	1372650	once you dig in a little bit, you see, you notice there's this functionality within
1372650	1380730	the CoreFlight software called ES. It's an ES application where you can potentially, you know,
1380730	1384730	have control over the applications on board. So we're going to see if we can reconstruct a packet
1385290	1390790	to do a reboot of a particular application. So in the real world, you know, you would have to
1390790	1396550	reverse engineer the packet structure of the RF signal. But in our scenario, we're going to
1396550	1401490	transmit the UDP packet with the following information and see if we can get a reset of
1401490	1409090	one of the applications. So we use that 1806 because that's the default message ID for the
1409090	1415570	ES application. So that tells the flight software, hey, this command is meant for the ES application
1415570	1421570	to process once it gets on the satellite. And then the rest of the numbers is just,
1421570	1427550	you know, understanding the... translating the command and telemetry database into this format,
1427550	1431010	which I won't bore you with all the details that had to happen for that to occur, but
1432270	1437050	you can get there, essentially. It just takes a while to figure out what the structure is and
1437050	1441910	what numbers need to go where and what those values need to be. So let's send this raw packet
1441910	1449350	up and see what we can do. So we send that raw packet up to the satellite and look at that. So
1449350	1456270	we see in the UR of the actual flight software that we have some sort of response. So you see
1457010	1463570	at the top of the window, you see CFE ES restart app initiated for HK. So it looks like it was
1463570	1469710	successful. So we essentially have reconstructed our own packet based on information that we've
1469710	1477230	gained from GitHub and then transmitted it to our spacecraft simulator and it indeed did process it.
1477230	1483090	So that's an example of, you know, a command-link intrusion where you've basically put your own
1483090	1488150	command structure and sent it up and got it to process. So that's kind of the response. So
1488830	1494670	the question is like, okay, why does the replay attack work? Why does this command-link intrusion
1494670	1500210	attack work? So part of it's the open sourceness of the information out there so you can pull
1500210	1506390	that data from GitHub and do your own research. But it really gets down to the protocols and some
1506390	1512770	of the protections. So in this example, there's a communications operational procedure that
1512770	1520610	typically runs on a satellite, at least ones that operate CCSDS called COP1. And that helps
1520610	1526170	with sequencing to make sure that the sequence of the commands and the packets received are
1526170	1533070	proper. On our example, COP1 wasn't turned on by design in our example, but
1533070	1539850	there's a lot of actual spacecraft who don't leverage COP1 for various reasons. So COP1 would
1539850	1545710	have provided some level of protection, but that can be fudged and gotten around if you know what
1545710	1553010	you're doing. So in example, I redid the same example for replay with COP1 enabled, and you see
1553010	1557370	here that the command is not processed because they were out of sequence. So I could have really
1557370	1564470	fudged the data around with sequencing and probably got the process, but we didn't
1564470	1568750	really want to get into that. But the point was just to articulate that there are sequencing
1568750	1576590	protections that you can put in to help with the replay. But the real control that
1576590	1582110	you want is encryption and authentication. So you really need to encrypt and authenticate
1582650	1588370	the command link. So it's not enough to just do encryption because you theoretically
1588370	1595170	could just replay an encrypted link and it would process accordingly. So you need the authentication
1595170	1599830	on the command link as well. So that's important. So you need both. So to properly protect
1599830	1605930	from a replay or an intrusion attack, like here are some just guidelines for
1607250	1611130	pseudo requirements, sample requirements about cryptography and authentication. So you need to
1611130	1618350	authenticate and you need to do cryptography to ensure that these attacks won't work. Okay, so now
1618350	1626230	we're going to jump into denial of service via GPS jamming. So the first two were particularly
1626230	1631910	to the command link. So those were intrusion and replay. This one's a little bit different
1631910	1635910	and it's going to use a different simulator, but we won't get into the specifics on the sim, but
1635910	1641910	it's a high fidelity simulator that has a lot of dynamics and a lot of command and data handling
1641910	1648130	and GNC capabilities. So what we're going to do is get the vehicle in an operational
1648130	1654910	state where it's doing a mission operations, and then we're going to simulate the
1654910	1659890	denial of service with GPS signal, which is basically cut off the GPS, and then we're going to see how the
1659890	1666930	system responds. So jamming, for those who aren't necessarily aware, is the intentional
1666930	1671210	or sometimes unintentional interference of the signal that prevents it from being received. So
1671210	1678670	it's relatively simple to do. It's easy to overpower at close range and jammers can be
1678670	1684030	on the ground, it could be in the ocean, airspace, jammers can be about anywhere. So in our scenario,
1684030	1689010	the spacecraft simulator is set up to be in what's called mission science mode or operational mode,
1689010	1694130	and once it reaches this mode, we're going to simulate the GPS signal by stopping the flow
1695010	1702110	on the space wire bus, which is where the GPS sends its data to the Singapore computer,
1702110	1709510	the flight software. So here is just a graphical representation of some of the telemetry and
1709510	1716210	dynamics data for this particular sim as it's operating. And we are, you know, it shows,
1716210	1723690	you see the attitude control mode previous to attitude control mode current, which is MSM,
1723690	1727730	which is the mission science, which is the operations mode. So what we're going to do here
1728290	1733510	is we're going to block that data from getting to the Singapore computer, the flight software
1733510	1737650	from the GPS sensors, and we're going to see what happens. So in the middle here, you see
1737650	1744830	the GPS data packet counts increasing. So you see it go from 920 to 944. So everything's optimal
1744830	1752310	here. We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine.
1752310	1759050	So here, now we're going to, in our simulation, we're going to basically leverage a capability
1759050	1765170	that was built into the simulator to block data across the Spacewire bus based on whichever
1765750	1770030	values we want. So we can block about anything that's flowing across the Spacewire bus,
1770030	1777670	or 5053 bus for that matter, and see what happens. So once you initiate this block sequence,
1777670	1783290	you see the ground telemetry values freeze. So you see, which indicates the gray background there.
1783290	1788550	So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore.
1788550	1792730	For some reason, it's not being downlinked. And that's because it's not being actually
1792730	1799070	provided to the Singapore computer for downlink. So you see that freeze. So, and you know,
1799070	1807070	for spacecraft, you know, one thing to understand is, you know, you can't, you can't go up there,
1807070	1811970	you can't like a, obviously a real computer, go, you know, hit the reset button. There's a lot of
1811970	1814930	autonomy built in, there's a lot of fault management, and a lot of testing goes around
1815150	1822630	fault management response. So what you should know is like, typically, when you have a
1822630	1829450	satellite in orbit, and some anomalous thing happens, the last-ditch effort to save it
1829450	1833410	basically is to go into what's called a sun pointer safe mode. So it basically takes the
1833410	1838470	solar arrays and points it to the sun and says, I'm just going to hang out here until I hear
1838470	1844050	from the people who control me in the ground station. So what we're going to do here is
1844050	1849850	see what the autonomous flight response is once the GPS signal is blocked. So safe mode
1849850	1855670	is an operational mode, where a lot of non-essential systems are shut down. It's very similar to
1856210	1861630	Windows, you know, when Windows goes in safe mode, it shuts off a lot of the features of
1861630	1867350	Windows from that perspective. So preservation of the spacecraft is the highest priority. So
1867860	1874890	here you see in the downlink telemetry, the flight software is starting to do its
1874890	1881570	autonomous fault management. It's running what are called RTSs, so relative time sequences.
1881570	1885110	So these are things, these are just automated flight responses that are there.
1885210	1890210	And it's starting to do various things, it's doing movements, it's stopping
1890210	1894990	antennas, it's transitioning to some point mode from an attitude control perspective. So it's
1894990	1900330	starting to safe itself. And in the telemetry you see from the attitude control mode perspective,
1900330	1907170	it's reached its desired some point state at this point. So why would you perform a denial
1907170	1914170	service, you know, like GPS jamming on something? So, you know, maybe you're just wanting to have
1914270	1918110	a little fun, maybe you're just trying to disrupt and degrade some sort of mission operations for
1918350	1923350	a specific time. Maybe you're wanting a mission to not achieve any objectives. But what if you're
1923490	1926990	a little bit smarter than that? And you understand the autonomous fault response
1927450	1931130	for satellites, and you understand the design and fault management a little bit more. So
1932170	1937350	a more strategic, you know, attacker understands that there's a lot of autonomous fault response
1937350	1941850	for a mission to put itself in a really safe state. So if you just think about the safe mode
1941850	1946610	for Windows, you know, a lot of the security features get disabled while you're in safe mode.
1947270	1952710	Similar things do happen for spacecraft. So forcing a spacecraft into safe mode
1952710	1959110	could potentially open up additional vectors that aren't there. So think about a, you know, maybe
1959730	1965250	if you've jammed the GPS signal, maybe your fault management response is to save yourself,
1965250	1971770	turn off cryptography, you know, and open up your command link for any signal that you can process.
1971770	1977710	Just depends on the fault management response. That's a design decision. But just think about
1977710	1983210	that as you're doing your design that you may not think through, like, hey, maybe adversaries may
1983210	1988010	know that I can be more vulnerable, get put in a more vulnerable state. So maybe I need to
1988010	1993690	design in something, you know, the terminology that we put in the paper that was linked in the
1993690	2000190	front, defending the spacecraft in the cyber domain paper. We talk about the cyber safe mode.
2000190	2006750	That's a slight transition from the traditional safe mode terminology. But it's basically
2008150	2014130	it's a safe mode that's cyber hardened to a degree. And you have a high integrity
2014910	2018890	mode that you're in, that you know you're in a good state and everything's valid,
2018890	2025830	and you still have authentication encryption going on. So that's a concept. That's a kind
2025830	2032550	of newer concept that's being discussed in the space sectors. But it should be there. Because
2032550	2037430	knowing, you know, more and more people that understand space and understand fault management
2037430	2042150	response may use that against you. So you may want to think about that a little bit more as
2042150	2048110	you do your design. So here's some recommendations for just generalized protection. This isn't
2048110	2052730	specifically GPS jamming because there's a whole there's papers upon papers out there that talk
2052730	2058350	about how to protect against jamming. But this is more in line with protecting against, you know,
2058350	2062070	leveraging fault management against you. So you need to really protect that documentation
2062650	2066430	because that's just basically providing an adversary a pathway to get you in a more
2066430	2073470	vulnerable state if your design is built that way. And other design considerations about always
2073470	2079570	encrypting information, especially on the downlink. So some people think that the downlink on the
2079570	2084410	telemetry side should not necessarily be encrypted because it's not, you know, it's not controlling
2084410	2089430	the vehicle. But there could be a lot of good information that is ascertained from telemetry.
2089430	2093450	So it could be you could have adversaries monitoring your telemetry stream looking for
2093850	2101190	various, you know, indicators that you are in a less secure state. And these are other
2101190	2105030	some design considerations that are that are here. I won't read them all to you. But basically
2105030	2110390	getting, you know, the cyber safe mode, getting, you know, only report error messages when needed
2110950	2115250	and encrypting it accordingly and getting make sure you have ability to recover and reconstitute
2115250	2120430	to a known state. So these are just some considerations to think about as you're
2120430	2127230	building your design for a spacecraft. So with that being said, those are just an example of
2127230	2133570	doing some protection. So let's talk about what it takes to let's transition the discussion a
2133570	2139450	little bit and talk about what it takes to just protect the overall ground system. So at this
2139450	2147610	point, we've talked about, you know, the command link intrusion. We've talked about command replay,
2147610	2152530	some denial of service. But let's talk more generically about space systems in general. So
2153150	2161010	I like to use defense in depth as a presentation material and discuss and a principle for design
2161010	2165930	as many people do. I mean, I think anyone in the security community really understands the
2165930	2172230	fits and depth. But with the fits and depth, I like to illustrate basically using an onion. So
2172230	2178070	in the typical, you know, IT sense, the onion diagram, you have, you know, the hardened server
2178070	2184010	configuration wrapped with intrusion prevention firewall type stuff. But in the space domain,
2184010	2188190	it's a little bit different, but it's somewhat similar. But so here's some graphics that I wanted
2188190	2193790	to provide that give you a representation of the fits and depth for both ground and space. So
2194650	2200110	this first graphic here is kind of the ground system. So it starts with the data that runs,
2200110	2207290	you know, on the endpoints, wrapped by software, supported by endpoints, connected by networks,
2207290	2211430	protected by intrusion detection and perimeter controls and physical controls. So there's,
2211430	2218170	you know, this isn't all inclusive, not every subcategory, you know, within each block is listed.
2218190	2224690	Due to space, but it provides a good list of things that you would expect to be at each
2224690	2230670	layer of the onion. So from a data perspective, you may have, you know, data at rest encryption,
2230670	2236010	you may have Tempest that you need to worry about. From a ground software perspective, you know,
2236010	2242370	SDLC, secure coding, common weakness enumeration prevention, things like that, binary analysis,
2242370	2248810	dynamic analysis, static code analysis, stuff like that. Your endpoints, your heads, your hips,
2248810	2254010	your AV malware, DLP, file integrity, things like that. So we won't dive into every one of these,
2254010	2258370	but it's kind of important to understand that you can pick and choose to apply controls at
2258370	2263090	each layer. And it's important to apply controls to each layer. So you don't want to just put all
2263090	2268650	your eggs in the perimeter basket and say, I'm going to stand up a good DLP, a good firewall,
2269290	2275730	and security zones on the perimeter. And then hope that gets me there because you have insiders,
2275730	2280150	you have other avenues where you need monitoring capability, you need protections.
2280310	2285370	So that's pretty common. You know, that's nothing groundbreaking from a ground perspective. But
2285370	2290130	similarly, you can do the kind of the exact same approach for the vehicle itself. So
2290730	2295290	this is a onion representation for the vehicle. So you have, you know,
2295290	2300510	similarly the data that's on board the vehicle, wrapped and processed by some sort of software
2300510	2307130	on board that has a single board computer or, you know, a processor and a bus,
2307130	2311970	hopefully protected by some sort of onboard intrusion detection prevention. So that's kind
2311970	2317550	of a new area. What's being researched today is kind of onboard cyber monitoring and intrusion
2317550	2324070	detection prevention. That's not typical on a lot of missions right now. What you see currently,
2324170	2329830	a lot of the focus on protecting space vehicles is really geared around the crypto comms area.
2329910	2338290	So, you know, the authentication encryption and the comms link, the transect, things like
2338290	2343450	that. But there are controls that you can apply and there are threat vectors that exist for
2343450	2349290	basically every one of these blocks on the vehicle as well as on the ground. So
2349930	2354770	since there's threats and vulnerabilities that can be exploited, that can happen on
2354770	2357790	kind of each block, it's important to put controls in each block, honestly,
2357790	2364810	so that you can have a better chance of protecting yourself. So in conclusion,
2364810	2368670	we've talked, you know, kind of three attack vectors, but those are just three
2368670	2375470	examples and there's many more that can be discussed. But it's kind of convenient,
2375970	2383070	to ignore security, honestly, because there's not been this, you know, windfall of
2384150	2389970	events that have happened that are cyber related on a vehicle. But it's not really an option moving
2389970	2396250	forward. Satellites are too critical to our everyday life or operations of our nation and
2396250	2401690	the world, honestly. And it's kind of important to understand that the barrier to entry into space
2401690	2407630	has been dramatically reduced in the last five, 10, 15 years. I mean, with small sats and launch
2407630	2416390	services, and AWS ground stations, it's getting real easy to get a lot cheaper to get information.
2417050	2424310	It's a lot cheaper to get assets into space. So, and defensive depth needs to be a big part
2424310	2428390	of the solution. So we need to design security at the beginning, which is kind of cliche, but
2428390	2434350	obvious. And it's going to be more and more important as we, you know, start to deploy all
2434350	2439850	these small sats in a peripheral-related constellation moving forward. So, you know,
2439850	2444970	from a defense in depth perspective, and, you know, understanding security, it's important. So
2444970	2449710	I mean, there's a little bit of a interesting parallel you can draw, you know, with space
2449710	2456670	systems, and in the industrial control system arena. So it's, you know, for years and years,
2456670	2462730	you see this at, you know, at the IoT village as well. For years and years, people have kind
2462730	2468590	of ignored security in the industrial control systems, OT, IoT arena. And it's not just been
2468590	2473970	the last few years, people have really started understanding that threat factor. And, and
2473970	2479270	mainly it's due to, there's been documented attacks, and a lot of bad things have happened
2479270	2483950	as a result of that. So let's try to learn from that lesson and not wait till something really bad
2483950	2488810	happens to make corrections. Because we know there are vulnerabilities, we know there are
2488810	2495390	corrections, we know there are things we can do. So we should be doing that. And the small set
2495390	2499870	marketplace, you know, and the embedded security community is evolving. There's a lot of commercial
2499870	2505590	things that are being put out, there's some open source solutions that are out there. And we need,
2505590	2510830	you know, accountability, we need people who are researching this to understand the security
2510830	2517150	ramifications of these things and, and need to be somewhat agile to get these things verified
2517150	2524150	and validated and accepted and put out in the community. As opposed to some niche areas,
2524150	2531430	niche markets, people doing things. So it's important for us to get, you know, leverage the
2531430	2539270	explosion in this market. But it's also, we need the security researchers and, you know, ethical
2540230	2545930	hackers and things like that to really, you know, hold people accountable for the things we're
2545930	2552890	putting out. Because, you know, the path of least resistance is often used. So if no one's looking
2552890	2557010	at your, looking at your work and understanding the security ramifications of your design and
2557010	2561770	what you're doing, you know, people kind of get lazy with their implementation at times. So it's
2561770	2566650	important that we all get out there and research this stuff and look, look into it to understand
2566650	2572130	the ramifications, some of these design choices that are being made. So we need to really, you
2572130	2577570	know, the government industry, I think we're coming to a very good, you know, agreement that
2577570	2582430	cybersecurity is super important for, for space programs. And there's a lot of investment that
2582430	2587930	needs an education, training and talent development and retention. So I, I feel like there's a huge
2587930	2592530	step forward this year at DEF CON with the hack-a-sat. I mean, that, that is a fantastic
2592530	2598590	event that, you know, that's ongoing within the Aerospace Village to, to, you know, hack into
2598590	2604910	to representative satellite systems. And it, you know, there's these open source technologies that
2604910	2608830	are put out that you can build your own ground-to-space simulation. You can start learning.
2609030	2615110	You know, five years ago, there was not that much out there to learn. So the, the activation energy
2615110	2622290	and the level of access to information was, wasn't there for the security community to get
2622290	2628850	into it. So I think it behooves us, you know, within the government, within the industry to start
2628850	2632910	getting this information out there and making this stuff available for the researchers so they can,
2632910	2638650	you know, we can find some of these vulnerabilities and get them fixed. And technology has evolved
2638650	2645410	from a simulation perspective so much in the last 10 years with the advent of, you know, digital twin
2645410	2651030	type technology for space. The embedded arena is getting there, you know, with open source,
2651030	2657730	things like QEMU, with commercial things like Simics or TCM, you can get really high fidelity
2657730	2664890	simulators running software. And that's, you know, built for target and running a lot of tests. You
2664890	2670390	don't have to buy these million dollar space platforms. And there, and also these, you know,
2670390	2674650	these CubeSats that you can buy, and these embedded processors, you can buy some of these
2675310	2678330	things kind of commercially off the shelf, start doing your own research if you have some of the
2678330	2684890	budget. But the last point is, you know, the reason I wanted to do this presentation
2684890	2691450	and be a part of the Aerospace Village and work with the Space Ice Act is information sharing
2691450	2697190	is a must. I mean, coming from the government arena, you really get into this compartmentalization
2697190	2703330	of information and the need to know and things like that. So, but we really need to have
2703330	2707910	information sharing, we need to do research, we need to have events like this, the Aerospace
2707910	2713990	Village, we need to come together as a community and start doing this research together. And we're
2713990	2718570	not trying to point fingers at people and, you know, say that, oh, your implementation is bad.
2718570	2724730	It's just we need to learn together and make things better and share what we learn and do
2724730	2730830	presentations like this. So, with that being said, that's about all I have to present. But I do have
2730830	2739170	here on slide 29 a link to some resources, the Space Ice Act, there for information on it,
2739170	2745990	the HackASAT link. Something that's going to be really cool is they, the HackASAT was,
2745990	2749830	you know, they had qualification rounds and they have the finals at DEF CON this year.
2749830	2756070	And they're going to open source a lot of those CTFs qualifications and things. So keep an eye
2756070	2761990	on the HackASAT URL to, you know, maybe pull down some of those CTFs once they get published
2761990	2768710	and give them a try yourself and learn. This is a really exciting exercises that were put together.
2768710	2774010	If you want to build some of your own simulators, these links are there with for OpenSATKit,
2774510	2781510	Noscubed, 42, things like that, Open Source Flight Software, CPCFS. And there's some info here on,
2781930	2785470	you know, jamming if you want to learn a bit more about that. And the paper that
2785470	2793390	was published in November 2019 is also linked here for your reference. So with that being said,
2793390	2799130	that is all I have to present. And thank you so much. And I'll take questions
2799130	2801890	in the offline session. Appreciate it.