SV-IT-5 - Time Synchronized Execution

Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands


Informational References

  • CENTRA Volume I - Cyber Content of Satellites
ID: SV-IT-5
DiD Layer: S/C Software
CAPEC #:  186 | 533
NIST Rev5 Control Tag Mapping:  AC-3 | AC-3(2) | CA-7 | CA-7(6) | RA-10 | SA-8 | SA-8(24) | SC-45 | SC-45(1) | SC-45(2)
Lowest Threat Tier to
Create Threat Event:  
IV
Notional Risk Rank Score: 14

High-Level Requirements

The spacecraft shall ensure any update to on-board stored procedures has met high assurance standards before execution.

Low-Level Requirements

Requirement Rationale/Additional Guidance/Notes
The spacecraft shall require multi-factor authorization for new and updates to on-board stored command sequences. {SV-IT-5} {AC-3(2)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description
RD-0004 Stage Capabilities Threat actors may upload, install, or otherwise set up capabilities that can be used for future campaigns or to perpetuate other techniques. To support their operations, a threat actor may need to develop their own capabilities or obtain them in some way in order to stage them on infrastructure under their control. These capabilities may be staged on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them.
RD-0004.01 Identify/Select Delivery Mechanism Threat actors may identify, select, and prepare a delivery mechanism in which to attack the space system (i.e., communicate with the victim spacecraft, deny the ground, etc.) to achieve their desired impact. This mechanism may be located on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them. The mechanism must include all aspects needed to communicate with the victim spacecraft, including ground antenna, converters, and amplifiers.
RD-0004.02 Upload Exploit/Payload Threat actors may upload exploits and payloads to a third-party infrastructure that they have purchased or rented or stage it on an otherwise compromised ground station. Exploits and payloads would include files and commands to be uploaded to the victim spacecraft in order to conduct the threat actor's attack.
IA-0007 Compromise Ground System Threat actors may initially compromise the ground system in order to access the target spacecraft. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes. Threat actors may also perform further reconnaissance within the system to enumerate mission networks and gather information related to ground station logical topology, missions ran out of said ground station, birds that are in-band of targeted ground stations, and other mission system capabilities.
IA-0007.01 Compromise On-Orbit Update Threat actors may manipulate and modify on-orbit updates before they are sent to the target spacecraft. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, or replacing compiled versions with a malicious one.
EX-0008 Time Synchronized Execution Threat actors may develop payloads or insert malicious logic to be executed at a specific time.
EX-0008.01 Absolute Time Sequences Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Absolute Time Sequences (ATS), the event is triggered at specific date/time - regardless of the state or location of the target.
EX-0008.02 Relative Time Sequences Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Relative Time Sequences (RTS), the event is triggered in relation to some other event. For example, a specific amount of time after boot.
EX-0012 Modify On-Board Values Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function.
EX-0012.01 Registers Threat actors may target the internal registers of the victim spacecraft in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the spacecraft rely on internal registries to store important data and temporary values. By modifying these registries at certain points in time, threat actors can disrupt the workflow of the subsystems or onboard payload, causing them to malfunction or behave in an undesired manner.
EX-0012.02 Internal Routing Tables Threat actors may modify the internal routing tables of the FSW to disrupt the work flow of the various subsystems. Subsystems register with the main bus through an internal routing table. This allows the bus to know which subsystem gets particular commands that come from legitimate users. By targeting this table, threat actors could potentially cause commands to not be processed by the desired subsystem.
EX-0012.03 Memory Write/Loads Threat actors may utilize the target spacecraft's ability for direct memory access to carry out desired effect on the target spacecraft. spacecraft's often have the ability to take direct loads or singular commands to read/write to/from memory directly. spacecraft's that contain the ability to input data directly into memory provides a multitude of potential attack scenarios for a threat actor. Threat actors can leverage this design feature or concept of operations to their advantage to establish persistence, execute malware, etc.
EX-0012.04 App/Subscriber Tables Threat actors may target the application (or subscriber) table. Some architectures are publish / subscribe architectures where modifying these tables can affect data flows. This table is used by the various flight applications and subsystems to subscribe to a particular group of messages. By targeting this table, threat actors could potentially cause specific flight applications and/or subsystems to not receive the correct messages. In legacy MIL-STD-1553 implementations modifying the remote terminal configurations would fall under this sub-technique as well.
EX-0012.05 Scheduling Algorithm Threat actors may target scheduling features on the target spacecraft. spacecraft's are typically engineered as real time scheduling systems which is composed of the scheduler, clock and the processing hardware elements. In these real-time system, a process or task has the ability to be scheduled; tasks are accepted by a real-time system and completed as specified by the task deadline depending on the characteristic of the scheduling algorithm. Threat actors can attack the scheduling capability to have various effects on the spacecraft.
EX-0012.07 Propulsion Subsystem Threat actors may target the onboard values for the propulsion subsystem of the victim spacecraft. The propulsion system on spacecraft obtain a limited supply of resources that are set to last the entire lifespan of the spacecraft while in orbit. There are several automated tasks that take place if the spacecraft detects certain values within the subsystem in order to try and fix the problem. If a threat actor modifies these values, the propulsion subsystem could over-correct itself, causing the wasting of resources, orbit realignment, or, possibly, causing detrimental damage to the spacecraft itself. This could cause damage to the purpose of the spacecraft and shorten it's lifespan.
EX-0012.08 Attitude Determination & Control Subsystem Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim spacecraft. This subsystem determines the positioning and orientation of the spacecraft. Throughout the spacecraft's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the spacecraft aligned as it should. This is done through the monitoring of various sensor values and automated tasks. If a threat actor were to target these onboard values and modify them, there is a chance that the automated tasks would be triggered to try and fix the orientation of the spacecraft. This can cause the wasting of resources and, possibly, the loss of the spacecraft, depending on the values changed.
EX-0012.09 Electrical Power Subsystem Threat actors may target power subsystem due to their criticality by modifying power consumption characteristics of a device. Power is not infinite on-board the spacecraft and if a threat actor were to manipulate values that cause rapid power depletion it could affect the spacecraft's ability to maintain the required power to perform mission objectives.
EX-0012.10 Command & Data Handling Subsystem Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim spacecraft. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the spacecraft to function correctly.

Related SPARTA Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
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-25 AC-3(11) AC-4(23) AC-4(25) AC-4(6) CA-3 CM-12 CM-12(1) PL-8 PL-8(1) PM-11 PM-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(12) SA-5 SA-8 SA-8(19) SA-9(7) SC-16 SC-16(1) SC-8(1) SC-8(3) SI-12 SI-21 SI-23 SR-12 SR-7 D3-AI D3-AVE D3-NVA D3-CH D3-CBAN D3-CTS D3-PA D3-FAPA D3-SAOR A.8.4 A.8.11 A.8.10 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.27 A.8.28 A.5.33 A.8.10 A.5.22
CM0009 Threat Intelligence Program A threat intelligence program helps an organization generate their own threat intelligence information and track trends to inform defensive priorities and mitigate risk. Leverage all-source intelligence services or commercial satellite imagery to identify and track adversary infrastructure development/acquisition. Countermeasures for this attack fall outside the scope of the mission in the majority of cases. PM-16 PM-16(1) PM-16(1) RA-10 RA-3 RA-3(2) RA-3(3) SA-3 SA-8 SI-4(24) SR-8 D3-PH D3-AH D3-NM D3-NVA D3-SYSM D3-SYSVA A.5.7 A.5.7 6.1.2 8.2 9.3.2 A.8.8 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0052 Insider Threat Protection Establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding of the spacecraft is possible. Establish an Insider Threat Program to aid in the prevention of people with authorized access performing malicious activities. AC-14 AC-3(11) AC-3(13) AC-3(15) AC-6 AT-2 AT-2(2) AT-2(4) AT-2(5) AT-2(6) AU-10 AU-12 AU-13 AU-6 AU-7 CA-7 CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-4 IR-2(3) IR-4 IR-4(6) IR-4(7) MA-7 MP-7 PE-2 PL-8 PL-8(1) PM-12 PM-14 PS-3 PS-4 PS-5 PS-8 RA-10 SA-3 SA-8 SC-38 SC-7 SI-4 SR-11(2) D3-OAM D3-AM D3-OM D3-CH D3-SPP D3-MFA D3-UAP D3-UBA A.8.4 A.5.15 A.8.2 A.8.18 7.3 A.6.3 A.8.7 A.5.25 A.6.8 A.8.15 A.8.15 A.8.12 A.8.16 9.1 9.3.2 9.3.3 A.5.36 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.16 A.5.25 A.5.26 A.5.27 A.5.10 A.7.10 A.7.2 A.5.8 A.6.1 A.5.11 A.6.5 A.5.11 A.6.5 7.3 A.6.4 A.5.7 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.16
CM0054 Two-Person Rule Utilize a two-person system to achieve a high level of security for systems with command level access to the spacecraft. Under this rule all access and actions require the presence of two authorized people at all times. AC-14 AC-3(13) AC-3(15) AC-3(2) AU-9(5) CP-2 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) PE-3 SA-8(15) D3-OAM D3-AM D3-ODM D3-OM D3-MFA 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.7.1 A.7.2 A.7.3 A.7.4
CM0033 Relay Protection Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus. AC-17(10) AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-16(1) SC-23 SC-23(1) SC-23(3) SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) D3-ITF D3-NTA D3-OTF A.5.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.24 A.8.26 A.5.31
CM0049 Machine Learning Data Integrity When AI/ML is being used for mission critical operations, the integrity of the training data set is imperative. Data poisoning against the training data set can have detrimental effects on the functionality of the AI/ML. Fixing poisoned models is very difficult so model developers need to focus on countermeasures that could either block attack attempts or detect malicious inputs before the training cycle occurs. Regression testing over time, validity checking on data sets, manual analysis, as well as using statistical analysis to find potential injects can help detect anomalies. AC-3(11) SC-28 SC-28(1) SC-8 SC-8(2) SI-7 SI-7(1) SI-7(2) SI-7(5) SI-7(6) SI-7(8) D3-PH D3-FE D3-DENCR D3-PA D3-FA A.8.4 A.5.10 A.5.14 A.8.20 A.8.26 A.5.10 A.5.33
CM0004 Development Environment Security In order to secure the development environment, the first step is understanding all the devices and people who interact with it. Maintain an accurate inventory of all people and assets that touch the development environment. Ensure strong multi-factor authentication is used across the development environment, especially for code repositories, as threat actors may attempt to sneak malicious code into software that's being built without being detected. Use zero-trust access controls to the code repositories where possible. For example, ensure the main branches in repositories are protected from injecting malicious code. A secure development environment requires change management, privilege management, auditing and in-depth monitoring across the environment. AC-17 AC-18 AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 CA-8(1) CA-8(1) CM-11 CM-14 CM-2(2) CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-4(1) CM-5(6) CM-7(8) CM-7(8) CP-2(8) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) RA-3(2) RA-5 RA-5(2) RA-9 SA-10 SA-10(4) SA-11 SA-11 SA-11(1) SA-11(2) SA-11(2) SA-11(4) SA-11(5) SA-11(5) SA-11(6) SA-11(7) SA-11(7) SA-11(7) SA-11(8) SA-15 SA-15(3) SA-15(5) SA-15(7) SA-15(8) SA-17 SA-3 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(3) SA-4(3) SA-4(5) SA-4(5) SA-4(9) SA-8 SA-8(19) SA-8(30) SA-8(31) SA-9 SC-38 SI-2 SI-2(6) SI-7 SR-1 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(2) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5 SR-5(2) SR-6 SR-6(1) SR-6(1) SR-7 D3-AI D3-AVE D3-SWI D3-HCI D3-NNI D3-OAM D3-AM D3-OM D3-DI D3-MFA D3-CH D3-OTP D3-BAN D3-PA D3- FAPA D3- DQSA D3-IBCA D3-PCSV D3-PSMD A.8.4 A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.8.9 A.8.9 A.8.31 A.8.19 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 A.8.28 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.8.28 A.5.8 A.8.25 A.8.28 A.8.25 A.8.27 A.6.8 A.8.8 A.8.32 5.2 5.3 7.5.1 7.5.2 7.5.3 A.5.1 A.5.2 A.5.4 A.5.19 A.5.31 A.5.36 A.5.37 A.5.19 A.5.20 A.5.21 A.8.30 A.5.20 A.5.21 A.5.21 A.8.30 A.5.20 A.5.21 A.5.23 A.8.29 A.5.22 A.5.22
CM0011 Vulnerability Scanning Vulnerability scanning is used to identify known software vulnerabilities (excluding custom-developed software - ex: COTS and Open-Source). Utilize scanning tools to identify vulnerabilities in dependencies and outdated software (i.e., software composition analysis). Ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. CM-10(1) RA-3 RA-5 RA-5(11) RA-5(3) RA-7 SA-11 SA-11(3) SA-15(7) SA-3 SA-4(5) SA-8 SA-8(30) SI-3 SI-3(10) SI-7 D3-AI D3-NM D3-AVE D3-NVA D3-PM D3-FBA D3-OSM D3-SFA D3-PA D3-PSA D3-PLA D3-PCSV D3-FA D3-DA D3-ID D3-HD D3-UA 6.1.2 8.2 9.3.2 A.8.8 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7
CM0012 Software Bill of Materials Generate Software Bill of Materials (SBOM) against the entire software supply chain and cross correlate with known vulnerabilities (e.g., Common Vulnerabilities and Exposures) to mitigate known vulnerabilities. Protect the SBOM according to countermeasures in CM0001. CM-10 CM-10(1) CM-11 CM-11 CM-11(3) CM-2 CM-5(6) CM-7(4) CM-7(5) CM-8 CM-8(7) PM-5 RA-5 RA-5(11) SA-10(2) SA-10(4) SA-11 SA-11(3) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(29) SA-8(30) SA-8(7) SA-9 SI-7 D3-AI D3-AVE D3-SWI A.8.9 A.8.19 A.8.19 A.5.9 A.8.9 A.5.32 A.8.19 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30
CM0013 Dependency Confusion Ensure proper protections are in place for ensuring dependency confusion is mitigated like ensuring that internal dependencies be pulled from private repositories vice public repositories, ensuring that your CI/CD/development environment is secure as defined in CM0004 and validate dependency integrity by ensuring checksums match official packages. CM-10(1) CM-11 CM-2 CM-5(6) RA-5 SA-11 SA-3 SA-8 SA-8(30) SA-8(7) SA-8(9) SA-9 SI-7 D3-LFP D3-UBA D3-RAPA D3-MAC A.8.9 A.8.19 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30
CM0015 Software Source Control Prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code. CM-11 CM-14 CM-2 CM-4 CM-5(6) CM-7(8) SA-10(2) SA-10(4) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(19) SA-8(29) SA-8(30) SA-8(31) SA-8(7) SA-9 SI-7 D3-PM D3-SBV D3-EI D3-EAL D3- EDL D3-DCE A.8.9 A.8.9 A.8.19 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30
CM0016 CWE List Create prioritized list of software weakness classes (e.g., Common Weakness Enumerations), based on system-specific considerations, to be used during static code analysis for prioritization of static analysis results. RA-5 SA-11 SA-11(1) SA-15(7) SI-7 D3-AI D3-AVE A.8.8 A.8.29 A.8.30 A.8.28
CM0017 Coding Standard Define acceptable coding standards to be used by the software developer. The mission should have automated means to evaluate adherence to coding standards. The coding standard should include the acceptable software development language types as well. The language should consider the security requirements, scalability of the application, the complexity of the application, development budget, development time limit, application security, available resources, etc. The coding standard and language choice must ensure proper security constructs are in place. PL-8 PL-8(1) SA-11 SA-11(3) SA-15 SA-3 SA-4(9) SA-8 SA-8(30) SA-8(7) SI-7 D3-AI D3-AVE D3-SWI D3-DCE D3-EHPV D3-ORA D3-FEV D3-FR D3-ER D3-PE D3-PT D3-PS A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.5.8 A.8.25
CM0018 Dynamic Analysis Employ dynamic analysis (e.g., using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code). Testing should occur (1) on potential system elements before acceptance; (2) as a realistic simulation of known adversary tactics, techniques, procedures (TTPs), and tools; and (3) throughout the lifecycle on physical and logical systems, elements, and processes. FLATSATs as well as digital twins can be used to perform the dynamic analysis depending on the TTPs being executed. Digital twins via instruction set simulation (i.e., emulation) can provide robust environment for dynamic analysis and TTP execution. CA-8 CA-8(1) CA-8(1) CM-4(2) CP-4(5) RA-3 RA-5(11) RA-7 SA-11 SA-11(3) SA-11(5) SA-11(8) SA-11(9) SA-3 SA-8 SA-8(30) SC-2(2) SC-7(29) SI-3 SI-3(10) SI-7 SR-6(1) SR-6(1) D3-DA D3-FBA D3-PSA D3-PLA D3-PA D3-SEA D3-MBT 6.1.2 8.2 9.3.2 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7
CM0019 Static Analysis Perform static source code analysis for all available source code looking for system-relevant weaknesses (see CM0016) using no less than two static code analysis tools. CM-4(2) RA-3 RA-5 RA-7 SA-11 SA-11(1) SA-11(3) SA-11(4) SA-15(7) SA-3 SA-8 SA-8(30) SI-7 D3-PM D3-FBA D3-FEMC D3-FV D3-PFV D3-SFV D3-OSM 6.1.2 8.2 9.3.2 A.8.8 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.28
CM0021 Software Digital Signature Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission. AC-14 CM-11 CM-11(3) CM-14 CM-14 CM-5(6) IA-2 SA-10(1) SA-11 SA-4(5) SA-8(29) SA-8(31) SA-9 SI-7 SI-7 SI-7(1) SI-7(12) SI-7(15) SI-7(6) D3-CH D3-CBAN D3-FV D3-DLIC D3-EAL D3-SBV A.8.19 A.5.16 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30
CM0023 Configuration Management Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available. CM-11(3) CM-2 CM-3(4) CM-3(6) CM-3(7) CM-3(8) CM-4 CM-5 CM-5(6) MA-7 SA-10 SA-10(2) SA-10(7) SA-11 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(29) SA-8(30) SA-8(31) SI-7 SR-11(2) D3-ACH D3-CI D3-SICA D3-USICA A.8.9 A.8.9 A.8.9 A.8.9 A.8.2 A.8.4 A.8.9 A.8.19 A.8.31 A.8.3 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30
CM0039 Least Privilege Employ the principle of least privilege, allowing only authorized processes which are necessary to accomplish assigned tasks in accordance with system functions. Ideally maintain a separate execution domain for each executing process. AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(5) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(19) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) D3-MAC D3-EI D3-HBPI D3-KBPI D3-PSEP D3-MBT D3-PCSV D3-LFP D3-UBA A.5.16 A.5.18 A.8.2 A.5.15 A.8.2 A.8.18 A.8.19 A.8.19 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0046 Long Duration Testing Perform testing using hardware or simulation/emulation where the test executes over a long period of time (30+ days). This testing will attempt to flesh out race conditions or time-based attacks. PL-8 PL-8(1) SA-3 SA-8 SA-8(30) D3-SJA D3-PM D3-OSM D3-SDM D3-UBA D3-SYSVA A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0055 Secure Command Mode(s) Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times. AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) IA-10 PL-8 PL-8(1) SA-3 SA-8 SC-7 SI-3(8) D3-AH D3-ACH D3-MFA D3-OTP A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26
CM0069 Process White Listing Simple process ID whitelisting on the firmware level could impede attackers from instigating unnecessary processes which could impact the spacecraft CM-11 CM-7(5) PL-8 PL-8(1) SI-10(5) D3-MAC D3-EAL D3-EDL A.8.19 A.8.19 A.5.8
CM0005 Ground-based Countermeasures This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks. AC-1 AC-10 AC-11 AC-11(1) AC-12 AC-12(1) AC-14 AC-16 AC-16(6) AC-17 AC-17 AC-17(1) AC-17(10) AC-17(2) AC-17(3) AC-17(4) AC-17(6) AC-17(9) AC-18 AC-18 AC-18(1) AC-18(3) AC-18(4) AC-18(5) AC-19 AC-19(5) AC-2 AC-2 AC-2(1) AC-2(11) AC-2(12) AC-2(13) AC-2(2) AC-2(3) AC-2(4) AC-2(9) AC-20 AC-20(1) AC-20(2) AC-20(3) AC-20(5) AC-21 AC-22 AC-3 AC-3(11) AC-3(13) AC-3(15) AC-3(4) AC-4 AC-4(23) AC-4(24) AC-4(25) AC-4(26) AC-4(31) AC-4(32) AC-6 AC-6(1) AC-6(10) AC-6(2) AC-6(3) AC-6(5) AC-6(8) AC-6(9) AC-7 AC-8 AT-2(4) AT-2(4) AT-2(5) AT-2(6) AT-3 AT-3(2) AT-4 AU-10 AU-11 AU-12 AU-12(1) AU-12(3) AU-14 AU-14(1) AU-14(3) AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(1) AU-5(2) AU-5(5) AU-6 AU-6(1) AU-6(3) AU-6(4) AU-6(5) AU-6(6) AU-7 AU-7(1) AU-8 AU-9 AU-9(2) AU-9(3) AU-9(4) CA-3 CA-3 CA-3(6) CA-3(7) CA-7 CA-7(1) CA-7(6) CA-8 CA-8(1) CA-8(1) CA-9 CM-10(1) CM-11 CM-11 CM-11(2) CM-11(3) CM-12 CM-12(1) CM-14 CM-2 CM-2(2) CM-2(3) CM-2(7) CM-3 CM-3(1) CM-3(2) CM-3(4) CM-3(5) CM-3(6) CM-3(7) CM-3(7) CM-3(8) CM-4 CM-5(1) CM-5(5) CM-6 CM-6(1) CM-6(2) CM-7 CM-7(1) CM-7(2) CM-7(3) CM-7(5) CM-7(8) CM-7(8) CM-7(9) CM-8 CM-8(1) CM-8(2) CM-8(3) CM-8(4) CM-9 CP-10 CP-10(2) CP-10(4) CP-2 CP-2 CP-2(2) CP-2(5) CP-2(8) CP-3(1) CP-4(1) CP-4(2) CP-4(5) CP-8 CP-8(1) CP-8(2) CP-8(3) CP-8(4) CP-8(5) CP-9 CP-9(1) CP-9(2) CP-9(3) IA-11 IA-12 IA-12(1) IA-12(2) IA-12(3) IA-12(4) IA-12(5) IA-12(6) IA-2 IA-2(1) IA-2(12) IA-2(2) IA-2(5) IA-2(6) IA-2(8) IA-3 IA-3(1) IA-4 IA-4(9) IA-5 IA-5(1) IA-5(13) IA-5(14) IA-5(2) IA-5(7) IA-5(8) IA-6 IA-7