safemode.space
← All techniques
DE-0006
ST0006Defense Evasion

Modify Whitelist

Description

Threat actors may target whitelists on the spacecrafts as a means to execute and/or hide malicious processes/programs. Whitelisting is a common technique used on traditional IT systems but has also been used on spacecrafts. Whitelisting is used to prevent execution of unknown or potentially malicious software. However, this technique can be bypassed if not implemented correctly but threat actors may also simply attempt to modify the whitelist outright to ensure their malicious software will operate on the spacecraft that utilizes whitelisting.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    high
    direct

    Modifying the on-board whitelist is unauthorized modification of a security-critical configuration table — squarely within (2)(f)'s integrity-of-configuration scope.

  • craAnnex I, Part I, (2)(k)
    addresses
    moderate
    inferred

    CRA Annex I (2)(k) is domain-relevant but does not mitigate DE-0006: whitelist modification is an execution-control vector that subverts the mitigation mechanism itself, not an incident-impact availability loss. The operative control is allowlist integrity and execution control. Addresses.

  • craAnnex I, Part II, (3)
    addresses
    moderate
    direct

    Modify-whitelist (primary mapping: Annex I, Part I, (2)(k)) requires regular tests under (3) of whitelist tamper-resistance — periodic verification that the whitelist enforcement mechanism remains intact.

  • eu-space-actArt. 81(3)
    addresses
    moderate
    direct

    Whitelist edits are critical-function actions; 81(3)(b) restricts which entities can write to enforcement tables.

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

    Whitelist modification rewrites a security-critical configuration table — within 84(2)'s integrity scope per Annex VII point 5.1.

  • nis2Art. 21(2)(h)
    addresses
    moderate
    inferred

    Art. 21(2)(h) crypto policy does not interdict modification of onboard command whitelists; the operative control is allowlist integrity and execution control. Addresses (domain relevance).

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

    Allowlists/whitelists are first-class access-controlled configuration that decides what executes; Art. 21(2)(i)'s access-control + asset-management obligation governs which roles and paths can edit them.

  • nis2-implAnnex 11.3.1
    addresses
    moderate
    derived

    Authority to modify execution whitelists is privileged; the privileged-account policy applies its identification and review obligations to that population.

  • nis2-implAnnex 6.3.1
    addresses
    high
    derived

    Configuration-management obligations cover the whitelist baseline as part of the documented configuration whose deviations must be detected and reviewed.

  • nis2-implAnnex 6.4.1
    addresses
    high
    derived

    Whitelist-table modifications are change-management events; documented procedures must govern additions, removals and edits of whitelisted process/program identifiers.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i01
    mitigates
    moderate

    Configuration management of whitelist baselines surfaces additions of unauthorised entries.

  • ENISA-STL-2025-03-sD.24-i08
    addresses
    high

    Process-ID whitelisting (only a limited list of IDs allowed to communicate with bus and payload firmware) is the canonical whitelist whose modification DE-0006 attempts.

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

    Integrity checking on whitelist configuration data detects unauthorised modifications attempting to add malicious software.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, DE-0006 (SPARTA v3.2).

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