The spacecraft shall protect the commanding capability from intrusion.
Low-Level Requirements
Requirement
Rationale/Additional Guidance/Notes
The spacecraft shall implement relay and replay-resistant authentication mechanisms for establishing a remote connection. {SV-AC-1,SV-AC-2} {IA-2(8)}
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)}
This could be performed using command lockout based upon when the spacecraft is over selected regions. This should be configurable so that when conflicts arise, the Program can update. The goal is so the spacecraft won't accept a command when the spacecraft determines it is in a certain region.
The spacecraft shall provide the capability to restrict command lock based on geographic location of ground stations. {SV-AC-1} {AC-2(11)}
Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values.
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 not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). {SV-AC-1,SV-CF-1,SV-CF-2} {AC-3(10)}
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 Program shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys. {SV-AC-1,SV-AC-3} {IA-5(7)}
The spacecraft shall protect authenticator content from unauthorized disclosure and modification. {SV-AC-1,SV-AC-3} {IA-5}
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}
Examples of devices to handle keys are electron circuits via FPGAs or ASICS. Intent is to ensure the FSW does not have access to crypto keys and system complies with the key management plan.
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)}
FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.
NSA-approved technology used for symmetric 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.
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)}
In most cased the Program will leverage NSA-approved key management technology and processes.
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 fail securely to a secondary device in the event of an operational failure of a primary boundary protection device (i.e., crypto solution). {SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2} {SC-7(18)}
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 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 mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management.
The spacecraft shall have on-board intrusion detection/prevention system that monitors the mission critical components or systems. {SV-AC-1,SV-AC-2,SV-MA-4} {SC-7}
Source from AEROSPACE REPORT NO. TOR-2019-02178
Vehicle Command Counter (VCC) - Counts received valid commands
Rejected Command Counter - Counts received invalid commands
Command Receiver On/Off Mode - Indicates times command receiver is accepting commands
Command Receivers Received Signal Strength - Analog measure of the amount of received RF energy at the receive frequency
Command Receiver Lock Modes - Indicates when command receiver has achieved lock on command signal
Telemetry Downlink Modes - Indicates when the satellite’s telemetry was transmitting
Cryptographic Modes - Indicates the operating modes of the various encrypted links
Received Commands - Log of all commands received and executed by the satellite
System Clock - Master onboard clock
GPS Ephemeris - Indicates satellite location derived from GPS Signals
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)}
This requirement applies if system components are being designed to address EMSEC and the measures taken to protect against compromising emanations must be in accordance with DODD S-5200.19, or superseding requirements.
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)}
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.
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.
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.
Threat actors may compromise a 3rd-party spacecraft that has the capability to maneuver within close proximity to a target spacecraft. This technique enables historically lower-tier attackers the same capability as top tier nation-state actors without the initial development cost. Additionally, this technique complicates attribution of an attack. Since many of the commercial and military assets in space are tracked, and that information is publicly available, attackers can identify the location of space assets to infer the best positioning for intersecting orbits. Proximity operations support avoidance of the larger attenuation that would otherwise affect the signal when propagating long distances, or environmental circumstances that may present interference. Further, the compromised spacecraft may posses the capability to grapple target spacecraft once it has established the appropriate space rendezvous. If from a proximity / rendezvous perspective a threat actor has the ability to connect via docking interface or expose testing (i.e., JTAG port) once it has grappled the target spacecraft, they could perform various attacks depending on the access enabled via the physical connection.
Threat actors may compromise a victim spacecraft via the crosslink communications of a neighboring spacecraft that has been compromised. spacecraft in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other spacecraft once they have access to another that is nearby.
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.
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.
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.
Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site.
Threat actors may gain access to a victim spacecraft through the use of a rogue ground system. With this technique, the threat actor does not need access to a legitimate ground station or communication site.
Replay attacks involve threat actors recording previously data streams and then resending them at a later time. This attack can be used to fingerprint systems, gain elevated privileges, or even cause a denial of service.
Threat actors may interact with the victim spacecraft by replaying captured commands to the spacecraft. While not necessarily malicious in nature, replayed commands can be used to overload the target spacecraft and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the spacecraft. If critical commands are captured and replayed, thruster fires, then the impact could impact the spacecraft's attitude control/orbit.
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.
Threat actors may attempt to command another neighboring spacecraft via crosslink. spacecraft in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another spacecraft.
Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked.
Threat actors may attempt to exfiltrate data via the out-of-band communication channels. While performing eavesdropping on the primary/second uplinks and downlinks is a method for exfiltration, some space vehicles leverage out-of-band communication links to perform actions on the space vehicle (i.e., re-keying). These out-of-band links would occur on completely different channels/frequencies and often operate on separate hardware on the space vehicle. Typically these out-of-band links have limited built-for-purpose functionality and likely do not present an initial access vector but they do provide ample exfiltration opportunity.
Measures designed to mislead an adversary by manipulation, distortion, or falsification of evidence or information into a system to induce the adversary to react in a manner prejudicial to their interests. Threat actors may seek to deceive mission stakeholders (or even military decision makers) for a multitude of reasons. Telemetry values could be modified, attacks could be designed to intentionally mimic another threat actor's TTPs, and even allied ground infrastructure could be compromised and used as the source of communications to the spacecraft.
Threat actors may attempt to steal the data that is being gathered, processed, and sent from the victim spacecraft. Many spacecraft have a particular purpose associated with them and the data they gather is deemed mission critical. By attempting to steal this data, the mission, or purpose, of the spacecraft could be lost entirely.
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
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.
Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment.
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.
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.
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.
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.
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.
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.
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.
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
In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.