Musings on modern vendor risk management

Modern vendor risk management certainly is strange.

In one corner, we have our customer who has their security requirements - controls that they require their vendors to have in place to protect their data and such.? In the other corner, we have the vendor, who has implemented a particular set of controls which may or may not be sufficient to meet the customer’s requirements.

Now, the vendor takes their implemented controls and transcribes them into a number of different representations: the security page on their website, their security whitepaper, their answers to self-assessment questionnaires, even the control descriptions in their SOC 2 report.? Each of these is a particular view of a particular subset of the vendor’s controls.

Then the customer, satisfied with none of these representations because they are not exactly the representation that the customer wants, requests that the vendor complete their questionnaire.? The vendor completes their questionnaire - another representation of their controls, except that this one is likely entirely unique for the customer.? The vendor has to do this for every single customer that sends them a questionnaire.

Now, of course this is insane, so we bring technology to bear on the problem - specifically, the magic of AI.? The obvious pain point is filling out all those questionnaires, so people smarter than I went and created AI-powered questionnaire responder systems.

The first ones incorporated natural language processing (NLP) to figure out the intent behind every question, and matched those determined intents to a library of responses that the customer had built up (yet another representation of their controls that the customer had to create) to automatically select appropriate responses to questions.

More recent examples use generative AI - they take the various representations of controls that the vendor has on hand (questionnaires, documents, that sort of thing), then, if powered by language models, generate responses based on statistical probabilities.? Which, if the input information is both current and generally consistent, should work out just fine.? I’m not sure how well such a system would deal with a control environment that is constantly evolving (since until you update every input document, descriptions of your old controls will be statistically more probable), but as I said, smarter people than I are working on this.

(As an aside, I’d gladly pay for an generative AI solution that lets me generate responses in the voice of a pirate.? “Ahoy there, me hearties! Hear this, for we take no chances when it comes to protectin' our precious data at rest. With the mighty AES 256, we've set up a fortress of encryption that no scallywag or bilge rat can breach. So rest easy, me crew, for our valuable treasure be safe and sound, hidden away from the prying eyes of the seven seas!”)

Now, the thing that strikes me as most odd about all of this is the fact that we need to go through any of these intermediate representations of the vendor’s controls at all.? There are many different ways to represent the information “data at rest is encrypted using AES 256”, and the customer is interested in exactly none of them - all they want to know is that the vendor actually does this.? All of these representations of the vendor's controls, and the technology to generate additional representations, are completely superfluous.

Note that I’m not saying that any of the tools that are around are bad - they all aim to address the issues that exist with the way that we do vendor risk management today.? I’m more saying that maybe how we do vendor risk tomorrow should look a bit different.

Consider the following hypothetical futuristic scenario.? A vendor has a SaaS product, and because information security is important, they have a suite of security controls in place protecting their product.? They represent these controls in a machine-readable language following an industry-standard schema.? This representation of their controls includes information about if and when each control was independently audited.? In fact, if we really want to get fancy, the auditor themselves could “sign” individual controls using their private key, specifying a validity period.? The vendor takes the file and uploads it into a trust exchange.

A customer is interested in purchasing this product.? The customer understands the particular risks inherent in using a third-party product for the use case, and so they require the vendor of the product to have particular security controls in place, some of which might need to be independently attested.? They enter these requirements into a vendor risk management tool.? They retrieve the vendor’s file from the trust exchange and load it into their vendor risk tool.? It instantly shows all of their requirements that are satisfied by the vendor, and perhaps more importantly, those that are not.? The tool also uses the auditor’s public key to verify the audited controls.? The customer is immediately able to start a conversation with the vendor about the small set of exceptions - those controls that they require that the vendor does not satisfy.

Now, how much time and effort have we saved here?? The vendor creates their controls file once, and that file can be used for every customer.? Every now and then, they update it (due to changes in their environment, new audits, etc) and upload it to the trust exchange.? On the other side, customers are able to determine very quickly whether vendors that they are considering will satisfy their information security requirements.? They can do this early in their vendor selection process to prevent the all-too-common situation where a vendor that the customer has gone through a long process to settle on falls short on the security front.

Most importantly, no security questionnaires.? Security conversations between vendors and prospective customers will focus only on a small set of controls - those that the customers require which the vendor does not have.??

Is this future realistic, and if so, how do we get to it?

(Incidentally, yes, I’m aware of OSCAL. I’m also aware that it’s large and complex and that there isn’t much in the way of tooling for it for the purposes that I described above.? Probably something of a chicken and egg issue here - tooling won’t appear until there is demand for it, and there won’t be demand for it without tooling.)