add AI

Author: wurstbrot

src/assets/YAML/default/AI/DataProtection.yaml

@@ -27,7 +27,7 @@ AI:
         time: 3
         resources: 1
       usefulness: 4
-      level: 2
+      level: 3
       tags:
         - ai
         - red-teaming
@@ -36,6 +36,8 @@ AI:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c07
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange
       references:
         samm2:
           - V-ST-A-1
@@ -54,16 +56,26 @@ AI:
       risk: |-
         One-off manual red teaming does not catch regressions. Model updates, prompt
         changes or new tool integrations silently reintroduce vulnerabilities in
-        AI-based features.
+        AI-based features. Upstream providers additionally update models without
+        notice ("silent model drift"): identical prompts produce different
+        behavior although nothing in the organization changed, and the change
+        goes unnoticed until complaints accumulate.
       measure: |-
         Integrate automated AI red teaming / adversarial testing tools into the
         delivery pipeline of AI-based features and run them regularly and on every
-        significant change to prompts, models or guardrails.
+        significant change to prompts, models or guardrails. Complement the
+        adversarial tests with behavioral regression tests ("golden answers"):
+        defined test queries whose responses are compared semantically against
+        approved reference answers, so silent upstream model updates are
+        detected. Maintain the reference answers like any other reviewed
+        content: stale expected answers make the tests pass while the
+        responses are wrong.
       dependsOn:
         - b4233919-6de0-4ed3-b7da-3bdd91c8db5e # Basic AI red teaming
       assessment: |
         - Show the automated AI red teaming tool and its integration into the delivery pipeline.
         - Show recent runs, what triggered them (e.g. prompt or model changes) and how regressions are reported.
+        - Show the golden-answer test set, the semantic comparison against reference answers and when the reference answers were last reviewed.
       difficultyOfImplementation:
         knowledge: 4
         time: 3
@@ -79,6 +91,8 @@ AI:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/garak
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/pyrit
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/promptfoo
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima
       references:
         samm2:
           - V-ST-A-2

src/assets/YAML/default/AI/Guidance.yaml

@@ -9,6 +9,6 @@ _meta:
     The _Red Teaming_ subdimension focuses on adversarial testing of AI components and AI-based features.
     The _Data Protection_ subdimension focuses on preventing leakage of sensitive data through AI tools,
     including validation of model input and output (e.g. prompt injection prevention).
-    The _Verification_ subdimension focuses on the verification of AI-generated code; automated security
+    The _Verification_ subdimension focuses on the verification of AI-generated artifacts (specifications, plans and code); automated security
     testing such as SAST/DAST is intentionally NOT duplicated here, it is referenced from the
     _Test and Verification_ dimension (see ARCHITECTURE.md, section "Handling duplicates").

src/assets/YAML/default/AI/Isolation.yaml

@@ -2,30 +2,31 @@
 ---
 Build and Deployment:
   Build:
-    Building and testing of artifacts in virtual environments:
+    Building and testing of artifacts in virtualized environments:
       uuid: a340f46b-6360-4cb8-847b-a0d3483d09d3
       description: |-
         While building and testing artifacts, third party systems, application frameworks
         and 3rd party libraries are used. These might be malicious as a result of
         vulnerable libraries or because they are altered during the delivery phase.
+
+        Depending on your environment, usage of virtual machines
+        or container technology is a good way. After the build, the filesystem should
+        not be used again in other builds.
       risk: |-
         While building and testing artifacts, third party systems, application frameworks
         and 3rd party libraries are used. These might be malicious as a result of
         vulnerable libraries or because they are altered during the delivery phase.
       measure:
         Each step during within the build and testing phase is performed in
         a separate virtual environments, which is destroyed afterward.
-      meta:
-        implementationGuide:
-          Depending on your environment, usage of virtual machines
-          or container technology is a good way. After the build, the filesystem should
-          not be used again in other builds.
       difficultyOfImplementation:
         knowledge: 2
         time: 2
         resources: 2
       usefulness: 2
       level: 2
+      dependsOn:
+        - 3a94d55e-fd82-4996-9eb3-20d23ff2a873 # Applications are running in virtualized environments
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology
@@ -82,6 +83,11 @@ Build and Deployment:
       comments: ""
     Pinning of artifacts:
       uuid: f3c4971e-9f4d-4e59-8ed0-f0bdb6262477
+      description:
+        Pinning artifacts in Dockerfile refers to the practice of using specific,
+        immutable versions of base images and dependencies in your build process. Instead of using the
+        latest tag for your base image, select a specific version or digest. For example, replace FROM node:latest,
+        to FROM node@sha256:abcdef12.
       risk:
         Unauthorized manipulation of artifacts might be difficult to spot. For
         example, this may result in using images with malicious code. Also, intended
@@ -91,12 +97,6 @@ Build and Deployment:
       comment:
         The usage of pinning requires a good processes for patching. Therefore,
         choose this activity wisely.
-      meta:
-        implementationGuide:
-          Pinning artifacts in Dockerfile refers to the practice of using specific,
-          immutable versions of base images and dependencies in your build process. Instead of using the
-          latest tag for your base image, select a specific version or digest. For example, replace FROM node:latest,
-          to FROM node@sha256:abcdef12.
       difficultyOfImplementation:
         knowledge: 2
         time: 2

src/assets/YAML/default/AI/RedTeaming.yaml

@@ -189,6 +189,56 @@ Build and Deployment:
         iso27001-2022:
           - 5.37
           - 8.32
+    Drift detection for deployed configuration:
+      uuid: 9cba815f-02d2-4b06-a11f-7f28580e135a
+      description: |-
+        Deployment pipelines put an approved, versioned state into production —
+        drift detection continuously verifies that production still matches it.
+        Deployed infrastructure and configuration can be changed past the
+        pipeline: through a quick hotfix, direct console or shell access, or a
+        compromised automation account. Continuously comparing the running
+        state against the versioned desired state (e.g. GitOps reconciliation,
+        infrastructure-as-code plan diffs) detects such out-of-band changes.
+      risk: |-
+        Production is modified outside the deployment process — a manual
+        hotfix, a console change or an attacker altering configuration. The
+        running state no longer matches the reviewed, versioned state:
+        hardening is silently loosened and never restored, the repository
+        gives a false sense of the deployed reality, and rebuilding the
+        environment reproduces neither the fix nor the compromise analysis.
+      measure: |-
+        Continuously compare the deployed state of infrastructure and
+        configuration against the versioned desired state (e.g. via GitOps
+        controllers that reconcile and report drift, or scheduled
+        infrastructure-as-code plan runs). Alert on every deviation and either
+        revert it automatically to the approved state or bring the change
+        through the regular review process. Document intentional exceptions
+        so the alerts stay actionable.
+      dependsOn:
+        - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process
+      assessment: |
+        - Show the drift detection mechanism (e.g. GitOps reconciliation status or scheduled plan diffs) and the covered environments.
+        - Demonstrate that an out-of-band change to production configuration raises an alert or is reverted automatically.
+        - Show how the last drift finding was handled (automatic revert or formal re-approval) and the documented exceptions.
+      difficultyOfImplementation:
+        knowledge: 3
+        time: 2
+        resources: 2
+      usefulness: 4
+      level: 3
+      implementation:
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gitops
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/argocd
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/fluxcd
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/terraform
+      references:
+        samm2:
+          - O-EM-A-2
+        iso27001-2017:
+          - 12.1.2
+        iso27001-2022:
+          - 8.9
+      comments: ""
     Environment depending configuration parameters (secrets):
       uuid: df428c9d-efa0-4226-9f47-a15bb53f822b
       risk: >-

src/assets/YAML/default/AI/Verification.yaml

@@ -30,6 +30,8 @@ Culture and Organization:
         * Input is escaped output is encoded appropriately using well established libraries.
 
         Source: OWASP Project Integration Project
+        # AI support
+        At this maturity level, AI can lift threat modeling from periodic workshops to a continuous activity: AI threat modeling tools generate architecture-aware threat model drafts from feature tickets and design documents before implementation starts, re-run the analysis when new tickets arrive and compare the threat model against the implemented code to surface drift between design intent and implementation (e.g. Apiiro AI Threat Modeling, commercial). The generated models require expert review, see the note on failure modes in _Conduction of simple threat modeling on technical level_.
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c
@@ -38,6 +40,8 @@ Culture and Organization:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threagile
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apiiro-ai-threat-modeling
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-designer
       references:
         samm2:
           - D-TA-B-2
@@ -112,7 +116,7 @@ Culture and Organization:
 
         ![SKF](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/skf_qs.png "SKF")
 
-        This practice has the side effect that it trains non-security specialists to think like attackers.
+        This practice has the side effect that it trains non-security specialists to spot how functionality can be misused.
 
         The outcomes of this stage should help lay the foundation of secure design and considerations.
 
@@ -127,6 +131,10 @@ Culture and Organization:
         GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes.
 
         Source: OWASP Project Integration Project
+        # AI support
+        Large language models can support threat modeling as a complementary tool: given an architecture description, a data flow diagram or a user story, they generate candidate threat lists (e.g. along STRIDE) and suggested mitigations, which the team then reviews, corrects and prioritizes in the workshop. Tools such as [STRIDE GPT](https://github.com/mrwadams/stride-gpt) automate this drafting step; agentic applications such as [Threat Designer](https://github.com/awslabs/threat-designer) analyze architecture diagrams and let the team refine the resulting threat model interactively; agent skills such as [tm_skills](https://github.com/izar/tm_skills) let an AI coding agent generate pytm-based threat models with data flow diagrams directly from the codebase and evaluate user stories for security-notable events.
+
+        Be aware of the failure modes: a language model confidently fills gaps in an incomplete system description and produces threats for components that do not exist, and its output is non-deterministic (the same input yields different threat models). Validating an AI-generated threat model requires exactly the security expertise the tool seems to replace (see [Team Werewolves wins!](https://threatmodeling.dev/team-werewolves-wins/)). AI-generated threats are a starting point for the discussion, not its result. The team exercise and the shared understanding remain the core of this activity.
       risk:
         Technical related threats are discovered too late in the development and deployment process.
       measure: |
@@ -147,6 +155,8 @@ Culture and Organization:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-designer
+        - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tm-skills
       references:
         samm2:
           - D-TA-B-2
@@ -197,6 +207,17 @@ Culture and Organization:
       comments: ""
     Creation of simple abuse stories:
       uuid: bacf85b6-5bc0-405d-b5ba-a5d971467cc1
+      description: |-
+        Abuse stories are the attacker's counterpart to user stories: for a
+        given user story they describe how the same functionality can be
+        misused. Large language models are well suited as a complementary
+        tool for this activity: given a user story and its acceptance
+        criteria, they generate candidate abuse stories. This covers a step
+        teams often skip, because systematically asking how functionality
+        can be misused requires experience most development teams do not
+        have. Generated abuse stories are drafts: the team
+        reviews them, discards irrelevant ones and derives security
+        acceptance criteria from the relevant ones.
       risk:
         User stories mostly don't consider security implications. Security flaws
         are discovered too late in the development and deployment process.

src/assets/YAML/default/AI/_meta.yaml

@@ -283,6 +283,14 @@ Implementation:
         - App. Hardening Level 2
     Secure headers:
       uuid: 29318d60-18ce-4526-80ea-f5928e49f639
+      description: |
+        Essential headers:
+        - Content-Security-Policy: Define trusted sources for content
+        - Strict-Transport-Security: Enforce HTTPS connections
+        - X-Frame-Options: Prevent clickjacking attacks
+        - X-Content-Type-Options: Prevent MIME-type sniffing
+        - X-XSS-Protection: Enable browser's XSS filtering
+        - Referrer-Policy: Control information in the Referrer header
       risk: |
         Missing or misconfigured security headers can lead to various security vulnerabilities, e.g.:
         - Cross-Site Scripting (XSS) due to missing Content Security Policy
@@ -310,15 +318,6 @@ Implementation:
       level: 3
       implementation:
         - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-secure-headers
-      meta:
-        implementationGuide: |
-          Essential headers:
-          - Content-Security-Policy: Define trusted sources for content
-          - Strict-Transport-Security: Enforce HTTPS connections
-          - X-Frame-Options: Prevent clickjacking attacks
-          - X-Content-Type-Options: Prevent MIME-type sniffing
-          - X-XSS-Protection: Enable browser's XSS filtering
-          - Referrer-Policy: Control information in the Referrer header
       references:
         samm2:
           - O-EM-A-2