Risk Assessment of a Space System
The purpose of a risk assessment is to identify & evaluate risks to the mission and can be used to guide prioritization of mitigations, both design/implementation and procedural, and candidates for requirements. Space systems are a combination of traditional-IT components (e.g., ground systems, software), operational technology (e.g., industrial control systems), and spacecraft platforms (e.g., satellite bus). Risk to traditional-IT components & operational technology components is better understood than spacecraft risks. Applying traditional-IT based methodologies such as the NIST Risk Management Framework (RMF) to platforms has had mixed results. Therefore, this example assessment will be using threats agents, threat actions, vulnerabilities, and risk to derive technical security requirements.
Using the previously described threat model, impact and likelihood can be calculated and placed on a traditional 5x5 risk matrix where the most critical threats/risk appear in the upper right-hand corner of the matrix. This space specific threat model can be used for legacy space systems to identify current risks as well as for future deployments to identify potential future risks that can be mitigated via secure design choices. Below is a visual depiction of an example ranking on a 5x5 risk matrix. This analysis was performed assuming a rather simple ground to space architecture in low earth orbit with no predefined security requirements. This analysis resulted in a many common threats and vulnerabilities that a traditional low earth orbit mission would be exposed to.
Overlaying this 5x5 risk matrix analysis with the graphical depiction of cyber threats, the below image depicts the essential threats/vulnerabilities that should be addressed with the baseline control set or deployment of new mitigations for legacy systems. The items highlighted in red are the most essential to mitigate based on analysis using a space specific threat model that accounted for known adversary capabilities.
An expansion of the above graphic is listed in the below table to focus solely on the essential threats/vulnerabilities that require mitigation. The categories denoted with * are threats/vulnerabilities that have mitigations needed during development in addition to operations. Click the IDs below to view more information about the threats/vulnerabilities.
| Category | Essential Threats/Vulnerabilities to Mitigate for Space |
|---|---|
| Data | SV-AC-3: Compromised master keys or any encryption key. Encryption is great but self-defeating if key management is not properly implemented. |
| Spacecraft Software * | SV-SP-1: Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the flight software. Due to autonomy of spacecraft and increased usage of software on-board, software attacks can be mission ending. |
| SV-SP-3: Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, rootkit, or Trojan Horse. Outside of unintentional vulnerabilities with on-board software, malicious compromise of the software supply chain is a substantial threat and can be difficult to detect and prevent depending on the sophistication. Malicious logic embedded in software is difficult to detect due to the novel nature of it which can’t be detected using signatures. | |
| SV-MA-3: Attacks on critical software subsystems {AD&C, TT&C, C&DH, EPS}. Many critical components on the spacecraft are controlled by software and adversaries would target these mission critical sub-systems | |
| SBC | SV-AC-6: Lack of bus segregation (e.g., 1553 injection). Things are not containerized from the operating system or flight software perspective. Generally, the on-board architectures rely on trust and segregation is often not implemented. While this is a default security principle in traditional IT, it is lacking in most spacecraft architectures. |
| SV-AC-8: Malicious use of hardware commands - backdoors / critical commands. Some spacecraft components have built in backdoor commands which can be exploited if discovered. Only enable the required backdoor commands or disable all commands that are not authenticated and encrypted. | |
| SV-MA-8: Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. Power is a critical commodity on the spacecraft and the availability of the spacecraft is directly dependent on power. If not properly implemented, a compromised payload could drain spacecraft power | |
| SV-SP-11: Software Defined Radios (SDRs) cyberattack. SDRs are gaining in popularity and capability, these minicomputers are vulnerable to attacks like any other computational component. | |
| IDS/IPS | SV-AV-5: Using fault management system against you. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understand your safing procedures and not putting the spacecraft in a more vulnerable state is key to building a resilient spacecraft. |
| SV-AV-6: Complete compromise or corruption of running state can be possible if not engineered properly. High integrity controls need to be in place to revert to safe and secure state. | |
| SV-MA-5: Not being able to recover from cyberattack. Autonomy is required for spacecraft and a well-designed fault management strategy accompanied with the high integrity safe/secure state is crucial. | |
| Crypto | SV-IT-1: Communications system spoofing resulting in denial of service and loss of availability and data integrity |
| SV-CF-1: Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information | |
| SV-AC-1: Attempting access to an access-controlled system resulting in unauthorized access (i.e., command link intrusion) | |
| SV-AC-2: Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction | |
| Comms Link | SV-AV-1: Communications system jamming resulting in denial of service and loss of availability and data integrity |
| SV-AC-7: Weak communication protocols. Ones that don't have strong support for encryption and authentication within it. | |
| Ground * | SV-MA-7: Exploit ground system and use to maliciously to interact with the spacecraft. |
| Prevention * | SV-AC-4: Insider Threat not being properly mitigated to prevent malicious interaction or attacking the spacecraft |
| SV-SP-4: General supply chain interruption or manipulation. This affects both the hardware and software for both ground and spacecraft | |
| SV-SP-5: Hardware failure (i.e., tainted hardware). On-board the spacecraft ASICs and FPGAs are heavily used and at due to outsourcing the supply chains that can be compromised. | |
| SV-SP-10: Compromising the development environment to embed malicious logic or steal trade secrets. | |
| SV-MA-4: Not planning for security on spacecraft or designing in security from the beginning which is needed to properly build a cyber resilient space system |