Threat Assessment (TA) - Infrastructure Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

Source of truth: ../practices/TA-Infrastructure-OnePager.md | ../HAIAMM-v3.0-Framing.md §8 (HAI TTPs), §10.1 (ATLAS), §14.5 (ATLAS tactic taxonomy)

Threat Assessment (TA) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Threat Assessment (TA) Domain: Infrastructure Purpose: Assess organizational maturity in building and maintaining a reusable threat library for the infrastructure that hosts and serves AI/HAI systems, covering all seven infrastructure archetypes mapped to HAI TTPs, ATLAS tactics (TA0001–TA0014), and the HAIAMM Cloud Threat Taxonomy (HCT) roots (BadCode, BadAction, BadPrincipal, BadPermissions) Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively, complete all Level 1 questions before Level 2
Level progression, achieve ALL questions at lower level before advancing
Baseline first, record current metric values before setting targets
Subject framing, the infrastructure asset is the subject being assessed; the threat library describes what threatens the asset, not what the asset does for security

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	All evidence items present AND ≥3 outcome metrics meet targets
0.67	Implemented	All evidence items present AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete OR fewer than 2 metrics meet targets
0.0	Not Implemented	No substantive evidence of the activity

Level Score = average of the three question scores at that level Practice Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2 (L2/L3 only scored if L1 = Fully Mature)

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.

Question 1: Build the AI/HAI infrastructure archetype threat library

Q1.1: Does the organization have a published, versioned threat library containing one threat model per AI/HAI infrastructure archetype, covering all seven archetypes (inference endpoint/model-serving cluster, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store/online serving cache), with each archetype's threats tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs (TA0001–TA0014) and technique IDs where applicable, HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions), and the PC-Infrastructure priority compliance map, owned by a named library steward with a documented quarterly refresh cadence?

Evidence Required: - [ ] Threat library document exists, is versioned, and names a single library steward responsible for quarterly refresh - [ ] All seven archetype models published: inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store infrastructure, AI-specific CI/CD, feature store/online serving cache, each scoped to infrastructure the org operates to host AI systems - [ ] Inference endpoint archetype covers: model extraction via inference API (AML.T0024/TM), denial-of-service/prompt-flood (TA0014), cross-tenant isolation breach (HCT.BadPermissions.011/BadCode.017), lateral movement from compromised endpoint (EA/TA0007), model swap/silent version flip (TA0006), HCT.BadPermissions and HCT.BadPrincipal standing risks - [ ] Model registry archetype covers: unauthorized model upload (AML.T0010/TA0003), model artifact tampering (AML.T0010/HCT.BadAction.011), credential theft for registry access (HCT.BadCode.002), deletion/rollback abuse (HCT.BadAction.007) - [ ] GPU/accelerator fleet archetype covers: cross-tenant residual-state leakage (HCT.BadCode.007/TA0010), scheduler abuse (TA0007/HCT.BadPrincipal.016), training-job hijack (RA/HCT.BadAction.010/AML.T0020), GPU-firmware persistence (TA0006/HCT.BadCode.006) - [ ] Orchestrator archetype covers: orchestrator credential abuse (EA/TA0008/HCT.BadPrincipal.006), workflow injection (AGH/AML.T0051 analog/TA0004/HCT.BadCode.003), agent-state tampering (AGH+RA/TA0006), control-plane API abuse (TM/TA0009/HCT.BadPermissions.018) - [ ] Vector-store archetype covers: unauthorized corpus read (AML.T0024 alt/TA0010), embedding extraction at scale (AML.T0024/TA0013), indexer abuse inserting injection payloads (AGH/AML.T0051/AML.T0020), retrieval-policy bypass (HCT.BadPermissions.013) - [ ] AI-specific CI/CD archetype covers: training-pipeline supply-chain compromise (AML.T0010/TA0003), poisoned-dependency injection (AML.T0010), model-promotion bypass (TA0008/HCT.BadCode.012), eval-gate spoofing (RA/TA0008), build-time SSRF (HCT.BadCode.010) - [ ] Each archetype walks ATLAS tactics (TA0001–TA0014) AND HCT four roots; exclusions explicit with rationale; standing-IAM risks (HCT.BadPermissions.*) noted separately

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI infrastructure assets in SM inventory with a current-year threat snapshot | measure | % | 100% for Sanctioned; ≥90% for all | ☐ | | | Archetype coverage (infra archetypes with a published threat model) | 0 / 7 | ___ / 7 | 7 / 7 | ☐ | | | Median snapshot turnaround from SM intake to threat snapshot delivery | measure | ___ | ≤1 business day | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP, ATLAS tactic ID, and HCT root | measure | % | 100% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Count infrastructure assets in SM inventory with a TA snapshot dated within the current calendar year divided by total active assets. Source: SM inventory × TA snapshot registry - Archetype coverage: Count distinct published archetype models for the seven infrastructure archetypes. Target is 7/7 before intake gates go live - Snapshot turnaround: Median elapsed time from SM infrastructure asset intake registration to threat snapshot delivery. Source: intake workflow telemetry - TTP/tactic/HCT tagging rate: For each snapshot, confirm top-5 threats each carry a HAI TTP tag, an ATLAS tactic ID, and an HCT root (BadCode/BadAction/BadPrincipal/BadPermissions). Source: snapshot metadata fields

Answer: - ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets) - ☐ Implemented (Evidence complete + 2 metrics meet targets) - ☐ Partial (Evidence partially complete + <2 metrics meet targets) - ☐ Not Implemented (No evidence of infrastructure archetype threat library)

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 2: Produce a per-intake threat snapshot for every SM infrastructure asset registration

Q2.1: Is a threat snapshot produced for every AI/HAI infrastructure asset registering in the SM inventory, delivered within one business day of intake for Sanctioned assets, documenting the applicable archetype(s), asset-specific deltas (workload tier hosted, multi-tenancy isolation model, customer-exposure level, data classification, geographic scope, decision-affecting use), top-5 threats with HAI TTP tags, ATLAS tactic IDs, HCT roots, compliance linkage, and controls evident vs. gaps for SR/SA follow-up, with 100% of newly Sanctioned assets in the last 90 days carrying a snapshot before Sanctioned status is issued?

Evidence Required: - [ ] Snapshot gate is bound to the SM infrastructure intake flow: Sanctioned status cannot be issued without a snapshot attached - [ ] Snapshot template includes: archetype(s), asset-specific deltas (workload tier, multi-tenancy isolation model, customer-exposure, data classification, geographic scope, decision-affecting use), top-5 threats with HAI TTP tags, ATLAS tactic IDs, HCT roots, compliance linkage, controls evident, gaps - [ ] Asset-specific deltas populated per snapshot, reviewers adapt archetype content; workload tier, tenant configuration, and network placement are reflected - [ ] Snapshot expiry rules documented: re-snapshot triggers include workload-tier change, new tenant onboarded, network topology change, major platform version upgrade - [ ] 100% of newly Sanctioned AI/HAI infrastructure assets in the last 90 days have a snapshot attached (sample audit evidence on file) - [ ] ≥90% of all active infrastructure assets in the SM inventory carry a current-year snapshot

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI infrastructure assets in SM inventory with a current-year threat snapshot | measure | % | 100% for Sanctioned; ≥90% for all | ☐ | | | Median snapshot turnaround from SM intake to threat snapshot delivery | measure | ___ | ≤1 business day | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP, ATLAS tactic ID, and HCT root | measure | % | 100% | ☐ | | | Snapshot-to-SR linkage rate (snapshots whose top-5 threats referenced by ≥1 SR-Infrastructure requirement) | measure | ___% | ≥80% | ☐ | |

Metric Collection Guidance: - Snapshot coverage: Same as Q1, current-year snapshots divided by active infrastructure assets - Turnaround: Median time from SM intake open to snapshot delivered; measure weekly - Tagging rate: Per-snapshot check, each of the top-5 threats must have TTP, ATLAS tactic ID, and HCT root fields populated - SR linkage: After SR-Infrastructure L1 is operational, cross-reference snapshot threat IDs against SR requirements. Track % of snapshots with ≥1 SR-Infrastructure cross-reference

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 3: Author the shadow-AI-in-infrastructure threat view

Q3.1: Is there a published shadow-AI-in-infrastructure threat view, reviewed by the program sponsor within the last 12 months, that documents entry vectors for unsanctioned AI infrastructure (untagged GPU instances in cloud accounts, model-serving endpoints outside the monitored namespace, unsanctioned artifact registries, training jobs via personal credentials), elevated threats for shadow assets (no threat model, no SR requirements pack, no eval gate, deployer-duty evidence trail unmet), and the L1 detections available (cloud-spend signals for untagged GPU/TPU usage, DNS/network signals to ML model hosting domains outside the allow-list, IAM signals for personal credential use in model API calls)?

Evidence Required: - [ ] "Shadow AI in Infrastructure, Threat View" document exists, is dated, and names the reviewer (program sponsor or delegate) - [ ] Document covers 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 documented: no threat model, no SR requirements pack, no eval gate; deployer-duty evidence trail unmet; HCT.BadPrincipal risks elevated (personal credentials, no workload identity) - [ ] Specific failure modes named: untagged GPU instance running a fine-tune job with no model review; inference endpoint deployed from a personal cloud account with no DPA or no-train verification - [ ] L1 detections documented: 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) - [ ] Document feeds ML-Infrastructure detection backlog and IM-Infrastructure triage playbook (links on file) - [ ] Shadow-AI-in-infrastructure threat view published and reviewed in last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Shadow-AI-in-infrastructure threat view published and reviewed in last 12 months | n/a | Yes/No | Yes | ☐ | | | % of snapshot top-5 threats tagged to a HAI TTP, ATLAS tactic ID, and HCT root | measure | % | 100% | ☐ | | | Archetype coverage (infra archetypes with a published threat model) | 0 / 7 | ___ / 7 | 7 / 7 | ☐ | | | Downstream reuse rate (SR, SA, ST artifacts citing snapshot threats vs. re-deriving) | measure | % | ≥80% | ☐ | |

Metric Collection Guidance: - Shadow threat view currency: Confirm document exists with review date within last 12 months and program-sponsor approval record - Tagging rate: Same measurement source as Q1/Q2 - Archetype coverage: Same 7/7 metric as Q1 - Downstream reuse: Sample 10 recent SR-Infrastructure, SA-Infrastructure, or ST-Infrastructure artifacts and check whether threats trace back to snapshot top-5 entries

Evidence Location: _____ Validation Date: ____ Notes: ______

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.

Question 4: Per-asset deep threat modeling for Critical-tier infrastructure assets

Q4.1: Does every Critical-tier AI/HAI infrastructure asset in the SM inventory have a current-year per-asset deep threat model, not a recycled archetype snapshot, covering a cloud-tactic walk using the per-cloud TM template (AWS/GCP/Azure), a full HCT four-root deep analysis (BadCode/BadAction/BadPrincipal/BadPermissions for the specific asset's IAM posture and network placement), a named-adversary abuse-case catalog, EU AI Act Art. 26 deployer-duty mapping, and all 14 ATLAS tactics enumerated with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on platform upgrade, new tenant onboarded, or network topology change?

Evidence Required: - [ ] Per-asset deep threat models exist for 100% of Critical-tier infrastructure assets; model age does not exceed 180 days for any Critical-tier asset - [ ] Per-asset models contain a cloud-tactic walk using the per-cloud TM template (AWS/GCP/Azure as applicable); cloud-native techniques from the HCT taxonomy mapped to the asset's current IAM posture, network placement, and workload configuration - [ ] HCT four-root deep analysis for the specific asset: BadCode risks (insecure code patterns), BadAction risks (unauthorized or anomalous actions), BadPrincipal risks (identity misuse, over-privileged identities), BadPermissions risks (standing-IAM exposure), all enumerated for current configuration - [ ] Abuse-case catalog names adversary archetypes (external attacker, malicious insider, compromised CI/CD runner, compromised vendor supply chain) with concrete attack narratives for this specific asset - [ ] EU AI Act Art. 26 deployer-duty mapping covers Art. 15 (accuracy/robustness/cybersecurity requirements for hosted workloads) for this specific infrastructure asset - [ ] Full ATLAS tactic walk: all 14 tactics enumerated; technique IDs assigned; exclusions with rationale on record - [ ] High-tier assets carry archetype snapshot + asset-specific deltas + cloud-tactic walk (no High-tier asset on archetype snapshot alone) - [ ] Refresh cadence: Critical semi-annual + change-driven; High annual + change-driven; cadence compliance tracked

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier infrastructure assets with current-year per-asset deep threat model | measure | % | 100% | ☐ | | | % High-tier assets with archetype snapshot + asset-specific deltas + cloud-tactic walk | measure | % | ≥90% | ☐ | | | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | | | Threat-library change lead time from intel signal to library update | measure | ___ days | ≤30 days for Critical-impact items | ☐ | |

Metric Collection Guidance: - Critical-tier coverage: Count Critical-tier infrastructure assets with a per-asset deep model dated within 180 days divided by all Critical-tier assets - High-tier coverage: Count High-tier assets with archetype snapshot + deltas + cloud-tactic walk divided by all High-tier assets - Intel triage cadence: Count completed quarterly intel triage sessions in last 12 months. Each session must produce a triage log artifact - Change lead time: For each Critical-impact item in the last four quarters, calculate days from receipt to library update. Compute median and P90

Answer: - ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets) - ☐ Implemented (Evidence complete + 2 metrics meet targets) - ☐ Partial (Evidence partially complete + <2 metrics meet targets) - ☐ Not Implemented (No per-asset deep models for Critical-tier infrastructure assets)

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 5: External AI infrastructure threat intelligence integration

Q5.1: Is external AI infrastructure threat intelligence, covering MITRE ATLAS technique updates relevant to ML infrastructure, AVID infrastructure-related vulnerability entries, CNCF AI security working group advisories, OpenSSF AI supply-chain security advisories, cloud-provider security bulletins (AWS/GCP/Azure for SageMaker/Vertex AI/Azure ML/EKS/GKE/AKS), and academic/practitioner publications on GPU security and orchestrator vulnerabilities, subscribed to and operationalized with a quarterly triage cadence producing a documented change-log, with intel-to-library update ≤30 days on Critical-impact items?

Evidence Required: - [ ] Subscriptions active for all six intelligence sources: MITRE ATLAS, AVID, CNCF AI security working group, OpenSSF AI, cloud-provider security bulletins (AWS/GCP/Azure), academic GPU and orchestrator security publications - [ ] Quarterly triage cadence documented: triage session records showing date, intel items reviewed, triage decisions with library impact assessment - [ ] Documented change-log with entries keyed to intel source, item date, impact assessment, library update record, and steward sign-off - [ ] Change-log reviewed by the library steward and the IM backlog owner each quarter - [ ] Intel-to-library update lead time ≤30 days for Critical-impact items: evidence from change-log timestamps - [ ] No quarter in the last 12 months with zero library changes

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | | | Threat-library change lead time from intel signal to library update | measure | ___ days | ≤30 days for Critical-impact items | ☐ | | | Library gaps discovered per quarter (red-team exercises) | measure | tracked | trending down | ☐ | | | % Critical-tier infrastructure assets with current-year per-asset deep threat model | measure | ___% | 100% | ☐ | |

Metric Collection Guidance: - Triage cadence: Count triage session records in the last 12 months. Each session must produce a triage log artifact referencing cloud-provider bulletin and ATLAS technique IDs reviewed - Change lead time: For each Critical-impact item in the last four quarters, calculate days from receipt to library update. Compute median and P90 - Library gaps: From red-team exercise output, count infrastructure threats identified not present in the library for that archetype. Track per quarter - Critical-tier coverage: Same metric as Q4

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 6: Red-team the threat library itself

Q6.1: Does the organization run a quarterly red-team-the-library exercise, where ST-Infrastructure probes an in-scope AI/HAI infrastructure asset using only threat scenarios documented in the library for that archetype, surfaces all unmatched findings as library gaps rather than passing results, and closes every gap with a named owner and expiry date (Critical gaps within 30 days, High within 60 days), with the gap rate trending down quarter over quarter?

Evidence Required: - [ ] Quarterly red-team-the-library exercise on file: exercise records show date, infrastructure asset probed, archetype used, library version, probe scenarios drawn exclusively from library, and unmatched findings enumerated - [ ] Gap log maintained: every unmatched finding becomes a ticket with a named owner and expiry date - [ ] Critical-tier gap closure SLA enforced: no Critical gap open past 30 days (audit evidence on file) - [ ] High-tier gap closure SLA: no High gap open past 60 days - [ ] Gap rate tracked per quarter and documented as trending down - [ ] Gaps reviewed for SR-Infrastructure and ST-Infrastructure update implications

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Library gaps discovered per quarter (red-team exercises) | measure | tracked | trending down | ☐ | | | % Critical-tier infrastructure assets with current-year per-asset deep threat model | measure | % | 100% | ☐ | | | % High-tier assets with archetype snapshot + asset-specific deltas + cloud-tactic walk | measure | % | ≥90% | ☐ | | | External intel triage cadence met (quarterly) | measure | ___ / year | 4 / year | ☐ | |

Metric Collection Guidance: - Library gap rate: Count library gaps logged per quarter from red-team exercises. Plot trend; expect initial rise then sustained decline - Gap closure SLA: Verify no Critical gap exceeded 30 days from creation to closure in the last four quarters - Critical-tier and High-tier coverage: Same metrics as Q4 - Intel triage cadence: Same metric as Q5

Evidence Location: _____ Validation Date: ____ Notes: ______

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.

Question 7: Telemetry-driven library updates

Q7.1: Does the threat library auto-update from an integrated signal pipeline, consuming ML-Infrastructure detection alert patterns, IM-Infrastructure post-incident ATLAS tactic walks, ATLAS technique additions, AVID new entries, CNCF AI security advisories, OpenSSF AI bulletins, cloud-provider security bulletins, and GPU/hardware security publications, via human-curator approval workflow, with ≥60% of changes auto-proposed, ≤14-day lead time from signal to update, and a machine-readable change-log subscribed to by downstream SR and ST practices?

Evidence Required: - [ ] Auto-proposal pipeline operational: ML-Infrastructure detections and IM-Infrastructure incident ATLAS walks generate structured candidate threat entries surfaced to the curation queue - [ ] External feed ingestion active: ATLAS, AVID, CNCF AI security advisories, OpenSSF AI bulletins, cloud-provider security bulletins, GPU/hardware security publications all feeding the pipeline - [ ] Human-curator workflow implemented: curators approve, reject, or defer each auto-proposal with decision rationale on record - [ ] ≥60% of library changes in the last 12 months were auto-proposed - [ ] Change-log is machine-readable; downstream SR-Infrastructure and ST-Infrastructure practices subscribe and receive update-required notifications - [ ] Lead time from signal to library update ≤14 days: change-log timestamps support this claim

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Library change lead time from telemetry / external signal to update | measure | ___ days | ≤14 days | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | | | Industry contributions per year (MITRE ATLAS / AVID / CNCF / OpenSSF AI) | 0 | ___ | ≥4 | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | |

Metric Collection Guidance: - Change lead time: Measure days from signal timestamp to library commit. Focus on cloud-provider bulletins and ATLAS technique additions as the highest-cadence signal types - Auto-proposal rate: Count changes with origin "auto-proposed" divided by all changes in last 12 months - Industry contributions: Count substantive technical artifacts submitted to ATLAS/AVID/CNCF/OpenSSF AI. GPU residual-state variants, orchestrator injection mechanics, inference-API exfiltration patterns qualify - Recognized TTPs: Check ATLAS commit history, AVID entry list, CNCF/OpenSSF AI guidance for citations of the program

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 8: Industry contribution of discovered AI/HAI infrastructure TTPs

Q8.1: Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS, AVID, CNCF AI working groups, and OpenSSF AI, covering novel infrastructure TTPs discovered in own-operated AI infrastructure (GPU residual-state variants, orchestrator workflow injection mechanics, inference-API exfiltration patterns, training-pipeline supply-chain compromise mechanics) following ATLAS evidence-and-provenance requirements, with at least two contributions externally recognized in published advisories, standard revisions, or community guidance?

Evidence Required: - [ ] Contribution log maintained: each entry records target body (ATLAS/AVID/CNCF/OpenSSF AI), submission date, artifact type, evidence package, anonymization review sign-off, and status - [ ] ≥4 substantive technical contributions submitted in the last 12 months, each is a technical artifact with evidence, not a cosmetic observer comment - [ ] ≥2 contributions externally recognized in the last 12 months (ATLAS technique merge, AVID entry published, CNCF AI security guidance update, OpenSSF AI bulletin citing the program) - [ ] Submissions anonymized and legally vetted; review record on file for each submission - [ ] Contributions focus on infrastructure-domain attack classes: GPU residual-state leakage, orchestrator injection, inference-API exfiltration, AI-CI/CD supply-chain compromise, model registry tampering

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Industry contributions per year (MITRE ATLAS / AVID / CNCF / OpenSSF AI) | 0 | ___ | ≥4 | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | | | Library change lead time from telemetry / external signal to update | measure | ___ days | ≤14 days | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | |

Metric Collection Guidance: - Contributions: Source is contribution log. Quality-grade: technical artifact with evidence = counts; comment without evidence = does not count - Recognized TTPs: Check ATLAS commit history, AVID entry list, CNCF/OpenSSF AI guidance for citations - Change lead time and auto-proposal rate: Same as Q7

Evidence Location: _____ Validation Date: ____ Notes: ______

Question 9: Shared threat-model artifacts and industry tabletops

Q9.1: Are anonymized infrastructure 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?

Evidence Required: - [ ] Anonymized infrastructure archetype threat models published: public or consortium-accessible URL on file; license is permissive; org-specific asset names, tenant configurations, and IAM details scrubbed - [ ] Anonymization review record on file for each published model - [ ] Peer-org adoption tracked: download counts, fork counts, direct adoption notifications, or consortium usage reports - [ ] Industry tabletop hosted or co-hosted in last 12 months: event record with date, hosting org(s), topic tied to the infrastructure threat library, and participant count - [ ] Published models maintained in sync with internal library: last internal update vs. last published update gap ≤90 days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Peer-org adoption of published archetype threat models | 0 | tracked | tracked | ☐ | | | External-recognized TTPs originating from the program | 0 | ___ | ≥2 / year | ☐ | | | Industry contributions per year (MITRE ATLAS / AVID / CNCF / OpenSSF AI) | 0 | ___ | ≥4 | ☐ | | | % of library changes auto-proposed vs. manually authored | measure | ___% | ≥60% auto-proposed | ☐ | |

Metric Collection Guidance: - Peer-org adoption: Collect download/fork/adoption metrics from the publishing platform quarterly. Trend is the measure - Recognized TTPs: Same metric as Q8 - Contributions and auto-proposal rate: Same metrics as Q7/Q8

Evidence Location: _____ Validation Date: ____ Notes: ______

Summary Scorecard

Level	Q1	Q2	Q3	Level Score	Gate Met?
L1	___	___	___	___	☐

Level	Q4	Q5	Q6	Level Score	Gate Met?
L2	___	___	___	___	☐

Level	Q7	Q8	Q9	Level Score	Gate Met?
L3	___	___	___	___	☐

Practice Maturity Score: ___ Assessed Maturity Level: ☐ L1 ☐ L2 ☐ L3

Practice Maturity Statement: The organization's TA-Infrastructure practice is at Level ___ . The archetype threat library covers ___ / 7 infrastructure archetypes mapped to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs (TA0001–TA0014), and HCT threat roots (BadCode/BadAction/BadPrincipal/BadPermissions). Threat snapshots are produced at SM intake for ___% of Sanctioned infrastructure assets. [Add narrative on gaps, next steps, and L2/L3 readiness.]

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

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown