CM0001

Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode;


Informational References

ID: CM0001
DiD Layer: IDS/IPS
CAPEC #:  74 | 166 | 578 | 581 | 620
NIST Rev5 Control Tag Mapping:  AC-3 | AC-3(11) | AC-4 | AC-4(23) | AU-5 | AU-5(5) | CA-7 | CA-7(6) | CM-12 | CM-12(1) | CP-4 | CP-4(5) | CP-10 | CP-10(4) | CP-12 | IR-4 | IR-4(3) | RA-3 | RA-3(1) | RA-9 | RA-10 | SA-3 | SA-3(1) | SA-5 | SA-8 | SA-8(21) | SA-8(23) | SA-8(24) | SA-11 | SA-11(9) | SC-24 | SC-47 | SI-11 | SI-17
Lowest Threat Tier to
Create Threat Event:  
V
Notional Risk Rank Score: 

High-Level Requirements

The Program shall protect all fault management documents (i.e., FMEA/FMECA artifacts) from inadvertent and inappropriate disclosure.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
This is not a cyber control for the spacecraft, but these controls would apply to ground system, contractor networks, etc. where design sensitive information would reside. NIST 800-171 is insufficient to properly protect this information from exposure, exfiltration, etc. Should require contractors to be CMMC 2.0 Level 3 certified (https://www.acq.osd.mil/cmmc/about-us.html). The Program shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. {SV-CF-3,SV-AV-5} {SA-5} Essential Elements of Information (EEI):
The Program shall protect documentation and Essential Elements of Information (EEI) as required, in accordance with the risk management strategy. {SV-CF-3,SV-AV-5} {SA-5} Least privilege and need to know should be employed with the protection of all documentation. Documentation can contain sensitive information that can aid in vulnerability discovery, detection, and exploitation. For example, command dictionaries for ground and space systems should be handles with extreme care. Additionally, design documents for missions contain many key elements that if compromised could aid in an attacker successfully exploiting the system.
The Program shall distribute documentation to only personnel with defined roles and a need to know. {SV-CF-3,SV-AV-5} {SA-5}
See threat ID SV-CF-3 to help with protecting design specific information, in this case the FMEA/FMECA artifacts so that particular fault responses are not disclosed via documentation. {SV-AV-5}
The spacecraft shall provide or support the capability for recovery and reconstitution to a known state after a disruption, compromise, or failure. {SV-AV-5,SV-AV-6,SV-AV-7} {CP-10,CP-10(4),IR-4} 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 SW functions to preattack 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 available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved.
The spacecraft shall 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). {SV-AV-5,SV-AV-6,SV-AV-7} {CP-12,SI-17,IR-4(3)}
The spacecraft shall enter a cyber-safe mode when conditions that threaten the spacecraft are detected with restrictions as defined based on the cyber-safe mode. {SV-AV-5,SV-AV-6,SV-AV-7} {CP-12,SI-17,IR-4(3)} Cyber-safe mode is using a fail-secure mentality where if there is a malfunction that the spacecraft goes into a fail-secure state where cyber protections like authentication and encryption are still employed (instead of bypassed) and the spacecraft can be restored by authorized commands. The cyber-safe mode should be stored in a high integrity location of the on-board SV so that it cannot be modified by attackers.
The spacecraft's cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable. {SV-AV-5,SV-AV-6,SV-AV-7} {SI-17}
The spacecraft shall fail to a known secure state for all types of failures preserving information necessary to determine cause of failure and to return to operations with least disruption to mission operations. {SV-AV-5,SV-AV-6,SV-AV-7} {SC-24,SI-17}
The spacecraft shall generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. {SV-AV-5,SV-AV-6,SV-AV-7} {SI-11}
The spacecraft shall reveal error messages only to operations personnel monitoring the telemetry. {SV-AV-5,SV-AV-6,SV-AV-7} {SI-11}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
REC-0001 Gather Spacecraft Design Information Threat actors may gather information about the victim SV's design that can be used for future campaigns or to help perpetuate other techniques. Information about the SV can include software, firmware, encryption type, purpose, as well as various makes and models of subsystems.
REC-0001.09 Fault Management Threat actors may gather information about any fault management that may be present on the victim SV. This information can help threat actors construct specific attacks that may put the SV into a fault condition and potentially a more vulnerable state depending on the fault response.
REC-0004 Gather Launch Information Threat actors may gather the launch date and time, location of the launch (country & specific site), organizations involved, launch vehicle, etc. This information can provide insight into protocols, regulations, and provide further targets for the threat actor, including specific vulnerabilities with the launch vehicle itself.
REC-0004.01 Flight Termination Threat actor may obtain information regarding the vehicle's flight termination system. Threat actors may use this information to perform later attacks and target the vehicle's termination system to have desired impact on mission.
REC-0007 Monitor for Safe-Mode Indicators Threat actors may gather information regarding safe-mode indicators on the victim SV. Safe-mode is when all non-essential systems are shut down and only essential functions within the SV are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
IA-0010 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim SV being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the SV are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
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 SV (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 SV depending on which component experiences the SEU. SEU is a known phenomenon for SV due to high radiation in space, but threat actors may attempt to utilize items like microwaves to create a SEU.
EX-0013 Flooding Threat actors use jamming and flooding attacks to disrupt communications by injecting unexpected noise or messages into a transmission channel. There are several types of attacks that are consistent with this method of exploitation, and they can produce various outcomes. Although, the most prominent of the impacts are denial of service or data corruption. Several elements of the space vehicle may be targeted by jamming and flooding attacks, and depending on the time of the attack, it can have devastating results to the availability of the system.
EX-0013.02 Erroneous Data Threat actors inject noise into the target channel so that legitimate messages cannot be correctly processed due to data integrity impacts. Additionally, while this technique does not utilize valid commands, the target SV still must consume computing resources to process and discard the signal.
EX-0013.01 Valid Commands Threat actors may utilize valid commanding as a mechanism for flooding as the processing of these valid commands could expend valuable resources like processing power and battery usage. Flooding the spacecraft bus, sub-systems or link layer with valid commands can create temporary denial of service conditions for the space vehicle while the SV is consumed with processing these valid commands.
EX-0006 Disable/Bypass Encryption Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim SV. By bypassing or disabling this particular mechanism, further tactics can be performed, such as Exfiltration, that may have not been possible with the internal encryption process in place.
EX-0011 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim SV being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the SV are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
DE-0001 Disable Fault Management Threat actors may disable fault management within the victim SV during the attack campaign. During the development process, many fault management mechanisms are added to the various parts of the SV in order to protect it from a variety of bad/corrupted commands, invalid sensor data, and more. By disabling these mechanisms, threat actors may be able to have commands processed that would not normally be allowed.
DE-0005 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim SV being in safe mode and send malicious commands that may not otherwise be processed. Safe-mode is when all non-essential systems are shut down and only essential functions within the SV are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections (i.e. security features) may be disabled at this time which would ensure the threat actor achieves evasion.
IMP-0001 Deception (or Misdirection) 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 SV.
IMP-0002 Disruption Threat actors may seek to disrupt communications from the victim SV to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the SV's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications.
IMP-0003 Denial Threat actors may seek to deny ground controllers and other interested parties access to the victim SV. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time.
IMP-0004 Degradation Threat actors may target various subsystems or the hosted payload in such a way in order to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim SV.

Related SPARTA Countermeasures

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
CM0001 Protect Sensitive Information Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. AC-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22