Attempting access to an access-controlled system resulting in unauthorized access
| 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)} |
| ID | Name | Description | |
|---|---|---|---|
| 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 SV. 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 SV. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. | |
| RD-0002.03 | 3rd-Party Spacecraft | Threat actors may compromise a 3rd-party SV that has the capability to maneuver within close proximity to a target SV. 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. | |
| IA-0003 | Crosslink via Compromised Neighbor | Threat actors may compromise a victim SV via the crosslink communications of a neighboring SV that has been compromised. SVs in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other SVs once they have access to another that is nearby. | |
| IA-0007 | Compromise Ground Station | Threat actors may initially compromise the ground station in order to access the target SV. 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. | |
| IA-0007.01 | Compromise On-Orbit Update | Threat actors may manipulate and modify on-orbit updates before they are sent to the target SV. 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 SV. 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-0008 | Rogue External Entity | Threat actors may gain access to a victim SV 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. | |
| IA-0008.01 | Rogue Ground Station | Threat actors may gain access to a victim SV 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. | |
| EX-0001 | Replay | 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. | |
| EX-0001.01 | Command Packets | Threat actors may interact with the victim SV by replaying captured commands to the SV. While not necessarily malicious in nature, replayed commands can be used to overload the target SV and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the SV. If critical commands are captured and replayed, thruster fires, then the impact could impact the SV's attitude control/orbit. | |
| EXF-0004 | Out-of-Band Communications Link | 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. | |
| 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 SV 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. | |
| LM-0003 | Constellation Hopping via Crosslink | Threat actors may attempt to command another neighboring spacecraft via crosslink. SVs in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another SV. | |
| LM-0004 | Visiting Vehicle Interface(s) | Threat actors may move to other SVs through visiting vehicle interfaces. When a vehicle docks with a SV, 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 SV 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 SV once docked. | |
| IMP-0001 | Deception (or Misdirection) | 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 SV. | |
| IMP-0006 | Theft | Threat actors may attempt to steal the data that is being gathered, processed, and sent from the victim SV. Many SVs 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 SV could be lost entirely. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0000 | Countermeasure Not Identified | This technique is a result of utilizing TTPs to create an impact and the applicable countermeasures are associated with the TTPs leveraged to achieve the impact | None | None | ||
| CM0001 | Protect Sensitive Information | Organizations should look to identify and properly classify mission sensitive design/operations information (e.g., fault management approach) and apply access control accordingly. Any location (ground system, contractor networks, etc.) storing design information needs to ensure design info is protected from exposure, exfiltration, etc. Space system sensitive information may be classified as Controlled Unclassified Information (CUI) or Company Proprietary. Space system sensitive information can typically include a wide range of candidate material: the functional and performance specifications, any ICDs (like radio frequency, ground-to-space, etc.), command and telemetry databases, scripts, simulation and rehearsal results/reports, descriptions of uplink protection including any disabling/bypass features, failure/anomaly resolution, and any other sensitive information related to architecture, software, and flight/ground /mission operations. This could all need protection at the appropriate level (e.g., unclassified, CUI, proprietary, classified, etc.) to mitigate levels of cyber intrusions that may be conducted against the project’s networks. Stand-alone systems and/or separate database encryption may be needed with controlled access and on-going Configuration Management to ensure changes in command procedures and critical database areas are tracked, controlled, and fully tested to avoid loss of science or the entire mission. Sensitive documentation should only be accessed by personnel with defined roles and a need to know. Well established access controls (roles, encryption at rest and transit, etc.) and data loss prevention (DLP) technology are key countermeasures. The DLP should be configured for the specific data types in question. | AC-3(11) AC-4(23) AC-4(25) CM-12 CM-12(1) PM-11 PM-17 SA-3(1) SA-3(2) SA-4(12) SA-5 SA-9(7) SI-21 SI-23 SR-12 SR-7 | A.8.4 A.8.11 A.8.10 A.8.33 7.5.1 7.5.2 7.5.3 A.5.37 A.8.10 A.5.22 | ||