Vendors are increasingly becoming one of the easiest and cheapest ways to attack organizations. Passwords are being reused from previous breaches. Vendor access is being leveraged into lateral movement. Software supply chains are being used to place malware into otherwise secure systems. Organizations are being compromised through malicious and vulnerable software.
Target was hacked through their HVAC vendor. Atrium Health was breached through their billing vendor. BitPay was compromised through a Node.js dependency. Marriott was breached through an acquired organization.
A lot has been written on how vendor due diligence doesn’t accurately measure or increase security. But we can change that by being more thoughtful about vendor review programs. In this post, I present a vendor security review that’s designed to be efficient and effective at understanding and reducing risk in your organization. Most importantly, this review is designed to give you a more accurate perspective of your vendors’s security posture, so you can make more impactful decisions about your most risky vendors.
Most organizations throw a long questionnaire at vendors and look at the results, but it’s important to add depth to those canned answers and checkboxes. There are several dimensions of depth you should be considering before assigning a risk rating and making a decision about a vendor.
I find it helpful to categorize vendors by overall relationship — vendor versus partner — and business lines — technology versus finance.
It’s important to understand the basics. What does this vendor do? What are we using this vendor for? Understanding these things could raise or alleviate concerns later in the process.
What kind of relationship do with have with this vendor? A vendor might be less risky if they are open to implementing security features or improvements for us.
Who will be using this vendor? Who is the primary contact to this vendor? A bank chosen by the finance team might be less risky than a database chosen by the legal team.
Data and Access
There’s a difference between a vendor that is granted access to sensitive data (say Dropbox or Slack) and a vendor that granted network access to production (say AWS or an organization you just acquired). Before you can assess the security of a vendor, you need to know some things about the data the vendor will have access to and the access that will be granted to the vendor.
Will sensitive data be accessed or stored by this vendor? Where will sensitive data live? Can we manage and limit access?
Do we trust this vendor? A trustworthy organization that has a reputation in their industry may be less risky. Does the vendor have a strong security track record? Previous initiative shown by a vendor may indicate current and future risk. How difficult would it be to compromise this vendor? Sometimes it’s important to use your own offensive judgement and intuition.
Whether or not this vendor is a likely target of your adversaries should be one of the most important dimensions you measure on. Is it likely this vendor is compromised? If this vendor is compromised, how likely are we to be affected?
Just because a vendor is compromised doesn’t mean it will affect you (or you’ll ever know about it). How valuable of a customer are we in comparison to other customers of this vendor? If this vendor is compromised, are we going to be one of the first customers that is affected?
Adversary economics are important here too. Is this vendor likely on a target list of one of our adversaries? Could an adversary compromise this vendor with less resources than it would take to compromise us?
Does this vendor do anything that we consider dangerous? Does this vendor mint API keys to our services or infrastructure? Does this vendor sell customer data? Does this vendor download code from the internet and execute it?
Vendor Assessment Cadence
So often do organizations ask for a questionnaire once and never revisit, even for the most risky of vendors. You must review your vendor catalog regularly, keep it up to date and make sure it’s accurate and complete. You should re-review your most risky vendors often.
Finally, you need to ask the vendor some questions and trust their answers. Many organizations like to use a standard set of questions like the Shared Assessments Standardized Information Gathering questionnaire. More often than not, you’ll find questionnaires like this one needlessly verbose and lacking in quality; not to mention that it’s too long to be actually ever be reviewed by anyone.
I find it much more effective to ask a much shorter list of pointed questions that can tell you much more about the security posture of an organization (if answered accurately, of course) and help you better assess the risk of your vendors.
Product security is often an overvalued part of a security program. Instead of asking about an organizations product security team, static analysis products, or automated testing (all of which most organizations don’t have, or if they do have they don’t utilize properly), ask: How does your organization perform third-party tests of their products? What firm performs these tests?
Application penetration testing is significantly flawed. You can learn a lot about an organization by how they decide to perform these tests and who they choose to perform them. Do they scope their tests well? Do they find a boutique firm that specializes in their industry or product?
Every organization is going to tell you they do the required basics. They’ll say they encrypt all their data at rest and in transit. They’ll say they have a vulnerability scanner and they patch regularly. The problem are their blind spots. Do they have an accurate asset inventory? Can they detect when new machines that are not built with their images or policies start existing in their environment?
Instead of asking the typical infrastructure questions, ask: Does your organization continuously monitor their infrastructure? Please briefly describe the practices and tools. This will immediately tell you how modern their infrastructure security program is and how large their blind spots are.
Incident detection and response is one of the most undervalued parts of a security program. Ask: Does your organization have an incident response function? Please briefly describe it. This will tell you if the vendor has a SOC, how effective it is, and how integrated it is with the rest of their security functions.
How an organization builds a threat model can give you insight into how mature their overall security program is. Ask: Please briefly describe how your organization performs threat modeling or threat analysis. A thoughtful threat modeling framework means this security organizations is going above and beyond an outdated basic framework.
Every organization will have different defensive controls for different reasons based on their threat model, but there are a small set of basic controls that every mature organization will have in one form or another and these controls can tell you a lot about the sophistication of their security organization.
Does your organization use endpoint protection or endpoint detection and response solutions? Which ones? How were they chosen? A thoughtful team will use a EPP or EDR solution backed by threat intelligence data. A thoughtful team would avoid signature-based solutions and baseless machine learning and artificial intelligence claims.
Does your organization require the use of a password manager for credentials? Requiring the use of a password manager signals that the team is aware of common adversary tactics like password reuse.
Does your organization enforce MFA for sensitive systems? A thoughtful team will have 2FA in critical places and avoid SMS, phone calls, and e-mail as 2FA factors.
Does your organization collect relevant telemetry and audit logs from systems to detect breaches? Mature organizations have robust log management for investigations and alerting.
Finally, some vendors are going to need specific questions answered about their technology. This could include protocols, authentication mechanisms, security controls, and more.