Threat Assessment (TA)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

Objective: Build and maintain a reusable threat library for the infrastructure that hosts and serves AI/HAI systems, one archetype-level threat model per infrastructure asset type, so every infrastructure asset entering the SM inventory carries a documented threat view before it is provisioned, connected to AI workloads, or exposed to external traffic.

Description: TA-Infrastructure catalogs the threats specific to the infrastructure the organization operates to host and serve AI/HAI systems, not generic cloud-infrastructure threats, but the failure modes specific to inference endpoints, model registries, GPU/accelerator fleets, orchestrator control planes, vector-store infrastructure, AI-specific CI/CD pipelines, and feature stores. At L1 the library covers one threat model per infrastructure archetype mapped to HAIAMM's HAI-specific TTPs (EA, AGH, TM, RA), to MITRE ATLAS tactics and techniques, and to the HAIAMM Cloud Threat Taxonomy (HCT). Each new infrastructure asset registered in SM's inventory generates a threat snapshot by pulling the archetype model and adding asset-specific deltas (specific tenant configuration, specific workload classification, specific network placement). L2 layers per-asset deep models for Critical-tier assets with cloud-tactic walks and quarterly red-team cycles. L3 contributes discovered TTPs back to MITRE ATLAS, AVID, CNCF AI working groups, and OpenSSF AI.

Context: Classic infrastructure threat modeling was not designed to enumerate AI-specific failure modes, cross-tenant GPU residual-state leakage, model-artifact tampering in a registry, orchestrator workflow injection that redirects agent execution, inference-API flooding that degrades serving quality for all tenants, or training-job hijack that plants a backdoor in a shared accelerator fleet. These are first-party infrastructure risks owned by the platform and MLOps teams that provision and operate the substrate on which AI systems run. TA-Infrastructure closes the gap by making infrastructure-asset-specific threats a first-class library, tied to both ATLAS tactic IDs and HCT threat roots (BadCode, BadAction, BadPrincipal, BadPermissions) so the walk from attacker capability to infrastructure exposure is concrete and cloud-native.

Maturity Level 1

Objective: Build the AI/HAI infrastructure archetype threat library, integrate a threat snapshot into every infrastructure asset intake, and ensure every asset's threat surface is documented before it is connected to AI workloads

At this level, every platform engineer, MLOps reviewer, and security architect reviewing a new AI infrastructure asset has a reusable, archetype-keyed library that maps AI/HAI infrastructure failure modes to HAI TTPs, ATLAS tactics, and HCT threat roots. No infrastructure asset enters the AI-serving stack without a documented threat view.

Dependencies

• SM-Infrastructure L1 (required): the infrastructure asset inventory defines which archetypes exist and which assets need threat models; without it, TA operates on guesswork about scope.
• PC-Infrastructure L1 (required): the priority compliance map identifies which regulatory obligations (EU AI Act Art. 26, Art. 9 risk management, GDPR Art. 32, ISO/IEC 42001) must be reflected in the threat library.
• EG-Infrastructure L1 (required for reviewer activity): reviewers must recognize AI/HAI-specific infrastructure archetypes, TTPs, and HCT roots before they can produce a credible snapshot.
• Supports / unblocks: SR-Infrastructure L1 (requirements derive from archetype threats), SA-Infrastructure L1 (reference patterns address archetype threat surfaces), ST-Infrastructure L1 (test battery targets archetype threats), ML-Infrastructure L1 (detections prioritized from threat library), IM-Infrastructure L1 (incident classifications derive from the threat library).

Desired Outcomes

• Every AI/HAI infrastructure asset reaching SM intake gets a threat snapshot within one business day, pulled from the archetype library and adapted to the specific asset's workload tier, tenant configuration, and network placement.
• HAIAMM's HAI-specific TTPs, EA (Excessive Agency), AGH (Agent Goal Hijack), TM (Tool Misuse), RA (Rogue Agents), are tagged to each archetype's threats where applicable; reviewers can explain the infrastructure-specific implications of each tag.
• MITRE ATLAS tactics (TA0001 Reconnaissance through TA0014 Impact) and HCT threat roots (BadCode, BadAction, BadPrincipal, BadPermissions) are both walked for each archetype at intake; exclusions are explicit.
• The threat library is versioned, owned, and refreshed on a documented cadence, it does not rot as new AI infrastructure attack research emerges.
• Downstream practices (SR, SA, ST, ML, IM) inherit the library rather than re-deriving threats per asset.

Activities

A) Build the AI/HAI infrastructure archetype threat library

Author one threat model per AI/HAI infrastructure archetype. Each archetype model is concise (target ≤2 pages), explicitly scoped to infrastructure assets the organization operates to host AI systems, and maps threats to HAI TTPs, ATLAS tactic IDs and technique IDs, HCT entries, and the PC-Infrastructure priority compliance map.

Archetypes to cover at L1 (from SM-Infrastructure's inventory schema):

• Inference endpoint / model-serving cluster, the network-exposed endpoint (API gateway, load balancer, serving cluster) that puts a model behind production traffic and serves predictions to consumers.
• Model registry, the versioned artifact store that holds model weights, metadata, lineage records, and promotion history; consumed by inference endpoints, fine-tuning pipelines, and evaluation harnesses.
• GPU / accelerator fleet, the pool of GPU or accelerator (TPU, Trainium, Inferentia) instances used for training, fine-tuning, and high-throughput inference; may be shared across workloads or tenants.
• Orchestrator / control plane, the workflow engine, agent orchestration platform, or MLOps control plane that coordinates training jobs, agent steps, tool invocations, and pipeline execution.
• Vector-store infrastructure, the vector database, embedding index, and associated ingest pipeline that back RAG retrieval and similarity-search workloads.
• AI-specific CI/CD, the training pipeline, eval-gate, model-promotion workflow, and deployment automation specific to AI artifacts; distinct from general application CI/CD by its handling of model weights, training data, and evaluation corpora.
• Feature store / online serving cache, the low-latency feature-serving layer that provides pre-computed features to models at inference time; bridges offline feature engineering and online prediction.

Per-archetype threat content (minimum):

Inference endpoint / model-serving cluster: - Model extraction via inference API (AML.T0024), high-volume queries designed to reconstruct model weights or decision boundaries from returned outputs. HAI-TTP: TM. ATLAS: TA0013 Exfiltration; TA0040 ML Attack Staging. HCT: HCT.BadAction.020 (high-velocity inference-API calls). - Denial-of-service / prompt-flood (TA0040 ML Attack Staging), crafted inputs or flooding designed to exhaust GPU capacity, degrade latency SLAs, or force serving cluster shutdown. ATLAS: TA0014 Impact. HCT: HCT.BadAction.009. - Cross-tenant isolation breach, one tenant's request context, prompt history, or model-state leaks into another tenant's inference response due to misconfigured session handling or shared memory. HCT: HCT.BadPermissions.011; HCT.BadCode.017. - Lateral movement from compromised endpoint, a compromised inference-endpoint workload identity is used to reach the model registry, training data stores, or the orchestration control plane. HAI-TTP: EA. ATLAS: TA0007 Privilege Escalation; TA0006 Persistence. HCT: HCT.BadPrincipal.002; HCT.BadPermissions.001. - Model swap / silent version flip, the model version served by the endpoint is changed without passing the eval gate or notifying output-integrity-critical consumers. ATLAS: TA0006 Persistence. HCT: HCT.BadAction.017. - HCT.BadPermissions standing risk: inference-endpoint workload identity granted access to model registry write operations or to training data stores (HCT.BadPermissions.012); inference endpoint running with wildcard IAM policy (HCT.BadPermissions.001); these standing-IAM risks are cloud-native and outside ATLAS scope. - HCT.BadPrincipal standing risk: inference-endpoint service account with over-broad scope used by multiple workloads (HCT.BadPrincipal.002, .012); dormant or orphaned inference service accounts (HCT.BadPrincipal.003).

Model registry: - Unauthorized model upload (AML.T0010 ML Supply Chain Compromise), a principal outside the approved write-list pushes a model artifact containing a backdoor, malicious deserialization payload, or poisoned weights. ATLAS: TA0003 Initial Access; TA0006 Persistence. HCT: HCT.BadCode.005; HCT.BadPermissions.012. - Model artifact tampering, a model artifact already in the registry is modified post-upload by exploiting excessive write permissions or by a compromised pipeline principal. AML.T0010. HCT: HCT.BadAction.011; HCT.BadPermissions.012. - Credential theft for registry access, long-lived API keys or service account keys used for registry authentication are exfiltrated and used to pull model weights or push malicious artifacts. HCT: HCT.BadCode.002; HCT.BadPrincipal.001; HCT.BadPermissions standing risk: long-lived keys for registry access (no workload-identity-only enforcement). - Deletion / rollback abuse, a principal with delete permissions removes a production model version or forces a rollback to an older, vulnerable, or lower-performing model version. HCT: HCT.BadAction.007; HCT.BadPermissions.012.

GPU / accelerator fleet: - Cross-tenant residual-state leakage on shared GPUs, GPU memory not cleared between jobs from different tenants; a subsequent job reads residual activations, weights, or data from a prior tenant's computation. HCT: HCT.BadCode.007; HCT.BadPermissions.011. ATLAS: TA0010 Collection. - Scheduler abuse, a principal manipulates the job scheduler (priority, resource allocation, node affinity) to co-locate a hostile workload with a sensitive training job, enabling cache-side-channel attacks or data exfiltration. ATLAS: TA0007 Privilege Escalation. HCT: HCT.BadPrincipal.016; HCT.BadPermissions.005. - Training-job hijack (HCT.BadAction.010), a principal modifies a running training job's dataset URI, hyperparameters, or output artifact path; produces a backdoored or poisoned model without triggering the normal eval gate. ATLAS: AML.T0020; TA0004 Execution. HAI-TTP: RA. - GPU-firmware persistence (TA0006), a compromised training workload deploys firmware-level persistence in the GPU's management interface, surviving job reset and appearing benign to host-level security tooling. ATLAS: TA0006 Persistence; TA0005 Persistence. HCT: HCT.BadCode.006. - HCT.BadPermissions standing risk: scheduler-level permissions granted to non-MLOps principals (HCT.BadPermissions.005); GPU node groups accessible from development namespaces (HCT.BadPermissions.018).

Orchestrator / control plane: - Orchestrator credential abuse, the orchestrator's workload identity or API token is exfiltrated and used to submit fraudulent jobs, read pipeline secrets, or elevate privileges to connected data stores. HAI-TTP: EA. ATLAS: TA0008 Credential Access; TA0007 Privilege Escalation. HCT: HCT.BadPrincipal.006; HCT.BadPermissions.001. - Workflow injection, a malicious actor injects a step, modifies a pipeline definition, or substitutes a legitimate step with a hostile one; the orchestrator executes attacker-controlled logic under the pipeline's trusted identity. HAI-TTP: AGH. ATLAS: AML.T0051 (LLM Prompt Injection analog at the workflow level); TA0004 Execution. HCT: HCT.BadCode.003; HCT.BadCode.012. - Agent-state tampering, an attacker modifies the agent's in-flight state (memory, tool-call history, goal representation) stored in the orchestrator's state backend; redirects the agent's subsequent actions toward attacker-controlled outcomes. HAI-TTP: AGH, RA. ATLAS: TA0006 Persistence; TA0003 Initial Access. - Control-plane API abuse, the orchestrator's management API is reachable without authentication or with over-broad permissions; allows an attacker to list pipelines, trigger runs, modify schedules, or exfiltrate pipeline secrets. HAI-TTP: TM. ATLAS: TA0009 Discovery; TA0010 Collection. HCT: HCT.BadPermissions.018; HCT.BadCode.009. - HCT.BadPermissions standing risk: orchestrator API exposed without workload-identity authentication (HCT.BadPermissions.018); pipeline step granted ambient permissions broader than the step's function (HCT.BadPermissions.001).

Vector-store infrastructure: - Unauthorized read of corpus (AML.T0024 alt), a principal or inference-time workload reads embedding content or raw chunk text outside its authorized namespace; classified content leaks to lower-trust consumers. ATLAS: TA0010 Collection. HCT: HCT.BadPermissions.013; HCT.BadPermissions.006. - Embedding extraction at scale, a high-volume attacker uses the retrieval API to reconstruct source-document content by combining retrieved chunks or inverting embeddings via repeated queries. ATLAS: AML.T0024; TA0013 Exfiltration. HCT: HCT.BadAction.020. - Indexer abuse, a principal with write access to the ingest pipeline inserts attacker-controlled documents that contain prompt-injection payloads, influencing future retrievals for all consumers. HAI-TTP: AGH. ATLAS: AML.T0051; AML.T0020. HCT: HCT.BadCode.011; HCT.BadAction.018. - Retrieval-policy bypass, tenant-namespace isolation is missing or bypassable; a query from tenant A retrieves chunks indexed for tenant B. HCT: HCT.BadPermissions.013; HCT.BadCode.011. - HCT.BadPermissions standing risk: vector-store write and admin permissions granted to inference-time principals (HCT.BadPermissions.013); embedding query interface world-readable (HCT.BadPermissions.006).

AI-specific CI/CD: - Training-pipeline supply-chain compromise (AML.T0010), a dependency, base image, or dataset registry used by the training pipeline is compromised; malicious code executes during training and poisons the model output. ATLAS: TA0003 Initial Access; TA0006 Persistence. HCT: HCT.BadCode.004; HCT.BadCode.006; HCT.BadCode.003. - Poisoned-dependency injection, a package substitution (dependency confusion, typosquatting) injects attacker code into the training or evaluation environment. ATLAS: AML.T0010; TA0003. HCT: HCT.BadCode.004. - Model-promotion bypass, a principal pushes a model directly to the production registry or inference endpoint without passing the eval gate or the required approvals; backdoored or regressed models reach production silently. ATLAS: TA0008 Defense Evasion. HCT: HCT.BadCode.012; HCT.BadPermissions.012. - Eval-gate spoofing, a malicious pipeline step submits fabricated evaluation results to the eval gate, causing it to pass a model that would otherwise fail safety or quality checks. ATLAS: TA0008 Defense Evasion. HAI-TTP: RA. - Build-time SSRF (HCT.BadCode.010), CI builds that fetch dataset URLs or model checkpoints from user-influenced locations are exploited to reach cloud metadata endpoints and exfiltrate IAM credentials. - HCT.BadPrincipal standing risk: build runner with cloud credentials broader than the build scope (HCT.BadPrincipal.007); CI service account with model-registry write access from any branch (HCT.BadPermissions.012).

Feature store / online serving cache: - Feature poisoning, a principal with write access to the feature store or its offline pipeline inserts maliciously crafted feature values; inference using poisoned features produces attacker-influenced decisions. HAI-TTP: RA. ATLAS: AML.T0020; TA0006 Persistence. - Online/offline-skew abuse, an attacker manipulates the online serving cache to diverge from the offline training distribution; predictions degrade silently for targeted entities. ATLAS: TA0006 Persistence. - Unauthorized feature read, a principal retrieves feature values for entities (customer IDs, user profiles, financial accounts) it is not authorized to access; feature data may include sensitive attributes. ATLAS: TA0010 Collection. HCT: HCT.BadPermissions.013; HCT.BadPrincipal.002.

B) Produce a per-intake threat snapshot for every SM inventory registration

Bind TA into the SM intake flow, every new infrastructure asset registration emits a threat snapshot before the Sanctioned status is issued; Provisional-status assets receive a snapshot within five business days of registration.

Snapshot contents: - Which archetype(s) apply (an asset may be composite, e.g., an inference endpoint backed by a GPU fleet serving a vector-store RAG pattern). - Asset-specific deltas: workload tier hosted (Critical / High / Medium / Low per SM-Infrastructure L2); multi-tenancy isolation model; customer-exposure level; data classification of workloads hosted; geographic scope; decision-affecting use. - Top-5 threats for this asset, each with: HAI TTP tag, ATLAS tactic ID, HCT entry (BadCode / BadAction / BadPrincipal / BadPermissions root), compliance linkage, and controls already evident vs. gaps for SR/SA follow-up. - Reviewer, date, expiry (re-snapshot on workload-tier change, new tenant onboarded, network topology change, or major platform version upgrade).

Time target: ≤1 business day per intake with the library available.

C) Author the shadow-AI-in-infrastructure threat view

Shadow AI infrastructure, unsanctioned GPU instances spun up for experimentation, model registries created outside the governed platform, inference endpoints deployed from personal cloud accounts, has its own threat surface. Author a standalone shadow-AI-in-infrastructure threat document covering: - Entry vectors: untagged GPU instances in cloud spend; model-serving endpoints outside the monitored namespace; unsanctioned artifact registries in cloud accounts; training jobs submitted through personal credentials rather than governed service accounts. - Elevated threats for shadow assets: no threat model, no SR requirements pack, no SR REM, no eval gate; deployer-duty evidence trail is unmet. - Detections available at L1: cloud-spend signals (untagged GPU/TPU usage, unexpected API endpoints); DNS/network signals (outbound from compute to known ML model hosting domains not in the allow-list); IAM signals (personal credentials used for model API calls).

Output: a "Shadow AI in Infrastructure, Threat View" one-pager reviewed by the program sponsor and feeding the ML-Infrastructure detection backlog and the IM-Infrastructure triage playbook.

Outcome Metrics (L1)

Process Metrics (leading)

• Threat library review cadence, quarterly archetype refresh recorded; no quarter with zero updates.
• New-archetype lead time, from "first intake in new infra category" to "archetype model published" ≤30 days.
• Snapshot-to-SR linkage, % of snapshots whose top-5 threats are referenced by at least one downstream SR-Infrastructure requirement.
• Library steward named and active, single owner, not a committee.

Effectiveness Metrics (business value)

• Threats that converted to prevented incidents, cases where a snapshot-identified threat caused a control to be added before production landing (e.g., GPU residual-state clearing added after GPU-fleet snapshot flagged cross-tenant leakage; registry write-list enforced after model-registry snapshot flagged unauthorized upload risk).
• Reviewer consistency, EG-Infrastructure calibration exercises use live threat snapshots; inter-reviewer threat-identification drift stays within target.
• Downstream reuse, SR, SA, ST artifacts cite snapshot threats in ≥80% of cases rather than re-deriving independently.

Success Criteria

• Seven archetype threat models published (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each tagged to HAI TTPs, ATLAS tactic IDs, HCT entries, and the PC-Infrastructure priority compliance map.
• Threat snapshot gate live in the SM intake flow, 100% of newly Sanctioned AI/HAI infrastructure assets in the last 90 days have a snapshot attached.
• Shadow-AI-in-infrastructure threat view published, reviewed by the program sponsor, and feeding the ML-Infrastructure detection backlog.
• Named library steward and quarterly refresh cadence operating.
• ≥90% of active AI/HAI infrastructure assets in the inventory carry a current-year snapshot.

Maturity Level 2

Objective: Layer per-asset deep threat models on top of archetype snapshots for Critical-tier infrastructure assets, integrate external AI infrastructure threat intelligence, and red-team the threat library quarterly against novel real-world attack patterns

At this level, threat assessment stops being "snapshot plus go" for high-stakes infrastructure assets. Critical-tier assets (per SM-Infrastructure L2's risk-tier rubric) receive full per-asset deep threat models with cloud-tactic walks using the per-cloud TM templates. External threat intel (MITRE ATLAS updates, AVID, CNCF AI security advisories, OpenSSF AI, cloud-provider security bulletins) is wired in and triaged quarterly. The library is stress-tested by running a quarterly red-team probe against real in-scope infrastructure to surface what the library catches and what it misses.

Dependencies

• TA-Infrastructure L1 (required): archetype threat library and per-intake snapshot gate.
• SM-Infrastructure L2 (required): the risk-tier rubric (Critical / High / Medium / Low, based on workload tier hosted, multi-tenancy isolation, customer-exposure, compute scale/concentration, data classification, decision-affecting use, geographic scope) determines where per-asset deep modeling is required.
• ST-Infrastructure L2 (required for red-team-the-library activity): the red-team capability to probe real infrastructure comes from ST.
• Supports / unblocks: SR-Infrastructure L2 (per-tier threat depth drives per-tier requirements), SA-Infrastructure L2 (threat depth drives pattern complexity), DR-Infrastructure L2 (scenario-based design reviews need per-asset models), ML-Infrastructure L2 (detections tuned to per-asset threats).

Desired Outcomes

• Every Critical-tier AI/HAI infrastructure asset has a current-year per-asset deep threat model using the cloud-tactic walk template, not a recycled archetype snapshot.
• High-tier assets receive archetype snapshot plus asset-specific deltas and a full cloud-tactic walk; no High-tier asset on archetype-only.
• External AI infrastructure security threat intel is routinely consumed and reflected in the library; the library is not frozen at publication time.
• The library is proved against reality, quarterly red-team exercises show what it catches and misses; gaps are closed with owners and expiry dates.
• Per-tier threat-assessment depth is visibly differentiated, matching the SM-Infrastructure L2 tier-treatment matrix.

Activities

A) Per-asset deep threat modeling for Critical-tier assets

For every Critical-tier infrastructure asset in the SM inventory, produce a full per-asset threat model covering: - Cloud-tactic walk using per-cloud TM template (AWS / GCP / Azure): all ATLAS tactics enumerated for the specific cloud platform; cloud-native techniques from the HCT taxonomy mapped to the asset's IAM posture, network placement, and workload configuration. - HCT four-root deep analysis: for the specific asset, enumerate BadCode, BadAction, BadPrincipal, and BadPermissions risks in the current configuration; identify standing-IAM risks (HCT.BadPermissions.) that ATLAS does not enumerate but that represent significant exposure. - Abuse-case catalog: named adversary archetypes (external attacker, malicious insider, compromised CI/CD runner, compromised vendor supply chain) with concrete attack narratives for this specific asset. - Deployer-duty mapping:* EU AI Act Art. 26 obligations mapped to the threat-control chain for this specific infrastructure asset (Art. 15 accuracy/robustness/cybersecurity requirements for the workloads it hosts). - Refresh cadence: Critical semi-annual plus change-driven (platform upgrade, new tenant onboarded, network topology change, tier reclassification); High annual plus change-driven.

B) External AI infrastructure threat intelligence integration

Subscribe to and operationalize: - MITRE ATLAS updates (new technique additions relevant to ML infrastructure). - AVID (AI Vulnerability Database), infrastructure-related vulnerability entries. - CNCF AI security working group advisories (Kubernetes AI workload security, container isolation). - OpenSSF AI, supply-chain security advisories for ML dependencies, model formats, and CI/CD tooling. - Cloud-provider security bulletins (AWS Security Bulletins, Google Cloud Security Advisories, Microsoft Security Response Center) for services hosting AI workloads (SageMaker, Vertex AI, Azure ML, Bedrock, EKS/GKE/AKS). - Academic and practitioner publications on GPU security, side-channel attacks on ML hardware, and orchestrator-level vulnerabilities.

Quarterly triage cadence: which new intel items change the archetype library, change per-asset models, or change SR or ST artifacts that depend on the library.

C) Red-team the threat library itself

Each quarter, ST-Infrastructure runs an adversarial probe against an in-scope AI/HAI infrastructure asset using ONLY the threat scenarios documented in the library for that archetype. Threats the red-team exercise identifies that are NOT in the library are library gaps, not passing findings.

Gap closure: every gap becomes a ticket with a named owner and an expiry date; Critical-tier gaps close within 30 days; High-tier gaps within 60 days. Gaps are reviewed for SR and ST update implications.

Outcome Metrics (L2)

Process Metrics (leading)

• Library change-log cadence, no quarter with zero changes.
• Per-asset deep model age, no Critical model older than 180 days; no High model with archetype snapshot alone.
• Red-team-the-library exercise cadence, at least quarterly; exercise artifact on file.
• Gap closure SLA tracked; no Critical gap open past 30 days.

Effectiveness Metrics (business value)

• Incidents caught by pre-existing library entries vs. library gaps, ratio trends toward pre-existing over time.
• Downstream reuse at tier, SR, SA, DR, ST artifacts for Critical-tier assets cite per-asset threats rather than generic archetype content.
• Library becomes a named internal resource, platform engineers and MLOps architects consult it before provisioning new AI infrastructure.

Success Criteria

• Per-asset deep threat models live for 100% of Critical-tier and ≥90% of High-tier assets, with refresh cadence met.
• External threat intel integrated with quarterly triage and documented change-log.
• Quarterly red-team-the-library exercise operating; gaps closed with named owners and expiry dates.
• Intel-to-library update lead time ≤30 days on Critical-impact items.

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered AI/HAI infrastructure TTPs back to MITRE ATLAS, AVID, CNCF AI, and OpenSSF AI

At this level, the threat library is self-updating. Telemetry from ML-Infrastructure detections and incident patterns from IM-Infrastructure, combined with external signal feeds (ATLAS, AVID, CNCF, OpenSSF AI, cloud-provider bulletins), auto-propose library updates; human curators review and approve. The program contributes emerging first-party-observed infrastructure TTPs to MITRE ATLAS, AVID, CNCF AI working groups, and OpenSSF AI, making the org a net contributor to the AI infrastructure security knowledge base.

Dependencies

• TA-Infrastructure L2 (required): per-asset models and external intel integration must be operational before automation is trustworthy.
• ML-Infrastructure L2+ (required): the detection telemetry that proposes library updates comes from the monitoring pipeline.
• IM-Infrastructure L2+ (required): incident pattern data feeds update proposals for threat actors, TTPs, and impact scenarios.

Desired Outcomes

• Library staleness is measured in weeks, not quarters, material new attack patterns reach the library within 14 days of first observation in external feeds or internal telemetry.
• Program-sourced infrastructure TTPs appear in MITRE ATLAS, AVID, CNCF AI security advisories, and OpenSSF AI, the org is cited as a practitioner contributor.
• External threat-landscape shifts are reflected in the library before most peers who lack an automated signal pipeline.

Activities

A) Telemetry-driven library updates

Wire the following signal sources into an auto-proposal pipeline: - ML-Infrastructure detections, alert patterns that do not map to any existing library entry are surfaced as candidate new threats. - IM-Infrastructure incident records, post-incident review records generate structured threat updates. - External feeds, ATLAS technique additions, AVID new entries, CNCF AI security advisories, OpenSSF AI bulletins, cloud-provider security bulletins. - GPU / hardware security publications, side-channel attack papers, firmware security research.

Human curators approve, reject, or defer each auto-proposal. Change-log is machine-readable; downstream SR, SA, ST artifacts subscribe to the change feed for update-required notifications.

B) Industry contribution

Contribute to: - MITRE ATLAS, new techniques observed in own-operated AI infrastructure (GPU residual-state variants, orchestrator injection mechanics, inference-API exfiltration patterns); submissions follow ATLAS evidence-and-provenance requirements. - AVID, structured disclosure submissions for newly discovered infrastructure vulnerabilities. - CNCF AI working groups, security guidance for AI workload isolation in Kubernetes; contribute threat models for AI-specific admission control and namespace isolation. - OpenSSF AI, supply-chain security requirements for ML pipeline dependencies, model artifact signing, and build provenance.

Target: minimum 4 substantive contributions per year; quality-graded and legally vetted before submission; every contribution anonymized.

C) Shared threat-model artifacts

Publish anonymized archetype threat models under a permissive license. Host or co-host at least one industry tabletop per year tied to the library (ATLAS practitioner table, CNCF AI security working group, OpenSSF AI chapter, or cloud-provider ISAC AI working group).

Outcome Metrics (L3)

Process Metrics (leading)

• Auto-proposal pipeline health, ≥1 actionable auto-proposal per week; staleness alert if feed silent for 7 days.
• Contribution pipeline always ≥2 in-flight (draft, in-review, or being prepared).
• External tabletop cadence, at least 1 per year.
• Library change-log machine-readable and consumed by at least one downstream practice (SR or ST) for auto-update notifications.

Effectiveness Metrics (business value)

• Program cited in industry advisories as a practitioner contributor to ATLAS / AVID / CNCF / OpenSSF AI.
• Time-to-defend shrinks for library-sourced threats.
• Talent signal, AI infrastructure security engineers are attracted by the program's external profile.

Success Criteria

• Library auto-update pipeline operating with ≤14-day lead time from signal to update.
• ≥4 industry contributions per year; ≥2 recognized in external artifacts.
• Anonymized archetype threat models published under permissive license with tracked adoption.
• Industry tabletop hosted or co-hosted in last 12 months.

Key Success Indicators

Level 1: - Seven archetype threat models published (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and the PC-Infrastructure priority compliance map. - Threat snapshot gate live in the SM intake flow, 100% of newly Sanctioned AI/HAI infrastructure assets in the last 90 days have a snapshot attached before Sanctioned status is issued. - Each snapshot documents: archetype(s), asset-specific deltas (workload tier, tenant isolation model, data classification, geographic scope), top-5 threats with HAI TTP tags, ATLAS tactic IDs, and HCT roots, and gaps for SR/SA follow-up. - Shadow-AI-in-infrastructure threat view published, reviewed by the program sponsor, and linked to the ML-Infrastructure detection backlog and the IM-Infrastructure triage playbook. - Named library steward, quarterly refresh cadence, and ≥90% of active AI/HAI infrastructure assets carrying a current-year snapshot.

Level 2: - Per-asset deep threat models live for 100% of Critical-tier assets and ≥90% of High-tier assets, with refresh cadence (Critical semi-annual, High annual) met and cloud-tactic walks using per-cloud TM templates. - External AI infrastructure security threat intel (ATLAS, AVID, CNCF, OpenSSF AI, cloud-provider bulletins) integrated with quarterly triage and a documented change-log; intel-to-library update ≤30 days for Critical-impact items. - Quarterly red-team-the-library exercise operating; every gap closed with a named owner and expiry date; Critical gaps ≤30 days, High gaps ≤60 days.

Level 3: - Library auto-update pipeline operating with ≤14-day lead time; ≥60% of changes auto-proposed; change-log machine-readable and consumed by downstream SR and ST practices. - ≥4 substantive industry contributions per year to MITRE ATLAS / AVID / CNCF AI / OpenSSF AI, with ≥2 externally recognized. - Anonymized archetype threat models published under permissive license with tracked peer-org adoption; at least one industry tabletop hosted or co-hosted annually.

Common Pitfalls

Level 1: - ❌ Threat models describe "the AI" as the actor performing security work (v2.0 framing) rather than describing the infrastructure asset as the subject being assessed, the library ends up cataloging what AI tools do rather than what threats face the infra the org operates. - ❌ Archetype library treats all seven infrastructure archetypes as variations of "cloud compute"; GPU-specific threats (residual-state leakage, firmware persistence, scheduler abuse) and orchestrator-specific threats (workflow injection, agent-state tampering) are not separately enumerated. - ❌ HCT threat roots are not walked alongside ATLAS, standing-IAM risks (HCT.BadPermissions) and identity misuse (HCT.BadPrincipal) are missed because ATLAS does not enumerate them; the threat snapshot is incomplete for cloud-native threats. - ❌ Threat snapshot is a checklist checkbox with no asset-specific deltas, the workload tier hosted, multi-tenancy isolation model, and data classification are not reflected, making the snapshot useless for SR and SA follow-through. - ❌ Library steward is unnamed, "the platform security team owns it", so the quarterly refresh calendar item is no one's job and the library drifts from current attack research within two quarters. - ❌ Shadow-AI-in-infrastructure threat view is omitted because "all compute is provisioned through IaC", the entry vector for untagged GPU instances in cloud accounts is not modeled.

Level 2: - ❌ "Per-asset deep model" is the archetype snapshot with the asset name swapped in, no cloud-tactic walk, no HCT four-root analysis, no asset-specific IAM posture review; the depth is cosmetic. - ❌ External intel is subscribed but never triaged, cloud-provider security bulletins pile up unread; the library is frozen at L1 publication while GPU-firmware CVEs and orchestrator-level vulnerabilities accumulate. - ❌ Red-team-the-library exercise is a penetration test that adds findings to a finding log but never cross-checks against the library, gaps are never surfaced because the comparison was never made. - ❌ Critical-tier accepted gaps from the library red-team lack owners or expiry dates, gap backlog grows without accountability. - ❌ Deep modeling stops at Critical; High-tier assets (e.g., shared GPU fleets hosting regulated training workloads) remain on archetype-only snapshots.

Level 3: - ❌ Auto-proposal pipeline accepts signals without curation, false-positive detections from ML-Infrastructure pollute the library with phantom threats; downstream SR and ST artifacts generate incorrect requirements and tests. - ❌ "Contributions" to ATLAS/AVID/CNCF are observer submissions (conference talks, mailing-list comments) rather than technical artifacts with evidence, they appear in the contribution log but produce no substantive change. - ❌ Published anonymized archetype models are not maintained after release, external adopters build on a stale version; the gap becomes an embarrassment when discrepancies are cited. - ❌ Telemetry-driven update loop fires on every routine infrastructure change, overwhelming the curation queue, teams disable telemetry rather than tune signal sensitivity.

Practice Maturity Questions

Level 1: 1. Are there published, versioned threat models for all seven AI/HAI infrastructure archetypes (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infra, AI-specific CI/CD, feature store), each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and PC-Infrastructure compliance items, with a named library steward and a documented quarterly refresh cadence? 2. Does every AI/HAI infrastructure asset entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents: the applicable archetype(s), asset-specific deltas (workload tier hosted, multi-tenancy isolation model, customer-exposure, data classification, geographic scope), top-5 threats with HAI TTP tags, ATLAS tactic IDs, and HCT roots, and gaps for SR/SA follow-up, with 100% of newly Sanctioned assets carrying a snapshot in the last 90 days? 3. Is there a published shadow-AI-in-infrastructure threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors (untagged GPU instances, unsanctioned registries, personal-credential-based model deployments), elevated threat scenarios for unreviewed infrastructure assets, and the specific detections (from SM discovery sources) used to surface them?

Level 2: 1. Does every Critical-tier AI/HAI infrastructure asset have a current-year per-asset deep threat model (not an archetype snapshot) covering a cloud-tactic walk using the per-cloud TM template, a full HCT four-root analysis for the asset's current IAM posture and network placement, an abuse-case catalog with named adversary archetypes, and deployer-duty mapping, with a semi-annual refresh cadence and change-driven updates on platform upgrade, new tenant onboarding, or network topology change? 2. Is external AI infrastructure threat intel (MITRE ATLAS updates, AVID, CNCF AI security advisories, OpenSSF AI, cloud-provider security bulletins) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? 3. Do you run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI infrastructure asset using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and an expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter?

Level 3: 1. Does the threat library auto-update from telemetry (ML-Infrastructure detections, IM-Infrastructure incidents) and external feeds (ATLAS, AVID, CNCF, OpenSSF AI, cloud-provider bulletins) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? 2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / CNCF AI / OpenSSF AI, with at least two externally recognized in published advisory, standard revision, or community guidance? 3. Are anonymized archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, CNCF AI security working group, OpenSSF AI chapter, or cloud-provider ISAC AI working group) tied to the library?

Document Version: HAIAMM v3.0 Practice: Threat Assessment (TA) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai