SA-8(8) - Security and Privacy Engineering Principles | Secure Evolvability

Implement the security design principle of secure evolvability in [Assignment: organization-defined systems or system components].


Informational References

ISO 27001

ID: SA-8(8)
Enhancement of : SA-8

Countermeasures Covered by Control

ID Name Description D3FEND

Space Threats Tagged by Control

ID Description

Sample Requirements

Requirement Rationale/Additional Guidance/Notes
The [organization] shall ensure any update to on-board software, memory, or stored procedures has met high assurance standards before execution. {AC-3(2),CM-3,SA-8(8),SA-8(31),SA-10(2),SR-4(4)}
The [spacecraft] shall require multi-factor authorization for all spacecraft [applications or operating systems] updates within the spacecraft.{SV-SP-9,SV-SP-11}{AC-3(2),CM-3(8),CM-5,PM-12,SA-8(8),SA-8(31),SA-10(2),SI-3(8),SI-7(12),SI-10(6)} The intent is for multiple checks to be performed prior to executing these SV SW updates. One action is mere act of uploading the SW to the spacecraft. Another action could be check of digital signature (ideal but not explicitly required) or hash or CRC or a checksum. Crypto boxes provide another level of authentication for all commands, including SW updates but ideally there is another factor outside of crypto to protect against FSW updates. Multi-factor authorization could be the "two-man rule" where procedures are in place to prevent a successful attack by a single actor (note: development activities that are subsequently subject to review or verification activities may already require collaborating attackers such that a "two-man rule" is not appropriate).
The [spacecraft] shall use automated mechanisms to maintain and validate baseline configuration to ensure the [spacecraft] is up-to-date, complete, accurate, and readily available.{SV-SP-3}{CM-2(2),CM-3(5),CM-3(7),CM-6,SA-8(8)} This could be command trigger from Ground or elsewhere. The point here is that the self-test is executed onboard the spacecraft via onboard HW/SW self-test mechanisms and its result is reported to the Ground
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 ground.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)}
The [spacecraft] shall execute procedures for ensuring that security-relevant hardware, software, and firmware updates uploaded are exactly as specified by the gold copies. {CM-3(5),SA-8(8),SA-8(21),SA-8(31),SA-10(3),SA-10(4),SA-10(6),SI-7(10),SI-7(12)}
The [spacecraft] shall retain the capability to update/upgrade operating systems while on-orbit.{SV-SP-7}{SA-4(5),SA-8(8),SA-8(31),SA-10(2),SI-3} The operating system updates should be performed using multi-factor authorization and should only be performed when risk of compromise/exploitation of identified vulnerability outweighs the risk of not performing the update.
The [spacecraft] shall be capable of removing flight software after updated versions have been installed.{SV-SP-1,SV-SP-9}{SA-8(8),SI-2(6)}

Related SPARTA Techniques and Sub-Techniques

ID Name Description