# THREAT DOMAIN TAXONOMY: MANIPULATE THE TRAINING DATA SET (DATA POISONING)

## 1. Standardized Phase Taxonomy (The Threat Lifecycle)
In the context of Machine Learning Operations (MLOps) and AI systems, the traditional cyber kill chain requires adaptation to account for the unique lifecycle of algorithmic training. Data poisoning represents a supply chain attack targeting the semantic integrity of the model.

*   **Reconnaissance:** The adversary identifies the target organization's data ingestion pipelines, scraping mechanisms, open-source dataset dependencies (e.g., HuggingFace datasets), or crowdsourced feedback loops. 
*   **Weaponization & Delivery (Initial Access):** The adversary crafts malicious data samples designed to introduce a specific statistical bias, vulnerability, or backdoor. This payload is delivered by compromising an upstream data source, submitting fraudulent user feedback, or directly breaching the data lake/S3 buckets used for staging.
*   **Exploitation & Installation (Execution/Persistence):** The MLOps pipeline automatically ingests the poisoned data during a routine training or fine-tuning run. The model updates its neural weights based on the malicious data, effectively "installing" the vulnerability deeply within the model's parameters. The vulnerability is now mathematically persistent.
*   **Command and Control (C2):** Traditional network C2 is replaced by "Inference Triggering." The adversary establishes control by submitting specific, pre-calculated inputs (triggers) to the production model via standard APIs. These triggers activate the poisoned weights established during the installation phase.
*   **Actions on Objectives (Impact/Exfiltration):** Upon activation, the model executes the adversary's goal. This manifests as targeted misclassification, generation of malicious code, bypass of safety guardrails, or targeted degradation of service (model collapse).

## 2. TTP Mapping (Tactics, Techniques, and Procedures)
For audit verifiability, this domain incorporates both MITRE ATT&CK and the MITRE ATLAS (Adversarial Threat Landscape for AI Systems) frameworks.

*   **Reconnaissance:** AML.T0002 (Acquire Public ML Artifacts); T1596 (Search Open Technical Databases).
*   **Weaponization & Delivery:** AML.T0020 (Poison Training Data); T1190 (Exploit Public-Facing Application - targeting feedback APIs); T1078 (Valid Accounts - compromising data engineering credentials).
*   **Exploitation & Installation:** AML.T0039 (Evade ML Model - through backdoor installation); T1059 (Command and Scripting Interpreter - if automated ML pipelines execute malicious scripts hidden in data formats like `.pkl` or `.csv`).
*   **Command and Control (C2):** AML.T0018 (Backdoor ML Model - triggering the hidden vulnerability via crafted inference payloads).
*   **Actions on Objectives:** AML.T0031 (Erode ML Model Integrity); AML.T0029 (Denial of ML Service).

## 3. Control Intersection and Segregation (The "Kill" Mechanism)

*   **Reconnaissance**
    *   *Preventive:* Obfuscation of internal dataset sourcing; strict NDA enforcement for external data labeling vendors.
    *   *Detective:* Anomaly detection on public-facing dataset repository queries.
    *   *Corrective:* Automated blocking of scraping/scanning IP blocks.
*   **Weaponization & Delivery**
    *   *Preventive:* Cryptographic hashing and digital signatures for all external and internal datasets (Data Provenance); strictly enforced Role-Based Access Control (RBAC) on data lakes.
    *   *Detective:* Statistical anomaly detection on incoming data batches (e.g., sudden shifts in data distribution, unusual file sizes, hash mismatches).
    *   *Corrective:* Automated quarantine of non-conforming or unsigned data batches before they reach the staging environment.
*   **Exploitation & Installation**
    *   *Preventive:* Human-in-the-loop (HITL) review for data anomalies; execution of training scripts in highly isolated, ephemeral container environments.
    *   *Detective:* Continuous monitoring of training loss curves (sudden, inexplicable drops or spikes); failure of the model against a mathematically verified, immutable "Golden Dataset" during the validation phase.
    *   *Corrective:* Automated halt of the ML training pipeline; forced rollback to the last verified clean model checkpoint.
*   **Command and Control (C2) / Triggering**
    *   *Preventive:* Input sanitization and semantic filtering via independent guardrail models.
    *   *Detective:* Alerting on statistically highly improbable input sequences or known adversarial prompt patterns.
    *   *Corrective:* API gateway rejection of the inference request; temporary account suspension for the requesting user.
*   **Actions on Objectives**
    *   *Preventive:* Output evaluation guardrails to block policy-violating generations.
    *   *Detective:* Continuous semantic monitoring of production outputs for toxicity, bias, or logic failures.
    *   *Corrective:* Redaction of generated output; automated fallback to deterministic, rule-based systems.

## 4. Telemetry and Evidence Generation
To satisfy audit requirements, the following immutable logs must be generated and routed to a centralized, WORM (Write-Once-Read-Many) compliant SIEM:
*   **Data Lineage Logs:** Output from Data Version Control (DVC) tools detailing exact hash values, timestamps, and origin points for every data file ingested.
*   **Access Logs:** Cloud storage access events (e.g., AWS CloudTrail, Azure Monitor) identifying which identity accessed or modified the training buckets.
*   **ML Pipeline Execution Logs:** Detailed run logs from orchestration platforms (e.g., MLflow, Kubeflow, Airflow) capturing training parameters, loss metrics, and validation scores.
*   **Inference Logs:** Complete capture of user inputs and model outputs, tagged with session IDs and timestamped for retrospective anomaly hunting.

## 5. Auditor’s Perspective (CCCE Application)

*   **Criteria:** AI and ML architectures must enforce strict cryptographic data provenance, utilize WORM-compliant storage for training datasets, and maintain rigorous continuous evaluation using immutable baseline datasets (Golden Datasets) in alignment with the NIST AI RMF and MITRE ATLAS frameworks.
*   **Condition:** Management frequently treats ML training datasets as standard, fluid file shares, applying minimal to no cryptographic integrity checks. Data ingestion pipelines are often fully automated without intermediate validation, and organizations rely purely on post-training, ad-hoc validation rather than systematic integrity verification.
*   **Cause:** There is a pervasive operational bias where ML engineering teams prioritize model performance, dataset scale, and rapid iteration over secure data lineage. Furthermore, traditional cybersecurity functions lack visibility into, and understanding of, data science workflows, resulting in unmonitored shadow MLOps pipelines.
*   **Effect:** The organization’s models become highly susceptible to systemic compromise from the inside out. Poisoned weights create untraceable vulnerabilities where the model acts maliciously or fails catastrophically under specific, adversary-controlled conditions, entirely invalidating the operational integrity of the AI system.
*   **Recommendation:** Management must implement cryptographic Data Version Control (DVC), enforce strict Segregation of Duties (SoD) between data engineering and model training execution, and mandate that all models pass evaluation against a cryptographically secured "Golden Dataset" before being approved for production deployment.