HITRUST CSF requirement statement [?] (07.10bAISecSystem.1)
Before they are processed by the model, the AI system
(1) actively filters user inputs (regardless of modality or source, including attachments) for
suspicious and/or unexpected values or patterns which could be adversarial or malicious in nature.
- Evaluative elements in this requirement statement [?]
-
1. Before they are processed by the model, the AI system actively filters user inputs (regardless of modality or source, including attachments) for suspicious and/or unexpected values or patterns which could be adversarial or malicious in nature.
- Illustrative procedures for use during assessments [?]
- Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
- Procedure: Examine evidence that written or undocumented procedures exist as defined in the HITRUST scoring rubric. Determine if the procedures and address the operational aspects of how to perform each evaluative element within the requirement statement.
- Implemented: Examine evidence that all evaluative elements within the requirement statement have been implemented as defined in the HITRUST scoring rubric, using a sample-based test where possible for each evaluative element. Example test(s):
- For example, review the AI system configurations to ensure that user inputs (regardless of modality or source, including attachments) are actively filtered before they reach the model.
- For example, review the AI system configurations to ensure that user inputs (regardless of modality or source, including attachments) are actively filtered before they reach the model.
- Measured: Examine measurements that formally evaluate and communicate the operation and/or performance of each evaluative element within the requirement statement. Determine the percentage of evaluative elements addressed by the organization’s operational and/or independent measure(s) or metric(s) as defined in the HITRUST scoring rubric. Determine if the measurements include independent and/or operational measure(s) or metric(s) as defined in the HITRUST scoring rubric. Example test(s):
- For example, measures indicate if the organization checks user inputs (regardless of modality or source, including attachments) for anomalies and filters suspicious and/or unexpected values or patterns which could be adversarial or malicious in nature. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm the identified anomalous entries are removed.
- For example, measures indicate if the organization checks user inputs (regardless of modality or source, including attachments) for anomalies and filters suspicious and/or unexpected values or patterns which could be adversarial or malicious in nature. Reviews, tests, or audits are completed by the organization to measure the effectiveness of the implemented controls and to confirm the identified anomalous entries are removed.
- Managed: Examine evidence that a written or undocumented risk treatment process exists, as defined in the HITRUST scoring rubric. Determine the frequency that the risk treatment process was applied to issues identified for each evaluative element within the requirement statement.
- Policy: Examine policies related to each evaluative element within the requirement statement. Validate the existence of a written or undocumented policy as defined in the HITRUST scoring rubric.
- Placement of this requirement in the HITRUST CSF [?]
- Assessment domain: 07 Vulnerability Management
- Control category: 10.0 – Information Systems Acquisition, Development, and Maintenance
- Control reference: 10.b – Input Data Validation
- Specific to which parts of the overall AI system? [?]
-
AI application layer:
- Application AI safety and security systems
- Model safety and security systems
- Discussed in which authoritative AI security sources? [?]
-
- OWASP 2023 Top 10 for LLM Applications
Oct. 2023, © The OWASP Foundation- Where:
- LLM02: Insecure output handling > Prevention and Mitigation Strategies > Bullet #2
- LLM04: Model denial of service > Prevention and Mitigation Strategies > Bullet #1
- LLM06: Sensitive information disclosure > Prevention and Mitigation Strategies > Bullet #2
- LLM07: Insecure plugin design > Prevention and Mitigation Strategies > Bullet #1
- LLM07: Insecure plugin design > Prevention and Mitigation Strategies > Bullet #2
- LLM10: Model theft > Prevention and Mitigation Strategies > Bullet #5
- Where:
- OWASP 2025 Top 10 for LLM Applications
2025, © The OWASP Foundation- Where:
- LLM01: Prompt injection > Prevention and Mitigation Strategies > Bullet #3
- LLM02: Sensitive information disclosure > Prevention and Mitigation Strategies >
- LLM05: Improper output handling > Prevention and Mitigation Strategies > Bullet #1
- LLM06: Excessive agency > Prevention and Mitigation Strategies > Bullet #8
- LLM10: Unbounded consumption > Prevention and Mitigation Strategies > Bullet #1
- Where:
- OWASP Machine Learning Security Top 10
2023, © The OWASP Foundation- Where:
- ML01:2023 Input manipulation attack > How to prevent > Bullet #3
- ML03:2023 Model inversion attack > How to prevent > Bullet #2
- Where:
- OWASP AI Exchange
2024, © The OWASP Foundation
- LLM AI Cybersecurity & Governance Checklist
Feb. 2024, © The OWASP Foundation- Where:
- 3. Checklist > 3.9. Using or implementing large language model solutions > Bullet #5
- 3. Checklist > 3.9. Using or implementing large language model solutions > Bullet #5
- Where:
- MITRE ATLAS
2024, © The MITRE Corporation- Where:
- NIST AI 100-2 E2023: Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
Jan. 2024, National Institute of Standards and Technology (NIST)- Where:
- 3. Generative AI taxonomy > 3.3. Direct prompt injection attacks and mitigations > 3.3.2. Mitigations
- 3. Generative AI taxonomy > 3.4. Indirect prompt injection attacks and mitigations > 3.4.5. Mitigations
- Where:
- Guidelines for Secure AI System Development
Nov. 2023, Cybersecurity & Infrastructure Security Agency (CISA)- Where:
- 1. Secure design > Design your system for security as well as functionality and performance
- 3. Secure deployment > Protect your model continuously
- Where:
- Deploying AI Systems Securely: Best Practices for Deploying Secure and Resilient AI Systems
Apr 2024, National Security Agency (NSA)- Where:
- Continuously protect the AI system > Secure exposed APIs > Bullet 2
- Continuously protect the AI system > Secure exposed APIs > Bullet 2
- Where:
- Generative AI framework for HM Government
2023, Central Digital and Data Office, UK Government- Where:
- Building generative AI solutions > Building the solution > Getting reliable results > Bullet 3
- Building generative AI solutions > Building the solution > Getting reliable results > Bullet 3
- Where:
- Securing Machine Learning Algorithms
2021, © European Union Agency for Cybersecurity (ENISA)- Where:
- 4.1- Security Controls > Specific ML: Implement tools to detect if a data point is an adversarial example or not
- 4.1- Security Controls > Specific ML: Implement tools to detect if a data point is an adversarial example or not
- Where:
- OWASP 2023 Top 10 for LLM Applications
- Discussed in which commercial AI security sources? [?]
-
- The anecdotes AI GRC Toolkit
2024, © Anecdotes A.I Ltd.- Where:
- Control 7.1: Input validation
- Control 7.1: Input validation
- Where:
- Databricks AI Security Framework
Sept. 2024, © Databricks- Where:
- Control DASF 58: Protect data with filters and masking
- Control DASF 58: Protect data with filters and masking
- Where:
- Snowflake AI Security Framework
2024, © Snowflake Inc.- Where:
- Prompt injection > Mitigations > Prompt validation and filtering
- Indirect prompt injection > Mitigations > Bullet 1
- Sponge samples > Mitigations > Input validation and normalization
- Fuzzing > Mitigations > Input validation
- Model inversion > Mitigations > Bullet 3
- Training data poisoning > Mitigations > Input validation
- Where:
- The anecdotes AI GRC Toolkit
- Control functions against which AI security threats? [?]
-
- Control function: Preventative
- Additional information
-
- Q: When will this requirement included in an assessment? [?]
- This requirement will always be added to HITRUST assessments which include the
Security for AI systems
regulatory factor. - No other assessment tailoring factors affect this requirement.
- This requirement will always be added to HITRUST assessments which include the
- Q: When will this requirement included in an assessment? [?]