CM0001 Protect Sensitive Information Space mission sensitive information spans a broad attack surface and must be inventoried, classified, and protected at a level commensurate with its sensitivity across every location where it resides, including ground systems, contractor networks, and remote access environments. Sensitive material typically includes functional and performance specifications, interface control documents (ICDs), command and telemetry (C&T) databases, uplink protection schemes including disable and bypass features, fault management logic, scripts, simulation and rehearsal results, failure and anomaly resolution records, and architecture and software documentation. Each information type must be assigned a protection level, such as unclassified, controlled, proprietary, or classified, and access must be restricted to personnel with defined roles and a verified need to know. Sensitive data shall be protected at rest and in transit using encryption or other mission-approved safeguards commensurate with its classification, sensitivity, threat exposure, and operational constraints. DLP capabilities shall be applied to systems and data flows where they are technically feasible and effective, with alternative access controls, monitoring, or information-flow protections used where conventional DLP technology is not suitable. Ongoing configuration management must track, control, and document all changes to command procedures and critical database content to prevent unauthorized modification and mission degradation.
CM0009 Threat Intelligence Program A threat intelligence program enables an organization to systematically collect, analyze, and apply information about adversary capabilities, infrastructure, and intent to inform defensive priorities and drive risk-informed security decisions across the mission lifecycle. For space missions specifically, this may include leveraging available all-source intelligence services or commercial satellite imagery to identify and monitor adversary infrastructure development and acquisition activities that may signal emerging threats to mission assets. Threat intelligence outputs should be operationalized into concrete adjustments to defensive architecture, monitoring priorities, and incident response posture rather than treated as informational products alone. Direct countermeasures against adversary infrastructure identified through this program will fall outside the scope of the mission in the majority of cases; the primary value of the program is in generating actionable awareness that sharpens the organization's own defensive posture.
CM0020 Threat modeling Threat modeling is a structured analytical process that identifies, enumerates, and prioritizes potential threats to a system by systematically examining assets, trust boundaries, data flows, and adversary capabilities relative to the system's architecture. Applied in combination with attack surface analysis and vulnerability analysis, threat modeling produces an integrated picture of where the system is most exposed and what the consequences of successful exploitation would be. Analysis should draw on findings from similar systems, components, or services where applicable, leveraging documented threat experience from comparable missions or architectures to avoid re-learning known lessons. The outputs of threat modeling must directly inform design decisions throughout the development process, with attack surface reduction treated as a design objective rather than a post-development hardening activity: interfaces, services, protocols, and code paths that are not necessary to mission function should be eliminated or constrained before they become embedded in the architecture. Threat model artifacts should be treated as living documents, updated as the system design evolves and as new threat intelligence becomes available.
CM0011 Vulnerability Scanning Vulnerability scanning systematically identifies known security weaknesses in commercial off-the-shelf (COTS) and open-source software (OSS) components, including vulnerable dependencies and outdated software versions, across spacecraft and ground system environments. Custom-developed code requires separate analysis approaches, such as static and dynamic code analysis, that fall outside the scope of this countermeasure; however, COTS, OSS, and third-party dependencies incorporated into custom-developed software remain within the scope of vulnerability scanning and SCA. Scanning programs should incorporate software composition analysis (SCA) to detect vulnerabilities introduced through third-party libraries and dependency chains, which represent a significant and frequently underestimated attack surface in modern space systems. Scanning tools and processes should conform to recognized interoperability standards that support enumeration of platforms, software flaws, and configuration weaknesses; standardized formatting of checklists and test procedures; and consistent measurement of vulnerability impact. Adherence to these standards enables automation of key vulnerability management workflow steps, facilitates tool interoperability across the mission ecosystem, and produces outputs that are comparable across programs and organizations.
Vulnerability scanning shall be performed against the approved as-built or deployed software baseline using methods that do not jeopardize mission operations. Active scanning of live spacecraft, safety-critical ground systems, or operational technology should occur only after the scanning method has been authorized and evaluated for operational impact. Where live scanning presents unacceptable risk, scanning should be performed against representative software images, firmware packages, or test environments that match the approved operational baseline.
CM0072 Protocol Update / Refactoring Communication and data exchange protocols governing spacecraft, ground system, and inter-system interfaces may contain specification-level vulnerabilities that cannot be resolved through implementation hardening alone, requiring updates to or refactoring of the protocol itself to eliminate the underlying weakness. Protocol vulnerabilities may arise from design flaws in the original specification, from advances in adversarial capability that render previously adequate security assumptions insufficient, or from emerging threats such as quantum computing that threaten the cryptographic primitives upon which protocol security depends. Protocol update or refactoring encompasses the deliberate modification of the rules, formats, and procedures governing system communications to address known vulnerabilities, improve security properties, or maintain adequate protection against the evolving threat environment over the mission's operational lifetime. Because space system protocols are often tightly coupled to hardware interfaces, flight software implementations, and ground system processing pipelines, protocol changes carry significant integration risk and must be managed through rigorous engineering change processes; this complexity makes proactive protocol security assessment and planned update capability more cost-effective than reactive refactoring under operational urgency.