A.5.4 - Management responsibilities

NIST SP 800-53 Revision 5 Mapping

ID Name
AC-1 Policy and Procedures
AT-1 Policy and Procedures
AU-1 Policy and Procedures
CA-1 Policy and Procedures
CM-1 Policy and Procedures
CP-1 Policy and Procedures
IA-1 Policy and Procedures
IR-1 Policy and Procedures
MA-1 Policy and Procedures
MP-1 Policy and Procedures
PE-1 Policy and Procedures
PL-1 Policy and Procedures
PL-4 Rules of Behavior
PM-1 Information Security Program Plan
PM-18 Privacy Program Plan
PS-1 Policy and Procedures
PS-6 Access Agreements
PS-7 External Personnel Security
PT-1 Policy and Procedures
RA-1 Policy and Procedures
SA-1 Policy and Procedures
SA-9 External System Services
SC-1 Policy and Procedures
SI-1 Policy and Procedures
SR-1 Policy and Procedures

SPARTA Countermeasures Mapping

ID Name Description D3FEND
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. D3-AVE D3-OSM D3-IDA D3-SJA D3-AI D3-DI D3-SWI D3-NNI D3-HCI D3-NM D3-PLM D3-AM D3-SYSM D3-SVCDM D3-SYSDM D3-SYSVA D3-OAM D3-ORA
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.  D3-AI D3-SWI D3-HCI D3-FEMC D3-DLIC D3-FV
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. D3-OAM D3-ODM
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. D3-OAM D3-ODM D3-AM D3-FV D3-SFV
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. D3-OAM D3-ODM D3-AM D3-FV D3-SFV
CM0028 Tamper Protection Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. D3-PH D3-AH D3-RFS D3-FV
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. D3-OAM D3-ORA
CM0088 Organizational Policy Documenting cyber security policies is crucial for several reasons, paramount among them being the establishment of a clear, consistent framework for managing and protecting an organization's information assets. Such documentation serves as a foundational guideline that outlines the principles, procedures, and responsibilities that govern the security of information. Having well-documented security policies ensures that everyone in the organization, from the top management to the newest employee, is on the same page regarding security expectations and behaviors. It provides a reference point for all staff, helping them understand their roles and responsibilities in safeguarding sensitive data. By clearly defining what is expected, employees are better equipped to follow best practices and avoid actions that could compromise security. These policies act as a guide for implementing technical controls and security measures. They inform the selection, development, and maintenance of security tools and protocols, ensuring that there is a methodical approach to securing the organization's digital assets. In the event of a security incident, having a documented policy in place provides a roadmap for response and recovery, reducing the time and resources spent in mitigating the issue. As cybersecurity in space is an area where regulatory compliance is becoming increasingly stringent, having documented information security policies is often a legal or regulatory requirement, and not simply a best practice.
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. 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
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]. Ideally old versions of software are removed after upgrading but restoration states (i.e., gold images) are recommended to remain on the system. D3-SU
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. D3-AI D3-AVE D3-SWI
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. D3-LFP D3-UBA D3-RAPA D3-MAC
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. D3-PM D3-SBV D3-EI D3-EAL D3- EDL D3-DCE
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. D3-CH D3-CBAN D3-FV D3-DLIC D3-EAL D3-SBV
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. Nearly all D3FEND Techniques apply to Ground
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. D3-MH D3-MAN

Related SPARTA Techniques and Sub-Techniques

ID Name Description
REC-0001 Gather Spacecraft Design Information Threat actors may gather information about the victim spacecraft's design that can be used for future campaigns or to help perpetuate other techniques. Information about the spacecraft can include software, firmware, encryption type, purpose, as well as various makes and models of subsystems.
REC-0001.01 Software Threat actors may gather information about the victim spacecraft's internal software that can be used for future campaigns or to help perpetuate other techniques. Information (e.g. source code, binaries, etc.) about commercial, open-source, or custom developed software may include a variety of details such as types, versions, and memory maps. Leveraging this information threat actors may target vendors of operating systems, flight software, or open-source communities to embed backdoors or for performing reverse engineering research to support offensive cyber operations.
REC-0001.02 Firmware Threat actors may gather information about the victim spacecraft's firmware that can be used for future campaigns or to help perpetuate other techniques. Information about the firmware may include a variety of details such as type and versions on specific devices, which may be used to infer more information (ex. configuration, purpose, age/patch level, etc.). Leveraging this information threat actors may target firmware vendors to embed backdoors or for performing reverse engineering research to support offensive cyber operations.
REC-0001.03 Cryptographic Algorithms Threat actors may gather information about any cryptographic algorithms used on the victim spacecraft's that can be used for future campaigns or to help perpetuate other techniques. Information about the algorithms can include type and private keys. Threat actors may also obtain the authentication scheme (i.e., key/password/counter values) and leverage it to establish communications for commanding the target spacecraft or any of its subsystems. Some spacecraft only require authentication vice authentication and encryption, therefore once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. The authentication information may be obtained through reconnaissance of the ground system or retrieved from the victim spacecraft.
REC-0001.04 Data Bus Threat actors may gather information about the data bus used within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information about the data bus can include the make and model which could lead to more information (ex. protocol, purpose, controller, etc.), as well as locations/addresses of major subsystems residing on the bus. Threat actors may also gather information about the bus voltages of the victim spacecraft. This information can include optimal power levels, connectors, range, and transfer rate.
REC-0001.05 Thermal Control System Threat actors may gather information about the thermal control system used with the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include type, make/model, and varies analysis programs that monitor it.
REC-0001.06 Maneuver & Control Threat actors may gather information about the station-keeping control systems within the victim spacecraft that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include thruster types, propulsion types, attitude sensors, and data flows associated with the relevant subsystems.
REC-0001.07 Payload Threat actors may gather information about the type(s) of payloads hosted on the victim spacecraft. This information could include specific commands, make and model, and relevant software. Threat actors may also gather information about the location of the payload on the bus and internal routing as it pertains to commands within the payload itself.
REC-0001.08 Power Threat actors may gather information about the power system used within the victim spacecraft. This information can include type, power intake, and internal algorithms. Threat actors may also gather information about the solar panel configurations such as positioning, automated tasks, and layout. Additionally, threat actors may gather information about the batteries used within the victim spacecraft. This information can include the type, quantity, storage capacity, make and model, and location.
REC-0001.09 Fault Management Threat actors may gather information about any fault management that may be present on the victim spacecraft. This information can help threat actors construct specific attacks that may put the spacecraft into a fault condition and potentially a more vulnerable state depending on the fault response.
REC-0002 Gather Spacecraft Descriptors Threat actors may gather information about the victim spacecraft's descriptors that can be used for future campaigns or to help perpetuate other techniques. Information about the descriptors may include a variety of details such as identity attributes, organizational structures, and mission operational parameters.
REC-0002.01 Identifiers Threat actors may gather information about the victim spacecraft's identity attributes that can be used for future campaigns or to help perpetuate other techniques. Information may include a variety of details such as the satellite catalog number, international designator, mission name, and more.
REC-0002.02 Organization Threat actors may gather information about the victim spacecraft's associated organization(s) that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target the mission owner/operator in order to conduct further attacks against the organization, individual, or other interested parties. Threat actors may also seek information regarding the spacecraft's designer/builder, including physical locations, key employees, and roles and responsibilities as they pertain to the spacecraft, as well as information pertaining to the mission's end users/customers.
REC-0002.03 Operations Threat actors may gather information about the victim spacecraft's operations that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target mission objectives, orbital parameters such as orbit slot and inclination, user guides and schedules, etc. Additionally, threat actors may seek information about constellation deployments and configurations where applicable.
REC-0003 Gather Spacecraft Communications Information Threat actors may obtain information on the victim spacecraft's communication channels in order to determine specific commands, protocols, and types. Information gathered can include commanding patterns, antenna shape and location, beacon frequency and polarization, and various transponder information.
REC-0003.01 Communications Equipment Threat actors may gather information regarding the communications equipment and its configuration that will be used for communicating with the victim spacecraft. This includes: Antenna Shape: This information can help determine the range in which it can communicate, the power of it's transmission, and the receiving patterns. Antenna Configuration/Location: This information can include positioning, transmission frequency, wavelength, and timing. Telemetry Signal Type: Information can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's telemetry system. Beacon Frequency: This information can provide insight into where the spacecrafts located, what it's orbit is, and how long it can take to communicate with a ground station. Beacon Polarization: This information can help triangulate the spacecrafts it orbits the earth and determine how a satellite must be oriented in order to communicate with the victim spacecraft. Transponder: This could include the number of transponders per band, transponder translation factor, transponder mappings, power utilization, and/or saturation point.
REC-0003.02 Commanding Details Threat actors may gather information regarding the commanding approach that will be used for communicating with the victim spacecraft. This includes: Commanding Signal Type: This can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's commanding system. Valid Commanding Patterns: Most commonly, this comes in the form of a command database, but can also include other means that provide information on valid commands and the communication protocols used by the victim spacecraft. Valid Commanding Periods: This information can provide insight into when a command will be accepted by the spacecraft and help the threat actor construct a viable attack campaign.
REC-0003.03 Mission-Specific Channel Scanning Threat actors may seek knowledge about mission-specific communication channels dedicated to a payload. Such channels could be managed by a different organization than the owner of the spacecraft itself.
REC-0003.04 Valid Credentials Threat actors may seek out valid credentials which can be utilized to facilitate several tactics throughout an attack. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms.
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-0006 Gather FSW Development Information Threat actors may obtain information regarding the flight software (FSW) development environment for the victim spacecraft. This information may include the development environment, source code, compiled binaries, testing tools, and fault management.
REC-0006.01 Development Environment Threat actors may gather information regarding the development environment for the victim spacecraft's FSW. This information can include IDEs, configurations, source code, environment variables, source code repositories, code "secrets", and compiled binaries.
REC-0006.02 Security Testing Tools Threat actors may gather information regarding how a victim spacecraft is tested in regards to the FSW. Understanding the testing approach including tools could identify gaps and vulnerabilities that could be discovered and exploited by a threat actor.
REC-0007 Monitor for Safe-Mode Indicators Threat actors may gather information regarding safe-mode indicators on the victim spacecraft. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft 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.
REC-0008 Gather Supply Chain Information Threat actors may gather information about a mission's supply chain or product delivery mechanisms that can be used for future campaigns or to help perpetuate other techniques.
REC-0008.01 Hardware Threat actors may gather information that can be used to facilitate a future attack where they manipulate hardware components in the victim spacecraft prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well.
REC-0008.02 Software Threat actors may gather information relating to the mission's software supply chain in order to facilitate future attacks to achieve data or system compromise. This attack can take place in a number of ways, including manipulation of source code, manipulation of the update and/or distribution mechanism, or replacing compiled versions with a malicious one.
REC-0008.03 Known Vulnerabilities Threat actors may gather information about vulnerabilities that can be used for future campaigns or to perpetuate other techniques. A vulnerability is a weakness in the victim spacecraft's hardware, subsystems, bus, or software that can, potentially, be exploited by a threat actor to cause unintended or unanticipated behavior to occur. During reconnaissance as threat actors identify the types/versions of software (i.e., COTS, open-source) being used, they will look for well-known vulnerabilities that could affect the space vehicle. Threat actors may find vulnerability information by searching leaked documents, vulnerability databases/scanners, compromising ground systems, and searching through online databases.
REC-0008.04 Business Relationships Adversaries may gather information about the victim's business relationships that can be used during targeting. Information about an mission’s business relationships may include a variety of details, including second or third-party organizations/domains (ex: managed service providers, contractors/sub-contractors, etc.) that have connected (and potentially elevated) network access or sensitive information. This information may also reveal supply chains and shipment paths for the victim’s hardware and software resources.
REC-0009 Gather Mission Information Threat actors may initially seek to gain an understanding of a target mission by gathering information commonly captured in a Concept of Operations (or similar) document and related artifacts. Information of interest includes, but is not limited to: - the needs, goals, and objectives of the system - system overview and key elements/instruments - modes of operations (including operational constraints) - proposed capabilities and the underlying science/technology used to provide capabilities (i.e., scientific papers, research studies, etc.) - physical and support environments
RD-0002 Compromise Infrastructure Threat actors may compromise third-party infrastructure that can be used for future campaigns or to perpetuate other techniques. Infrastructure solutions include physical devices such as antenna, amplifiers, and convertors, as well as software used by satellite communicators. Instead of buying or renting infrastructure, a threat actor may compromise infrastructure and use it during other phases of the campaign's lifecycle.
RD-0002.01 Mission-Operated Ground System Threat actors may compromise mission owned/operated ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
RD-0002.02 3rd Party Ground System Threat actors may compromise access to third-party ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems can be or may have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation.
RD-0003 Obtain Cyber Capabilities Threat actors may buy and/or steal cyber capabilities that can be used for future campaigns or to perpetuate other techniques. Rather than developing their own capabilities in-house, threat actors may purchase, download, or steal them. Activities may include the acquisition of malware, software, exploits, and information relating to vulnerabilities. Threat actors may obtain capabilities to support their operations throughout numerous phases of the campaign lifecycle.
RD-0003.02 Cryptographic Keys Threat actors may obtain encryption keys as they are used for the main commanding of the target spacecraft or any of its subsystems/payloads. Once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. These keys may be obtained through reconnaissance of the ground system or retrieved from the victim spacecraft.
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-0001 Compromise Supply Chain Threat actors may manipulate or compromise products or product delivery mechanisms before the customer receives them in order to achieve data or system compromise.
IA-0001.01 Software Dependencies & Development Tools Threat actors may manipulate software dependencies (i.e. dependency confusion) and/or development tools prior to the customer receiving them in order to achieve data or system compromise. Software binaries and applications often depend on external software to function properly. spacecraft developers may use open source projects to help with their creation. These open source projects may be targeted by threat actors as a way to add malicious code to the victim spacecraft's dependencies.
IA-0001.02 Software Supply Chain Threat actors may manipulate software binaries and applications prior to the customer receiving them in order to achieve data or system compromise. This attack can take place in a number of ways, including manipulation of source code, manipulation of the update and/or distribution mechanism, or replacing compiled versions with a malicious one.
IA-0001.03 Hardware Supply Chain Threat actors may manipulate hardware components in the victim spacecraft prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well. A spacecraft component can also be damaged if a specific HW component, built to fail after a specific period, or counterfeit with a low reliability, breaks out.
IA-0002 Compromise Software Defined Radio Threat actors may target software defined radios due to their software nature to establish C2 channels. Since SDRs are programmable, when combined with supply chain or development environment attacks, SDRs provide a pathway to setup covert C2 channels for a threat actor.
IA-0004 Secondary/Backup Communication Channel Threat actors may compromise alternative communication pathways which may not be as protected as the primary pathway. Depending on implementation the contingency communication pathways/solutions may lack the same level of security (i.e., physical security, encryption, authentication, etc.) which if forced to use could provide a threat actor an opportunity to launch attacks. Typically these would have to be coupled with other denial of service techniques on the primary pathway to force usage of secondary pathways.
IA-0004.01 Ground Station Threat actors may establish a foothold within the backup ground/mission operations center (MOC) and then perform attacks to force primary communication traffic through the backup communication channel so that other TTPs can be executed (man-in-the-middle, malicious commanding, malicious code, etc.). While an attacker would not be required to force the communications through the backup channel vice waiting until the backup is used for various reasons. Threat actors can also utilize compromised ground stations to chain command execution and payload delivery across geo-separated ground stations to extend reach and maintain access on spacecraft. The backup ground/MOC should be considered a viable attack vector and the appropriate/equivalent security controls from the primary communication channel should be on the backup ground/MOC as well.
IA-0004.02 Receiver Threat actors may target the backup/secondary receiver on the space vehicle as a method to inject malicious communications into the mission. The secondary receivers may come from different supply chains than the primary which could have different level of security and weaknesses. Similar to the ground station, the communication through the secondary receiver could be forced or happening naturally.
IA-0006 Compromise Hosted Payload Threat actors may compromise the target spacecraft hosted payload to initially access and/or persist within the system. Hosted payloads can usually be accessed from the ground via a specific command set. The command pathways can leverage the same ground infrastructure or some host payloads have their own ground infrastructure which can provide an access vector as well. Threat actors may be able to leverage the ability to command hosted payloads to upload files or modify memory addresses in order to compromise the system. Depending on the implementation, hosted payloads may provide some sort of lateral movement potential.
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.
IA-0007.02 Malicious Commanding via Valid GS Threat actors may compromise target owned ground systems components (e.g., front end processors, command and control software, etc.) that can be used for future campaigns or to perpetuate other techniques. These ground systems components have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
IA-0009 Trusted Relationship Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status.
IA-0009.01 Mission Collaborator (academia, international, etc.) Threat actors may seek to exploit mission partners to gain an initial foothold for pivoting into the mission environment and eventually impacting the spacecraft. The complex nature of many space systems rely on contributions across organizations, including academic partners and even international collaborators. These organizations will undoubtedly vary in their system security posture and attack surface.
IA-0009.02 Vendor Threat actors may target the trust between vendors and the target space vehicle. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target space vehicle. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the space vehicle context vendors may have direct commanding and updating capabilities outside of the primary communication channel.
IA-0009.03 User Segment Threat actors can target the user segment in an effort to laterally move into other areas of the end-to-end mission architecture. When user segments are interconnected, threat actors can exploit lack of segmentation as the user segment's security undoubtedly varies in their system security posture and attack surface than the primary space mission. The user equipment and users themselves provide ample attack surface as the human element and their vulnerabilities (i.e., social engineering, phishing, iOT) are often the weakest security link and entry point into many systems.
IA-0010 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim spacecraft 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 spacecraft 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-0011 Auxiliary Device Compromise Threat actors may exploit the auxiliary/peripheral devices that get plugged into space vehicles. It is no longer atypical to see space vehicles, especially CubeSats, with Universal Serial Bus (USB) ports or other ports where auxiliary/peripheral devices can be plugged in. Threat actors can execute malicious code on the space vehicles by copying the malicious code to auxiliary/peripheral devices and taking advantage of logic on the space vehicle to execute code on these devices. This may occur through manual manipulation of the auxiliary/peripheral devices, modification of standard IT systems used to initially format/create the auxiliary/peripheral device, or modification to the auxiliary/peripheral devices' firmware itself.
IA-0012 Assembly, Test, and Launch Operation Compromise Threat actors may target the spacecraft hardware and/or software while the spacecraft is at Assembly, Test, and Launch Operation (ATLO). ATLO is often the first time pieces of the spacecraft are fully integrated and exchanging data across interfaces. Malware could propagate from infected devices across the integrated spacecraft. For example, test equipment (i.e., transient cyber asset) is often brought in for testing elements of the spacecraft. Additionally, varying levels of physical security is in place which may be a reduction in physical security typically seen during development. The ATLO environment should be considered a viable attack vector and the appropriate/equivalent security controls from the primary development environment should be implemented during ATLO as well.
EX-0003 Modify Authentication Process Threat actors may modify the internal authentication process of the victim spacecraft to facilitate initial access, recurring execution, or prevent authorized entities from accessing the spacecraft. This can be done through the modification of the software binaries or memory manipulation techniques.
EX-0004 Compromise Boot Memory Threat actors may manipulate boot memory in order to execute malicious code, bypass internal processes, or DoS the system. This technique can be used to perform other tactics such as Defense Evasion.
EX-0005 Exploit Hardware/Firmware Corruption Threat actors can target the underlying hardware and/or firmware using various TTPs that will be dependent on the specific hardware/firmware. Typically, software tools (e.g., antivirus, antimalware, intrusion detection) can protect a system from threat actors attempting to take advantage of those vulnerabilities to inject malicious code. However, there exist security gaps that cannot be closed by the above-mentioned software tools since they are not stationed on software applications, drivers or the operating system but rather on the hardware itself. Hardware components, like memory modules and caches, can be exploited under specific circumstances thus enabling backdoor access to potential threat actors. In addition to hardware, the firmware itself which often is thought to be software in its own right also provides an attack surface for threat actors. Firmware is programming that's written to a hardware device's non-volatile memory where the content is saved when a hardware device is turned off or loses its external power source. Firmware is written directly onto a piece of hardware during manufacturing and it is used to run on the device and can be thought of as the software that enables hardware to run. In the space vehicle context, firmware and field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic/code is considered equivalent to firmware.
EX-0005.01 Design Flaws Threat actors may target design features/flaws with the hardware design to their advantage to cause the desired impact. Threat actors may utilize the inherent design of the hardware (e.g. hardware timers, hardware interrupts, memory cells), which is intended to provide reliability, to their advantage to degrade other aspects like availability. Additionally, field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic can be exploited just like software code can be exploited. There could be logic/design flaws embedded in the hardware (i.e., FPGA/ASIC) which may be exploitable by a threat actor.
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-0009 Exploit Code Flaws Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target spacecraft. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components.
EX-0009.01 Flight Software Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. Some FSW suites contain API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. In some cases, these code flaws can perpetuate throughout the victim spacecraft, allowing access to otherwise segmented subsystems.
EX-0009.02 Operating System Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus. There has been a trend where some modern spacecraft are running Unix-based operating systems and establishing SSH connections for communications between the ground and spacecraft. Threat actors may seek to gain access to command line interfaces & shell environments in these instances. Additionally, most operating systems, including real-time operating systems, include API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands.
EX-0009.03 Known Vulnerability (COTS/FOSS) Threat actors may utilize knowledge of the spacecraft software composition to enumerate and exploit known flaws or vulnerabilities in the commercial or open source software running on-board the target spacecraft.
EX-0010 Malicious Code Threat actors may rely on other tactics and techniques in order to execute malicious code on the victim spacecraft. This can be done via compromising the supply chain or development environment in some capacity or taking advantage of known commands. However, once malicious code has been uploaded to the victim spacecraft, the threat actor can then trigger the code to run via a specific command or wait for a legitimate user to trigger it accidently. The code itself can do a number of different things to the hosted payload, subsystems, or underlying OS.
EX-0010.01 Ransomware Threat actors may encrypt spacecraft data to interrupt availability and usability. Threat actors can attempt to render stored data inaccessible by encrypting files or data and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key or to render data permanently inaccessible in cases where the key is not saved or transmitted.
EX-0010.02 Wiper Malware Threat actors may deploy wiper malware, which is a type of malicious software designed to destroy data or render it unusable. Wiper malware can spread through various means, software vulnerabilities (CWE/CVE), or by exploiting weak or stolen credentials.
EX-0010.03 Rootkit Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.
EX-0010.04 Bootkit Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
EX-0011 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim spacecraft 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 spacecraft 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-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.12 System Clock An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, such as forcing execution of stored commands in an incorrect order.
EX-0016 Jamming Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions.
EX-0016.03 Position, Navigation, and Timing (PNT) Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions.
EX-0014 Spoofing Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim spacecraft. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the spacecraft to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the spacecraft's reliability and integrity.
EX-0014.01 Time Spoof Threat actors may attempt to target the internal timers onboard the victim spacecraft and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the spacecraft and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the spacecraft is in orbit in order for it to fulfill it's purpose. Threat actors that target this particular system and attempt to spoof it's data could cause these processes to trigger early or late.
EX-0014.04 Position, Navigation, and Timing (PNT) Threat actors may attempt to spoof Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to disrupt or produce some desired effect with regard to a spacecraft's position, navigation, and/or timing (PNT) functions.
PER-0001 Memory Compromise Threat actors may manipulate memory (boot, RAM, etc.) in order for their malicious code and/or commands to remain on the victim spacecraft. The spacecraft may have mechanisms that allow for the automatic running of programs on system reboot, entering or returning to/from safe mode, or during specific events. Threat actors may target these specific memory locations in order to store their malicious code or file, ensuring that the attack remains on the system even after a reset.
PER-0002 Backdoor Threat actors may find and target various backdoors, or inject their own, within the victim spacecraft in the hopes of maintaining their attack.
PER-0002.01 Hardware Threat actors may find and target various hardware backdoors within the victim spacecraft in the hopes of maintaining their attack. Once in orbit, mitigating the risk of various hardware backdoors becomes increasingly difficult for ground controllers. By targeting these specific vulnerabilities, threat actors are more likely to remain persistent on the victim spacecraft and perpetuate further attacks.
PER-0002.02 Software Threat actors may inject code to create their own backdoor to establish persistent access to the spacecraft. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable).
PER-0003 Ground System Presence Threat actors may compromise target owned ground systems that can be used for persistent access to the spacecraft or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute persistently.
PER-0004 Replace Cryptographic Keys Threat actors may attempt to fully replace the cryptographic keys on the space vehicle which could lockout the mission operators and enable the threat actor's communication channel. Once the encryption key is changed on the space vehicle, the spacecraft is rendered inoperable from the operators perspective as they have lost commanding access. Threat actors may exploit weaknesses in the key management strategy. For example, the threat actor may exploit the over-the-air rekeying procedures to inject their own cryptographic keys.
PER-0005 Valid Credentials Threat actors may seek out valid credentials which can be utilized to maintain persistent access to the spacecraft or related C2 systems and facilitate additional tactics throughout an attack. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms.
DE-0002 Prevent Downlink Threat actors may target the downlink connections to prevent the victim spacecraft from sending telemetry to the ground controllers. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0002.01 Inhibit Ground System Functionality Threat actors may utilize ground-system presence to inhibit the ground system software's ability to process (or display) telemetry, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0003 Modify On-Board Values Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock.
DE-0003.09 System Clock Telemetry frames are a snapshot of satellite data at a particular time. Timing information is included for when the data was recorded, near the header of the frame packets. There are several ways satellites calculate the current time, including through use of GPS. An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, including misrepresentation of when certain actions took place.
DE-0004 Masquerading Threat actors may gain access to a victim spacecraft by masquerading as an authorized entity. This can be done several ways, including through the manipulation of command headers, spoofing locations, or even leveraging Insider's access (i.e., Insider Threat)
DE-0005 Exploit Reduced Protections During Safe-Mode Threat actors may take advantage of the victim spacecraft 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 spacecraft 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.
DE-0007 Rootkit Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.
DE-0008 Bootkit Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly.
DE-0011 Valid Credentials Threat actors may utilize valid credentials to conduct an attack against a spacecraft or related system as a means to conceal their activity. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms.
LM-0001 Hosted Payload Threat actors may use the hosted payload within the victim spacecraft in order to gain access to other subsystems. The hosted payload often has a need to gather and send data to the internal subsystems, depending on its purpose. Threat actors may be able to take advantage of this communication in order to laterally move to the other subsystems and have commands be processed.
LM-0002 Exploit Lack of Bus Segregation Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller)
LM-0007 Valid Credentials Threat actors may utilize valid credentials move laterally across spacecraft subsystems, communication buses, or additional spacecraft in a constellation. Credentials may include, but are not limited to: system service accounts, user accounts, maintenance accounts, cryptographic keys and other authentication mechanisms.
EXF-0006 Modify Communications Configuration Threat actors can manipulate communications equipment, modifying the existing software, hardware, or the transponder configuration to exfiltrate data via unintentional channels the mission has no control over.
EXF-0006.01 Software Defined Radio Threat actors may target software defined radios due to their software nature to setup exfiltration channels. Since SDRs are programmable, when combined with supply chain or development environment attacks, SDRs provide a pathway to setup covert exfiltration channels for a threat actor.
EXF-0006.02 Transponder Threat actors may change the transponder configuration to exfiltrate data via radio access to an attacker-controlled asset.
EXF-0007 Compromised Ground System Threat actors may compromise target owned ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
EXF-0008 Compromised Developer Site Threat actors may compromise development environments located within the ground system or a developer/partner site. This attack can take place in a number of different ways, including manipulation of source code, manipulating environment variables, or replacing compiled versions with a malicious one. This technique is usually performed before the target spacecraft is in orbit, with the hopes of adding malicious code to the actual FSW during the development process.
EXF-0009 Compromised Partner Site Threat actors may compromise access to partner sites that can be used for future campaigns or to perpetuate other techniques. These sites are typically configured for communications to the primary ground station(s) or in some cases the spacecraft itself. Unlike mission operated ground systems, partner sites may provide an easier target for threat actors depending on the company, roles and responsibilities, and interests of the third-party. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.

Space Threats Mapped

ID Description
SV-AC-3 Compromised master keys or any encryption key
SV-IT-2 Unauthorized modification or corruption of data
SV-SP-3 Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse
SV-SP-6 Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat
SV-SP-9 On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code
SV-SP-11 Software defined radios - SDR is also another computer, networked to other parts of the spacecraft that could be pivoted to by an attacker and infected with malicious code. Once access to an SDR is gained, the attacker could alter what the SDR thinks is correct frequencies and settings to communicate with the ground.
SV-SP-7 Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS.
SV-AV-6 Complete compromise or corruption of running state
SV-DCO-1 Not knowing that you were attacked, or attack was attempted
SV-AC-1 Attempting access to an access-controlled system resulting in unauthorized access
SV-AC-2 Replay of recorded authentic communications traffic at a later time with the hope that the authorized communications will provide data or some other system reaction
SV-CF-1 Tapping of communications links (wireline, RF, network) resulting in loss of confidentiality; Traffic analysis to determine which entities are communicating with each other without being able to read the communicated information
SV-IT-1 Communications system spoofing resulting in denial of service and loss of availability and data integrity
SV-AC-7 Weak communication protocols. Ones that don't have strong encryption within it
SV-MA-7 Exploit ground system and use to maliciously to interact with the spacecraft
SV-AC-4 Masquerading as an authorized entity in order to gain access/Insider Threat
SV-AV-7 The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound.
SV-MA-4 Not knowing what your crown jewels are and how to protect them now and in the future.
SV-MA-6 Not planning for security on SV or designing in security from the beginning
SV-SP-4 General supply chain interruption or manipulation
SV-SP-5 Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused}

Sample Requirements

Requirement
The spacecraft's encryption keys shall be restricted so that they cannot be read via any telecommands. {SV-AC-1,SV-AC-3} {SC-12}
The spacecraft's encryption keys shall be restricted so that the onboard software is not able to access the information for key readout. {SV-AC-1,SV-AC-3} {SC-12}
The spacecraft's encryption key handling shall be handled outside of the onboard software and protected using cryptography. {SV-AC-1,SV-AC-3} {SC-12,SC-28(1)}
The spacecraft shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(2)}
The Program shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(2)}
The spacecraft shall produce, control, and distribute asymmetric cryptographic keys using [Program-defined] asymmetric key management processes. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(3)}
The spacecraft shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing]. {SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3} {IA-7,SC-13}
The Program shall use NSA approved key management technology and processes. NSA-approved technology used for asymmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria. {SV-AC-1,SV-AC-3} {SC-12,SC-12(1),SC-12(3)}
The Program shall enable integrity verification of software and firmware components. {SV-IT-2} {SA-10(1),SI-7}
The Program shall perform configuration management during system, component, or service during [design; development; implementation; operations]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-10}
The spacecraft shall 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 Program. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9} {CM-14}
The Program shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2)}
The Program shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2)}
The Program shall perform a manual code review of all flight code. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(4)}
The Program shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of [all] software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11,SA-11(5),CA-8}
The Program shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(5),SA-11(7),CA-8}
The Program shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11}
The Program shall perform vulnerability analysis and risk assessment of [all systems and software]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15(7),RA-5}
The Program shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(1),SA-15(7)}
The Program shall perform static source code analysis for [all available source code] looking for [Select one {Program-defined Top CWE List, SANS Top 25, OWASP Top 10}] weaknesses using no less than two static code analysis tools. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(1),SA-15(7),RA-5}
The Program shall perform component analysis (a.k.a. origin analysis) for developed or acquired software. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15(7),RA-5}
The Program shall 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). {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(5),SA-11(8),CA-8}
The Program shall protect against supply chain threats to the system, system components, or system services by employing [institutional-defined security safeguards] {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-1}
The Program shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design. {SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4} {SR-1,RA-9,SA-15(3),CP-2(8)}
The Program shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S. person information. {SV-SP-3,SV-SP-4,SV-SP-11} {SR-1}
The Program shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SA-11(5)}
The Program shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware. {SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11} {SR-11}
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. See threat ID SV-SP-1, SV-SP-3, and SV-SP-4 for information on secure SW and supply chain protection. Should require contractors to be CMMC 2.0 Level 3 certified (https://www.acq.osd.mil/cmmc/about-us.html). The Program shall ensure [Program defined] security requirements/configurations are placed on the development environments to prevent the compromise of source code from supply chain or information leakage perspective. {SV-SP-10} {SA-15}
The Program shall review proposed changes to the spacecraft, assessing both mission and security impacts. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-10,CM-3(2)}
The Program shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(6),SA-15(5)}
The Program shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11(2),SA-15(8)}
The Program shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11,CA-8}
The Program 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} {SA-11}
The Program shall correct flaws identified during security testing/evaluation. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-11}
The Program shall define acceptable coding languages to be used by the software developer. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15}
The Program shall define acceptable secure coding standards for use by the developer. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15}
The Program shall have automated means to evaluate adherence to coding standards. {SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SA-15,SA-15(7),RA-5}
The Program shall ensure reused TT&C software has adequate uniqueness for command decoders/dictionaries so that commands are received by only the intended satellite. {SV-SP-6} {AC-17(10)}
The Program shall develop and implement anti-counterfeit policy and procedures, in coordination with the [CIO], that is demonstrably consistent with the anti-counterfeit policy defined by the Program office. {SV-SP-4,SV-SP-11} {SR-11}
The Program shall perform static binary analysis of all firmware that is utilized on the spacecraft. {SV-SP-7,SV-SP-11} {SA-11,RA-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}
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)}
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}
The spacecraft shall be designed and configured so that SV memory can be monitored by the on-board intrusion detection/prevention capability. {SV-DCO-1} {SI-16}
The spacecraft shall select and execute safe countermeasures against cyberattacks prior to entering cyber-safe mode. {SV-DCO-1} {SI-17,IR-4}
The spacecraft shall provide the capability to modify the set of audited events (e.g., cyber-relevant data). {SV-DCO-1} {AU-14}
The spacecraft shall uniquely identify and authenticate the ground station and other SVs before establishing a remote connection. {SV-AC-1,SV-AC-2} {IA-3,IA-4,AC-17(10)}
The spacecraft shall authenticate the ground station (and all commands) and other SVs before establishing remote connections using bidirectional authentication that is cryptographically based. {SV-AC-1,SV-AC-2} {IA-3(1),IA-4,IA-7,AC-17(10),AC-17(2),SC-7(11),AC-18(1)}
The spacecraft shall terminate the connection associated with a communications session at the end of the session or after [TBD minutes] of inactivity. {SV-AC-1} {SC-10}
The spacecraft shall restrict the use of information inputs to SVs and designated ground stations as defined in the applicable ICDs. {SV-AC-1,SV-AC-2} {SC-23,SI-10,SI-10(5)}
The spacecraft shall monitor [Program defined telemetry points] for malicious commanding attempts. {SV-AC-1,SV-AC-2} {SC-7,AU-3(1),AC-17(1)}
See threat ID SV-AC-1 for crypto and auth requirements. But to protect for TEMPEST. The spacecraft shall be designed such that it protects itself from information leakage due to electromagnetic signals emanations. {SV-CF-2,SV-MA-2} {PE-19,PE-19(1)}
The Program shall have Insider Threat Program to aid in the prevention of people with authorized access to perform malicious activities. {SV-AC-4} {PM-12,AT-2(2),IR-4(7)}
The [software subsystem] shall initialize the spacecraft to a known safe state. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall identify and reject commands received out-of-sequence when the out-of-sequence commands can cause a hazard/failure or degrade the control of a hazard or mission. {SV-MA-3,SV-AV-7} {SI-10}
The [software subsystem] shall detect and recover/transition from detected memory errors to a known cyber-safe state. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall recover to a known cyber-safe state when an anomaly is detected. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall accept [Program defined hazardous] commands only when prerequisite checks are satisfied. {SV-MA-3,SV-AV-7} {SI-10}
The [software subsystem] shall safely transition between all predefined, known states. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall discriminate between valid and invalid input into the software and rejects invalid input. {SV-MA-3,SV-AV-7} {SI-10,SI-10(3)}
The [software subsystem] shall properly handle spurious input and missing data. {SV-MA-3,SV-AV-7} {SI-10,SI-10(3)}
The spacecraft shall have failure tolerance on sensors used by software to make mission-critical decisions. {SV-MA-3,SV-AV-7} {SI-17}
The [software subsystem] shall provide at least one independent command for each operator-initiated action used to shut down a function leading to or reducing the control of a hazard. {SV-MA-3,SV-AV-7} {SI-10(5)}
The spacecraft’s mission/cyber critical commands shall require to be "complex" and/or diverse from other commands so that a single bit flip could not transform a benign command into a hazardous command. {SV-MA-3,SV-AV-7} {SI-10(5)}
The [software subsystem] shall perform prerequisite checks for the execution of hazardous commands. {SV-MA-3,SV-AV-7} {SI-10}
The [software subsystem] shall validate a functionally independent parameter prior to the issuance of any sequence that could remove an inhibit or perform a hazardous action. {SV-MA-3,SV-AV-7} {SI-10(3)}
The Program shall document the spacecraft's security architecture, and how it is established within and is an integrated part of the Program's mission security architecture. {SV-MA-6} {SA-17}
The Program shall report counterfeit information system components to [Selection (one or more): source of counterfeit component; [Program-defined external reporting organizations]; [Program-defined personnel or roles]]. {SV-SP-4} {SR-11}
The Program shall report counterfeit information system components to the [CIO]. {SV-SP-4} {SR-11}
The Program shall ensure that the contractors/developers have all EEEE, and mechanical piece parts procured from the Original Component Manufacturer (OCM) or their authorized franchised distribution network. {SV-SP-5} {SR-1,SR-5}
Any EEEE or mechanical piece parts that cannot be procured from the OCM or their authorized franchised distribution network shall be approved by the program’s Parts, Materials and Processes Control Board (PMPCB) as well as the government program office to prevent and detect counterfeit and fraudulent parts and materials. {SV-SP-5} {SR-1,SR-5}
The Program shall ensure that the contractors/developers have all ASICs designed, developed, manufactured, packaged, and tested by suppliers with a Defense Microelectronics Activity (DMEA) Trust accreditation. {SV-SP-5} {SR-1,SR-5}
For ASICs that are designed, developed, manufactured, packaged, or tested by a supplier that is NOT DMEA accredited Trusted, the ASIC development shall undergo a threat/vulnerability risk assessment. The assessment shall use Aerospace security guidance and requirements tailored from TOR-2019-00506 Vol. 2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist. Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the ASIC. {SV-SP-5} {SR-1,SR-5}
The developer shall use a DMEA certified environment to develop, code and test executable software (firmware or bit-stream) that will be programmed into a one-time programmable FPGA or be programmed into non-volatile memory (NVRAM) that the FPGA executes. {SV-SP-5} {SR-1,SR-5}
For FPGA pre-silicon artifacts that are developed, coded, and tested by a developer that is NOT DMEA accredited Trusted, the contractor/developer shall be subjected to a development environment and pre-silicon artifacts risk assessment by the Program. The assessment shall use Aerospace security guidance and requirements in TOR-2019-00506 Vol. 2, and TOR-2019-02543 ASIC and FPGA Risk Assessment Process and Checklist. Based on the results of the risk assessment, the Program may require the developer to implement protective measures or other processes to ensure the integrity of the FPGA pre-silicon artifacts. {SV-SP-5} {SR-1,SR-5}
In the event we want to levy the Government Microelectronics Assessment for Trust (GOMAT) framework outright, to perform ASIC and FPGA threat/vulnerability risk assessment, the following requirements would apply: {SV-SP-5} {SR-1,SR-5} * The GOMAT framework shall be used to perform an initial risk assessment via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to provide ASIC/FPGA lifecycle security guidance and requirements via Aerospace TOR-2019-00506 Volumes & 2 “ASIC and FPGA Lifecyle Security: Threats and Countermeasures”. * The GOMAT framework shall be used to perform development environment vulnerability assessment via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to perform development environment vulnerability (DEV) assessment using the tailored DEV requirements from Aerospace TOR-2019-00506 Volume 2. * The GOMAT framework shall be used to perform hardware Trojan horse (HTH) detection independent verification and validation (IV&V). * The GOMAT framework shall be used to perform incremental and final risk assessments via Aerospace TOR-2019-02543 ASIC/FPGA Risk Assessment Process and Checklist. * The GOMAT framework shall be used to recommend mitigations, based on the findings of the risk assessments, to address identified security concerns and vulnerabilities.