After introducing space systems and the constraints and challenges of operating within the space environment, we covered extensively the threats to space vehicles and their mission. Discussing at length the vectors an attacker might leverage to introduce those threats and then ultimately walking through a pair of scenarios to drive home how the various threats and vectors could be combined in a cyber attack campaign to wreak havoc across a space system and its operations, I would like to now cover some of the cyber problems related to space systems which will need to be acknowledged and addressed by both the space and cybersecurity communities moving forward.
The Cost Problem
Space systems and especially complex space systems involving a mesh of vehicles have a cost problem. By cost I mean that the cost of implementing a fix to a cybersecurity problem is hard to justify to a space system operator as being worth of implementation, if the cost is definable at all. The easiest way to represent such cost to a space system owner or operator is by identifying the amount of their mission window that will be consumed by doing something. That something might be changing a configuration which will have negligible impact to the overall mission life span, or it could be uploading and re-installing a new version of an operating system for a space vehicle resident component.
A configuration change likely has a low size so it doesn’t take up much of a pass to upload it to the space vehicle, and implementing the configuration change on the onboard computing device might take only seconds. Conversely re-installing an operating system might take many passes to upload the files necessary. Worse, installation might take a longer period of time and come with the added risk that if there is an issue during the re-install process and probably power cycling of that component, it might stop functioning all together.
Given the latter I think the decision from many system operators would be to accept the risk of someone potentially compromising the component or having an error due to a bug happen than introduce the risk of potentially irreparably damaging the space vehicle during re-install. Since this is the case, as cybersecurity professionals, we need to be able to tell the story to the owner about how the vulnerability or flaw they don’t necessarily understand really poses a risk and impact to their space system so they can make better informed decisions.
More difficult than situations where cost is known are the situations where it is not. It is one thing to try and justify taking ten passes to upload a fix and 1 hour of time on the vehicle to install as well as risking a reboot. That would be a situation that can easily be translated into a percentage of space vehicle mission lifetime. It is entirely another thing to try and convince an owner of a space system mesh to roll out an operating system re-install across a mesh of satellites and not be able to communicate what the impact to operations will be.
There is a whole lot more analysis that needs to be done to calculate how long it takes to get something like a driver or an operating system up into one or more space vehicles in the mesh and then proliferate that file across the mesh and install and power cycle the updated component. Coming up with the answer to that problem in a representation of the time it takes and the risk to the various space vehicles as they power cycle is difficult on its own. Then comparing that to the overall operational life span of the mesh and the immediate mission impact of power cycling the devices represents a more complex problem.
In a mesh, is it acceptable if one out of ten satellites to have issues after the power cycle? What about 1 in 100? Optimizing this problem to identify a way to proliferate an update file across a mesh and install and power cycle when various space vehicles are not actively conducting payload mission activity or communicating with a ground station would certainly make the process more appealing to space system owners. That being said, the analysis and problem solving to come up with these methods would require significant investment from skilled space professionals, machine learning, and cybersecurity.
What can’t happen is the owner of a large mesh of satellites arguing for not addressing a critical cybersecurity concern because they are willing to assume the risk on the premise that as long as only one or two of their satellites get hacked, they can still operate the mesh and carry out the mission. If a cyber security vulnerability can affect one satellite in a mesh, it can affect all of them and the repercussions of a cyber attack could spread across a mesh of satellites just as quickly as that mesh passes payload mission data around itself and down to the ground.
The Cyber Warfare Problem
Unfortunately for the space domain, it has a big bad boogeyman in cyber warfare and a boogeyman that is exceptionally suited to space domain operations. A quick aside on cyber warfare, it has a cost-benefit problem of its own. Let’s say you want to disable an enemy radar site to safely fly a rescue mission into the enemy country. If you wanted to use cyber effects to do so, you have to hope that the site is accessible, and you have the exploits necessary to gain access.
Even assuming that away, a cyber effect against the radar site is not guaranteed to function as intended, and a battle damage assessment of whether or not it worked well enough to completely disable the radar is nearly impossible. The other option is with a kinetic effect where I can just shoot a missile at the radar site whenever I want, observe the crater in the ground where the radar site used to be, and then safely fly over it on my rescue mission. Now, if I was flying the helicopter on that rescue mission, I will be a lot more comfortable flying over the smoking crater of what used to be a radar site than looking at what appears to be an intact radar system thinking to myself, man I hope those cyber nerds did their job.
This is a problem in most warfighting domains, air, land, and sea, for instance, where a kinetic effect often has a much better cost benefit than a cyber one. In space the opposite is true. A kinetic effect against, say, a satellite in space would create a debris field in a popular orbital plane, travelling thousands of miles per hour and potentially destroying unrelated space vehicles belonging to any number of people. The space domain is the perfect place for cyber warfare because if it can be done successfully, a satellite will be disabled quietly on orbit or burn itself up in the atmosphere and pose negligible risk to other space systems.
The other issue for the space domain concerning cyber warfare is that any cyber action taken on a space vehicle is almost sure to be an attack effect that ultimately disables the satellite or its mission capability. Intelligence gathering or even altering of payload mission data is easier to do from a cyber perspective and just as effective if done on a compromised ground station. So the only real reason to go through the trouble of getting code execution on the satellite is to damage or disable it or use it as a launch point to compromise other space vehicles or ground stations.
Tying together the facts that cyber warfare is particularly suited to the space domain and that cyber attacks against a space vehicle are almost certainly in an effort to disable or damage the space system, we come to another frightening conclusion. The most likely individuals to target space systems and the space vehicles that are operated within them are nation state or nation state sponsored actors and advanced persistent threats. This means that the cybersecurity threats posed to most space systems are to a one likely to be highly motivated, highly resourced, and highly skilled.
The Test Problem
Currently, for space specifically, there is a bit of a test problem. Where other environmental and operational risks are both mitigated during design and development as well as exercised, for cyber this is not the case. For the structural integrity of a space vehicle’s components, things are done like specifically torquing each bolt to a prescribed amount of torque determined by engineers. After this is done though, the space vehicle is still exercised through a vibration test to ensure that it holds up under the shaking it will experience during launch and deployment.
In some cases, government regulations dictate a validation of security controls on space systems tailored to their being a space vehicle or normal network like a ground station. This is similar to making sure all the bolts have been tightened with the correct amount of torque. The closest thing in the cyber domain to something like a vibration test would be to combine software testing and red teaming to actually exercise the code and computational activities on the space vehicle and ensure they are not easily compromised by an attacker despite having met validation checks of a cybersecurity risk framework. Without both compliance and an exercising of the space vehicle and ground station security apparatus, space systems will have an elevated and partially unknown cyber risk posture.
The Adaptation Problem
All non-cyber risks to a space vehicle can be considered mitigated when appropriate steps are taken to burn down that risk and those steps are verified, validated, and exercised. In the case of risks to the integrity of the space vehicle’s physical components, the risk of breaking during launch can be mitigated by appropriate construction and torque definitions and verification that they were followed during the build and validated through being exercised in a vibration test.
At that point the risk can be considered acceptable and that’s the end of it. With cybersecurity issues, not only do solutions need to continue to improve but they need to evolve with the threats. A cybersecurity risk mitigation solution for a space vehicle today might be nullified by a different vulnerability and exploit being discovered and weaponized tomorrow. As space systems adapt to cyber threats, those threats are also adapting to overcome the defenses of the space systems. This means that there can be no complacency by space system operators after initial cybersecurity checks are passed.
The Defense in Depth Problem
Another problem with current space system architectures and operations is the overly abundant trust between the systems that make up these systems of systems. It has resulted in most current systems having no defense in depth beyond the ground station. From the ground station up, everything is completely trusted, and the space vehicles and other ground stations trust what they get from each other completely. This is the case because it is more computationally efficient to trust what you are receiving from component to component on a space vehicle as well as from the ground station to the space vehicle and vice versa. This is also the same for mesh communications.
Implementing a little suspicion and verification of what is being passed from component to component and system to system in the space system will go a long way in preventing ease of attack and ease of attack proliferation across space systems. As computational resources on board space vehicles become more powerful, there will be enough resources to perform more permissions and rule-based security, and if a space system can afford the resource cost of implementing security solutions, they should.
The Modernization Problem
The last problem for cyber and space that I want to cover is the modernization problem. This is really manifested in two forms. First there is a need for modernization, and second there is a need to modernize correctly. The need for modernization is because the operating systems and software currently in use by space systems are stripped- down, resource-conscious, power budget–constrained in efforts to squeeze everything possible out of a space vehicle to accomplish the functional mission necessary using as little resources as possible. What this leads to though, is that via a compromised ground station, an attacker is essentially attacking the computing devices of yesteryear which have limited, if any, security implementations with the tools, exploits, and computing power of today.
As onboard computers grow in capability, they will likely transition from running one-off software, tiny and real-time operating systems and begin using more traditional Linux or Unix distributions. This makes it easier on those developing code for space vehicles as their code is more traditional, more portable, and easier to implement. They also get the benefit of having access to much larger communities of support. In general, it is just easier to implement functionality via software from a more modern operating system. While this makes it easier for developers to write code that runs effectively on the space vehicle, it also makes it easier for attackers to write malware that runs effectively on the space vehicle.
As space systems modernize and start using operating systems closer to what is seen in many places terrestrially, the attack surface of space systems will go from foreign to many attackers to familiar. I say this not to dissuade such modernization but to caution that as choices are made to move from something like VxWorks or OpenRTOS to things like CentOS or BSD, the full capability of those operating systems is utilized, not just from an ease of coding and higher functionality standpoint but also to leverage the more mature security solutions available to such operating systems like stateful software firewalls, mature permissions management, and the like.
The danger is that to make development of a space vehicle easier, the choice is made to use Linux operating system, but the security software and settings available to that Linux operating system are not used, installed, or running in an effort to still keep the operating system as lightweight on resources as possible. In doing so the space vehicle would be an extremely targetable and familiar target to malicious cyber actors. As developmental decisions to modernize are made, they need to be full implementations of modern solutions to include the security functions that can be utilized with them.
The Failure Analysis Problem
As the software definition of space vehicle (SV) components expands and the reliance of SVs on digital components increases, the threats posed by cyber attack are essentially innumerous and their potential impact immeasurable. The space industry has a robust failure analysis heritage; however, a purposeful cyber effect being the cause of a SV failure is likely to be overlooked for some time. This is due to the fact that an attacker skilled enough to gain access to the SV is likely capable of covering their tracks well and that the operators will focus on a failure analysis of what is known to them first. They will first ask questions of why did this component potentially physically fail? Then they will ask last if at all, did someone use a cyber attack to damage the SV? Until failure analysis begins with the cyber aspects such as the C&DH which ties all operations of the SV together or other integral components like SDRs, we will be actively losing ground to cyber attackers.
Conclusion
In conclusion I hope that this book has been educational to both cybersecurity professionals and any of those from the space industry or others that read it. To me the space domain is a really interesting and complex puzzle for cybersecurity, and I think that both industries need to embrace that they are inextricably tied. With the growth of the space industry and the overall increasing accessibility of space systems, the cybersecurity industry needs to understand the constraints and challenges of space operation.
In doing so we will be able to offer solutions that can be implemented in that unique environment that still allow space systems to accomplish their mission and not simply be another added constraint. The space industry needs to begin accepting that many of the threats to their systems while not cyber in nature can be brought about via cyber means. As the software definition of onboard functions increases, so too will the breadth of threats that a cyber attack could bring to bear on a space system.
Accepting that cybersecurity is a targeted and evolving risk to many aspects of space system operations is a must. Those responsible for space systems should go so far as at least taking a moment to ask the question, of any space system component having an issue, is this something that could be tied to a cyber attack, and has my space system been compromised? My hope in writing this book is that the scenarios of ships’ computers being used to terrorize and attack the crew on board or other space vehicles remain in my beloved science fiction franchises and stay out of reality.