Smart Contracts

Smart contracts can be used to mitigate harm when an attacker is attempting to compromise a hosted payload. Smart contracts will stipulate security protocol required across a bus and should it be violated, the violator will be barred from exchanges across the system after consensus achieved across the network.

Sources

https://corpgov.law.harvard.edu/2018/05/26/an-introduction-to-smart-contracts-and-their-potential-and-inherent-limitations/

Best Segment for Countermeasure Deployment

Space Segment

NIST Rev5 Controls

D3FEND Techniques

D3FEND Artifacts

ISO 27001

A.8.16 - Monitoring activities

ID: CM0067

NASA Best Practice Guide: MI-AUTH-01 | MI-AUTH-02 | MI-INTG-01 | MI-DCO-02

ESA Space Shield Mitigation: M2057

Created: 2022/10/19

Last Modified: 2023/11/29

Techniques Addressed by Countermeasure

ID	Name	Description
IA-0006	Compromise Hosted Payload	Threat actors may compromise the target spacecraft 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.
LM-0001	Hosted Payload	Threat actors may use the hosted payload within the victim spacecraft 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.
LM-0002	Exploit Lack of Bus Segregation	Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller)
LM-0003	Constellation Hopping via Crosslink	Threat actors may attempt to command another neighboring spacecraft via crosslink. spacecraft in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another spacecraft.
LM-0004	Visiting Vehicle Interface(s)	Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked.

Space Threats Addressed by Countermeasure

ID	Description
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-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-AC-1	Attempting access to an access-controlled system resulting in unauthorized access

Low-Level Requirements

Requirement	Rationale/Additional Guidance/Notes
The [spacecraft] shall monitor security relevant telemetry points for malicious commanding attempts.{AC-17,AC-17(1),AC-17(10),AU-3(1),RA-10,SC-7,SC-16,SC-16(2),SC-16(3),SI-3(8),SI-4,SI-4(1),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}
The [spacecraft] shall authenticate the ground station (and all commands) and other spacecraft before establishing remote connections using bidirectional authentication that is cryptographically based.{SV-AC-1,SV-AC-2}{AC-3,AC-17,AC-17(2),AC-17(10),AC-18(1),AC-20,IA-3(1),IA-4,IA-4(9),IA-7,IA-9,SA-8(18),SA-8(19),SA-9(2),SC-7(11),SC-16(1),SC-16(2),SC-16(3),SC-23(3),SI-3(9)}	Authorization can include embedding opcodes in command strings, using trusted authentication protocols, identifying proper link characteristics such as emitter location, expected range of receive power, expected modulation, data rates, communication protocols, beamwidth, etc.; and tracking command counter increments against expected values.
The [spacecraft] shall enforce approved authorizations for controlling the flow of information within the platform and between interconnected systems so that information does not leave the platform boundary unless it is encrypted.{SV-AC-6}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-3,CA-3(6),CA-3(7),CA-9,IA-9,SA-8(19),SC-8(1),SC-16(3)}
The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32}
The [spacecraft] shall, when transferring information between different security domains, implements the following security policy filters that require fully enumerated formats that restrict data structure and content: connectors and semaphores implemented in the RTOS.{SV-AC-6}{AC-3(3),AC-3(4),AC-4(14),IA-9,SA-8(19),SC-16}
The [spacecraft] shall use protected processing domains to enforce the policy that information does not leave the platform boundary unless it is encrypted as a basis for flow control decisions.{SV-AC-6}{AC-4(2),IA-9,SA-8(19),SC-8(1),SC-16(3)}
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 alert in the event of the audit/logging processing failures.{AU-5,AU-5(1),AU-5(2),SI-3,SI-4,SI-4(1),SI-4(7),SI-4(12),SI-4(24)}
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 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 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 have on-board intrusion detection/prevention system that monitors the mission critical components or systems.{SV-AC-1,SV-AC-2,SV-MA-4}{RA-10,SC-7,SI-3,SI-3(8),SI-4,SI-4(1),SI-4(7),SI-4(13),SI-4(24),SI-4(25),SI-10(6)}	The mission critical components or systems could be GNC/Attitude Control, C&DH, TT&C, Fault Management.