safemode.space
← All techniques
EX-0010.01
ST0004Execution
sub-technique

Ransomware

Parent: EX-0010

Description

Ransomware on a spacecraft encrypts data or critical configuration so that nominal operations can no longer proceed without the attacker’s cooperation. Targets include mass-memory file stores (engineering telemetry, payload data), configuration and command tables, event logs, on-board ephemerides, and even intermediate buffers used by downlink pipelines. Some variants interfere with key services instead of bulk data, e.g., encrypting a command dictionary or table index so valid inputs are rejected, or wrapping the payload data path in an attacker-chosen cipher so downlinked products appear as noise. By denying access to on-board content or control artifacts at scale, attackers convert execution into bargaining power or irreversible mission degradation.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    moderate
    derived

    Integrity protection on stored data and configuration resists ransomware-induced encryption of mission-critical content.

  • craAnnex I, Part I, (2)(h)
    addresses
    high
    derived

    Manufacturer obligation to protect availability of essential and basic functions also after an incident is the recovery-side obligation engaged by ransomware: products must remain operationally recoverable through resilience and mitigation mechanisms.

  • eu-space-actArt. 86(1)
    addresses
    high
    direct

    Ransomware encrypting on-board files, configuration tables, and command dictionaries is the canonical case 86(1)'s backup management policy addresses — backups enable restoration of network and information systems and recovery of data without paying ransom.

  • eu-space-actArt. 87(2)
    addresses
    high
    direct

    87(2)'s response-and-recovery plans must allow operators to quickly and effectively respond to ransomware and contain its adverse effects — the BCDR discipline that complements backup-restore.

  • eu-space-actArt. 87(4)
    addresses
    moderate
    direct

    Ransomware response (primary: Art. 87(2) BCDR) cascades to 87(4) — staff executing ransomware recovery (backup restoration, key segregation) must have role-appropriate training.

  • eu-space-actArt. 91(1)
    addresses
    moderate
    direct

    91(1)'s incident-management process governs the operator's discipline in detecting, identifying, handling, and responding to ransomware events.

  • nis2Art. 21(2)(b)
    addresses
    high
    derived

    Encryption of mission data or critical configuration that prevents nominal operations is a paradigmatic incident the entity's incident-handling capability under Art. 21(2)(b) must triage, contain, and restore from.

  • nis2Art. 21(2)(c)
    addresses
    high
    direct

    Backup management, disaster recovery, and crisis management under Art. 21(2)(c) is the precise obligation that bounds ransomware impact — restoring engineering telemetry, payload data, command tables, and ephemerides without paying.

  • nis2Art. 23(1)
    triggers obligation
    high
    direct

    Ransomware causing the entity to lose access to mission-critical content meets the Art. 23(3)(a) significance threshold (severe operational disruption) and triggers Art. 23(1) reporting without undue delay.

  • nis2Art. 23(2)
    addresses
    moderate
    derived

    Primary mapping to Art. 23(1) establishes that ransomware against ground or mission-control infrastructure is a significant incident triggering the reporting obligation. Art. 23(2) addresses the timing dimension (notification without undue delay after becoming aware), which automatically applies once Art. 23(1) is triggered.

  • nis2Art. 23(3)
    relates to
    high
    derived

    Primary mapping to Art. 23(1) treats ransomware as a significant incident. Art. 23(3) defines the significance criteria (operational disruption, financial loss); ransomware against MOC/IT systems satisfies both directly and frequently has cross-border impact when the affected operator serves multi-Member-State customers.

  • nis2Art. 23(4)
    addresses
    moderate
    derived

    Primary mapping to Art. 23(1) triggers the Art. 23(4) timing cascade (24-hour early warning, 72-hour incident notification, one-month final report). For a ransomware event the deadlines are operationally tight but unconditional.

  • nis2-implAnnex 3.3.1
    addresses
    moderate
    derived

    Ransomware events are operator-visible (mission impact, encrypted files, denied access); Annex 3.3.1 requires a simple mechanism for employees to report suspicious events, which is the upstream feeder for the 3.4 assessment that classifies the event and triggers 3.5.1 response.

  • nis2-implAnnex 3.4.1
    addresses
    high
    derived

    Primary mapping to Annex 3.5.1 (incident response) implies upstream event assessment and classification. Annex 3.4.1 requires the entity to determine whether suspicious events constitute incidents and assign severity — the gate that must run before ransomware-class incident-response procedures activate.

  • nis2-implAnnex 3.4.2
    addresses
    moderate
    derived

    Annex 3.4.2 specifies how assessment is performed (impact-based criteria, severity assignment); for ransomware events, this is the procedure that converts a 'suspicious encryption activity' alert into the incident classification that drives Annex 3.5.1 response.

  • nis2-implAnnex 3.5.1
    addresses
    moderate
    derived

    Incident-response procedures govern containment and recovery from ransomware events; they are the operational layer that turns the existence of backups into actual restoration of service.

  • nis2-implAnnex 3.6.1
    addresses
    high
    derived

    Annex 3.6.1 requires post-incident review after recovery; ransomware events are exactly the high-impact class for which root-cause review and lessons-learned analysis must follow Annex 3.5.1 incident response.

  • nis2-implAnnex 3.6.2
    addresses
    moderate
    derived

    Annex 3.6.2 requires post-incident reviews to feed back into the security approach; ransomware incidents typically expose backup, segmentation or auth weaknesses whose remediation closes the loop on Annex 3.5.1 response.

  • nis2-implAnnex 3.6.3
    addresses
    moderate
    derived

    Annex 3.6.3 requires planned-interval review of whether incidents triggered post-incident reviews; a ransomware event would be expected to populate that schedule.

  • nis2-implAnnex 4.2.1
    addresses
    high
    direct

    Backup-and-redundancy obligations require the entity to maintain backup copies of data and resources so that ransomware-induced loss of access does not become loss of operations; backups are the recovery lever specifically targeted at this attack class.

  • nis2-implAnnex 4.2.6
    addresses
    high
    direct

    Regular testing of backup recovery is the procedural mechanism that ensures the recovery-from-ransomware path is operationally viable, not merely documented; untested backups are the failure mode that converts ransomware into a successful denial event.

  • nis2-implAnnex 6.9.1
    addresses
    high
    derived

    Ransomware is malicious software encrypting data and configuration; the malware-protection obligations require the entity to implement detection or prevention measures appropriate to the asset.

ENISA controls

  • ENISA-STL-2025-03-sD.24-i04
    mitigates
    high

    Regular tested backups with verified integrity provide the alternative to paying the ransom and underpin recovery from on-board ransomware encryption.

  • ENISA-STL-2025-03-sD.25-i01
    mitigates
    high

    Malware-protection mechanisms at endpoints and entry points intercept ransomware payloads before they execute on-board.

  • ENISA-STL-2025-03-sD.31-i02
    addresses
    high

    Incident Recovery Plan with detailed recovery procedures and roles is the operational discipline through which a ransomware incident is contained and the mission restored.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0010.01 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.