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.

Best Segment for Countermeasure Deployment

Development Environment

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

ISO 27001

NASA Best Practice Guide

ESA Space Shield Mitigation

None

Related MITRE EMB3D Mitigations

No related MITRE EMB3D Mitigations

ID: CM0046

Created: 2022/10/19

Last Modified: 2023/11/29

Techniques Addressed by Countermeasure

ID		Name	Description
EX-0008		Time Synchronized Execution	Threat actors may develop payloads or insert malicious logic to be executed at a specific time.
	.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.
	.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.

Space Threats Addressed by Countermeasure

ID	Description
SV-AV-2	Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing)
SV-AV-8	Clock synchronization attack for Spacewire. Since terminals in a distributed system are driven by independent clocks, the clock sync performance is one of the most important indexes in a networked system.

Sample Requirements

Requirement	Rationale/Additional Guidance/Notes
The [organization] shall identify the applicable physical and environmental protection policies covering the development environment and spacecraft hardware. {PE-1,PE-14,SA-3,SA-3(1),SA-10(3)}
The [organization] shall develop and document program-specific identification and authentication policies for accessing the development environment and spacecraft. {AC-3,AC-14,IA-1,SA-3,SA-3(1)}
The [organization] shall protect documentation and Controlled Unclassified Information (CUI) as required, in accordance with the risk management strategy.{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-10,SC-8(1),SC-28(3),SI-12}
The [organization] shall identify and properly classify mission sensitive design/operations information and access control shall be applied in accordance with classification guides and applicable federal laws, Executive Orders, directives, policies, regulations, and standards.{SV-CF-3,SV-AV-5}{AC-3,CM-12,CP-2,PM-17,RA-5(4),SA-3,SA-3(1),SA-5,SA-8(19),SC-8(1),SC-28(3),SI-12}	* Mission sensitive information should be classified as Controlled Unclassified Information (CUI) or formally known as Sensitive but Unclassified. Ideally these artifacts would be rated SECRET or higher and stored on classified networks. Mission sensitive information can typically include a wide range of candidate material: the functional and performance specifications, the RF ICDs, 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, SBU, 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.
The [organization] shall ensure security requirements/configurations are placed in accordance with NIST 800-171 with enhancements in 800-172 on the development environments to prevent the compromise of source code from supply chain or information leakage perspective.{AC-3,SA-3,SA-3(1),SA-15}
The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)}	The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
The [organization] shall establish robust procedures and technical methods to perform testing to include adversarial testing (i.e.abuse cases) of the platform hardware and software.{CA-8,CP-4(5),RA-5,RA-5(1),RA-5(2),SA-3,SA-4(3),SA-11,SA-11(1),SA-11(2),SA-11(5),SA-11(7),SA-11(8),SA-15(7)}
The [organization] shall develop, document, and maintain under configuration control, a current baseline configuration of the spacecrafts.{CM-2,CM-3(7),CM-4(2),CM-6,SA-8(30),SA-10}
The [organization] shall maintain the integrity of the mapping between the master build data (hardware drawings and software/firmware code) describing the current version of hardware, software, and firmware and the on-site master copy of the data for the current version.{CM-6,SA-8(21),SA-8(30),SA-10,SA-10(3),SA-10(4),SA-10(5),SI-7(10),SR-4(4)}
The [organization] shall develop a security plan for the spacecraft.{SV-MA-6}{PL-2,PL-7,PM-1,SA-8(29),SA-8(30)}
The [organization] shall document the platform's security architecture, and how it is established within and is an integrated part of the overall [organization] mission security architecture.{PL-7,SA-8(7),SA-8(13),SA-8(29),SA-8(30),SA-17}
The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}	Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply.
For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is not accredited, the [organization] shall be subjected to a development environment and pre-silicon artifacts risk assessment by [organization]. Based on the results of the risk assessment, the [organization] may need to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts.{SV-SP-5}{SA-3,SA-3(1),SA-8(9),SA-8(11),SA-12,SA-12(1),SR-1,SR-5}	DOD-I-5200.44 requires the following: 4.c.2 “Control the quality, configuration, and security of software, firmware, hardware, and systems throughout their lifecycles... Employ protections that manage risk in the supply chain… (e.g., integrated circuits, field-programmable gate arrays (FPGA), printed circuit boards) when they are identifiable (to the supplier) as having a DOD end-use. “ 4.e “In applicable systems, integrated circuit-related products and services shall be procured from a Trusted supplier accredited by the Defense Microelectronics Activity (DMEA) when they are custom-designed, custommanufactured, or tailored for a specific DOD military end use (generally referred to as application-specific integrated circuits (ASIC)). “ 1.g “In coordination with the DOD CIO, the Director, Defense Intelligence Agency (DIA), and the Heads of the DOD Components, develop a strategy for managing risk in the supply chain for integrated circuit-related products and services (e.g., FPGAs, printed circuit boards) that are identifiable to the supplier as specifically created or modified for DOD (e.g., military temperature range, radiation hardened).
The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)}	Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc.
The [organization] shall ensure that the allocated security safeguards operate in a coordinated and mutually reinforcing manner.{SV-MA-6}{CA-7(5),PL-7,PL-8(1),SA-8(19)}
The [organization] shall document and design a security architecture using a defense-in-depth approach that allocates the [organization]s defined safeguards to the indicated locations and layers: [Examples include: operating system abstractions and hardware mechanisms to the separate processors in the platform, internal components, and the FSW].{SV-MA-6}{CA-9,PL-7,PL-8,PL-8(1),SA-8(3),SA-8(4),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30)}
The [organization] shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection.{SV-MA-6}{PL-7,SA-2,SA-8,SA-8(1),SA-8(2),SA-8(3),SA-8(4),SA-8(5),SA-8(6),SA-8(7),SA-8(9),SA-8(11),SA-8(13),SA-8(19),SA-8(29),SA-8(30),SC-32,SC-32(1)}