Not knowing that you were attacked, or attack was attempted
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The [spacecraft] shall monitor and collect all onboard cyber-relevant data (from multiple system components), including identification of potential attacks and sufficient information about the attack for subsequent analysis.{SV-DCO-1}{AC-6(9),AC-20,AC-20(1),AU-2,AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4,SI-4(1),SI-4(2),SI-4(7),SI-4(24)} | The spacecraft will monitor and collect data that provides accountability of activity occurring onboard the spacecraft. Due to resource limitations on the spacecraft, analysis must be performed to determine which data is critical for retention and which can be filtered. Full system coverage of data and actions is desired as an objective; it will likely be impractical due to the resource limitations. “Cyber-relevant data” refers to all data and actions deemed necessary to support accountability and awareness of onboard cyber activities for the mission. This would include data that may indicate abnormal activities, critical configuration parameters, transmissions on onboard networks, command logging, or other such data items. This set of data items should be identified early in the system requirements and design phase. Cyber-relevant data should support the ability to assess whether abnormal events are unintended anomalies or actual cyber threats. Actual cyber threats may rarely or never occur, but non-threat anomalies occur regularly. The ability to filter out cyber threats for non-cyber threats in relevant time would provide a needed capability. Examples could include successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels). |
| The [spacecraft] shall provide the capability to modify the set of audited events (e.g., cyber-relevant data).{SV-DCO-1}{AU-12(3),AU-14} | |
| The [spacecraft] shall generate cyber-relevant audit records containing information that establishes what type of event occurred, when the event occurred, where the event occurred, the source of the event, and the outcome of the event.{SV-DCO-1}{AU-3,AU-3(1),AU-12,IR-4,IR-4(1),RA-10,SI-3,SI-3(10),SI-4(7),SI-4(24)} | |
| The [spacecraft] shall be configured to allocate audit record storage capacity in accordance with 1 week audit record storage requirements.{SV-DCO-1}{AU-4,AU-5,AU-5(1),AU-5(2)} | |
| The [spacecraft] shall attribute cyberattacks and identify unauthorized use of the spacecraft by downlinking onboard cyber information to the mission ground station within [mission-appropriate timelines minutes].{SV-DCO-1}{AU-4(1),SI-4(5)} | Requirement is to support offboard attribution by enabling the fusion of spacecraft cyber data with ground-based cyber data. This would provide end-to-end accountability of commands, data, and other data that can be used to determine the origin of attack from the ground system. Data should be provided within time constraints relevant for the particular mission and its given operational mode. Analysis should be performed to identify the specific timeliness requirements for a mission, which may vary depending on mission mode, operational status, availability of communications resources, and other factors. The specific data required should be identified, as well. |
| The [spacecraft] shall alert in the event of the [organization]-defined audit/logging processing failures.{SV-DCO-1}{AU-5} | |
| The [spacecraft] shall provide an alert immediately to [at a minimum the mission director, administrators, and security officers] when the following failure events occur: [minimally but not limited to: auditing software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity reaching 95%, 99%, and 100%] of allocated capacity.{SV-DCO-1}{AU-5,AU-5(1),AU-5(2),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24),SI-7(7)} | Intent is to have human on the ground be alerted to failures. This can be decomposed to SV to generate telemetry and to Ground to alert. |
| The [spacecraft] shall provide the capability of a cyber “black-box” to capture necessary data for cyber forensics of threat signatures and anomaly resolution when cyber attacks are detected.{SV-DCO-1}{AU-5(5),AU-9(2),AU-9(3),AU-12,IR-4(12),IR-4(13),IR-5(1),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(24),SI-7(7)} | Similar concept of a "black box" on an aircraft where all critical information is stored for post forensic analysis. Black box can be used to record CPU utilization, GNC physical parameters, audit records, memory contents, TT&C data points, etc. The timeframe is dependent upon implementation but needs to meet the intent of the requirement. For example, 30 days may suffice. |
| The [spacecraft] shall provide automated onboard mechanisms that integrate audit review, analysis, and reporting processes to support mission processes for investigation and response to suspicious activities to determine the attack class in the event of a cyber attack.{SV-DCO-1}{AU-6(1),IR-4,IR-4(1),IR-4(12),IR-4(13),PM-16(1),RA-10,SA-8(21),SA-8(22),SC-5(3),SI-3,SI-3(10),SI-4(7),SI-4(24),SI-7(7)} | * Identifying the class (e.g., exfiltration, Trojans, etc.), nature, or effect of cyberattack (e.g., exfiltration, subverted control, or mission interruption) is necessary to determine the type of response. The first order of identification may be to determine whether the event is an attack or a non-threat event (anomaly). The objective requirement would be to predict the impact of the detected signature. * Unexpected conditions can include RF lockups, loss of lock, failure to acquire an expected contact and unexpected reports of acquisition, unusual AGC and ACS control excursions, unforeseen actuator enabling's or actions, thermal stresses, power aberrations, failure to authenticate, software or counter resets, etc. Mitigation might include additional TMONs, more detailed AGC and PLL thresholds to alert operators, auto-capturing state snapshot images in memory when unexpected conditions occur, signal spectra measurements, and expanded default diagnostic telemetry modes to help in identifying and resolving anomalous conditions. |
| The [organization] shall integrate terrestrial system audit log analysis as part of the standard anomaly resolution process to correlate any anomalous behavior in the terrestrial systems that correspond to anomalous behavior in the spacecraft.{SV-DCO-1}{AU-6(1),IR-5(1)} | |
| The [spacecraft] shall integrate cyber related detection and responses with existing fault management capabilities to ensure tight integration between traditional fault management and cyber intrusion detection and prevention.{SV-DCO-1}{AU-6(4),IR-4,IR-4(1),RA-10,SA-8(21),SA-8(26),SC-3(4),SI-3,SI-3(10),SI-4(7),SI-4(13),SI-4(16),SI-4(24),SI-4(25),SI-7(7),SI-13} | The onboard IPS system should be integrated into the existing onboard spacecraft fault management system (FMS) because the FMS has its own fault detection and response system built in. SV corrective behavior is usually limited to automated fault responses and ground commanded recovery actions. Intrusion prevention and response methods will inform resilient cybersecurity design. These methods enable detected threat activity to trigger defensive responses and resilient SV recovery. |
| The [spacecraft] shall record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).{SV-DCO-1}{AU-8} | |
| The [spacecraft] shall record time stamps for audit records that provide a granularity of one Z-count (1.5 sec).{SV-DCO-1}{AU-8} | |
| The [spacecraft] shall use internal system clocks to generate time stamps for audit records.{SV-DCO-1}{AU-8} | |
| The [spacecraft] shall protect information obtained from logging/intrusion-monitoring from unauthorized access, modification, and deletion.{SV-DCO-1}{AU-9,AU-9(3),RA-10,SI-4(7),SI-4(24)} | |
| The [spacecraft] shall implement cryptographic mechanisms to protect the integrity of audit information and audit tools.{SV-DCO-1}{AU-9(3),RA-10,SC-8(1),SI-3,SI-3(10),SI-4(24)} | |
| The [spacecraft], upon detection of a potential integrity violation, shall provide the capability to [audit the event and alert ground operators].{SV-DCO-1}{CM-3(5),SA-8(21),SI-3,SI-4(7),SI-4(12),SI-4(24),SI-7(8)} | One example would be for bad commands where the system would reject the command and not increment the Vehicle Command Counter (VCC) and include the information in telemetry. |
| The [spacecraft] shall be able to locate the onboard origin of a cyber attack and alert ground operators within 3 minutes.{SV-DCO-1}{IR-4,IR-4(1),IR-4(12),IR-4(13),RA-10,SA-8(22),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(16),SI-4(24)} | The origin of any attack onboard the vehicle should be identifiable to support mitigation. At the very least, attacks from critical element (safety-critical or higher-attack surface) components should be locatable quickly so that timely action can occur. |
| The [spacecraft] shall detect and deny unauthorized outgoing communications posing a threat to the spacecraft.{SV-DCO-1}{IR-4,IR-4(1),RA-5(4),RA-10,SC-7(9),SC-7(10),SI-4,SI-4(1),SI-4(4),SI-4(7),SI-4(11),SI-4(13),SI-4(24),SI-4(25)} | |
| The [spacecraft] shall select and execute safe countermeasures against cyber attacks prior to entering cyber-safe mode.{SV-DCO-1}{IR-4,RA-10,SA-8(21),SA-8(24),SI-4(7),SI-17} | These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker exquisitely—with or without ground aiding. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system." These countermeasures are likely executed prior to entering into a cyber-safe mode. |
| The [spacecraft] shall provide cyber threat status to the ground segment for the Defensive Cyber Operations team, per the governing specification.{SV-DCO-1}{IR-5,PM-16,PM-16(1),RA-3(3),RA-10,SI-4,SI-4(1),SI-4(24),SI-7(7)} | The future space enterprises will include full-time Cyber Defense teams supporting space mission systems. Their work is currently focused on the ground segment but may eventually require specific data from the space segment for their successful operation. This requirement is a placeholder to ensure that any DCO-related requirements are taken into consideration for this document. |
| The [spacecraft] shall be designed and configured so that encrypted communications traffic and data is visible to on-board security monitoring tools.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(10),SI-4(13),SI-4(24),SI-4(25)} | |
| The [spacecraft] shall be designed and configured so that spacecraft memory can be monitored by the on-board intrusion detection/prevention capability.{SV-DCO-1}{RA-10,SA-8(21),SI-3,SI-3(10),SI-4,SI-4(1),SI-4(24),SI-16} | |
| The [spacecraft] shall provide the capability to verify the correct operation of security-relevant software and hardware mechanisms (e.g.spacecraft IDS/IPS, logging, crypto, etc..) {SV-DCO-1}{SA-8(21),SI-3,SI-6} |
| ID | Name | Description | |
|---|---|---|---|
| DE-0003 | Modify On-Board Values | Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock. | |
| DE-0003.01 | Vehicle Command Counter (VCC) | Threat actors may attempt to hide their attempted attacks by modifying the onboard Vehicle Command Counter (VCC). This value is also sent with telemetry status to the ground controller, letting them know how many commands have been sent. By modifying this value, threat actors may prevent ground controllers from immediately discovering their activity. | |
| DE-0003.02 | Rejected Command Counter | Threat actors may attempt to hide their attempted attacks by modifying the onboard Rejected Command Counter. Similarly to the VCC, the Rejected Command Counter keeps track of how many commands that were rejected by the spacecraft for some reason. Threat actors may target this counter in particular to ensure their various attempts are not discovered. | |
| DE-0003.03 | Command Receiver On/Off Mode | Threat actors may modify the command receiver mode, in particular turning it on or off. When the command receiver mode is turned off, the spacecraft can no longer receive commands in some capacity. Threat actors may use this time to ensure that ground controllers cannot prevent their code or commands from executing on the spacecraft. | |
| DE-0003.04 | Command Receivers Received Signal Strength | Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the spacecraft. For ground controllers to communicate with spacecraft in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the spacecraft from receiving ground commands. | |
| DE-0003.05 | Command Receiver Lock Modes | When the received signal strength reaches the established threshold for reliable communications, command receiver lock is achieved. Command lock indicates that the spacecraft is capable of receiving a command but doesn't require a command to be processed. Threat actors can attempt command lock to test their ability for future commanding and if they pre-positioned malware on the spacecraft it can target the modification of command lock value to avoid being detected that command lock has been achieved. | |
| DE-0003.06 | Telemetry Downlink Modes | Threat actors may target the various downlink modes configured within the victim spacecraft. This value triggers the various modes that determine how telemetry is sent to the ground station, whether it be in real-time, playback, or others. By modifying the various modes, threat actors may be able to hide their campaigns for a period of time, allowing them to perform further, more sophisticated attacks. | |
| DE-0003.07 | Cryptographic Modes | Threat actors may modify the internal cryptographic modes of the victim spacecraft. Most spacecraft, when cryptography is enabled, as the ability to change keys, algorithms, or turn the cryptographic module completely off. Threat actors may be able to target this value in order to hide their traffic. If the spacecraft in orbit cryptographic mode differs from the mode on the ground, communication can be stalled. | |
| DE-0003.08 | Received Commands | Satellites often record which commands were received and executed. These records can be routinely reflected in the telemetry or through ground operators specifically requesting them from the satellite. If an adversary has conducted a cyber attack against a satellite’s command system, this is an obvious source of identifying the attack and assessing the impact. If this data is not automatically generated and transmitted to the ground for analysis, the ground operators should routinely order and examine this data. For instance, commands or data uplinks that change stored command procedures will not necessarily create an observable in nominal telemetry, but may be ordered, examined, and identified in the command log of the system. Threat actors may manipulate these stored logs to avoid detection. | |
| DE-0003.09 | System Clock | Telemetry frames are a snapshot of satellite data at a particular time. Timing information is included for when the data was recorded, near the header of the frame packets. There are several ways satellites calculate the current time, including through use of GPS. An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, including misrepresentation of when certain actions took place. | |
| DE-0003.10 | GPS Ephemeris | A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course. | |
| DE-0003.11 | Watchdog Timer (WDT) | Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources. | |
| DE-0009 | Camouflage, Concealment, and Decoys (CCD) | This technique deals with the more physical aspects of CCD that may be utilized by threat actors. There are numerous ways a threat actor may utilize the physical operating environment to their advantage, including powering down and laying dormant within debris fields as well as launching EMI attacks during space-weather events. | |
| DE-0009.01 | Debris Field | Threat actors may hide their spacecraft by laying dormant within clusters of space junk or similar debris fields. This could serve several purposes including concealment of inspection activities being performed by the craft, as well as facilitating some future kinetic intercept/attack, and more. | |
| DE-0009.02 | Space Weather | Space weather and its associated hazards imposed on spacecraft are a well-studied field of their own. However, it is also important to note the potential for threat actors to take advantage of heightened periods of solar activity to conduct electromagnetic interference (EMI) operations as they may be falsely attributed to natural events. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| CM0077 | Space Domain Awareness | The credibility and effectiveness of many other types of defenses are enabled or enhanced by the ability to quickly detect, characterize, and attribute attacks against space systems. Space domain awareness (SDA) includes identifying and tracking space objects, predicting where objects will be in the future, monitoring the space environment and space weather, and characterizing the capabilities of space objects and how they are being used. Exquisite SDA—information that is more timely, precise, and comprehensive than what is publicly available—can help distinguish between accidental and intentional actions in space. SDA systems include terrestrial-based optical, infrared, and radar systems as well as space-based sensors, such as the U.S. military’s Geosynchronous Space Situational Awareness Program (GSSAP) inspector satellites. Many nations have SDA systems with various levels of capability, and an increasing number of private companies (and amateur space trackers) are developing their own space surveillance systems, making the space environment more transparent to all users.* *https://csis-website-prod.s3.amazonaws.com/s3fs-public/publication/210225_Harrison_Defense_Space.pdf?N2KWelzCz3hE3AaUUptSGMprDtBlBSQG | CP-13 CP-2(3) CP-2(5) CP-2(7) PE-20 PE-6 PE-6 PE-6(1) PE-6(2) PE-6(4) RA-6 SI-4(17) | D3-APLM D3-PM D3-HCI D3-SYSM | A.5.29 A.7.4 A.8.16 A.7.4 A.7.4 A.5.10 | |
| CM0069 | Process White Listing | Simple process ID whitelisting on the firmware level could impede attackers from instigating unnecessary processes which could impact the spacecraft | CM-11 CM-7(5) PL-8 PL-8(1) SI-10(5) | D3-MAC D3-EAL D3-EDL | A.8.19 A.8.19 A.5.8 | |
| CM0034 | Monitor Critical Telemetry Points | Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. | AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-16(1) SC-7 SI-3(8) SI-4(7) | D3-NTA D3-PM D3-PMAD D3-RTSD | A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| CM0032 | On-board Intrusion Detection & Prevention | Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system. | 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) 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(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) | D3-FA D3-DA D3-FCR D3-FH D3-ID D3-IRA D3-HD D3-IAA D3-FHRA D3-NTA D3-PMAD D3-RTSD D3-ANAA D3-CA D3-CSPP D3-ISVA D3-PM D3-SDM D3-SFA D3-SFV D3-SICA D3-USICA D3-FBA D3-FEMC D3-FV D3-OSM D3-PFV D3-EHB D3-IDA D3-MBT D3-SBV D3-PA D3-PSMD D3-PSA D3-SEA D3-SSC D3-SCA D3-FAPA D3-IBCA D3-PCSV D3-FCA D3-PLA D3-UBA D3-RAPA D3-SDA D3-UDTA D3-UGLPA D3-ANET D3-AZET D3-JFAPA D3-LAM D3-NI D3-RRID D3-NTF D3-ITF D3-OTF D3-EI D3-EAL D3-EDL D3-HBPI D3-IOPR D3-KBPI D3-MAC D3-SCF | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | |
| CM0042 | Robust Fault Management | Ensure fault management system cannot be used against the spacecraft. Examples include: safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft. | CP-2 CP-4(5) IR-3 IR-3(1) IR-3(2) PE-10 PE-10 PE-11 PE-11(1) PE-14 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(24) SA-8(26) SA-8(3) SA-8(30) SA-8(4) SC-16(2) SC-24 SC-5 SI-13 SI-13(4) SI-17 SI-4(13) SI-4(7) SI-7(5) | D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.7.11 A.7.11 A.7.5 A.7.8 A.7.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.16 | |
| CM0044 | Cyber-safe Mode | Provide the capability to enter the spacecraft into a configuration-controlled and integrity-protected state representing a known, operational cyber-safe state (e.g., cyber-safe mode). Spacecraft should enter a cyber-safe mode when conditions that threaten the platform are detected. Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode, authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and software functions to pre-attack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on equipment still available after a cyber-attack. The goal is for the spacecraft to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. Cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable. | CP-10 CP-10(4) CP-12 CP-2 CP-2(5) IR-3 IR-3(1) IR-3(2) IR-4 IR-4(12) IR-4(3) PE-10 PE10 PL-8 PL-8(1) SA-3 SA-8 SA-8(10) SA-8(12) SA-8(13) SA-8(19) SA-8(21) SA-8(23) SA-8(24) SA-8(26) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-4(7) SI-7(17) SI-7(5) | D3-PH D3-EI D3-NI D3-BA | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.29 A.5.25 A.5.26 A.5.27 A.7.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0066 | Model-based System Verification | Real-time physics model-based system verification of state could help to verify data input and control sequence changes | SI-4 SI-4(2) | D3-OAM D3-AM D3-DEM D3-SVCDM D3-SYSDM | A.8.16 | |
| CM0048 | Resilient Position, Navigation, and Timing | If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. | CP-2 PE-20 PL-8 PL-8(1) SA-9 SC-16(2) SC-45 SC-45(1) SC-45(2) | D3-MH D3-MAN | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.10 A.5.8 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 | |