SPARTA Countermeasures

Countermeasures represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed. The below table view not only describes the countermeasure, it also provides informative references to the NIST Risk Management Framework (RMF) revision 5 control identifier. Each NIST control ID is a hyperlink to more information on the control itself. This mapping is meant to be informative and provide traceability to common standards that are being leveraged within the space community. In addition to the table view, there is a Defense-in-Depth (DiD) view that provides the countermeasures overlaid onto Aerospace's DiD model for space systems which was discussed in TOR 2021-01333 REV A. When selecting a specific countermeasure the following information will be displayed: description of the countermeasure, the best segment for countermeasure deployment, any informative references as well as any techniques that the countermeasure addresses. The mapping to countermeasure to technique(s) are a one to many relationship. For the best segment for countermeasure deployment, this is meant to articulate the ideal place to deploy the countermeasure leveraging the following choices: space segment, the development environment, or the ground segment. The space segment is considered to be the spacecraft or spacecrafts if within a constellation. The development segment captures the factories, hardware foundries, the software development organization as well as the Assembly, Test and Launch Operations (ATLO) facilities. The ground segment is meant to capture the operational and maintenance areas for the ground system. This includes the mission operations environments, the antenna environments, the back haul networks, as well as any management network segments for vendors or commercial entities.

ID Name Description NIST Rev5 Controls
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
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
CM0008 Security Testing Results As penetration testing and vulnerability scanning is a best practice, protecting the results from these tests and scans is equally important. These reports and results typically outline detailed vulnerabilities and how to exploit them. As with countermeasure CM0001, protecting sensitive information from disclosure to threat actors is imperative. AC-3(11) | CA-8 | RA-5 | RA-5(11) | SA-11(5) | SA-5
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(2) | RA-3(3) | SR-8
CM0020 Threat modeling Use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. SA-11(2) | SA-15(8)
CM0022 Criticality Analysis Conduct a criticality analysis to identify mission critical functions, critical components, and data flows and reduce the vulnerability of such functions and components through secure system design. Focus supply chain protection on the most critical components/functions. Leverage other countermeasures like segmentation and least privilege to protect the critical components. CP-2(8) | PM-11 | PM-17 | PM-30 | PM-30(1) | PM-32 | RA-3(1) | RA-9 | RA-9 | SA-15(3) | SC-32(1) | SC-7(29) | SR-1 | SR-1 | SR-2 | SR-2(1) | SR-3 | SR-3(2) | SR-3(3) | SR-5(1) | SR-7
CM0024 Anti-counterfeit Hardware Develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including tamper resistance and protection against the introduction of malicious code or hardware.  AC-20(5) | CM-7(9) | PM-30 | PM-30(1) | RA-3(1) | SA-10(3) | SA-10(4) | SR-1 | SR-10 | SR-11 | SR-11 | SR-11(3) | SR-11(3) | SR-2 | SR-2(1) | SR-3 | SR-4 | SR-4(1) | SR-4(2) | SR-4(3) | SR-4(4) | SR-5 | SR-5(2) | SR-6(1) | SR-9 | SR-9(1)
CM0025 Supplier Review Conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services. PM-30 | PM-30(1) | RA-3(1) | SR-11 | SR-3(1) | SR-3(3) | SR-4 | SR-4(1) | SR-4(2) | SR-4(3) | SR-4(4) | SR-5 | SR-5(1) | SR-5(2) | SR-6 | SR-6
CM0026 Original Component Manufacturer Components/Software that cannot be procured from the original component manufacturer or their authorized franchised distribution network should be approved by the supply chain board or equivalent to prevent and detect counterfeit and fraudulent parts, materials, and software. AC-20(5) | PM-30 | PM-30(1) | RA-3(1) | SA-10(4) | SR-1 | SR-1 | SR-11 | SR-2 | SR-2(1) | SR-3 | SR-3(1) | SR-3(3) | SR-4 | SR-4(1) | SR-4(2) | SR-4(3) | SR-4(4) | SR-5 | SR-5 | SR-5(1) | SR-5(2)
CM0027 ASIC/FPGA Manufacturing Application-Specific Integrated Circuit (ASIC) / Field Programmable Gate Arrays should be developed by accredited trusted foundries to limit potential hardware-based trojan injections. PM-30 | PM-30(1) | RA-3(1) | SA-10(3) | SI-3 | SR-1 | SR-1 | SR-11 | SR-2 | SR-2(1) | SR-3 | SR-5 | SR-5(2) | SR-6(1)
CM0028 Tamper Protection Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. CA-8(3) | CM-7(9) | MA-7 | PM-30 | PM-30(1) | RA-3(1) | SA-10(3) | SA-10(4) | SC-51 | SR-1 | SR-1 | SR-10 | SR-11 | SR-11(3) | SR-2 | SR-2(1) | SR-3 | SR-4(3) | SR-4(4) | SR-5 | SR-5 | SR-5(2) | SR-6(1) | SR-9 | SR-9(1)
CM0041 User Training Train users to be aware of access or manipulation attempts by a threat actor to reduce the risk of successful spear phishing, social engineering, and other techniques that involve user interaction. Ensure that role-based security-related training is provided to personnel with assigned security roles and responsibilities: (i) before authorizing access to the information system or performing assigned duties; (ii) when required by information system changes; and (iii) at least annually if not otherwise defined. AT-2 | AT-2(1) | AT-2(4) | AT-2(4) | AT-2(5) | AT-2(6) | AT-3 | AT-3(3) | IR-2(3) | SR-11(1)
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-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 | 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 | PM-12 | PM-14 | PS-3 | PS-4 | PS-5 | PS-8 | RA-10 | SC-38 | SC-7 | SI-4 | SR-11(2)
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-3(13) | AC-3(15) | AC-3(2) | IA-12 | IA-12(1) | IA-12(2) | IA-12(3) | IA-12(4) | IA-12(5) | IA-12(6) | PE-3
CM0002 COMSEC A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. AC-17(1) | AC-17(10) | AC-17(10) | AC-17(2) | AC-18(1) | AC-2(11) | AC-3(10) | IA-4(9) | IA-5 | IA-5(7) | IA-7 | SA-8(18) | SA-9(6) | SC-10 | SC-12 | SC-12(1) | SC-12(2) | SC-12(3) | SC-12(6) | SC-13 | SC-13(1) | SC-13(2) | SC-16(3) | SC-28(1) | SC-28(3) | SC-7 | SC-7(10) | SC-7(11) | SC-7(18) | SC-7(5) | SI-10 | SI-10(3) | SI-10(5) | SI-10(6) | SI-19(4) | SI-3(8)
CM0030 Crypto Key Management Leverage best practices for crypto key management as defined by organization like NIST or the National Security Agency. Leverage only approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. Encryption key handling should be performed outside of the onboard software and protected using cryptography. Encryption keys should be restricted so that they cannot be read via any telecommands. SA-9(6) | SC-12 | SC-12(1) | SC-12(2) | SC-12(3) | SC-12(6) | SC-28(3)
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)
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-23 | SC-7 | SC-7(11) | SC-7(18) | SI-10 | SI-10(5) | SI-10(6) | SI-3(8)
CM0073 Traffic Flow Analysis Defense Utilizing techniques to assure traffic flow security and confidentiality to mitigate or defeat traffic analysis attacks or reduce the value of any indicators or adversary inferences. This may be a subset of COMSEC protections, but the techniques would be applied where required to links that carry TT&C and/or data transmissions (to include on-board the spacecraft) where applicable given value and attacker capability. Techniques may include but are not limited to methods to pad or otherwise obfuscate traffic volumes/duration and/or periodicity, concealment of routing information and/or endpoints, or methods to frustrate statistical analysis. SC-8 | SI-4(15)
CM0003 TEMPEST The spacecraft should protect system components, associated data communications, and communication buses in accordance with TEMPEST controls to prevent side channel / proximity attacks. Encompass the spacecraft critical components with a casing/shielding so as to prevent access to the individual critical components. PE-19 | PE-19(1) | PE-21
CM0040 Shared Resource Leakage Prevent unauthorized and unintended information transfer via shared system resources. Ensure that processes reusing a shared system resource (e.g., registers, main memory, secondary storage) do not have access to information (including encrypted representations of information) previously stored in that resource during a prior use by a process after formal release of that resource back to the system or reuse AC-4(23) | AC-4(25) | SC-2(2) | SC-32(1) | SC-4 | SC-49 | SC-50 | SC-7(29)
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)
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)
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-20(5) | AC-3(11) | AC-3(13) | AC-3(15) | CA-8 | CM-14 | CM-2(2) | CM-3(2) | CM-3(7) | CM-3(8) | CM-4(1) | CM-7(8) | CM-7(8) | CP-2(8) | MA-7 | 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(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(8) | SA-15 | SA-15(3) | SA-15(5) | SA-15(7) | SA-15(8) | SA-3 | SA-3(1) | SA-3(2) | SA-4(3) | SA-4(5) | SC-38 | SI-2 | SI-2(6) | 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
CM0007 Software Version Numbers When using COTS or Open-Source, protect the version numbers being used as these numbers can be cross referenced against public repos to identify Common Vulnerability Exposures (CVEs) and exploits available. AC-3(11) | SA-5
CM0010 Update Software Perform regular software updates to mitigate exploitation risk. Software updates may need to be scheduled around operational down times. Release updated versions of the software/firmware systems incorporating security-relevant updates, after suitable regression testing, at a frequency no greater than mission-defined frequency [i.e., 30 days]. CM-3(2) | CM-3(7) | CM-3(8) | CM-4(1) | CM-7(4) | SA-10(4) | SI-2
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-5 | RA-5(11) | RA-5(3) | SA-15(7) | SI-3
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(1) | CM-11(3) | CM-8 | CM-8(7) | RA-5(11) | SA-10(4)
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) | RA-5 | SA-8(9)
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-14 | CM-7(8) | SA-10(4)
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(1) | SA-15(7)
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. SA-15
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 | CP-4(5) | RA-5(11) | SA-11(5) | SA-11(8) | SA-11(9) | SC-2(2) | SC-7(29) | SI-3 | SR-6(1) | SR-6(1)
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. RA-5 | SA-11(1) | SA-15(7)
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. CM-11(3) | CM-14 | CM-14 | SA-10(1) | SI-7 | SI-7(12) | SI-7(15)
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-3(7) | CM-3(8) | CM-5 | MA-7 | SA-10 | SA-10(7) | SR-11(2)
CM0036 Session Termination Terminate the connection associated with a communications session at the end of the session or after an acceptable amount of inactivity which is established via the concept of operations. AC-12 | SC-10 | SI-14(3)
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-3(13) | AC-3(15) | AC-4(2) | AC-6 | CA-3(6) | CM-7 | CM-7(4) | CM-7(8) | SA-17(7) | SA-8(14) | SA-8(15) | SA-8(9) | SC-2(2) | SC-32(1) | SC-49 | SC-50 | SC-7(29)
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. None
CM0047 Operating System Security Ensure spacecraft's operating system is scrutinized/whitelisted and has received adequate software assurance previously. The operating system should be analyzed for its attack surface and non-utilized features should be stripped from the operating system. Many real-time operating systems contain features that are not necessary for spacecraft operations and only increase the attack surface. CM-11(3) | CM-7 | CM-7(5) | CM-7(8) | CM-7(8) | SI-3(8)
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) | SC-7 | SI-3(8)
CM0062 Dummy Process - Aggregator Node According to Securing Sensor Nodes Against Side Channel Attacks, it is practically inefficient to prevent adversaries from identifying aggregator nodes in a network (i.e., constellation) because camouflaging traffic in sensor networks is power intensive. Consequently, focus on preventing adversaries from identifying valid aggregation cycles of aggregator nodes. One solution to counter such attacks is to have each aggregator node execute dummy operations that resemble the average power consumption curve observed during the normal operation of the aggregator node. Apart from simulating the power consumption of a genuine process execution, the two necessities that the execution of the dummy process must incorporate to be successful in thwarting the accumulation phase are to use a different dummy execution process each time or have a low repetition rate. This should help prevent the attacker from finding a pattern that would differentiate the execution of a dummy process from the normal execution of an aggregator node. The second requirement relates to the timing of the execution of the dummy process. Depending on whether there is a pattern to the timing of the execution of a dummy process, a threat actor may be able to identify and disregard the dummy process. For example, if a threat actor is capable of identifying the presence or absence of a radio frequency transmission, the attacker can disregard any power consumption curve computed during the absence of transmission signal. Similarly, if the dummy process is not executed every time the aggregator node receives a transmission, the attacker will be able to identify invalid transmission. Hence, to ensure the effectiveness of this scheme, the dummy process must be executed each time the aggregator receives a transmission as well as randomly during idle periods. The advantage of incorporating dummy processes in an aggregator is to minimize the ease of identifying transmission flow in a sensor network that can be used to identify the base station of the sensor network, which could be highly confidential in critical applications. PE-19 | PE-19(1)
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-7(5) | SI-10(5)
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 ( Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations 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(1) | AC-17(10) | AC-17(2) | AC-17(3) | AC-17(4) | AC-17(6) | AC-17(9) | AC-18 | AC-18(1) | AC-18(3) | AC-18(4) | AC-18(5) | AC-19 | AC-19(5) | 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(6) | CA-3(7) | CA-7 | CA-7(1) | CA-7(6) | CA-8 | CA-9 | CM-10(1) | 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(5) | 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(2) | CP-2(5) | CP-2(8) | CP-3(1) | 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 | IA-8 | IR-2 | IR-2(2) | IR-2(3) | IR-3(3) | IR-4 | IR-4(1) | IR-4(11) | IR-4(11) | IR-4(12) | IR-4(13) | IR-4(14) | IR-4(3) | IR-4(4) | IR-4(5) | IR-4(6) | IR-4(7) | IR-4(8) | IR-5 | IR-5(1) | IR-6 | IR-6(1) | IR-7 | IR-7(1) | MA-2 | MA-3 | MA-3(1) | MA-3(2) | MA-3(3) | MA-4 | MA-4(1) | MA-4(3) | MA-4(6) | MA-4(7) | MA-5(1) | MA-6 | MA-7 | MP-2 | MP-3 | MP-4 | MP-5 | MP-5(4) | MP-6 | MP-6(3) | MP-7 | PE-3(7) | PL-10 | PL-11 | PL-8 | PL-8(1) | PL-8(2) | PL-9 | PL-9 | PM-11 | PM-16(1) | PM-17 | PM-30 | PM-30(1) | PM-31 | PM-32 | RA-10 | RA-3(1) | RA-3(2) | RA-3(2) | RA-3(3) | RA-3(4) | RA-5 | RA-5(10) | RA-5(11) | RA-5(2) | RA-5(4) | RA-5(5) | RA-7 | RA-9 | RA-9 | SA-10 | SA-10(1) | SA-10(7) | SA-11 | SA-11(2) | SA-11(9) | SA-15 | SA-15(3) | SA-15(7) | SA-17 | SA-2 | SA-22 | SA-3 | SA-3(1) | SA-3(2) | SA-3(2) | SA-4 | SA-4(1) | SA-4(10) | SA-4(12) | SA-4(2) | SA-4(3) | SA-4(5) | SA-4(7) | SA-4(9) | SA-5 | SA-8 | SA-8(14) | SA-8(15) | SA-8(18) | SA-8(21) | SA-8(22) | SA-8(23) | SA-8(24) | SA-8(9) | SA-9 | SA-9(1) | SA-9(2) | SA-9(6) | SA-9(7) | SC-10 | SC-12 | SC-12(1) | SC-12(6) | SC-13 | SC-15 | SC-16(2) | SC-16(3) | SC-18(1) | SC-18(2) | SC-18(3) | SC-18(4) | SC-2 | SC-2(2) | SC-20 | SC-21 | SC-22 | SC-23 | SC-23(1) | SC-23(3) | SC-23(5) | SC-24 | SC-28 | SC-28(1) | SC-28(11) | SC-28(3) | SC-3 | SC-38 | SC-39 | SC-4 | SC-45 | SC-45(1) | SC-45(1) | SC-45(2) | SC-49 | SC-5 | SC-5(1) | SC-5(2) | SC-5(3) | SC-50 | SC-51 | SC-7 | SC-7(10) | SC-7(11) | SC-7(12) | SC-7(13) | SC-7(14) | SC-7(18) | SC-7(21) | SC-7(25) | SC-7(29) | SC-7(3) | SC-7(4) | SC-7(5) | SC-7(5) | SC-7(7) | SC-7(8) | SC-7(9) | SC-8 | SC-8(1) | SC-8(2) | SC-8(5) | SI-10 | SI-10(3) | SI-10(6) | SI-11 | SI-14(3) | SI-16 | SI-19(4) | SI-2 | SI-2(2) | SI-2(3) | SI-2(6) | SI-21 | SI-3 | SI-3 | SI-3(10) | SI-4 | SI-4(1) | SI-4(10) | SI-4(11) | SI-4(12) | SI-4(13) | SI-4(14) | SI-4(15) | SI-4(16) | SI-4(17) | SI-4(2) | SI-4(20) | SI-4(22) | SI-4(23) | SI-4(24) | SI-4(25) | SI-4(4) | SI-4(5) | SI-5 | SI-5(1) | SI-6 | SI-7 | SI-7(1) | SI-7(17) | SI-7(2) | SI-7(5) | SI-7(7) | SI-7(8) | SR-1 | SR-1 | SR-10 | SR-11 | SR-11 | SR-11(1) | SR-11(2) | SR-11(3) | SR-12 | SR-2 | SR-2(1) | SR-3 | SR-3(1) | SR-3(2) | SR-3(2) | SR-3(3) | SR-4 | SR-4(1) | SR-4(2) | SR-4(3) | SR-4(4) | SR-5 | SR-5 | SR-5(1) | SR-5(2) | SR-6 | SR-6(1) | SR-6(1) | SR-7 | SR-7 | SR-8 | SR-9 | SR-9(1)
CM0034 Monitor Critical Telemetry Points Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. AC-17(1) | AU-3(1) | CA-7(6) | IR-4(14) | SC-7 | SI-3(8)
CM0035 Protect Authenticators Protect authenticator content from unauthorized disclosure and modification. AC-3(11) | IA-4(9) | IA-5
CM0053 Physical Security Controls Employ physical security controls (badge with pins, guards, gates, etc.) to prevent unauthorized access to the systems that have the ability to command the spacecraft. CA-3(6) | CA-8 | CA-8(3) | PE-2 | PE-2(1) | PE-2(3) | PE-3 | PE-3(1) | PE-3(2) | PE-3(3) | PE-3(5) | PE-3(7) | SC-12(6) | SC-51 | SC-8(5) | SR-11(2)
CM0056 Data Backup Implement disaster recovery plans that contain procedures for taking regular data backups that can be used to restore critical data. Ensure backups are stored off system and is protected from common methods adversaries may use to gain access and destroy the backups to prevent recovery. CP-9
CM0070 Alternate Communications Paths Establish alternate communications paths to reduce the risk of all communications paths being affected by the same incident. CP-8(3) | SC-47
CM0006 Cloaking Safe-mode Attempt to cloak when in safe-mode and ensure that when the system enters safe-mode it does not disable critical security features. Ensure basic protections like encryption are still being used on the uplink/downlink to prevent eavesdropping. CP-12 | SC-13 | SC-24 | SC-8
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)
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 | SC-5 | 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 | SC-5 | SI-11 | SI-17 | SI-7(17)
CM0051 Fault Injection Redundancy To counter fault analysis attacks, it is recommended to use redundancy to catch injected faults. For certain critical functions that need protected against fault-based side channel attacks, it is recommended to deploy multiple implementations of the same function. Given an input, the spacecraft can process it using the various implementations and compare the outputs. A selection module could be incorporated to decide the valid output. Although sensor nodes have limited resources, critical regions usually comprise the crypto functions, which must be secured. CP-4(5) | SI-13 | SI-4(25)
CM0066 Model-based System Verification Real-time physics model-based system verification of state could help to verify data input and control sequence changes SI-4 | SI-4(2)
CM0067 Smart Contracts Smart contracts can be used to mitigate harm when an attacker is attempting to compromise a hosted payload. Smart contracts will stipulate security protocol required across a bus and should it be violated, the violator will be barred from exchanges across the system after consensus achieved across the network. SI-4 | SI-4(2)
CM0068 Reinforcement Learning Institute a reinforcement learning agent that will detect anomalous events and redirect processes to proceed by ignoring malicious data/input. IR-5 | IR-5(1) | SI-4 | SI-4(2)
CM0014 Secure boot Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment.  SC-51 | SI-7(9)
CM0037 Disable Physical Ports Provide the capability for data connection ports or input/output devices (e.g., JTAG) to be disabled or removed prior to spacecraft operations. MA-7 | SC-41 | SC-7(14)
CM0038 Segmentation Identify the key system components or capabilities that require isolation through physical or logical means. Information should not be allowed to flow between partitioned applications unless explicitly permitted by security policy. Isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. Enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the defined security policy that information does not leave the spacecraft boundary unless it is encrypted. Implement boundary protections to separate bus, communications, and payload components supporting their respective functions. AC-4 | AC-4(14) | AC-4(2) | AC-4(24) | AC-4(26) | AC-4(31) | AC-4(32) | AC-6 | CA-3(7) | SA-8(15) | SA-8(18) | SA-8(9) | SC-16(3) | SC-2(2) | SC-3 | SC-32(1) | SC-39 | SC-4 | SC-49 | SC-50 | SC-6 | SC-7(20) | SC-7(21) | SC-7(29) | SC-7(5) | SI-17
CM0043 Backdoor Commands Ensure that all viable commands are known to the mission/spacecraft owner. Perform analysis of critical (backdoor/hardware) commands that could adversely affect mission success if used maliciously. Only use or include critical commands for the purpose of providing emergency access where commanding authority is appropriately restricted.  SI-10 | SI-10(3) | SI-10(6) | SI-3(8)
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
CM0048 Resilient Position, Navigation, and Timing If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. 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(2)
CM0057 Tamper Resistant Body Using a tamper resistant body can increase the one-time cost of the sensor node but will allow the node to conserve the power usage when compared with other countermeasures. PE-19 | PE-19(1)
CM0058 Power Randomization Power randomization is a technique in which a hardware module is built into the chip that adds noise to the power consumption. This countermeasure is simple and easy to implement but is not energy efficient and could be impactful for size, weight, and power which is limited on spacecraft as it adds to the fabrication cost of the device. PE-19 | PE-19(1)
CM0059 Power Consumption Obfuscation Design hardware circuits or perform obfuscation in general that mask the changes in power consumption to increase the cost/difficulty of a power analysis attack. This will increase the cost of manufacturing sensor nodes. PE-19 | PE-19(1)
CM0060 Secret Shares Use of secret shares in which the original computation is divided probabilistically such that the power subset of shares is statistically independent. One of the major drawbacks of this solution is the increase in the power consumption due to the number of operations that are almost doubled. PE-19 | PE-19(1)
CM0061 Power Masking Masking is a scheme in which the intermediate variable is not dependent on an easily accessible subset of secret key. This results in making it impossible to deduce the secret key with partial information gathered through electromagnetic leakage. PE-19 | PE-19(1)
CM0063 Increase Clock Cycles/Timing Use more clock cycles such that branching does not affect the execution time. Also, the memory access times should be standardized to be the same over all accesses. If timing is not mission critical and time is in abundance, the access times can be reduced by adding sufficient delay to normalize the access times. These countermeasures will result in increased power consumption which may not be conducive for low size, weight, and power missions. PE-19 | PE-19(1)
CM0064 Dual Layer Protection Use a dual layered case with the inner layer a highly conducting surface and the outer layer made of a non-conducting material. When heat is generated from internal computing components, the inner, highly conducting surface will quickly dissipate the heat around. The outer layer prevents accesses to the temporary hot spots formed on the inner layer. PE-19 | PE-19(1)
CM0065 OSAM Dual Authorization Before engaging in an On-orbit Servicing, Assembly, and Manufacturing (OSAM) mission, verification of servicer should be multi-factor authenticated/authorized by both the serviced's ground station and the serviced asset. CA-3(6) | IA-2(1) | IA-2(2) | IA-2(6)
CM0071 Communication Physical Medium Establish alternate physical medium for networking based on threat model/environment. For example, fiber optic cabling is commonly perceived as a better choice in lieu of copper for mitigating network security concerns (i.e., eavesdropping / traffic flow analysis) and this is because optical connections transmit data using light, they don’t radiate signals that can be intercepted. PE-4 | SC-8 | SC-8(5)
CM0072 Protocol Update / Refactoring A protocol is a set of rules (i.e., formats and procedures) to implement and control some type of association (e.g., communication) between systems. Protocols can have vulnerabilities within their specification and may require updating or refactoring based on vulnerabilities or emerging threats (i.e., quantum computing). CM-3 | CP-11 | SI-2
CM0029 TRANSEC Utilize TRANSEC in order to prevent interception, disruption of reception, communications deception, and/or derivation of intelligence by analysis of transmission characteristics such as signal parameters or message externals. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated. AC-18(5) | CP-8 | SC-40 | SC-40(1) | SC-40(3) | SC-40(4) | SC-5 | SC-8(4)