Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim SV. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the SV to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the SV's reliability and integrity.
ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
CM0031 | Authentication | Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended. | AC-17(10) AC-17(10) AC-17(2) AC-18(1) IA-3(1) IA-4 IA-4(9) IA-7 SA-8(15) SA-8(9) SC-16(2) SC-32(1) SC-7(11) SI-14(3) | A.5.16 | ||
CM0050 | On-board Message Encryption | In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus. | AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) SA-8(18) SA-8(9) SA-9(6) SC-13 SC-16(2) SC-16(3) SI-19(4) SI-4(10) SI-4(25) | A.5.14 A.8.22 A.8.23 A.8.11 A.8.24 A.8.26 A.5.31 A.8.11 | ||
CM0032 | On-board Intrusion Detection & Prevention | Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system. | AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-5 IR-5(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5(3) SC-7(9) SI-10(6) SI-16 SI-17 SI-4 SI-4(10) SI-4(11) SI-4(16) SI-4(2) SI-4(25) SI-4(4) SI-4(5) SI-6 SI-7(17) SI-7(8) | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.7 A.8.16 A.8.16 A.8.16 | ||
CM0042 | Robust Fault Management | Ensure fault management system cannot be used against the spacecraft. Examples include: 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. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft. | CP-4(5) SA-8(24) SC-16(2) SC-24 SI-13 SI-17 | |||
CM0044 | Cyber-safe Mode | Provide the capability to enter the spacecraft into a configuration-controlled and integrity-protected state representing a known, operational cyber-safe state (e.g., cyber-safe mode). Spacecraft should enter a cyber-safe mode when conditions that threaten the platform are detected. Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode, authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and software functions to pre-attack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on equipment still available after a cyber-attack. The goal is for the spacecraft to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. Cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable. | CP-10 CP-10(4) CP-12 CP-2(5) IR-4 IR-4(12) IR-4(3) SA-8(21) SA-8(23) SA-8(24) SC-16(2) SC-24 SI-11 SI-17 SI-7(17) | A.5.29 A.5.25 A.5.26 A.5.27 | ||
CM0048 | Resilient On-board Timing | Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. | SC-16(2) SC-45 SC-45(1) SC-45(1) SC-45(2) SC-45(2) |