safemode.space
← All techniques
DE-0003.12
ST0006Defense Evasion
sub-technique

Poison AI/ML Training for Evasion

Parent: DE-0003

Description

When security monitoring relies on AI/ML (e.g., anomaly detection on telemetry, RF fingerprints, or command semantics), the training data itself is a target. Data-poisoning introduces crafted examples or labels so the learned model embeds false associations, treating attacker behaviors as normal, or flagging benign patterns instead. Variants include clean-label backdoors keyed to subtle triggers, label flipping that shifts decision boundaries, and biased sampling that suppresses rare-but-critical signatures. Models trained on tainted corpora are later deployed as routine updates; once in service, the adversary presents inputs containing the trigger or profile they primed, and the detector omits or downranks the very behaviors that would reveal the intrusion.

Mappings

EU regulation articles

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

    Poisoning training data with crafted examples or labels is unauthorized modification of the data (and downstream model) the product processes — the integrity property (2)(f) covers.

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

    Anomaly-detection / monitoring models ARE the (2)(l) recording-and-monitoring layer when the product implements ML-based security telemetry; clean-label backdoors and label flipping directly defeat the obligation.

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

    AI/ML training-data poisoning via third-party component pipelines (primary mapping: Art. 13(5)) requires SBOM-grade documentation of training data and model artifacts; (1)'s component-and-vulnerability-identification obligation extends to ML pipeline components.

  • craArt. 13(5)
    triggers obligation
    moderate
    direct

    Training data and pretrained models are commonly sourced from third parties; (13)(5)'s component-due-diligence obligation triggers when a manufacturer integrates third-party ML pipelines exposed to poisoning.

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

    Poisoned training data corrupts the model the network-and-information-system relies on for monitoring — 84(2)'s integrity scope under Annex VII point 5.1.

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

    88(1)'s testing programme can include adversarial-input testing on monitoring models — surfacing clean-label backdoors and biased-sampling artifacts.

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

    AI/ML training-data poisoning (primary: Art. 88(1)) cascades to 88(3) — TLPT every 3 years should validate ML pipeline integrity against adversarial-input tests.

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

    ML training corpora and pretrained models often arrive via supplier or scientific-archive channels — 92(1)'s contractual information-security obligation governs how training-data provenance is disciplined.

  • nis2Art. 21(2)(d)
    addresses
    moderate
    direct

    Detector training corpora (telemetry archives, RF-fingerprint datasets, command-semantic logs) often ride supplier and service-provider data flows; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework around those sources.

  • nis2Art. 21(2)(e)
    addresses
    moderate
    direct

    Detector model training/packaging/promotion is part of the network-and-information-systems development/maintenance pipeline Art. 21(2)(e) governs, including disclosed-weakness handling on label-flipping and clean-label backdoor attacks.

  • nis2Art. 21(2)(f)
    addresses
    moderate
    direct

    Validating that anomaly detectors actually detect — including against adversarial-input campaigns — is exactly how the entity assesses the effectiveness of its cybersecurity risk-management measures under Art. 21(2)(f).

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers supplier-relationship security for the AI/ML training-data pipeline. Art. 21(3) extends that obligation to the supplier-quality assessment itself (vulnerabilities of direct suppliers, secure development procedures), which is exactly the procedural lever needed to detect and remediate poisoned training data flowing from upstream data brokers, annotation services, and pretrained-model vendors.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Training datasets and reference labels for security-monitoring models are mission-critical information assets whose classification level drives integrity and access controls.

  • nis2-implAnnex 5.1.1
    addresses
    moderate
    derived

    Anomaly-detection model training data is supplied through data brokers, telemetry-archive providers and ML-as-a-service vendors; the supply-chain policy governs how these data suppliers are vetted, contracted and monitored.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    AI/ML model training is part of the secure-development life cycle; the rules for that lifecycle govern training-data integrity, model provenance and pre-deployment validation that detect poisoned anomaly-detection models.

ENISA controls

  • ENISA-STL-2025-03-sD.25-i10
    addresses
    moderate

    Integrity checking on training corpora and packaged ML model artefacts detects poisoned data before deployment.

  • ENISA-STL-2025-03-sD.33-i06
    addresses
    high

    ML data-integrity testing (regression, validity, manual, statistical analysis) is the named control against poisoning of detector training data for evasion.

Cross-reference controls

SPARTA countermeasures

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

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