Your Security Position & the Vendor’s

We all use them, vendors and we either have great, terrible, functional, respectful, non-functional relationships with them. The fact of the matter is your organization doesn’t have the time, expertise or the skill set to build all the software we need and want. Vendors play a crucial role in our success often solving niche problems or specifics that folks just don’t have the time to work on. Love them or hate them vendors have etched a permanent place within your organization and within the software development industry. The ironic thing is your organization is in turn a vendor to someone else that probably has the very same feelings towards you that you do towards your vendors. The interesting question that arises is what happens when your security position does not align with the security position of the vendor?

Your Organization

In the light of all the security breaches that have been happening lately, it’s hard to argue in 2015 how any organization will not take the appropriate steps to strengthen their security position within the landscape in which they operate, in fact you have a duty to do just that, a duty to your customers, staff and share holders. You can take on the task rigorous task of securing your network, hardening your applications and doing everything you can possibly do with the assets that you control. However, unless your vendor is doing the same thing, you have a serious problem that needs to be addressed, even if the vendor is doing the same thing, chances are they are focused on their own network, etc. So what happens when you encounter a situation whereby the vendor’s software has a security hole in it, therefore creating a security hole within your organization?

The obvious answer is to phone the vendor up and ask them for a patch. This is where things get interesting for a variety of reasons, it’s conceivable that your vendor is actually using that software from another vendor and now the patch has to flow through two vendors before reaching your organization. The vendor in question might be more than willing to release a patch and quickly work with you to implement it – this is really your base case scenario from a security perspective. The difficulty really arises then, when your vendor says that they’re really not willing to release a patch or their patches are going to be a long time out and coming. There are several reasons for this possibility, the foremost is that securing your systems and network is not the vendor’s priority. You may not be their only client and the way they manage their software development, you have no idea about.

Security Quagmire

If the vendor isn’t willing to help you out, the security quagmire for your organization is, that you are exposed with a potentially high risk vulnerability especially if there is a CVE filed for it and even more so if there is a metasploit exploit for it. If a nefarious individual is able to exploit your organization via a vendor vulnerability yes you may have legal recourse, etc., however that’s only a small piece of the pie and the reputation damage is already done and may not be repairable. Considering the Anthem breach, the world is not going to care or let Anthem off the hook if Anthem comes out and points the finger at a vulnerable vendor. Whether it was Anthem or a vendor that was ultimately vulnerable, it was Anthem that had the data stolen and was breached. Often, it’s the what’s happened, the whom has been breached that matter and actually how the breach was accomplished is not so important and for that matter often poorly understood by non technical people.

The Vendor

The vendor from their perspective cares about a security breach, but their first and foremost mission will be to protect themselves and their interests ahead of yours. The vendor often times the vendor’s security position is that we’re just the vendor and yes our software might have a security issue associated with it, however said security issue is not so bad because our application is protected by your network. In my personal opinion, this is an excuse and cannot and should not be tolerated. The reasoning why I see this as an excuse is clearly outlined when I wrote about Not trusting the network. Additionally, this is an attitude that must change, that I also alluded too.

Chances are however that your organization is not the only client of the vendor that you’re using unless the said vendor is operating in a very niche market, solving a very specific problem. It’s important to realize that your vendor is also running a software development shop and has their own business to run above and beyond how you’re using them. In acknolwedging this however, this does not mean that you should let the vendor off the hook for their insecure software. The question then becomes how do you get the vendor to change their money & attitudes?

Competition

Chances are that your vendor is not operating in a niche market and you’re not their only client, there is also a good chance there are other vendors offering similar or the same product that take security far more seriously then your current vendor does. You can shop around and trying to find a vendor with a better security position, the difficulty you’ll run into with this approach is if you’ve tightly ingrained your current vendor in your systems it’ll be costly to swap out vendors, there is probably also contractual terms and conditions that will stop you from getting the immediate security benefit that you seek.

Money Talks

You can certainly explore the prospect of paying said vendor for a patch directly and working with them to get your software patched. This may or may not be successful, you may have to pay them a lot, depending on the way they develop software patching may not be a possibility. Then there’s always bigger fish in the pond and your vendor may have a bigger client that’s willing to pay more to have their priorities placed over yours.

Contracts

This is a preventative measure in my opinion because I believe it’s always better to prevent a security vulnerability then realize one. It maybe possible to build the fixing security vulnerabilities into the contract support terms, etc. Chances are though this is going to cost you a lot of money. It maybe worth your time and expense, it may not be worth your time and expense.

Security Audits – Veracode

Again this is a preventative measure, doing a full security work up on the product before you purchase it can save you a lot of trouble and then again along every upgrade opportunity. This can be a difficult and time consuming approach however you may not have the security expertise to do this, or your security experts may be well over burdened with other problems along the way. The risk associated with this particular approach is that the vendor wanting to protect their IP and possibly confidentiality or just wanting to make a sale may not be entirely forthcoming with you about the issues. Hopefully, you’ve talked that into a contract before getting started. Veracode – a security vendor, has an interesting solution to this problem, they offer their Vender Application Security Testing program to various clients in an aim to find security vulnerabilities in vendor products.

Be rest assured the vendor is going to pass the cost of these tests directly back on to you as a client, however Veracode will act as an independent third party providing you with an honest security assessment of the product you’re working with. It’s an interesting solution to a complex problem.

Responsibility

Whatever you choose to do, a vulnerability in a vendor application within your network does not absolve you of the responsibility to address the problem. Regardless of the feedback from the vendor, there are many solutions that can be put into place. Harden your network, build sandboxes around your vulnerable vendor software, use proxies to protect yourself, monitor the heck out of any exposure you know you have. Don’t be a victim.

The post Your Security Position & the Vendor’s appeared first on Security Synergy.