1
00:00:04,920 --> 00:00:06,860
Hi, my name is Brandon Bailey.

2
00:00:06,860 --> 00:00:26,540
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.

3
00:00:26,540 --> 00:00:28,440
So we'll jump right into it.

4
00:00:28,440 --> 00:00:37,800
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.

5
00:00:37,800 --> 00:01:00,460
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,

6
00:01:00,460 --> 00:01:04,520
ground system vulnerabilities, and how it relates to our critical infrastructure as a country.

7
00:01:04,520 --> 00:01:18,600
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.

8
00:01:18,780 --> 00:01:22,840
But the space systems are similar to other systems.

9
00:01:23,200 --> 00:01:28,900
One that you would kind of know about is the industrial control systems or operational technology field.

10
00:01:28,900 --> 00:01:36,280
So you see some good parallels that can be drawn between the spacecraft and the space systems arena with that.

11
00:01:36,280 --> 00:01:52,880
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.

12
00:01:52,920 --> 00:02:03,720
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.

13
00:02:03,880 --> 00:02:09,200
So the threats are changing quite rapidly in this arena.

14
00:02:09,200 --> 00:02:14,140
So there's a lot more knowledge about space and things of that nature.

15
00:02:14,780 --> 00:02:19,720
And then when they would have happened, there'd be an absence of warning.

16
00:02:19,720 --> 00:02:25,560
So you know there's not real-time consistent communication between ground and space a lot of times.

17
00:02:25,560 --> 00:02:29,920
So there could be times where you're not aware that there's attacks ongoing.

18
00:02:30,380 --> 00:02:34,980
And attribution is difficult in the IT world and it's even more difficult in the space world.

19
00:02:35,340 --> 00:02:38,340
And there definitely needs to be more research in this area.

20
00:02:38,340 --> 00:02:42,740
And that's one of the reasons why we're presenting this material.

21
00:02:42,740 --> 00:02:51,380
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.

22
00:02:51,660 --> 00:02:55,620
And the CubeSat arena is just exploding as we all know.

23
00:02:55,640 --> 00:03:00,120
And the barrier to entry into space is being reduced quite extensively.

24
00:03:00,120 --> 00:03:12,220
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.

25
00:03:12,220 --> 00:03:23,840
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.

26
00:03:24,560 --> 00:03:31,520
NOS3 was put out by NASA's Independent Verification and Validation Program to help people build simulators for space.

27
00:03:31,520 --> 00:03:34,680
So there's a lot of good open source material out there now.

28
00:03:34,680 --> 00:03:37,900
So people can actually start researching this for themselves, which is great.

29
00:03:38,300 --> 00:03:49,760
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.

30
00:03:49,760 --> 00:03:52,100
You want to make sure that you can change those default configs.

31
00:03:52,100 --> 00:03:55,580
So let's move on to some basics.

32
00:03:55,580 --> 00:04:07,240
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.

33
00:04:07,240 --> 00:04:14,580
Command and Data Handling or referred to as CDH is essentially how data is relayed to and from the spacecraft.

34
00:04:14,580 --> 00:04:19,280
So that's where the encoding and decoding happens for the commands and the telemetry.

35
00:04:19,900 --> 00:04:23,960
There's kind of generically four pieces of a space system.

36
00:04:23,960 --> 00:04:31,800
You have the user terminal where you do the commanding and the telemetry and process telemetry that runs the ground software.

37
00:04:31,800 --> 00:04:46,300
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.

38
00:04:46,480 --> 00:04:54,480
So from a cyber perspective, the attack surface is quite large because there's a lot of standard IT equipment in there.

39
00:04:54,480 --> 00:05:05,660
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.

40
00:05:05,660 --> 00:05:08,580
And of course the RF link is the obvious one.

41
00:05:09,260 --> 00:05:21,420
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.

42
00:05:21,420 --> 00:05:30,700
So I left that out just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle.

43
00:05:31,440 --> 00:05:50,420
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.

44
00:05:50,420 --> 00:05:55,520
So that's just a simple animation to kind of articulate what we're talking about here.

45
00:05:55,960 --> 00:06:17,160
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.

46
00:06:17,160 --> 00:06:34,950
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.

47
00:06:34,950 --> 00:06:39,730
So vulnerabilities exist in all these segments and there's cyber threats within all these segments.

48
00:06:40,090 --> 00:06:58,930
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.

49
00:06:58,930 --> 00:07:03,470
So the user segment is one of the easier areas to get in.

50
00:07:03,470 --> 00:07:12,210
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.

51
00:07:12,210 --> 00:07:24,010
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.

52
00:07:24,010 --> 00:07:34,670
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.

53
00:07:34,670 --> 00:07:45,510
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.

54
00:07:45,510 --> 00:07:55,030
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.

55
00:07:55,030 --> 00:08:02,410
So we'll jump in to the command replay first and discuss that attack vector.

56
00:08:02,410 --> 00:08:16,390
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.

57
00:08:16,390 --> 00:08:27,930
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.

58
00:08:28,050 --> 00:08:39,690
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.

59
00:08:39,690 --> 00:08:45,030
So we're not, you know, sending RF signals from a ground station to a simulated satellite.

60
00:08:45,030 --> 00:09:00,450
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.

61
00:09:00,650 --> 00:09:07,170
So if we're doing that with UDP, then we can obviously use something as simple as TCP for our research.

62
00:09:07,170 --> 00:09:09,590
So that's, that's, that's kind of how we're set up.

63
00:09:09,590 --> 00:09:16,250
So this is the simulator that we're using, and it's, it's got some real components to it.

64
00:09:16,930 --> 00:09:22,470
That's, you know, runs in operations today for various missions that are flying.

65
00:09:22,470 --> 00:09:36,310
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.

66
00:09:36,310 --> 00:09:41,510
So we're using real ground software in this simulation.

67
00:09:41,510 --> 00:09:43,770
We're using real front end processor software.

68
00:09:43,770 --> 00:09:44,810
None of these have been modified.

69
00:09:44,810 --> 00:09:48,990
They're using the same software baselines as operational missions are using.

70
00:09:48,990 --> 00:09:54,670
It uses the same communication protocols, CCSDS, TC and AOS.

71
00:09:55,050 --> 00:09:58,010
So you can google those if you want to learn more about it.

72
00:09:58,010 --> 00:10:00,270
We'll get a little bit more into that detail later.

73
00:10:00,570 --> 00:10:06,530
But we aren't using any type of encryption, so there's no point-to-point encryption or bulk encryption anywhere in this.

74
00:10:06,810 --> 00:10:12,610
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.

75
00:10:13,690 --> 00:10:21,310
We have some real flight software that runs on several operational missions currently, but it's cross-compiled for Linux.

76
00:10:21,310 --> 00:10:28,210
So it's not running on an embedded processor, a power PC, or an arm, or some FPGA.

77
00:10:28,370 --> 00:10:38,070
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.

78
00:10:38,070 --> 00:10:44,010
But there are technologies that exist where you can get super high fidelity, and we've used those in the past for several things.

79
00:10:44,590 --> 00:10:49,970
Things like Simix, or QEMU, or TCM.

80
00:10:49,970 --> 00:10:58,530
These are different technologies that you can use to have higher fidelity simulations to run software compiled for target.

81
00:10:58,530 --> 00:11:01,310
So those can be integrated in these simulators as well.

82
00:11:01,310 --> 00:11:08,190
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.

83
00:11:08,190 --> 00:11:17,470
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.

84
00:11:17,470 --> 00:11:22,210
So that helps us understand the orbit and how we're progressing there.

85
00:11:22,210 --> 00:11:23,850
So here we go.

86
00:11:24,470 --> 00:11:28,610
And you can build your own one of these with some sources from GitHub.

87
00:11:28,610 --> 00:11:36,370
So these are linked here, OpenSATKit and NOS3 have some great components that you can construct something similar for yourself.

88
00:11:37,010 --> 00:11:48,970
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.

89
00:11:48,970 --> 00:11:51,950
One in California, one in Spain, one in Australia.

90
00:11:51,950 --> 00:11:58,710
So one would be Australia's in Canberra, Spain, Madrid, California, out near LA.

91
00:11:58,710 --> 00:12:07,090
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.

92
00:12:07,090 --> 00:12:11,010
So this mimics an RF sniffing capture.

93
00:12:11,010 --> 00:12:13,410
And then we're going to replay that with TCP replay.

94
00:12:13,410 --> 00:12:25,790
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.

95
00:12:25,810 --> 00:12:34,710
And basically it's around $7,000 and you could get some equipment that could record, capture, and transmit signal to a lower orbit.

96
00:12:34,710 --> 00:12:39,390
So it's definitely achievable for, you know, people who have a little bit of money.

97
00:12:39,390 --> 00:12:45,930
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.

98
00:12:45,930 --> 00:12:57,150
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.

99
00:12:57,210 --> 00:12:59,470
So to prevent, you know, these type of things from happening.

100
00:12:59,470 --> 00:13:11,290
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.

101
00:13:11,470 --> 00:13:14,230
Okay, so setting up the attack.

102
00:13:14,230 --> 00:13:21,210
So in our simulation, the satellite is visible to the ground station over the Madrid ground station.

103
00:13:21,210 --> 00:13:22,430
So it's there.

104
00:13:22,430 --> 00:13:30,070
And then in the bottom middle here, you see a signal lock in that window, it says, okay, it's locked, it's acquired.

105
00:13:30,070 --> 00:13:33,210
So it's sending the connect message, and then it's uplinking the command.

106
00:13:33,210 --> 00:13:36,430
So you see several commands being transmitted.

107
00:13:36,750 --> 00:13:38,230
You know, that's a bunch of numbers there.

108
00:13:38,230 --> 00:13:44,090
But what that does is you look in the far right, you see the flight software that's running.

109
00:13:44,090 --> 00:13:50,730
That's the, you know, that's kind of like the UART window of a flight software, where you have the flight software responding.

110
00:13:50,890 --> 00:13:53,030
You see it processes these NOOP commands.

111
00:13:53,030 --> 00:14:01,250
So in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know, in our terminology.

112
00:14:01,250 --> 00:14:05,050
So just to see if the application running on board is alive.

113
00:14:05,430 --> 00:14:12,290
So upon receiving that command, the flight software indeed does process that command and downloads the event messages, and the command counters increment.

114
00:14:12,290 --> 00:14:17,270
So you see here in the ground, you see that the event messages are processed.

115
00:14:17,270 --> 00:14:20,870
It says, hey, there was a NOOP command, and it's downlinked to the ground.

116
00:14:20,870 --> 00:14:23,890
And then you see the command counters increment accordingly.

117
00:14:23,890 --> 00:14:34,050
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.

118
00:14:34,050 --> 00:14:35,170
So it goes to one.

119
00:14:35,570 --> 00:14:41,970
Now the satellite in our scenario is in transit between Madrid and Canberra.

120
00:14:42,130 --> 00:14:45,550
And you see in the ground station simulation that it's lost signal.

121
00:14:45,550 --> 00:14:47,530
So it's no longer in view.

122
00:14:47,530 --> 00:14:50,930
So now here's where we could actually do our replay attack.

123
00:14:50,930 --> 00:14:57,330
So in a real world scenario, you would need equipment, obviously, in the Madrid area to capture the RF traffic.

124
00:14:57,330 --> 00:15:05,590
And then somewhere over India, in this example, you would need transmit capability to be able to send transmit the information to the satellite.

125
00:15:05,810 --> 00:15:11,050
So in our scenario, it's a lot easier, obviously, because we're using just the TCP replay.

126
00:15:11,050 --> 00:15:13,250
And here's just a simple command.

127
00:15:13,250 --> 00:15:16,850
It replays the PCAP file that was captured.

128
00:15:16,850 --> 00:15:23,850
And then you see the flight software respond accordingly with the same event messages within the UART.

129
00:15:24,010 --> 00:15:31,730
But what you don't see is any event messages on the ground station because you were in between passes at that point.

130
00:15:31,730 --> 00:15:39,430
And the command counters, you notice when you establish the downlink again over Canberra that the command counters went up.

131
00:15:39,430 --> 00:15:48,190
So the flight software is reporting, hey, I received another command and, you know, in between ground passes, which would be odd.

132
00:15:48,190 --> 00:16:06,990
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.

133
00:16:06,990 --> 00:16:17,590
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.

134
00:16:17,590 --> 00:16:21,690
So there's a lot of telemetry points out there that could help with that.

135
00:16:21,770 --> 00:16:24,430
So that wraps up the command replay.

136
00:16:24,430 --> 00:16:32,850
So essentially what we did was capture the command link up and then we replayed it and we saw that it processes.

137
00:16:32,850 --> 00:16:38,150
So we'll move on to command link intrusion, which is a little bit different.

138
00:16:38,150 --> 00:16:43,790
It's a slight different take on a command command link attack.

139
00:16:43,930 --> 00:17:01,190
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,

140
00:17:01,190 --> 00:17:06,970
theoretically, you could craft your own packet that matches that structure and just send it up and see if it processes the command.

141
00:17:06,970 --> 00:17:08,190
So you're not really replaying anything.

142
00:17:08,190 --> 00:17:14,830
You're just constructing your own raw command packet and then uplinking it and seeing what happens.

143
00:17:14,970 --> 00:17:17,250
So let's try that out and see how it works.

144
00:17:17,750 --> 00:17:27,850
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.

145
00:17:27,850 --> 00:17:31,270
You can record the RF on the downlink and record it as well.

146
00:17:31,270 --> 00:17:40,910
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.

147
00:17:40,910 --> 00:17:49,930
So you see that information there and that implies that they're using CoreFlight executive or CoreFlight software.

148
00:17:50,170 --> 00:17:53,950
And so then you can say, well, that's available on GitHub, I believe.

149
00:17:53,950 --> 00:17:59,210
So this is where that comment about default configs really comes into play.

150
00:17:59,210 --> 00:18:06,150
So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol.

151
00:18:06,150 --> 00:18:13,790
So then you get into this research study on command packet structures, which is a fun study.

152
00:18:13,790 --> 00:18:21,430
I would not recommend it for people if they're not really interested in it because it's a little bit of a read.

153
00:18:21,750 --> 00:18:28,090
So we're looking, we start to break down how these systems work from a protocol perspective.

154
00:18:28,090 --> 00:18:35,010
So we have space packets and then we're gonna get into some really space buzzword bingo here.

155
00:18:35,010 --> 00:18:36,410
So I apologize for that.

156
00:18:36,410 --> 00:18:40,690
But for the people who know what this is, you'll get it.

157
00:18:40,690 --> 00:18:53,970
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.

158
00:18:53,970 --> 00:19:01,630
So that's kind of how this structure works is CLTU, transfer frame headers, space packet, and then the trailers.

159
00:19:01,630 --> 00:19:09,050
So then we start looking in the CCSDS protocol and we understand, okay, this is the space packet.

160
00:19:09,050 --> 00:19:11,130
These are the octets that are there.

161
00:19:11,130 --> 00:19:17,950
And then we start really diving into some of these documents and we say, okay, well, this is what the primary header is.

162
00:19:17,950 --> 00:19:19,810
This is what a transfer frame looks like.

163
00:19:19,810 --> 00:19:22,630
This is what the transfer frame primary header looks like.

164
00:19:22,630 --> 00:19:24,510
This is what the CLTU looks like.

165
00:19:24,510 --> 00:19:31,250
And then so we're kind of in this overload of terminology, protocol breakdown, things like that.

166
00:19:31,250 --> 00:19:37,170
So it gets a little cumbersome and confusing, but it's important to understand all these things.

167
00:19:37,170 --> 00:19:41,470
And it's also important to realize that these protocols are open source protocols.

168
00:19:41,470 --> 00:20:00,710
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.

169
00:20:00,710 --> 00:20:02,770
So it's easy.

170
00:20:02,770 --> 00:20:09,650
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.

171
00:20:10,190 --> 00:20:17,730
So from our transmission, since there's no encryption on that, you just basically have the raw number structure.

172
00:20:17,810 --> 00:20:34,730
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.

173
00:20:34,730 --> 00:20:36,170
So let's look here.

174
00:20:36,170 --> 00:20:41,690
We see the, the fives in our scenario is the acquisition sequence.

175
00:20:42,030 --> 00:20:45,530
And then we've determined where the CLTU is.

176
00:20:45,870 --> 00:20:47,950
So we've now, we've got the CLTU.

177
00:20:47,950 --> 00:20:49,830
So let's break that down and see what we can get.

178
00:20:49,830 --> 00:20:53,130
So then we take off the headers and trailers in this example.

179
00:20:53,130 --> 00:21:02,790
And then now we have this subset, and then we have this code blocks and these check bytes, and we take those out.

180
00:21:02,810 --> 00:21:10,690
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.

181
00:21:10,690 --> 00:21:12,350
So now we've got that.

182
00:21:12,350 --> 00:21:14,630
So let's take out the header on that.

183
00:21:14,630 --> 00:21:16,850
And now we have the command packet.

184
00:21:16,850 --> 00:21:19,350
So this is the one that we were looking for.

185
00:21:19,350 --> 00:21:23,030
So with all those numbers, this is really what we were looking for.

186
00:21:23,030 --> 00:21:29,410
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.

187
00:21:30,010 --> 00:21:36,030
So from that, from the telemetry stream, we've kind of discussed, we see this no op command that came down.

188
00:21:36,030 --> 00:21:50,150
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.

189
00:21:50,150 --> 00:22:00,130
So because if you look at the, the header file for the message IDs, for the CFE table, command message ID, you see 1804.

190
00:22:00,190 --> 00:22:09,210
So that would indicate like the high likelihood of actually the software's using these default message ID types.

191
00:22:09,210 --> 00:22:19,850
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.

192
00:22:19,850 --> 00:22:26,050
So let's see if we can, we can reconstruct a packet with this knowledge and see what we can do with it.

193
00:22:26,350 --> 00:22:29,730
So with this knowledge, let's play around a little bit and see what we can do.

194
00:22:29,730 --> 00:22:40,530
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.

195
00:22:40,850 --> 00:22:47,670
So you have to do a little digging and understand the functionality of this software, but luckily all that information is open source.

196
00:22:47,670 --> 00:22:57,010
So once you dig in a little bit, you see, you notice there's this functionality within the CoreFlight software called ES.

197
00:22:57,010 --> 00:23:02,690
It's an ES application where you can potentially, you know, have control over the applications on board.

198
00:23:02,690 --> 00:23:08,010
So we're going to see if we can reconstruct a packet to do a reboot of a particular application.

199
00:23:08,010 --> 00:23:14,510
So in the real world, you know, you would have to reverse engineer the packet structure of the RF signal.

200
00:23:14,510 --> 00:23:22,490
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.

201
00:23:22,490 --> 00:23:30,030
So we use that 1806 because that's the default message ID for the ES application.

202
00:23:30,030 --> 00:23:38,350
So that tells the flight software, hey, this command is meant for the ES application to process once it gets on the satellite.

203
00:23:38,730 --> 00:23:54,010
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.

204
00:23:54,110 --> 00:23:59,830
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.

205
00:23:59,830 --> 00:24:04,030
So let's send this raw packet up and see what we can do.

206
00:24:04,370 --> 00:24:09,290
So we send that raw packet up to the satellite and look at that.

207
00:24:09,290 --> 00:24:15,550
So we see in the UR of the actual flight software that we have some sort of response.

208
00:24:15,750 --> 00:24:22,230
So you see at the top of the window, you see CFE ES restart app initiated for HK.

209
00:24:22,230 --> 00:24:24,130
So it looks like it was successful.

210
00:24:24,130 --> 00:24:37,230
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.

211
00:24:37,230 --> 00:24:46,350
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.

212
00:24:46,350 --> 00:24:48,150
So that's kind of the response.

213
00:24:48,150 --> 00:24:52,990
So the question is like, okay, why does the replay attack work?

214
00:24:52,990 --> 00:24:55,770
Why does this command-link intrusion attack work?

215
00:24:55,950 --> 00:25:03,270
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.

216
00:25:03,270 --> 00:25:07,170
But it really gets down to the protocols and some of the protections.

217
00:25:07,170 --> 00:25:19,110
So in this example, there's a communications operational procedure that typically runs on a satellite, at least ones that operate CCSDS called COP1.

218
00:25:19,250 --> 00:25:27,310
And that helps with sequencing to make sure that the sequence of the commands and the packets received are proper.

219
00:25:27,410 --> 00:25:38,130
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.

220
00:25:38,130 --> 00:25:46,270
So COP1 would have provided some level of protection, but that can be fudged and gotten around if you know what you're doing.

221
00:25:46,310 --> 00:25:56,290
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.

222
00:25:56,490 --> 00:26:05,250
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.

223
00:26:05,250 --> 00:26:12,790
But the point was just to articulate that there are sequencing protections that you can put in to help with the replay.

224
00:26:12,950 --> 00:26:18,890
But the real control that you want is encryption and authentication.

225
00:26:18,890 --> 00:26:23,910
So you really need to encrypt and authenticate the command link.

226
00:26:23,910 --> 00:26:33,670
So it's not enough to just do encryption because you theoretically could just replay an encrypted link and it would process accordingly.

227
00:26:33,670 --> 00:26:36,470
So you need the authentication on the command link as well.

228
00:26:36,470 --> 00:26:37,150
So that's important.

229
00:26:37,150 --> 00:26:38,570
So you need both.

230
00:26:38,630 --> 00:26:50,690
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.

231
00:26:50,690 --> 00:26:57,130
So you need to authenticate and you need to do cryptography to ensure that these attacks won't work.

232
00:26:57,630 --> 00:27:02,910
Okay, so now we're going to jump into denial of service via GPS jamming.

233
00:27:02,910 --> 00:27:07,190
So the first two were particularly to the command link.

234
00:27:07,190 --> 00:27:10,690
So those were intrusion and replay.

235
00:27:10,690 --> 00:27:23,650
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.

236
00:27:23,690 --> 00:27:41,230
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.

237
00:27:41,870 --> 00:27:51,090
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.

238
00:27:51,090 --> 00:27:53,430
So it's relatively simple to do.

239
00:27:54,550 --> 00:28:03,050
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.

240
00:28:03,150 --> 00:28:22,110
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,

241
00:28:22,110 --> 00:28:23,110
the flight software.

242
00:28:23,510 --> 00:28:33,170
So here is just a graphical representation of some of the telemetry and dynamics data for this particular sim as it's operating.

243
00:28:33,470 --> 00:28:46,230
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.

244
00:28:46,690 --> 00:28:56,550
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.

245
00:28:56,550 --> 00:29:01,070
So in the middle here, you see the GPS data packet counts increasing.

246
00:29:01,070 --> 00:29:03,990
So you see it go from 920 to 944.

247
00:29:03,990 --> 00:29:05,170
So everything's optimal here.

248
00:29:05,170 --> 00:29:12,310
We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine.

249
00:29:12,310 --> 00:29:26,490
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.

250
00:29:26,490 --> 00:29:34,670
So we can block about anything that's flowing across the Spacewire bus, or 5053 bus for that matter, and see what happens.

251
00:29:34,670 --> 00:29:40,130
So once you initiate this block sequence, you see the ground telemetry values freeze.

252
00:29:40,130 --> 00:29:43,290
So you see, which indicates the gray background there.

253
00:29:43,290 --> 00:29:48,550
So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore.

254
00:29:48,550 --> 00:29:51,030
For some reason, it's not being downlinked.

255
00:29:51,030 --> 00:29:54,650
And that's because it's not being actually provided to the Singapore computer for downlink.

256
00:29:54,650 --> 00:29:56,570
So you see that freeze.

257
00:29:57,190 --> 00:30:10,930
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.

258
00:30:11,290 --> 00:30:16,350
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.

259
00:30:16,610 --> 00:30:31,930
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.

260
00:30:31,930 --> 00:30:41,890
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.

261
00:30:42,330 --> 00:30:48,030
So what we're going to do here is see what the autonomous flight response is once the GPS signal is blocked.

262
00:30:48,590 --> 00:30:54,310
So safe mode is an operational mode, where a lot of non-essential systems are shut down.

263
00:30:54,310 --> 00:31:03,810
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.

264
00:31:03,810 --> 00:31:07,230
So preservation of the spacecraft is the highest priority.

265
00:31:07,230 --> 00:31:16,310
So here you see in the downlink telemetry, the flight software is starting to do its autonomous fault management.

266
00:31:16,310 --> 00:31:21,570
It's running what are called RTSs, so relative time sequences.

267
00:31:21,570 --> 00:31:25,110
So these are things, these are just automated flight responses that are there.

268
00:31:25,210 --> 00:31:34,750
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.

269
00:31:34,750 --> 00:31:36,590
So it's starting to safe itself.

270
00:31:37,030 --> 00:31:43,670
And in the telemetry you see from the attitude control mode perspective, it's reached its desired some point state at this point.

271
00:31:44,010 --> 00:31:50,510
So why would you perform a denial service, you know, like GPS jamming on something?

272
00:31:50,510 --> 00:31:59,110
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.

273
00:31:59,350 --> 00:32:02,610
Maybe you're wanting a mission to not achieve any objectives.

274
00:32:02,610 --> 00:32:04,810
But what if you're a little bit smarter than that?

275
00:32:05,290 --> 00:32:10,990
And you understand the autonomous fault response for satellites, and you understand the design and fault management a little bit more.

276
00:32:10,990 --> 00:32:20,330
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.

277
00:32:20,510 --> 00:32:26,610
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.

278
00:32:27,270 --> 00:32:29,650
Similar things do happen for spacecraft.

279
00:32:29,650 --> 00:32:36,030
So forcing a spacecraft into safe mode could potentially open up additional vectors that aren't there.

280
00:32:36,030 --> 00:32:51,770
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.

281
00:32:51,770 --> 00:32:54,410
Just depends on the fault management response.

282
00:32:54,530 --> 00:32:56,590
That's a design decision.

283
00:32:56,730 --> 00:33:07,390
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.

284
00:33:07,390 --> 00:33:17,670
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.

285
00:33:17,730 --> 00:33:20,190
We talk about the cyber safe mode.

286
00:33:20,190 --> 00:33:26,110
That's a slight transition from the traditional safe mode terminology.

287
00:33:26,110 --> 00:33:31,990
But it's basically it's a safe mode that's cyber hardened to a degree.

288
00:33:32,190 --> 00:33:42,990
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.

289
00:33:42,990 --> 00:33:45,390
So that's a concept.

290
00:33:45,390 --> 00:33:49,850
That's a kind of newer concept that's being discussed in the space sectors.

291
00:33:49,850 --> 00:33:52,350
But it should be there.

292
00:33:52,370 --> 00:33:59,550
Because knowing, you know, more and more people that understand space and understand fault management response may use that against you.

293
00:33:59,550 --> 00:34:03,330
So you may want to think about that a little bit more as you do your design.

294
00:34:03,990 --> 00:34:07,790
So here's some recommendations for just generalized protection.

295
00:34:07,790 --> 00:34:14,310
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.

296
00:34:14,310 --> 00:34:20,270
But this is more in line with protecting against, you know, leveraging fault management against you.

297
00:34:20,270 --> 00:34:29,790
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.

298
00:34:30,230 --> 00:34:35,990
And other design considerations about always encrypting information, especially on the downlink.

299
00:34:35,990 --> 00:34:44,850
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.

300
00:34:44,850 --> 00:34:49,430
But there could be a lot of good information that is ascertained from telemetry.

301
00:34:49,430 --> 00:34:58,810
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.

302
00:35:00,210 --> 00:35:03,110
And these are other some design considerations that are that are here.

303
00:35:03,110 --> 00:35:04,110
I won't read them all to you.

304
00:35:04,110 --> 00:35:16,090
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.

305
00:35:16,090 --> 00:35:22,770
So these are just some considerations to think about as you're building your design for a spacecraft.

306
00:35:23,390 --> 00:35:28,990
So with that being said, those are just an example of doing some protection.

307
00:35:28,990 --> 00:35:38,570
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.

308
00:35:38,570 --> 00:35:45,210
So at this point, we've talked about, you know, the command link intrusion.

309
00:35:45,210 --> 00:35:49,210
We've talked about command replay, some denial of service.

310
00:35:49,390 --> 00:35:52,330
But let's talk more generically about space systems in general.

311
00:35:52,330 --> 00:36:02,570
So I like to use defense in depth as a presentation material and discuss and a principle for design as many people do.

312
00:36:02,570 --> 00:36:06,930
I mean, I think anyone in the security community really understands the fits and depth.

313
00:36:07,190 --> 00:36:12,110
But with the fits and depth, I like to illustrate basically using an onion.

314
00:36:12,110 --> 00:36:22,410
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.

315
00:36:22,410 --> 00:36:25,890
But in the space domain, it's a little bit different, but it's somewhat similar.

316
00:36:25,890 --> 00:36:33,790
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.

317
00:36:33,790 --> 00:36:37,810
So this first graphic here is kind of the ground system.

318
00:36:37,810 --> 00:36:50,550
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.

319
00:36:51,030 --> 00:36:58,170
So there's, you know, this isn't all inclusive, not every subcategory, you know, within each block is listed.

320
00:36:58,190 --> 00:37:05,970
Due to space, but it provides a good list of things that you would expect to be at each layer of the onion.

321
00:37:05,970 --> 00:37:13,190
So from a data perspective, you may have, you know, data at rest encryption, you may have Tempest that you need to worry about.

322
00:37:13,410 --> 00:37:25,250
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.

323
00:37:25,570 --> 00:37:32,650
Your endpoints, your heads, your hips, your AV malware, DLP, file integrity, things like that.

324
00:37:32,650 --> 00:37:38,950
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.

325
00:37:38,950 --> 00:37:40,750
And it's important to apply controls to each layer.

326
00:37:40,750 --> 00:37:52,650
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.

327
00:37:52,790 --> 00:38:00,150
And then hope that gets me there because you have insiders, you have other avenues where you need monitoring capability, you need protections.

328
00:38:00,310 --> 00:38:02,310
So that's pretty common.

329
00:38:02,410 --> 00:38:05,250
You know, that's nothing groundbreaking from a ground perspective.

330
00:38:05,250 --> 00:38:09,930
But similarly, you can do the kind of the exact same approach for the vehicle itself.

331
00:38:09,930 --> 00:38:14,130
So this is a onion representation for the vehicle.

332
00:38:14,130 --> 00:38:30,850
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.

333
00:38:30,850 --> 00:38:32,870
So that's kind of a new area.

334
00:38:32,870 --> 00:38:38,450
What's being researched today is kind of onboard cyber monitoring and intrusion detection prevention.

335
00:38:38,450 --> 00:38:42,390
That's not typical on a lot of missions right now.

336
00:38:42,390 --> 00:38:49,830
What you see currently, a lot of the focus on protecting space vehicles is really geared around the crypto comms area.

337
00:38:49,910 --> 00:38:58,730
So, you know, the authentication encryption and the comms link, the transect, things like that.

338
00:38:58,910 --> 00:39:09,290
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.

339
00:39:09,290 --> 00:39:20,910
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.

340
00:39:22,030 --> 00:39:32,350
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.

341
00:39:32,350 --> 00:39:47,850
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.

342
00:39:47,870 --> 00:39:51,010
But it's not really an option moving forward.

343
00:39:51,350 --> 00:39:57,630
Satellites are too critical to our everyday life or operations of our nation and the world, honestly.

344
00:39:57,630 --> 00:40:06,090
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.

345
00:40:06,090 --> 00:40:16,390
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.

346
00:40:17,050 --> 00:40:21,110
It's a lot cheaper to get assets into space.

347
00:40:21,810 --> 00:40:25,010
So, and defensive depth needs to be a big part of the solution.

348
00:40:25,010 --> 00:40:29,450
So we need to design security at the beginning, which is kind of cliche, but obvious.

349
00:40:29,890 --> 00:40:38,670
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.

350
00:40:39,030 --> 00:40:44,890
So, you know, from a defense in depth perspective, and, you know, understanding security, it's important.

351
00:40:44,890 --> 00:40:52,810
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.

352
00:40:52,810 --> 00:41:00,710
So it's, you know, for years and years, you see this at, you know, at the IoT village as well.

353
00:41:00,710 --> 00:41:07,430
For years and years, people have kind of ignored security in the industrial control systems, OT, IoT arena.

354
00:41:07,710 --> 00:41:12,450
And it's not just been the last few years, people have really started understanding that threat factor.

355
00:41:13,450 --> 00:41:20,390
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.

356
00:41:20,390 --> 00:41:26,030
So let's try to learn from that lesson and not wait till something really bad happens to make corrections.

357
00:41:26,030 --> 00:41:30,610
Because we know there are vulnerabilities, we know there are corrections, we know there are things we can do.

358
00:41:30,610 --> 00:41:32,990
So we should be doing that.

359
00:41:33,710 --> 00:41:39,090
And the small set marketplace, you know, and the embedded security community is evolving.

360
00:41:39,150 --> 00:41:43,470
There's a lot of commercial things that are being put out, there's some open source solutions that are out there.

361
00:41:43,690 --> 00:42:00,390
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.

362
00:42:01,430 --> 00:42:06,110
As opposed to some niche areas, niche markets, people doing things.

363
00:42:06,110 --> 00:42:13,270
So it's important for us to get, you know, leverage the explosion in this market.

364
00:42:13,270 --> 00:42:26,890
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.

365
00:42:27,190 --> 00:42:31,210
Because, you know, the path of least resistance is often used.

366
00:42:31,210 --> 00:42:41,390
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.

367
00:42:41,390 --> 00:42:49,790
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.

368
00:42:50,970 --> 00:43:00,790
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.

369
00:43:00,970 --> 00:43:05,110
And there's a lot of investment that needs an education, training and talent development and retention.

370
00:43:05,110 --> 00:43:10,670
So I, I feel like there's a huge step forward this year at DEF CON with the hack-a-sat.

371
00:43:10,670 --> 00:43:20,830
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.

372
00:43:21,710 --> 00:43:27,670
And it, you know, there's these open source technologies that are put out that you can build your own ground-to-space simulation.

373
00:43:27,670 --> 00:43:28,830
You can start learning.

374
00:43:29,030 --> 00:43:32,790
You know, five years ago, there was not that much out there to learn.

375
00:43:32,790 --> 00:43:43,230
So the, the activation energy and the level of access to information was, wasn't there for the security community to get into it.

376
00:43:43,490 --> 00:43:56,630
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.

377
00:43:57,090 --> 00:44:07,190
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.

378
00:44:07,250 --> 00:44:19,750
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.

379
00:44:20,370 --> 00:44:24,830
And that's, you know, built for target and running a lot of tests.

380
00:44:24,830 --> 00:44:27,730
You don't have to buy these million dollar space platforms.

381
00:44:28,270 --> 00:44:38,970
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.

382
00:44:40,010 --> 00:44:52,210
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.

383
00:44:52,210 --> 00:45:01,230
I mean, coming from the government arena, you really get into this compartmentalization of information and the need to know and things like that.

384
00:45:01,230 --> 00:45:13,130
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.

385
00:45:13,650 --> 00:45:18,570
And we're not trying to point fingers at people and, you know, say that, oh, your implementation is bad.

386
00:45:18,570 --> 00:45:26,230
It's just we need to learn together and make things better and share what we learn and do presentations like this.

387
00:45:26,750 --> 00:45:29,950
So, with that being said, that's about all I have to present.

388
00:45:29,950 --> 00:45:40,750
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.

389
00:45:40,950 --> 00:45:49,830
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.

390
00:45:49,830 --> 00:45:55,330
And they're going to open source a lot of those CTFs qualifications and things.

391
00:45:55,330 --> 00:46:05,250
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.

392
00:46:05,530 --> 00:46:08,710
This is a really exciting exercises that were put together.

393
00:46:08,710 --> 00:46:19,270
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.

394
00:46:19,730 --> 00:46:24,450
And there's some info here on, you know, jamming if you want to learn a bit more about that.

395
00:46:24,450 --> 00:46:31,150
And the paper that was published in November 2019 is also linked here for your reference.

396
00:46:31,150 --> 00:46:36,730
So with that being said, that is all I have to present.

397
00:46:36,730 --> 00:46:38,070
And thank you so much.

398
00:46:38,070 --> 00:46:40,970
And I'll take questions in the offline session.

399
00:46:40,970 --> 00:46:41,890
Appreciate it.