Approach to AI Security Audit
Note: No AI was harmed in the writing of this posting.
With all the hype and marketing for AI today, lots is being lost in the noise. The biggest one is how do you tackle conducting an AI security audit, especially as the implementations are already deployed and the confidential information has already left the building.
Security with any new technology, regardless of the hype, needs to be approached from a risk management perspective always. I know this is boring, no new technology that will save the world just old school security basics. What I am outlining, at a high level, is how we need to consider how to use our current approaches within the context of an AI system.
AI systems are a challenge, especially to non-technical auditors, as the system can be run in only two layers of an OSI model view, such as the Application and Physical Layer. This then dramatically reduces the typical controls that would be used for risk mitigation. One must be able to use some other tactics to help identify where potential attacks exist and be able to independently deploy controls and/or monitoring. However, let’s not get ahead of ourselves here.
Let’s start with the basics. What does an AI Security Audit look like, and what does it need to contain?
- Governance – Your organization should have defined and documented approaches to AI usage, including identifying company-specific risks and mitigations that are considered mandatory. These aspects will drive any audit scope as they need to verify the implementation aspects.
- Data Training – Understanding the data sources and implementing a series of “labels” will aid in understanding the source but also where these specific datasets can be used or where they should not be used. Tracking these elements in detail will help to quickly identify compromises or malicious injections.
- Models and Architectures – Leveraging the governance framework that has been deployed should identify controls for the models being developed and used and how those correlate to the architectures for deployment.
- Inference and Prompt Logic – When using 3rd party provider prompts, understanding both the opportunities and limitations of the specific platform used helps to quantify any specific risks.
- APIs, SDKs, and Autonomous Agents – With lots of deployments and service offerings, your organization may be using 3rd party offerings. Understanding and performing a 3rd party security audit will help to identify any specific organizational risks.
- Logging, Monitoring, and Improvements – As with any ISMS that has been deployed, you must identify how you will actively monitor your implementation for signs of failure and methods that can be improved. While your goal might not be certification, still ensuring you have the means to identify faults and address these will aid significantly in the success of any deployment.
What is important to remember here is that many of the current tools and techniques used previously for risk management still apply. The difference is we need to change our approach to really uncover the intercommunication of the sub-systems which constitute about 80 percent of the implementation. You need to be detailed and understand how the components are being used, by whom, and what data is being used to derive the necessary results. The first time you do an audit it should consider all of these areas, you can break these down into smaller components to make it easier to complete but all of these aspects need to be considered so you can full quantify the overall risk of your current AI deployment(s).
I will be expanding on these in future blogs, so please stay tuned for more guidance.