9.3.3 - Management review results

NIST SP 800-53 Revision 5 Mapping

ID		Name
CA-5		Plan of Action and Milestones
CA-6		Authorization
CA-7		Continuous Monitoring
CM-3		Configuration Change Control

SPARTA Countermeasures Mapping

ID	Name	Description	D3FEND
CM0052	Insider Threat Protection	Establish policy and procedures to prevent individuals (i.e., insiders) from masquerading as individuals with valid access to areas where commanding of the spacecraft is possible. Establish an Insider Threat Program to aid in the prevention of people with authorized access performing malicious activities.
CM0005	Ground-based Countermeasures	This countermeasure is focused on the protection of terrestrial assets like ground networks and development environments/contractor networks, etc. Traditional detection technologies and capabilities would be applicable here. Utilizing resources from NIST CSF to properly secure these environments using identify, protect, detect, recover, and respond is likely warranted. Additionally, NISTIR 8401 may provide resources as well since it was developed to focus on ground-based security for space systems (https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8401.ipd.pdf). Furthermore, the MITRE ATT&CK framework provides IT focused TTPs and their mitigations https://attack.mitre.org/mitigations/enterprise/. Several recommended NIST 800-53 Rev5 controls are provided for reference when designing ground systems/networks.

Related SPARTA Techniques and Sub-Techniques

ID		Name	Description
REC-0001		Gather Spacecraft Design Information	Threat actors may gather information about the victim SV's design that can be used for future campaigns or to help perpetuate other techniques. Information about the SV can include software, firmware, encryption type, purpose, as well as various makes and models of subsystems.
	REC-0001.01	Software	Threat actors may gather information about the victim SV's internal software that can be used for future campaigns or to help perpetuate other techniques. Information (e.g. source code, binaries, etc.) about commercial, open-source, or custom developed software may include a variety of details such as types, versions, and memory maps. Leveraging this information threat actors may target vendors of operating systems, flight software, or open-source communities to embed backdoors or for performing reverse engineering research to support offensive cyber operations.
	REC-0001.02	Firmware	Threat actors may gather information about the victim SV's firmware that can be used for future campaigns or to help perpetuate other techniques. Information about the firmware may include a variety of details such as type and versions on specific devices, which may be used to infer more information (ex. configuration, purpose, age/patch level, etc.). Leveraging this information threat actors may target firmware vendors to embed backdoors or for performing reverse engineering research to support offensive cyber operations.
	REC-0001.03	Cryptographic Algorithms	Threat actors may gather information about any cryptographic algorithms used on the victim SV's that can be used for future campaigns or to help perpetuate other techniques. Information about the algorithms can include type and private keys. Threat actors may also obtain the authentication scheme (i.e., key/password/counter values) and leverage it to establish communications for commanding the target SV or any of its subsystems. Some SVs only require authentication vice authentication and encryption, therefore once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. The authentication information may be obtained through reconnaissance of the ground system or retrieved from the victim SV.
	REC-0001.04	Data Bus	Threat actors may gather information about the data bus used within the victim SV that can be used for future campaigns or to help perpetuate other techniques. Information about the data bus can include the make and model which could lead to more information (ex. protocol, purpose, controller, etc.), as well as locations/addresses of major subsystems residing on the bus. Threat actors may also gather information about the bus voltages of the victim SV. This information can include optimal power levels, connectors, range, and transfer rate.
	REC-0001.05	Thermal Control System	Threat actors may gather information about the thermal control system used with the victim SV that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include type, make/model, and varies analysis programs that monitor it.
	REC-0001.06	Maneuver & Control	Threat actors may gather information about the station-keeping control systems within the victim SV that can be used for future campaigns or to help perpetuate other techniques. Information gathered can include thruster types, propulsion types, attitude sensors, and data flows associated with the relevant subsystems.
	REC-0001.07	Payload	Threat actors may gather information about the type(s) of payloads hosted on the victim SV. This information could include specific commands, make and model, and relevant software. Threat actors may also gather information about the location of the payload on the bus and internal routing as it pertains to commands within the payload itself.
	REC-0001.08	Power	Threat actors may gather information about the power system used within the victim SV. This information can include type, power intake, and internal algorithms. Threat actors may also gather information about the solar panel configurations such as positioning, automated tasks, and layout. Additionally, threat actors may gather information about the batteries used within the victim SV. This information can include the type, quantity, storage capacity, make and model, and location.
	REC-0001.09	Fault Management	Threat actors may gather information about any fault management that may be present on the victim SV. This information can help threat actors construct specific attacks that may put the SV into a fault condition and potentially a more vulnerable state depending on the fault response.
REC-0002		Gather Spacecraft Descriptors	Threat actors may gather information about the victim SV's descriptors that can be used for future campaigns or to help perpetuate other techniques. Information about the descriptors may include a variety of details such as identity attributes, organizational structures, and mission operational parameters.
	REC-0002.01	Identifiers	Threat actors may gather information about the victim SV's identity attributes that can be used for future campaigns or to help perpetuate other techniques. Information may include a variety of details such as the satellite catalog number, international designator, mission name, and more.
	REC-0002.02	Organization	Threat actors may gather information about the victim SV's associated organization(s) that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target the mission owner/operator in order to conduct further attacks against the organization, individual, or other interested parties. Threat actors may also seek information regarding the SV's designer/builder, including physical locations, key employees, and roles and responsibilities as they pertain to the SV, as well as information pertaining to the mission's end users/customers.
	REC-0002.03	Operations	Threat actors may gather information about the victim SV's operations that can be used for future campaigns or to help perpetuate other techniques. Collection efforts may target mission objectives, orbital parameters such as orbit slot and inclination, user guides and schedules, etc. Additionally, threat actors may seek information about constellation deployments and configurations where applicable.
REC-0003		Gather Spacecraft Communications Information	Threat actors may obtain information on the victim SV's communication channels in order to determine specific commands, protocols, and types. Information gathered can include commanding patterns, antenna shape and location, beacon frequency and polarization, and various transponder information.
	REC-0003.01	Communications Equipment	Threat actors may gather information regarding the communications equipment and its configuration that will be used for communicating with the victim SV. This includes: Antenna Shape: This information can help determine the range in which it can communicate, the power of it's transmission, and the receiving patterns. Antenna Configuration/Location: This information can include positioning, transmission frequency, wavelength, and timing. Telemetry Signal Type: Information can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's telemetry system. Beacon Frequency: This information can provide insight into where the SV is located, what it's orbit is, and how long it can take to communicate with a ground station. Beacon Polarization: This information can help triangulate the SV as it orbits the earth and determine how a satellite must be oriented in order to communicate with the victim SV. Transponder: This could include the number of transponders per band, transponder translation factor, transponder mappings, power utilization, and/or saturation point.
	REC-0003.02	Commanding Details	Threat actors may gather information regarding the commanding approach that will be used for communicating with the victim SV. This includes: Commanding Signal Type: This can include timing, radio frequency wavelengths, and other information that can provide insight into the spacecraft's commanding system. Valid Commanding Patterns: Most commonly, this comes in the form of a command database, but can also include other means that provide information on valid commands and the communication protocols used by the victim SV. Valid Commanding Periods: This information can provide insight into when a command will be accepted by the SV and help the threat actor construct a viable attack campaign.
REC-0004		Gather Launch Information	Threat actors may gather the launch date and time, location of the launch (country & specific site), organizations involved, launch vehicle, etc. This information can provide insight into protocols, regulations, and provide further targets for the threat actor, including specific vulnerabilities with the launch vehicle itself.
	REC-0004.01	Flight Termination	Threat actor may obtain information regarding the vehicle's flight termination system. Threat actors may use this information to perform later attacks and target the vehicle's termination system to have desired impact on mission.
REC-0006		Gather FSW Development Information	Threat actors may obtain information regarding the flight software (FSW) development environment for the victim SV. This information may include the development environment, source code, compiled binaries, testing tools, and fault management.
	REC-0006.01	Development Environment	Threat actors may gather information regarding the development environment for the victim SV's FSW. This information can include IDEs, configurations, source code, environment variables, source code repositories, code "secrets", and compiled binaries.
	REC-0006.02	Security Testing Tools	Threat actors may gather information regarding how a victim SV is tested in regards to the FSW. Understanding the testing approach including tools could identify gaps and vulnerabilities that could be discovered and exploited by a threat actor.
REC-0007		Monitor for Safe-Mode Indicators	Threat actors may gather information regarding safe-mode indicators on the victim SV. Safe-mode is when all non-essential systems are shut down and only essential functions within the SV are active. During this mode, several commands are available to be processed that are not normally processed. Further, many protections may be disabled at this time.
REC-0008		Gather Supply Chain Information	Threat actors may gather information about a mission's supply chain or product delivery mechanisms that can be used for future campaigns or to help perpetuate other techniques.
	REC-0008.01	Hardware	Threat actors may gather information that can be used to facilitate a future attack where they manipulate hardware components in the victim SV prior to the customer receiving them in order to achieve data or system compromise. The threat actor can insert backdoors and give them a high level of control over the system when they modify the hardware or firmware in the supply chain. This would include ASIC and FPGA devices as well.
	REC-0008.02	Software	Threat actors may gather information relating to the mission's software supply chain in order to facilitate future attacks 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.
	REC-0008.03	Known Vulnerabilities	Threat actors may gather information about vulnerabilities that can be used for future campaigns or to perpetuate other techniques. A vulnerability is a weakness in the victim SV's hardware, subsystems, bus, or software that can, potentially, be exploited by a threat actor to cause unintended or unanticipated behavior to occur. During reconnaissance as threat actors identify the types/versions of software (i.e., COTS, open-source) being used, they will look for well-known vulnerabilities that could affect the space vehicle. Threat actors may find vulnerability information by searching leaked documents, vulnerability databases/scanners, compromising ground systems, and searching through online databases.
REC-0009		Gather Mission Information	Threat actors may initially seek to gain an understanding of a target mission by gathering information commonly captured in a Concept of Operations (or similar) document and related artifacts. Information of interest includes, but is not limited to: - the needs, goals, and objectives of the system - system overview and key elements/instruments - modes of operations (including operational constraints) - proposed capabilities and the underlying science/technology used to provide capabilities (i.e., scientific papers, research studies, etc.) - physical and support environments
RD-0002		Compromise Infrastructure	Threat actors may compromise third-party infrastructure that can be used for future campaigns or to perpetuate other techniques. Infrastructure solutions include physical devices such as antenna, amplifiers, and convertors, as well as software used by satellite communicators. Instead of buying or renting infrastructure, a threat actor may compromise infrastructure and use it during other phases of the campaign's lifecycle.
	RD-0002.01	Mission-Operated Ground System	Threat actors may compromise mission owned/operated ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems have already been configured for communications to the victim SV. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
	RD-0002.02	3rd Party Ground System	Threat actors may compromise access to third-party ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems can be or may have already been configured for communications to the victim SV. By compromising this infrastructure, threat actors can stage, launch, and execute an operation.
RD-0003		Obtain Capabilities	Threat actors may buy and/or steal capabilities that can be used for future campaigns or to perpetuate other techniques. Rather than developing their own capabilities in-house, threat actors may purchase, download, or steal them. Activities may include the acquisition of malware, software, exploits, and information relating to vulnerabilities. Threat actors may obtain capabilities to support their operations throughout numerous phases of the campaign lifecycle.
	RD-0003.02	Cryptographic Keys	Threat actors may obtain encryption keys as they are used for the main commanding of the target SV or any of its subsystems/payloads. Once obtained, threat actors may use any number of means to command the spacecraft without needing to go through a legitimate channel. These keys may be obtained through reconnaissance of the ground system or retrieved from the victim SV.
RD-0004		Stage Capabilities	Threat actors may upload, install, or otherwise set up capabilities that can be used for future campaigns or to perpetuate other techniques. To support their operations, a threat actor may need to develop their own capabilities or obtain them in some way in order to stage them on infrastructure under their control. These capabilities may be staged on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them.
	RD-0004.01	Identify/Select Delivery Mechanism	Threat actors may identify, select, and prepare a delivery mechanism in which to attack the space system (i.e., communicate with the victim SV, deny the ground, etc.) to achieve their desired impact. This mechanism may be located on infrastructure that was previously purchased or rented by the threat actor or was otherwise compromised by them. The mechanism must include all aspects needed to communicate with the victim SV, including ground antenna, converters, and amplifiers.
	RD-0004.02	Upload Exploit/Payload	Threat actors may upload exploits and payloads to a third-party infrastructure that they have purchased or rented or stage it on an otherwise compromised ground station. Exploits and payloads would include files and commands to be uploaded to the victim SV in order to conduct the threat actor's attack.
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.
IA-0004		Secondary/Backup Communication Channel	Threat actors may compromise alternative communication pathways which may not be as protected as the primary pathway. Depending on implementation the contingency communication pathways/solutions may lack the same level of security (i.e., physical security, encryption, authentication, etc.) which if forced to use could provide a threat actor an opportunity to launch attacks. Typically these would have to be coupled with other denial of service techniques on the primary pathway to force usage of secondary pathways.
	IA-0004.01	Ground Station	Threat actors may establish a foothold within the backup ground/mission operations center (MOC) and then perform attacks to force primary communication traffic through the backup communication channel so that other TTPs can be executed (man-in-the-middle, malicious commanding, malicious code, etc.). While an attacker would not be required to force the communications through the backup channel vice waiting until the backup is used for various reasons. The backup ground/MOC should be considered a viable attack vector and the appropriate/equivalent security controls from the primary communication channel should be on the backup ground/MOC as well.
IA-0006		Compromise Hosted Payload	Threat actors may compromise the target SV hosted payload to initially access and/or persist within the system. Hosted payloads can usually be accessed from the ground via a specific command set. The command pathways can leverage the same ground infrastructure or some host payloads have their own ground infrastructure which can provide an access vector as well. Threat actors may be able to leverage the ability to command hosted payloads to upload files or modify memory addresses in order to compromise the system. Depending on the implementation, hosted payloads may provide some sort of lateral movement potential.
IA-0007		Compromise Ground Station	Threat actors may initially compromise the ground station in order to access the target SV. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes.
	IA-0007.01	Compromise On-Orbit Update	Threat actors may manipulate and modify on-orbit updates before they are sent to the target SV. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, or replacing compiled versions with a malicious one.
	IA-0007.02	Malicious Commanding via Valid GS	Threat actors may compromise target owned ground systems components (e.g., front end processors, command and control software, etc.) that can be used for future campaigns or to perpetuate other techniques. These ground systems components have already been configured for communications to the victim SV. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
IA-0009		Trusted Relationship	Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status.
	IA-0009.01	Mission Collaborator (academia, international, etc.)	Threat actors may seek to exploit mission partners to gain an initial foothold for pivoting into the mission environment and eventually impacting the SV. The complex nature of many space systems rely on contributions across organizations, including academic partners and even international collaborators. These organizations will undoubtedly vary in their system security posture and attack surface.
	IA-0009.02	Vendor	Threat actors may target the trust between vendors and the target space vehicle. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target space vehicle. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the space vehicle context vendors may have direct commanding and updating capabilities outside of the primary communication channel.
	IA-0009.03	User Segment	Threat actors can target the user segment in an effort to laterally move into other areas of the end-to-end mission architecture. When user segments are interconnected, threat actors can exploit lack of segmentation as the user segment's security undoubtedly varies in their system security posture and attack surface than the primary space mission. The user equipment and users themselves provide ample attack surface as the human element and their vulnerabilities (i.e., social engineering, phishing, iOT) are often the weakest security link and entry point into many systems.
IA-0012		Assembly, Test, and Launch Operation Compromise	Threat actors may target the spacecraft hardware and/or software while the spacecraft is at Assembly, Test, and Launch Operation (ATLO). ATLO is often the first time pieces of the spacecraft are fully integrated and exchanging data across interfaces. Malware could propagate from infected devices across the integrated spacecraft. For example, test equipment (i.e., transient cyber asset) is often brought in for testing elements of the spacecraft. Additionally, varying levels of physical security is in place which may be a reduction in physical security typically seen during development. The ATLO environment should be considered a viable attack vector and the appropriate/equivalent security controls from the primary development environment should be implemented during ATLO as well.
EXF-0006		Modify 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-0007		Compromised Ground Station	Threat actors may compromise target owned ground systems that can be used for future campaigns or to perpetuate other techniques. These ground systems have already been configured for communications to the victim SV. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
EXF-0008		Compromised Developer Site	Threat actors may compromise development environments located within the ground system or a developer/partner site. This attack can take place in a number of different ways, including manipulation of source code, manipulating environment variables, or replacing compiled versions with a malicious one. This technique is usually performed before the target SV is in orbit, with the hopes of adding malicious code to the actual FSW during the development process.
EXF-0009		Compromised Partner Site	Threat actors may compromise access to partner sites that can be used for future campaigns or to perpetuate other techniques. These sites are typically configured for communications to the primary ground station(s) or in some cases the SV itself. Unlike mission operated ground systems, partner sites may provide an easier target for threat actors depending on the company, roles and responsibilities, and interests of the third-party. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration.
PER-0003		Ground System Presence	Threat actors may compromise target owned ground systems that can be used for persistent access to the SV or to perpetuate other techniques. These ground systems have already been configured for communications to the victim SV. By compromising this infrastructure, threat actors can stage, launch, and execute persistently.
DE-0002		Prevent Downlink	Threat actors may target the downlink connections to prevent the victim SV from sending telemetry to the ground controllers. Telemetry is the only method in which ground controllers can monitor the health and stability of the SV while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
	DE-0002.01	Inhibit Ground System Functionality	Threat actors may utilize ground-system presence to inhibit the ground system software's ability to process (or display) telemetry, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the SV while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place.
DE-0004		Masquerading	Threat actors may gain access to a victim SV by masquerading as an authorized entity. This can be done several ways, including through the manipulation of command headers, spoofing locations, or even leveraging Insider's access (i.e., Insider Threat)
LM-0001		Hosted Payload	Threat actors may use the hosted payload within the victim SV in order to gain access to other subsystems. The hosted payload often has a need to gather and send data to the internal subsystems, depending on its purpose. Threat actors may be able to take advantage of this communication in order to laterally move to the other subsystems and have commands be processed.

Space Threats Mapped

ID		Description
SV-IT-2		Unauthorized modification or corruption of data
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-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-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-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-IT-1		Communications system spoofing resulting in denial of service and loss of availability and data integrity
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-SP-4		General supply chain interruption or manipulation

Sample Requirements

Requirement	Rationale/Additional Guidance/Notes
The [organization] shall analyze changes to the spacecraft to determine potential security impacts prior to change implementation.{CM-4,CM-3,CM-3(2),CM-3(7),CM-4(2),SA-10}
The [organization] updates the inventory of spacecraft components as an integral part of component installations, removals, and spacecraft updates.{CM-8(1),CA-7,CM-2,CM-3}
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)}
In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation.{CA-2,CA-5,SA-11,SI-3,SI-3(10)}
The [organization] 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}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)}	The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
The [organization] shall maintain an up-to-date Plan of Action and Milestones (POA&M) that identifies, assesses, prioritizes, and documents specific actions to be taken to correct deficiencies in the spacecraft's security posture.{CA-5}
The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)}
The [organization] shall designate an authorizing official for the system.{CA-6}	These officials must be federal employees, and are responsible for reviewing the security authorization package, assessing the risks, and making the decision to authorize system operation. They shall ensure compliance with relevant organizational policies and standards and are accountable for the decision to accept the risks associated with operating the system. The authorizing officials must be empowered with the authority to oversee and enforce the implementation and maintenance of security controls in accordance with organizational requirements and applicable regulations.
The [organization] shall implement, as part of an A&A process, a Continuous Monitoring Program (CMP) that evaluates the effectiveness of security control implementations on a recurring pre-defined basis.{CA-7,PM-31}
The [organization] shall develop and document program-specific configuration management policies and procedures for the hardware and software for the spacecraft. {CM-1,CM-3,CM-5(6),SA-10,SA-10(3)}
The [organization] shall confirm that the operational spacecrafts correspond to the baseline configuration. {CM-2,CM-3,CM-3(7),CM-4(2),CM-6,SA-10}
The [organization] 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}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)}	This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear.
The [organization] shall define processes and procedures to be followed when integrity verification tools detect unauthorized changes to software, firmware, and information.{SV-IT-2}{CM-3,CM-3(1),CM-3(5),CM-5(6),CM-6,CP-2,IR-6,IR-6(2),PM-30,SC-16(1),SC-51,SI-3,SI-4(7),SI-4(24),SI-7,SI-7(7),SI-7(10)}
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)}