1. Home
  2. NASA's Space Security: BPG
  3. MI-ARCH-02

MI-ARCH-02 - Mission Least Privilege Function

Principle

The mission should employ the principles of domain separation and least privilege for the on-board architecture, communications, and control.

Rationale

Least privilege designs will protect the main processor and core control functions of the vehicle from compromised assemblies by limiting the actions that can be executed on shared buses and onboard networks from recognized attack vectors. Segmentation and boundary control on the vehicle will mitigate supply chain attacks in procured or provided assemblies and in onboard software of varying provenance, as well as operational vulnerabilities when multiple command paths are available (e.g., an instrument with its own command link). Fault management systems should be employed to power off or block non-safety-critical assemblies that exhibit behavior that suggests compromise or failure.

Related Countermeasures

ID Name Description NIST Rev 5
CM0022 Criticality Analysis Criticality analysis is a structured engineering process that identifies the mission functions, system components, and data flows whose compromise, degradation, or loss would most severely impact mission success, crew safety, or operational continuity. The outputs of this analysis directly drive security investment prioritization: components and functions assessed as most critical receive the most rigorous design-phase protections, supply chain scrutiny, and operational security controls, while lower-criticality elements are protected proportionately. Criticality analysis findings should inform the application of complementary security design principles, including network and functional segmentation and least-privilege access control, to isolate critical components from less-trusted system elements and reduce the consequence of compromise elsewhere in the system. Supply chain protection resources and oversight rigor should be explicitly allocated in proportion to component criticality, ensuring that the most mission-essential hardware and software receive the most intensive sourcing controls, provenance verification, and supplier oversight. Criticality analysis must be initiated early in the system design process and updated as the architecture evolves, threat intelligence changes, or operational experience reveals previously unrecognized dependencies. CM-4 CP-2 CP-2(8) PL-7 PL-8 PL-8(1) PM-11 PM-17 PM-30 PM-30(1) PM-32 RA-3 RA-3(1) RA-9 SA-11 SA-11(3) SA-15(3) SA-2 SA-3 SA-4(5) SA-4(9) SA-8 SA-8(25) SA-8(3) SA-8(30) SC-32(1) SC-7(29) SR-1 SR-2 SR-2(1) SR-3 SR-3(2) SR-3(3) SR-5(1) SR-7
CM0031 Authentication All command-bearing sessions, frames, or messages involving spacecraft command links, crosslinks, or relay services shall provide cryptographic authentication of the command origin and integrity verification before commands are accepted. Mutual or bidirectional authentication shall be required where both endpoints must authenticate one another and the link and protocol architecture support that exchange. Acquisition requirements should mandate cryptographically based, bidirectional authentication for all command sessions across external links, including ground-to-spacecraft uplinks, spacecraft-to-spacecraft crosslinks, and any relay or intermediary ground station connections, with authentication required aBidirectional authentication enables both communicating entities to verify each other’s identity and helps prevent impersonation. Authentication establishes identity but does not by itself authorize a command, protect mission-data confidentiality, or prevent session hijacking. Command acceptance must also enforce authorization, and authenticated sessions or security associations must maintain integrity and replay resistance so that subsequent traffic remains bound to the authenticated entities. Beyond external links, authentication is strongly recommended for spacecraft internal bus communications and onboard inter-component connections, as an adversary with access to internal interfaces, whether through a compromised component or a physical access event, should face the same authentication barrier as an external adversary attempting to inject commands from outside the spacecraft. AC-14 AC-17 AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6)
CM0040 Shared Resource Leakage Shared system resources (e.g., processor registers, main memory, secondary storage, cache) may retain residual data or security-relevant state after a process releases them for reuse. If a subsequent process can access that residual information, it may obtain data from the prior process, including sensitive information or encrypted representations of information that were not intended to cross process or partition boundaries. This countermeasure requires that shared resources be sanitized, zeroed, or otherwise cleared of prior process data before being allocated to a new process, ensuring that information transfer between processes occurs only through explicitly authorized channels. The protection must apply to encrypted representations as well as plaintext because encrypted data remains information belonging to the prior process and must not be transferred to another process solely because its contents are not immediately readable. This is particularly significant in space system environments where multiple processes of varying criticality and trust levels may share the same hardware resources. AC-4(23) AC-4(25) SA-8(19) SA-8(2) SA-8(5) SA-8(6) SC-2(2) SC-3(4) SC-32(1) SC-4 SC-49 SC-50 SC-7(29)
CM0050 On-board Message Encryption Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections. AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(19) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(1) SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25)
CM0039 Least Privilege The principle of least privilege requires that every process, user account, service, and system component be granted only the permissions and access rights necessary to perform its defined function, with no additional privileges retained beyond what the assigned task requires. Applied to spacecraft and ground systems, this means that processes executing on flight computers, operating system services, ground system applications, and inter-system communication handlers are each confined to the minimum privilege level needed for their specific function, preventing a compromised or malfunctioning component from leveraging excess permissions to affect other system resources or functions. Separate execution domains should be used where supported to reinforce least privilege and contain process failures or compromise. Process isolation does not replace explicit access controls, because authorized communication and shared resources may still cross execution-domain boundaries. Least privilege is a foundational design principle that reduces the consequence of any individual component compromise by limiting what an adversary can accomplish within that component's execution context. AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(5) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(19) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29)
CM0032 On-board Intrusion Detection & Prevention An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support. AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8)
CM0067 Smart Contracts Smart contracts provide an automated, consensus-based enforcement mechanism for security protocols governing data exchange across a spacecraft bus, particularly in hosted payload architectures where multiple independently operated payloads or subsystems share common infrastructure. By encoding security rules as deterministic contract logic, participating validator nodes can evaluate authenticated observations of bus activity and reach consensus on whether a defined violation occurred. A trusted bus controller, gateway, or access-control mechanism must then enforce any approved restriction because the smart contract itself cannot directly observe or block physical bus traffic. This approach is directly applicable to scenarios where a hosted payload is compromised or behaves maliciously, as the smart contract framework can detect the violation, achieve consensus among the remaining bus participants, and enforce exclusion of the offending payload before the attack propagates to other bus components or the host spacecraft. The consensus mechanism should prevent a single participating node from causing payload exclusion when the approved quorum and membership rules require agreement from multiple independent validators. Its effectiveness depends on the validator architecture, quorum threshold, communication assumptions, and number of compromised or unavailable validators. Smart contract-based enforcement is particularly valuable in multi-tenant spacecraft architectures where payload operators are organizationally distinct from the spacecraft bus operator and cannot be governed through a single chain of administrative control. IA-9 SI-4 SI-4(2)
CM0037 Disable Physical Ports Physical data connection, debug, programming, and maintenance interfaces (e.g., joint test action group (JTAG)) that are not required for spacecraft operations must be disabled, removed, or otherwise made inaccessible before spacecraft operations begin. Interfaces required for operational functions must be explicitly identified and protected against unauthorized physical access and use. These interfaces, essential during development for programming, debugging, and testing, represent persistent attack surfaces in the operational environment: an adversary with physical access to the spacecraft before launch, during ground handling, or at a shared launch facility could exploit active debug interfaces to read memory, modify firmware, bypass security controls, or implant persistent malicious code without leaving detectable traces in software-visible logs. Disabling or removing unused physical interfaces closes a direct hardware-access pathway and reduces reliance on procedural controls or physical security alone. The capability to disable these interfaces must be designed into the system from the outset, as physical removal or reliable hardware-enforced disablement cannot be easily retrofitted into a completed board design. AC-14 MA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-4(9) SA-8 SC-41 SC-7(14)
CM0038 Segmentation Segmentation establishes physical or logical isolation boundaries between spacecraft system components and functional domains to limit the propagation of compromise, contain the consequences of a security failure, and enforce controlled information flow across the mission architecture. Mission-critical functions must be isolated from non-mission-critical functions through enforced partition boundaries that control access to and protect the integrity of the hardware, software, and firmware implementing those functions. Information flow between partitioned components or applications must be explicitly authorized by security policy; any flow not affirmatively permitted is denied by default. Boundary protections must be implemented to separate spacecraft bus, communications, and payload components, preventing a compromise in one domain from directly affecting the others. Information crossing the spacecraft boundary shall receive confidentiality protection where required by its classification, sensitivity, or mission risk. Command-bearing and other security-critical exchanges shall receive the mission-required authentication, integrity, authorization, and anti-replay protections regardless of whether confidentiality is required. These controls collectively implement a defense-in-depth architecture in which an adversary who gains a foothold in one partition faces enforced barriers before reaching mission-critical assets. AC-4 AC-4(14) AC-4(2) AC-4(24) AC-4(26) AC-4(31) AC-4(32) AC-4(6) AC-6 CA-3 CA-3(7) PL-8 PL-8(1) SA-3 SA-8 SA-8(13) SA-8(15) SA-8(18) SA-8(3) SA-8(4) SA-8(9) SC-16(3) SC-2(2) SC-3 SC-3(4) SC-32 SC-32(1) SC-39 SC-4 SC-49 SC-50 SC-6 SC-7(20) SC-7(21) SC-7(29) SC-7(5) SI-17 SI-4(7)
CM0065 OSAM Dual Authorization Before a cooperative OSAM engagement enters a protected proximity, capture, docking, mating, or servicing phase, the servicing spacecraft must be authenticated and the specific engagement authorized by both the serviced asset’s mission control authority and, where technically capable, the serviced asset itself. Authentication establishes the identity of the servicer, while dual authorization requires two independent approval decisions for the proposed activity. The approvals may be sequential rather than simultaneous but must both remain valid and be bound to the same servicer, client, service scope, mission phase, interfaces, operational constraints, and validity period. Failure to obtain or maintain authorization must cause the serviced asset to withhold cooperation and interface enablement and must invoke the approved hold, retreat, or abort response. These controls reduce the risk of unauthorized servicing but cannot physically prevent a hostile or non-cooperative spacecraft from approaching the asset. CA-3(6) IA-2(1) IA-2(2) IA-2(6)