Services
This post talks about the do’s and don’ts of implementing a vendor management program.
In a broader business context, many companies already have vendor management programs to manage risks around tax exposure, vendor solvency, price, terms, etc.
In the context of information security, a vendor management program is a set of tasks, gathered data and risk decisions that together help us to engage with our vendors and partners in a way that appropriately accounts for the information risks we’re taking.
We hear about how companies are only as secure as their partners and vendors and it’s a pretty simple and straightforward concept that resonates.
Target is probably the quintessential modern example of this, where their POS systems were famously compromised through an attack chain that started with their HVAC vendor.
We at Jemurai have increasingly found ourselves subject to our clients’ vendor management programs. Sometimes we help build and implement programs for clients. Other times we help our clients work through the requirements in one of their partner’s vendor management programs (questionnaire hell).
We believe in vendor management programs. They are even incorporated into the policies and tools in our securityprogram.io tool. They are important for even the smallest businesses.
While we promote these programs and encourage our clients to implement them, we also find them increasingly out of touch with reality and difficult to handle.
Here are some recent examples:
I’ve seen people bend the truth on these surveys. When the interaction is a questionnaire and neither side understands it, the result is going to be a farce that both accept as a CYA.
Often, these programs aren’t collaborative or purpose driven and don’t have any way to take into account who the vendor is, what data they process and what the risk calculus should be in engaging them.
A funny quote from one customer that was part of this:
“I wonder which would be better for their security, my limited resources spending a day per
prospect manually answering 837 questions, or spending a day building a data flow diagram?”
Basically ONE SIZE DOES NOT FIT ALL. Sure, there are cases where 837 questions isn’t enough. But in most of the cases I’ve seen, it makes the exercise a performance that neither side fully understands.
Perhaps even worse, from what I’ve seen, THERE IS NO SIMPLE, COMMON SENSE, PROCESS OR SET
OF QUESTIONS WE CAN USE. Feel free to drop your thoughts in the comments, but I haven’t seen
a single simple standard I could get behind. Most of the time, when I read the questionnaires,
I think even the people that WROTE them didn’t understand the questions.
A side note: You don’t have to (and shouldn’t) answer “yes” to every single question on these surveys!!!
Nobody is actually doing all the things in any of these surveys across their organization.
Essential parts of running a vendor management program include:
Here is how we describe the program in our template for our customers:
Client has a simple vendor management program to ensure that the vendors and partners we work with protect data that we share with them in a way that is commensurate with both our and our client’s expectations.
The following outlines how our vendor management program works:
Response may be:
We expect the responses and further discussion to take place in a reasonable timeframe, which in this context may be one to two weeks.
Our goal through this process is to facilitate constructive discussion in which Client is clear about our requirements and what the Vendor / Partner needs to do to meet them. If we can help a Vendor to meet the requirements, we aim to do so. We expect Vendors to engage with us in an open and constructive way as well, as a business partner with interests that are aligned.
Client reserves the right to perform specific follow ups requesting evidence to support Vendor responses at their sole discretion. Client further reserves the right to perform its own external analysis of the Vendor system.
To reach our security team, email security@client.com. You may also communicate directly with your stakeholders about the Vendor Management Program.
Of course, we don’t like to just talk about the things we don’t like, we prefer to offer a solution or alternative - so here are the specific questions we currently recommend our clients to use when implementing a vendor management program.
Question | Answer | Client Notes |
|---|---|---|
| What is the most sensitive Client data your system will process? | (Models, Accounts, PII, PCI, ???) | Does the Vendor know what data matters? |
| Is the Vendor accepting legal responsibility for proper handling of Client data? | Is liability clear in the contract? | |
| Does the Vendor have a designated security leader? Who is it and what is their overall role in the company? Does the company have security policies? | Name: Email: Role: Policies: | This can be size appropriate but we want to understand the background. |
| Does the Vendor limit access to Client data to named accounts protected with multi factor authentication? What is the identity system or systems? Does the Vendor perform monthly user audits? How do subcontractors and Vendor’s Vendors fit into this answer? | (Yes / No) IAMIAM (Identity and Access Management) is a set of processes, policies, and technologies that enable organizations to manage and control access to their systems and data. IAM solutions help to ensure that only authorized individuals can access sensitive resources, and that access is granted on a "need-to-know" basis. System: Monthly User Audits: Vendor/Contractor Coverage: | Expect Vendor to limit access to named accounts protected by MFA and tracked in Google Apps, O365 or AD. |
| Does the Vendor have audit trails to identify user access to Client data? | (Yes / No) | Expect Vendor to be able to clearly show access. |
| Does the Vendor train employees on security? (Minimum: phishing, sharing passwords, data classification.) | (Yes / No) | Expect Vendor to provide training. |
| Does the Vendor scan for vulnerabilities in their systems (internal and external)? Please provide a summary of the results. | (Yes / No) High: Medium: Low: | Expect Vendor to be running vulnerability scans. |
| Does the Vendor system run in the cloud? Are security configurations actively managed? How? | (Yes / No) How: | Expect 'yes', via expert help, tools, AWS best practices. |
| Is Client data encrypted with TLS 1.2+ in transit everywhere in the Vendor system? | (Yes / No) | Expect 'yes'. |
| Is Client data always encrypted at rest with AES-256 or comparable encryption? | (Yes / No) Mechanism: Algorithm: | Expect 'yes', with e.g. S3/TDE, AES-256. |
| Does Vendor have a business continuity plan in place? What are the Vendor’s Recovery Time Objective and Recovery Point Objective? Has the BCP program been tested? | Has BCP (Yes/No): RPO: RTO: Tested (Yes/No): | Expect Vendor to have a plan to maintain high availability commensurate with technology role. |
Note that we encourage our customers to audit their providers by asking follow up questions if needed.
A great case study for this is Full Story, which we’ve seen used recently a few times. The tool basically captures much of the data in each user request and tracks it to a session. It is invaluable for providing insights into what users are experiencing. You can even replay a session and understand what it looked like in the system. However, left unchecked or unmanaged, using it might mean that you are inadvertently sharing sensitive data with a 3rd party.
Now, it is 100% possible to use Full Story in a safe way. However, it does take specific actions on the part of the user, and developers have to mark data that should not be shared. So we’re not saying don’t use Full Story. But we are saying that the answer is different for different companies with different data and different developer profiles.
We’re not picking on Full Story here, but rather using it as an example of a system where we need to know what is going on and how to mitigate the risks. Sometimes we might actually need to say “no” to using the system.
