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