I read (and gave feedback on) the entire HITRUST AI Security Specification so you don't have to
A highly-focused cybersecurity certification for those developing AI systems.
AI-related security and compliance standards are multiplying!
The latest is from the Health Information Trust Alliance (HITRUST), which is requesting comments on it draft AI Security Specification. HITRUST is taking feedback through October 17, 2024. And I gave them a fair amount.
Overview
The specification is far narrower than ISO 42001 in that it:
Excludes those merely using AI from scope.
Is only available to already HITRUST-certified organizations.
Requires organizations to protect against certain attacks and even implement specific technical controls. My comments to HITRUST reflect my view that the latter approach is too prescriptive and could have unintended consequences.
Overall, though, it’s a pretty good standard that can help organizations rolling out AI who don’t have a business justification for ISO 42001.
Each heading below links to the relevant section of the standard, and my near-verbatim comments are italicized:
Who can achieve this certification?
Roles and responsibilities
I would recommend adhering strictly to the ISO/IEC 22989:2022 terminology regarding roles. For example, that document does not use the term “deployer” (which is present in the HITRUST AI Security Certification Specification Draft).
The appropriate scope for this certification would thus be AI providers and AI producers.
What types of AI can certify?
Definitions
I recommend excluding the first category, “Rule-based AI” because:
Systems covered by it lack the ability to learn from data and adapt based on new inputs. They are completely deterministic.
These systems can’t generalize and only handle scenarios explicitly covered by rules provided by humans.
There is no machine-driven optimization process (e.g., minimizing error, maximizing likelihood) involved, nor do these systems rely on probabilistic or statistical models to infer relationships or make predictions.
Including these systems would cover most software, making the scope of the certification potentially unworkable.
Exclusions based on EU AI Act
Excluding from certification all systems banned by the EU AI Act, irrespective of jurisdiction, is too broad a prohibition. For example, the EU AI Act prohibits real-time, remote biometric identification in public places for law enforcement purposes. It is quite conceivable, however, that a hospital system in the United States could use a facial recognition system to identify individuals who have acted violently in the past and contact local police as a preemptive measure. This practice could be legal in the jurisdiction (and even compliant with ISO/IEC 42001:2023), so banning it due to the EU AI Act does not seem appropriate.
Furthermore, the phrase “categorized as unacceptable” does not make clear who decides on the characterization. It is conceivable that an activist group might categorize a vast swath of AI systems as “unacceptable” and then argue that companies deploying them should not receive a HITRUST AI Security Certification.
To resolve these issues, I would simply remove the phrases “categorized as unacceptable or are otherwise” and “or by the EU AI Act.”
Guidance for External Assessors
Consider including the International Association of Privacy Professionals (IAPP) AI Governance Professional (AIGP) as a relevant (but not required) professional certification for assessors.
How to tailor the HITRUST assessment?
I recommend clarifying what “sensitive and/or confidential data” means. Training data might be publicly available but still subject to regulatory requirements like the European Union (EU) General Data Protection Regulation (GDPR) and thus be “sensitive.”
Identifying security threats to the AI system
Threats vs. risks
The current language uses the terms “security threat” and “threat register,” but refers to things like evasion and poisoning, which I consider to be risks. Furthermore, these requirements are categorized under the Risk Management domain of HITRUST.
Threats imply there is an identifiable actor responsible (e.g. malicious outsider, unwitting insider). When combined with vulnerabilities, these threats can create risks. Breaking down risk analysis into these components is certainly useful, but I recommend centering the requirements around risk. The Factor Analysis of Information Risk (FAIR) Institute has a useful article on the interplay of these terms: https://www.fairinstitute.org/blog/fair-terminology-101-risk-threat-event-frequency-and-vulnerability.
Risk sources
I humbly submit the StackAware AI risk database as an “authoritative AI security source” and am happy to discuss providing a free, machine-readable version to HITRUST.
Threat modeling
There seems to be some overlap between threat identification, threat modeling, and risk analysis in the specification. I would consider risk analysis to be the broadest discipline with threat modeling being a specific method whereby defenders evaluate a system from the perspective of an attacker. Threat identification would form part of the threat modeling process.
Assign Roles and Responsibilities for AI
I really like the requirement to assign “human accountability for the actions performed by, outputs produced by and decisions made by the organization’s deployed AI systems.” This really drives home the concept of “accountability” which is vaguely discussed in standards like the National Institute of Standards and Technology (NIST) AI Risk Management Framework (RMF). This phrasing makes clear there must be a designated owner for all AI outputs.
Augment written policies to address AI specificities
I would recommend including ISO/IEC 42001:2023 as a reference here because it lays out some requirements for AI policies.
Change control over language model tools
This requirement seems a overly specific to “language models.” I think it would be more appropriate to apply it to the AI Application Layer (using the terminology elsewhere in the specification), which would include Large Language Model (LLM)-baed applications but also other types of AI systems.
Indemnification in agreements with genAI providers
I would recommend adjusting the preamble to read “If the organization’s AI system is bought or licensed commercially, the organization assesses the need for the agreement with the system provider to include obligations (e.g., indemnifications) for…”
This would generalize the requirement and make it applicable to more than just Large Language Models (LLM).
Review the model card of models used by the AI system
I recommend adjusting this requirement to be more flexible to account for situations where the AI model in question doesn’t have a model card:
“For externally-sourced AI models in production applications, the organization reviews available model cards prior to deployment of new model versions. If no model card is available, the organization affirmatively decides to accept, mitigate, transfer, and/or avoid the risk resulting from this lack of transparency.”
Otherwise it would seem organizations could not use a model that doesn’t have an accompanying card without a penalty.
Training data distortion
This requirement is too prescriptive from a technical perspective and I recommend dropping it. Specifically requiring the addition of random noise, smoothing techniques, or differential privacy would create too high a technical bar for many organizations, and doesn’t take into account their likely unique circumstances. It is also not clear exactly which specific risk this control will mitigate. I recommend focusing on requiring organizations to affirmatively manage whichever risk this may be, but generally avoiding requiring certain methods.
Adversarial training
Similarly to training data distortion, this requirement is too prescriptive and could have unintended consequences. I recommend dropping it entirely.
Limit output specificity and precision
Similarly to the training data distortion and adversarial training requirements, I recommend eliminating this requirement. It would seem to require intentionally degrading the model without the ability to consider other competing requirements (e.g. data integrity).
Ensembling
Similarly to the training data distortion, adversarial training requirements, and output specificity limitation requirements, I recommend eliminating this one due to it being overly prescriptive.
Limit the release of technical info about the AI system
I recommend rephrasing this requirement to read “The organization shall consider restricting the release of technical details on AI…”
Otherwise, it would appear to create a binary divide between open- and closed-source models. The former category would have their entire code base be publicly available for inspection while the latter would have the absolute minimum information available.
This requirement would thus prevent organizations from taking a middle ground in terms of transparency. It might make the most sense for companies to disclose partial details of their AI models and applications while obscuring others.
Restrict access to data used for AI
I would recommend removing the section “(e.g., residing in file formats such as .pkl, .pth, .hdf5, .gguf, .llamafile)” because this might create confusion as to what is in- and out-of-scope for the requirement.
Organizations should document how they have met this requirement, but shouldn’t necessarily look to the specification in terms of which specific file types for which they limit access.
Inventory deployed AI systems
AI inventory is hugely important and I am happy this is a requirement!
Output filtering
I view this requirement as being too prescriptive in that it mandates a certain risk appetite for organizations by preventing their models from returning certain types of information.
While not an attorney, for example, I know that what is “copyrighted text” is very gray and there is no database of such information against which model outputs can be queried for filtering.
What I would propose instead is a requirement that “the organization filter AI outputs which, if delivered, would exceed the organization’s risk appetite.”