Replacing old software on a computer system component.
https://d3fend.mitre.org/technique/d3f:SoftwareUpdate/
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| 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. | CM-3(2) CM-3(7) CM-3(8) CM-4 CM-4(1) CM-5(6) CM-7(5) SA-10(4) SA-11 SA-3 SA-8 SA-8(30) SA-8(31) SA-8(8) SA-9 SI-2 SI-2(6) SI-2(6) SI-7 | D3-SU | A.8.9 A.8.9 A.8.9 A.8.31 A.8.19 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30 A.6.8 A.8.8 A.8.32 | |
| ID | Name | Description | |
|---|---|---|---|
| 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-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. | |
| 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.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. | |
| 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.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). | |
| 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. | |
| ID | Description | |
| SV-AC-3 |
Compromised master keys or any encryption key |
|
| SV-CF-2 |
Eavesdropping (RF and proximity) |
|
| SV-IT-2 |
Unauthorized modification or corruption of data |
|
| SV-MA-2 |
Heaters and flow valves of the propulsion subsystem are controlled by electric signals so cyberattacks against these signals could cause propellant lines to freeze, lock valves, waste propellant or even put in de-orbit or unstable spinning |
|
| SV-AV-4 |
Attacking the scheduling table to affect tasking |
|
| SV-IT-5 |
Onboard control procedures (i.e., ATS/RTS) that execute a scripts/sets of commands |
|
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-SP-1 |
Exploitation of software vulnerabilities (bugs); Unsecure code, logic errors, etc. in the FSW. |
|
| 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-AC-5 |
Proximity operations (i.e., grappling satellite) |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-AC-8 |
Malicious Use of hardware commands - backdoors / critical commands |
|
| SV-AV-2 |
Satellites base many operations on timing especially since many operations are automated. Cyberattack to disrupt timing/timers could affect the vehicle (Time Jamming / Time Spoofing) |
|
| SV-AV-3 |
Affect the watchdog timer onboard the satellite which could force satellite into some sort of recovery mode/protocol |
|
| SV-IT-3 |
Compromise boot memory |
|
| SV-IT-4 |
Cause bit flip on memory via single event upsets |
|
| SV-MA-8 |
Payload (or other component) is told to constantly sense or emit or run whatever mission it had to the point that it drained the battery constantly / operated in a loop at maximum power until the battery is depleted. |
|
| 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-5 |
Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode; |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-MA-5 |
Not being able to recover from cyberattack |
|
| 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-CF-4 |
Adversary monitors for safe-mode indicators such that they know when satellite is in weakened state and then they launch attack |
|
| 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-AV-1 |
Communications system jamming resulting in denial of service and loss of availability and data integrity |
|
| 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-CF-3 |
Knowledge of target satellite's cyber-related design details would be crucial to inform potential attacker - so threat is leaking of design data which is often stored Unclass or on contractors’ network |
|
| 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-10 |
Compromise development environment source code (applicable to development environments not covered by threat SV-SP-1, SV-SP-3, and SV-SP-4). |
|
| SV-SP-2 |
Testing only focuses on functional requirements and rarely considers end to end or abuse cases |
|
| SV-SP-4 |
General supply chain interruption or manipulation |
|
| SV-SP-5 |
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused} |
|
| Requirement |
|---|
| The spacecraft shall protect the confidentiality and integrity of the [all information] using cryptography while it is at rest. {SV-IT-2,SV-CF-2} {SC-28,SC-28(1),SI-7(6)} |
| The Program shall define processes and procedures to be followed when the integrity verification tools detect unauthorized changes to [Program-defined software, firmware, and information]. {SV-IT-2} {SI-7} |
| The Program shall enable integrity verification of software and firmware components. {SV-IT-2} {SA-10(1),SI-7} |
| The spacecraft shall perform an integrity check of [Program-defined software, firmware, and information] at startup; at [Program-defined transitional states or security-relevant events] {SV-IT-2} {SI-7(1)} |
| The Program shall define and document the transitional state or security-relevant events when the spacecraft will perform integrity checks on software, firmware, and information. {SV-IT-2} {SI-7(1)} |
| The spacecraft shall provide automatic notification to [Program-defined personnel (e.g., ground operators)] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)} |
| The Program shall employ automated tools that provide notification to [Program-defined personnel] upon discovering discrepancies during integrity verification. {SV-IT-2} {SI-7(2)} |
| The Program shall define the security safeguards that are to be employed when integrity violations are discovered. {SV-IT-2} {SI-7(5)} |
| The spacecraft shall automatically [Selection (one or more):restarts the FSW/processor, performs side swap, audits failure; implements Program-defined security safeguards] when integrity violations are discovered. {SV-IT-2} {SI-7(8)} |
| The Program shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} |
| The Program shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes]. {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9} {SA-3,SA-4(3)} |
| 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 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 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 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 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 identify, report, and coordinate correction of cybersecurity-related information system flaws. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2} |
| The Program shall correct reported cybersecurity-related information system flaws. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2} |
| The Program shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {SI-2,CM-3(2),CM-4(1)} |
| The Program shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]]. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11} {CM-3(2),CM-4(1)} |
| The spacecraft shall be capable of removing flight software after updated versions have been installed. {SV-SP-1,SV-SP-9} {SI-2(6)} |
| The Program shall report identified systems or system components containing software affected by recently announced cybersecurity-related software flaws (and potential vulnerabilities resulting from those flaws) to [Program-defined officials] with cybersecurity responsibilities in accordance with organizational policy. {SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11} {SI-2} |
| 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 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 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)} |
| See threat ID number SV-SP-3 for information on software development requirements. In general terms threat ID SV-SP-4 applies from a generic sense since software reuse or COTS usage is a supply chain concern. The Program shall ensure that software planned for reuse meets the fit, form, and function, and security as a component within the new application. {SV-SP-6,SV-SP-7,SV-SP-11} {CM-7(5)} |
| 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 perform attestation at each stage of startup and ensure overall trusted boot regime (i.e., root of trust). {SV-IT-3} {SI-7(9)} |
| The trusted boot/RoT shall be a separate compute engine controlling the trusted computing platform cryptographic processor. {SV-IT-3} {SI-7(9)} |
| The trusted boot/RoT computing module shall be implemented on radiation tolerant burn-in (non-programmable) equipment. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot 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. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot firmware must enter a recovery routine upon failing to verify signed data in the trust chain, and not execute or trust that signed data. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall allocate enough boot ROM memory for secure boot firmware execution. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall allocate enough SRAM memory for secure boot firmware execution. {SV-IT-3} {SI-7(9)} |
| The spacecraft secure boot mechanism shall be Commercial National Security Algorithm Suite (CNSA) compliant. {SV-IT-3} {SI-7(9)} |
| The spacecraft shall support the algorithmic construct Elliptic Curve Digital Signature Algorithm (ECDSA) NIST P-384 + SHA-38{SV-IT-3} {SI-7(9)} |
| The spacecraft hardware root of trust must be an ECDSA NIST P-384 public key. {SV-IT-3} {SI-7(9)} |
| The spacecraft hardware root of trust must be loadable only once, post-purchase. {SV-IT-3} {SI-7(9)} |
| The spacecraft boot firmware must validate the boot loader, boot configuration file, and operating system image, in that order, against their respective signatures. {SV-IT-3} {SI-7(9)} |
| The Program shall define/maintain an approved operating system list for use on spacecraft. {SV-SP-7} {CM-7(5)} |
| The spacecraft's operating system, if COTS or FOSS, shall be selected from a [Program-defined] accepted list. {SV-SP-7} {CM-7(8),CM-7(5)} |
| The spacecraft, upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators]. {SV-DCO-1} {SI-7(8)} |
| The spacecraft shall implement cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission unless otherwise protected by alternative physical safeguards. {SV-AC-7} {SC-8(1),SI-7(6)} |
| The Program shall implement a security architecture and design that provides the required security functionality, allocates security controls among physical and logical components, and integrates individual security functions, mechanisms, and processes together to provide required security capabilities and a unified approach to protection. {SV-MA-6} {SA-2,SA-8} |