In a previous post I talked about how security questionnaires are security theater. They were in 2018—and they still are—but pointing this out always raised the same challenge:
It’s a fair point, and I think we have an answer. I’m a bit allergic to 1.0 and 2.0 designations, but in this case I think we have a clear transition.
Ask yourself how much time was wasted on security questionnaires for Solarwind, and how many of them did any good.
In short, Vendor Security 2.0 is the transition from external security checks to internal risk analysis.
For those of you who have been playing the security questionnaire game for multiple years, ask yourselves how many Solarwinds-type compromises, or data breaches from popped vendors were:
Caught by a security questionnaire process, AND
Stopped from doing business with the company because of the security questionnaire
Not many, right? They either weren’t caught by the process, or the business ignored the findings because they wanted to use that product or service.
I have been part of hundreds—possibly even thousands—of vendor security reviews in my 20 years in security, and I can think of very few examples of where the business really wanted to use a particular vendor and security shot it down.
I learned about it via a lucky interview with someone honest.
Not only that, but I’ve been onsite doing an in-depth security assessment while big-four teams were completing their reviews with thumbs-up and smiles everywhere. SOC2 no problem! Security questionnaires passed with flying colors! But at week two I found a critical issue that directly affected customer data.
Unless your (business) partner overrides you.
The best use of a security questionnaire is to ask the company if they’re an axe murderer. If they say yes, don’t hire them to babysit.
If we only used vendors that have never been hacked, we’d be writing our own operating systems, CMS software, and 100 other pieces of core technology.
As it turns out, if everyone you’re talking to is hiding the truth, you can easily do a full onsite security assessment and not find much of anything. If they can hide things that well while you’re onsite with decent access, imagine what they can do with a questionnaire.
Then there are the online reputation services that too often function like the mob.
Protect me from who?
I’d mention names but don’t want to get whacked.
Right, so we know what doesn’t work. Let’s add more detail to what we are proposing with Vendor Risk 2.0.
1. Assume compromise
Assume your vendors are compromised.
It can be more than two, but don’t let it expand.
Massively slim down your questionnaire to two basic questions: when was the last time you were breached (what happened, why, and how did you adjust), and do you have security leadership and a security program.
Focus mostly on when they admit they’re an axe murderer. So if they say, “Actually, we don’t really have a security program and we’re kind of struggling right now…”, consider telling the business that this is a serious problem. Optionally: maybe find a way to work with them later because they’re clearly honest.
In short, give really bad responses lots of weight, and give good responses very little.
2. Perform Risk Assessment Analysis
Perform Vendor Risk Assessments on all key vendors that have software running in your organization or that have your data.
“Key” being a function of penetration into your business infrastructure and data, combined with the amount of impact a breach would have.
Vendor Risk Assessments should function much like Threat Models, in the sense that they’re looking for an understanding of 1) the integration of that vendor into your business, 2) what could go wrong if/when they were/are compromised, and 3) what you can do to mitigate that risk.
Transition your Third-Party Risk Team’s efforts from questionnaires to doing these assessments, with most of the emphasis on #3.
For the assessments themselves, focus on improving visibility into the risk, adding controls to reduce said risk, and also on ways to reduce the scope, penetration, and access that the vendor tool has to minimum levels—thus reducing impact when a breach occurs.
After Solarwinds this conversation will be a lot eaiser.
3. Risk Visibility
Ensure the business understands that vendors are tradeoffs between easier/faster functionality vs. security.
Use the Vendor Risk Analysis process to educate the company, including senior leadership, on the real-world risk posed by all vendors in use.
Questionnaires are largely Security Theater because it’s nearly impossible to assess a company’s security risk from the outside.
If the business needs a given tool, they’ll likely force the company to use it despite the risk.
Given these truths, the most realistic path for protecting ourselves from vendors is heavy investment in Risk Visibility, Risk Reduction, and Risk Communication/Acceptance.
Thanks to Orianda G. for talking through this with me and helping validate from another vendor security veteran that my views on this stuff aren’t completely off-base.
Thanks to Jesper Johansson for my new favorite three-step description of threat modeling.
When people talk about 2.0 they’ll inevitably be asked about what 3.0 might look like. The short answer is that I don’t know. But I imagine it’ll be something like a combination of SBOMs, combined with risk assessments, combined with dependency and connectivity mapping. In other words, we use these software packages, with this data, in these processes, and given that they’re deemed to be X secure in Y configuration, we currently have Z amount of risk. Ok…that might be 4.0.