CA-2(2) - Control Assessments | Specialized Assessments
Include as part of control assessments, [Assignment: organization-defined frequency], [Selection: announced; unannounced], [Selection (one or more): in-depth monitoring; security instrumentation; automated security test cases; vulnerability scanning; malicious user testing; insider threat assessment; performance and load testing; data leakage or data loss assessment [Assignment: organization-defined other forms of assessment]
].
Independent assessment can surface issues mission teams may normalize. Consider assessors with both space systems and cybersecurity depth who can evaluate specialized areas, TT&C, propulsion safety interlocks, payload isolation, key management, without losing operational realism. Independence is most effective when assessors have access to representative environments (twin/flatsat), clear rules of engagement, and traceability from findings to corrective actions feasible within pass and power/thermal constraints.
Assessment and authorization (A&A) is a structured, formal process through which an organization evaluates the extent to which a system's design and implementation satisfy a defined set of security requirements, and grants or denies authorization for that system to operate based on the assessed risk. For space mission systems, A&A may apply to spacecraft, ground systems, mission networks, supporting infrastructure, common controls, and the interfaces and dependencies among them. The authorization scope and boundary must be defined by the governing risk management framework, mission architecture, information types, applicable requirements, and organizational risk decisions. The assessment phase produces evidence concerning whether selected controls are implemented correctly, operating as intended, and producing the required security outcomes. The resulting authorization package should contain the system security plan, assessment reports, plan of action and milestones, executive risk summary, and other evidence required by the authorizing authority. The authorization decision, made by a designated authority with accountability for accepting the residual risk of operating the system, formally records the organization's acceptance of that risk and establishes the conditions under which the system may operate. Authorization must be supported throughout the system lifecycle by continuous monitoring, security impact analysis, updated risk information, and maintenance of the authorization evidence. Proposed system changes must be assessed before implementation when they could affect the authorization boundary, control implementation, or accepted risk. Significant changes or material deviations from the authorization basis must be reported to the authorizing authority, who determines whether additional assessment, modified authorization conditions, or reauthorization is required.
Software reuse, COTS dependence, and standardization of onboard systems using building block approach with addition of open-source technology leads to supply chain threat
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
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.
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.
Hardware failure (i.e., tainted hardware) {ASIC and FPGA focused}
Sample Requirements
SPARTA ID
Requirement
Rationale/Additional Guidance/Notes
SPR-379
The [organization] shall conduct specialized assessments that are specifically tailored for space systems or space missions more generally, as opposed to traditional terrestrial IT systems.{SV-MA-6}{CA-2(2)}
Space missions require threat models distinct from terrestrial IT. Tailored assessments address unique operational constraints. Specialized evaluation improves relevance. Mission-specific review strengthens assurance.