Cause bit flip on memory via single event upsets
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The spacecraft shall use Error Detection and Correcting (EDAC) memory. {SV-IT-4} {SI-16} | |
| The spacecraft shall utilize an EDAC scheme to routinely check for bit errors in the stored data on board the spacecraft, correct the single-bit errors, and identify the memory addresses of data with uncorrectable multi-bit errors of at least order two, if not higher order in some cases. {SV-IT-4} {SI-16} | |
| The spacecraft shall integrate EDAC scheme with fault management and cyber-protection mechanisms to respond to the detection of uncorrectable multi-bit errors, other than time-delayed monitoring of EDAC telemetry by the mission operators on the ground. {SV-IT-4} {SI-16} | |
| The spacecraft's fault management solution shall utilize memory uncorrectable bit error detection information in a strategy to autonomously minimize the adverse effects of uncorrectable bit errors within the spacecraft. {SV-IT-4} {SI-16} | |
| The spacecraft's Interrupt Service Routine (ISR) shall have the ability to simultaneously update check-bits for [Program-defined] memory addresses. {SV-IT-4} {SI-16} |
| ID | Name | Description | |
|---|---|---|---|
| EX-0007 | Trigger Single Event Upset | Threat actors may utilize techniques to create a single-event upset (SEU) which is a change of state caused by one single ionizing particle (ions, electrons, photons...) striking a sensitive node in a spacecraft(i.e., microprocessor, semiconductor memory, or power transistors). The state change is a result of the free charge created by ionization in or close to an important node of a logic element (e.g. memory "bit"). This can cause unstable conditions on the spacecraft depending on which component experiences the SEU. SEU is a known phenomenon for spacecraft due to high radiation in space, but threat actors may attempt to utilize items like microwaves to create a SEU. | |
| IMP-0001 | Deception (or Misdirection) | Measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information into a system to induce the adversary to react in a manner prejudicial to their interests. Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the spacecraft. | |
| IMP-0005 | Destruction | Measures designed to permanently eliminate the use of a system, potentially through some physical damage to the system. Threat actors may destroy data, commands, subsystems, or attempt to destroy the victim spacecraft itself. This behavior is different from Degradation, as the individual parts are destroyed rather than put in a position in which they would slowly degrade over time. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0000 | Countermeasure Not Identified | This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact | None | None | ||
| 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 (initial access, execution, persistence, evasion, exfiltration, etc.) 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-4(5) 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 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) 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.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | ||
| 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 SC-5 SI-11 SI-17 SI-7(17) | A.5.29 A.5.25 A.5.26 A.5.27 | ||
| CM0045 | Error Detection and Correcting Memory | Use Error Detection and Correcting (EDAC) memory and integrate EDAC scheme with fault management and cyber-protection mechanisms to respond to the detection of uncorrectable multi-bit errors, other than time-delayed monitoring of EDAC telemetry by the mission operators on the ground. The spacecraft should utilize the EDAC scheme to routinely check for bit errors in the stored data on board the spacecraft, correct the single-bit errors, and identify the memory addresses of data with uncorrectable multi-bit errors of at least order two, if not higher order in some cases. | SI-16 | None | ||