# THREAT DOMAIN TAXONOMY: MANIPULATE PRE-TRAINED COMPONENTS (MODEL POISONING)

## 1. Standardized Phase Taxonomy (The Threat Lifecycle)
Unlike data poisoning, which alters the training corpus, manipulating pre-trained components constitutes a direct Supply Chain Compromise targeting the foundational architecture, embeddings, or neural weights of a model before the victim organization even begins fine-tuning.

*   **Reconnaissance:** The adversary identifies the target organization's machine learning dependencies, pinpointing the specific foundational models (e.g., Llama, BERT, ResNet) and open-source registries (e.g., HuggingFace, PyTorch Hub, GitHub) utilized by the target's MLOps teams.
*   **Weaponization & Delivery (Initial Access):** The adversary creates a malicious version of a popular pre-trained model. Weaponization takes two primary forms:
    1.  *Semantic Poisoning:* Subtly altering the mathematical weights to install a backdoor that survives fine-tuning.
    2.  *Code Execution (Serialization Exploits):* Embedding malicious executable code within unsafe serialization formats (e.g., Python `.pkl` / Pickle files).
    Delivery is achieved via repository compromise, account takeover of a trusted publisher, or typosquatting (uploading a model with a name visually identical to a legitimate model).
*   **Exploitation & Installation (Execution/Persistence):** The victim's automated MLOps pipeline or data scientist fetches and loads the compromised pre-trained model into the internal environment. Upon instantiation (e.g., `torch.load()`), embedded malicious serialization code executes, granting the adversary a foothold on the training server. If utilizing semantic poisoning, the backdoored weights are assimilated into the victim's proprietary model, establishing mathematical persistence.
*   **Command and Control (C2):** If the execution involved serialization exploits, traditional C2 infrastructure is established (reverse shells, beacons) from the compromised ML compute node. If purely semantic, the C2 is latent, awaiting "Inference Triggering" via specific user inputs in the production environment.
*   **Actions on Objectives (Impact/Exfiltration):** For code-execution exploits, the adversary conducts lateral movement to exfiltrate proprietary training data, intellectual property, or cryptographic keys stored in the ML environment. For semantic exploits, the adversary triggers targeted misclassifications or logic bypasses in the final, deployed application.

## 2. TTP Mapping (Tactics, Techniques, and Procedures)
For audit verifiability, this domain incorporates both MITRE ATT&CK and MITRE ATLAS matrices to bridge traditional infrastructure and AI-specific threats.

*   **Reconnaissance:** AML.T0002 (Acquire Public ML Artifacts); T1592 (Gather Victim Host Information).
*   **Weaponization & Delivery:** AML.T0010 (ML Supply Chain Compromise); T1195.001 (Compromise Software Dependencies and Development Tools); T1584.004 (Compromise Infrastructure: Server - targeting public model hubs).
*   **Exploitation & Installation:** T1059.006 (Command and Scripting Interpreter: Python - via insecure deserialization); AML.T0018 (Backdoor ML Model - weight manipulation).
*   **Command and Control (C2):** T1071 (Application Layer Protocol - for reverse shells from training nodes); AML.T0017 (Poisoning via Inference Trigger).
*   **Actions on Objectives:** T1552.004 (Credentials from Password Stores - stealing API keys from ML environments); AML.T0031 (Erode ML Model Integrity).

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

*   **Reconnaissance**
    *   *Preventive:* Strict Operational Security (OPSEC) regarding the organization's MLOps tech stack and vendor dependencies.
    *   *Detective:* Threat intelligence monitoring for typosquatted model names or compromised upstream authors.
    *   *Corrective:* Takedown requests for malicious repositories impersonating trusted components.
*   **Weaponization & Delivery**
    *   *Preventive:* Blocking direct developer access to public model hubs. Mandating the use of a centralized, internal, and hardened artifact registry (e.g., JFrog Artifactory) for all ML components.
    *   *Detective:* Network edge alerting on direct API calls to untrusted external model repositories; continuous scanning for hash mismatches against known-good baseline models.
    *   *Corrective:* Automated network-level blocking of unapproved model hub IP ranges/URLs.
*   **Exploitation & Installation**
    *   *Preventive:* Explicit policy and technical controls prohibiting the loading of models using unsafe serialization formats (e.g., restricting `.pkl` or `torch.load()` and strictly mandating `.safetensors` or ONNX). Cryptographic signature verification of all downloaded model components prior to instantiation.
    *   *Detective:* Endpoint Detection and Response (EDR) alerting on anomalous child processes spawning from Python/ML environments (e.g., a Jupyter notebook spawning `cmd.exe` or `/bin/bash`).
    *   *Corrective:* Automated termination of rogue Python processes by the EDR agent; isolation of the compromised ML compute node.
*   **Command and Control (C2)**
    *   *Preventive:* Strict egress filtering on all ML training and inference nodes (enforcing an air-gap or explicit proxy whitelisting for required APIs only).
    *   *Detective:* Network Intrusion Detection Systems (NIDS) alerting on anomalous outbound traffic patterns from high-compute clusters.
    *   *Corrective:* Dynamic firewall isolation (quarantine) of the communicating node.
*   **Actions on Objectives**
    *   *Preventive:* Least privilege enforcement for ML service accounts; restricting ML compute nodes from accessing production databases or cryptographic Key Management Systems (KMS).
    *   *Detective:* User and Entity Behavior Analytics (UEBA) detecting anomalous data staging or lateral movement from the MLOps subnet.
    *   *Corrective:* Immediate revocation of compromised service account tokens and API keys.

## 4. Telemetry and Evidence Generation
To satisfy audit requirements, the following immutable logs must be generated and routed to a centralized, WORM-compliant SIEM:
*   **Artifact Provenance Logs:** Cryptographic hashes, digital signatures, and source URLs for every pre-trained model or embedding downloaded, generated by the internal artifact registry.
*   **EDR Process Telemetry:** Granular process creation, file modification, and memory injection events from all GPU/ML compute nodes and data scientist workstations.
*   **Network Flow Data:** VPC flow logs, firewall egress logs, and DNS query logs specific to the MLOps environments to prove network isolation and detect unauthorized C2.
*   **CI/CD Pipeline Execution Logs:** Detailed logs of automated training runs, capturing exactly which base model hashes were loaded during the fine-tuning process.

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

*   **Criteria:** The organization must enforce strict Software Supply Chain Security protocols for all ML components, including the mandatory use of internal curated registries, cryptographic verification of model weights, the absolute prohibition of unsafe serialization formats (e.g., Pickle), and Zero Trust network isolation for training environments.
*   **Condition:** First Line engineering teams frequently bypass secure development lifecycles (SDLC) by directly executing API commands (e.g., `transformers.from_pretrained()`) to pull unverified, unhashed models from public internet hubs directly into corporate training or production environments, often using inherently unsafe file formats.
*   **Cause:** Operational bias prioritizing rapid AI prototyping, developer convenience, and a pervasive, dangerous assumption that public ML repositories are implicitly safe. Furthermore, standard IT security teams lack visibility into data science libraries and ML workflow mechanics.
*   **Effect:** The organization exposes its core infrastructure to immediate Remote Code Execution (RCE) via deserialization attacks, or permanently infects its proprietary AI systems with latent, mathematically persistent backdoors that standard vulnerability scanners cannot detect.
*   **Recommendation:** Management must implement a hardened, "walled-garden" internal model registry. Network controls must strictly block egress from ML compute nodes to the public internet, forcing all model acquisitions through a rigorous, automated DevSecOps validation and sanitization pipeline prior to internal availability.