AI

This past week I was able to attend my first ISO Annual Meeting being hosted by AFNOR in Paris, France. This is not an event I usually attend but I was asked to sit on a panel to provide a cybersecurity and standardization perspective.

It was both exciting and humbled to be asked to do this. Given I am an International Convenor for a working group within SC 27 and the national chair for the mirror committee to ISO/IEC SC 27 in Canada it provides me the ability to share experiences and approaches for both creating and implementing international standards for businesses and governments.

The focus of my comments was around how local views can be limiter especially when just chasing compliance targets. While helpful, compliance programs are basic level needs and are not built on risk based approaches but meeting a specific focused target. Many SMBs globally are struggling to understand how cyber security is impacting their businesses and stuck in the realization that the current situation is only for new threats is increasing. Hallway discussions with delegates this become abundantly clear and I hope this conversation, while only a starting point is a beginning.

As we are working towards a SMB Guide for ISO 27001 (currently in PWI stage) we acknowledge the market need and are working towards providing the guidance. Specific to my Working Group (WG 4 under ISO/IEC SC 27) we have several PWIs looking at AI from code generation, use of LLMs, and now agents. However this is not all, we are revamping our standards on secure software with a PWI so I hope to be able to share more in the future once this has been solidified. We have a great upcoming ISO lead editor in Matt Houseman leading these discussions.

Speaking of AI, it was entertaining to watch the AI interpretation of the global speakers. While this technology has come so far using LLMs and models on native English speakers on a global stage it demonstrates its clear limitations and how the tech bros focused on using Caucasian first nation countries to develop their models. Small but very significant impact for all countries attempting to use these technologies.

In closing, I want to thank the team at AFNOR and ISO for considering me for this panel and also to the Standards Council of Canada for supporting me to attend this event. I am grateful for this opportunity and hope my insight is helpful for anyone looking to improve their security posture globally.

Once available I will share the ISO links to these meetings.

SC 27 Free Resources: https://committee.iso.org/sites/jtc1sc27/home/wg2.html

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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.