Security 101: vendor risk management

How much do you trust companies providing you a service? Your website analytics provider? Your code hosting service? The marketing agency selling ads on your behalf? These are simple questions to ask, but hard to answer. Third party services are usually easy and quick to add, they have a well built on boarding experience and seem to provide immediate value: This is how they get customers and convert them to paying ones.

But with every new tool you use, with every JavaScript snippet you include in your page and with every third party getting an access token to your system you increase the potential for a data breach, compromised source code or make it easier to impersonate someone of your team.

Waydev, a git analytics company, was recently breached and GitHub as well as GitLab OAuth tokens were stolen. Which means the attackers have access to the source code of Waydevs customers.

Imagine the fun things someone can do with access to your companies source code. Maybe you have credentials checked in. The „quick hack“ you shipped might be a way to gain access to all your data and now someone else (but not you... yet) knows about it.

What if your analytics provider is compromised and your website and webapp starts sending all input to a third party? Or your error and logging provider?

Every third party which has access to any part of your company is a potential risk that can be exploited and lead to a data breach, security incident or major inconvenience.

You can obviously not build every single piece of software in house. Companies far larger and with a lot more money than you tried and failed. So assuming you do not intend to burn money on problems others already solved, how can we minimize the risk?

The most important advice I give everyone is asking yourself if you really need the service or software. And I mean it - do you really need it? More often than not the answer is no, you do not need it, but you want it. Do you really gain anything from some software analyzing your commit logs? I mean except a false sense of control and a metric that is completely useless. Do you really need a second or third analytics provider or is your new marketing expert just not willing to share data with the previous agency or learn another tool? More often than not you do not need another tool. You might need some additional training on the tools you have, they are often more powerful than you know.

Another option is hosting software yourself, even though this does not magically fix all problems and comes at a cost (as this means you have to maintain yet another production system). It surely is not always an option. Some of the tools you might be interested in might not even be open source or available for self hosting. I cannot stress enough how this does not reduce your risk to zero, but a service running in the private part of a VPC, requiring a VPN connection to get access to the system is usually a significant improvement.

Let's assume you end up having to use a third party provider. You will likely be told how to use their service and there is not a lot you can do about it. What you can do is control which data makes it to the third party provider. Do they need an access key? Lock it down to the bare minimum permissions. Do they need tracking information? Be sensitive what you send them and either remove or hash as much data as you can without losing value of their offering. A third party being breached still means a data breach for you if they hold any relevant data of yours.

As you grow and step up your security game you will likely hear the words „vendor risk assessment“ more often than you'd like. You want to check if a vendor follows your standards and how they run their business. This is a long, often tedious process that can easily turn into a full time job for some month when playing catch up. So do not try to get all of this right from the beginning, but focus on a few questions:

Even if you are not an expert, listen to their explanation how they secure data. You want to at least hear the words „encryption at rest“ and „encryption in transit“. You might also ask for the option to secure accounts with two factor authentication.

The JavaScript part is in there for a simple reason and obviously only applies if they provide you some code to include in your site. It gives you back some control. If the vendor is breached it might safe you from including a modifying version of the script which might include things like a key logger or crypto currency miner.

You will have a horrible time trying to not work with any vendor, if it is possible at all. Engage vendors which are established in their field, even if they might cost a bit more - this is also not a guarantee all will be good, but it helps if they have processes in place and follow standards like SOC, ISO and others. If they have large enterprises as customer there is a good chance they went through a very throughout security check, far more extensive than you will be able to do without a dedicated team.

Every third party with access to any part of your system is a potential security risk and you should treat them that way. Try to hold them to the same standards you hold your team to. Try to figure out ways to minimize their access to systems and data. The best you can do is minimize the number of vendors you are using.

As tempting as it is to „just include a JS snippet“, it is your responsibility to keep your customers data safe no matter where it goes if it passes your system. They trust you with their data. To them it does not matter if you're startup or a vendor is breached - if their data shows up in a data breach, they will be angry at you.

>> posted on Aug. 20, 2020, midnight in security, security101