In the course of my business, I frequently ask IT service providers questions about their information security practices, either as part of a third-party review, or as due diligence before a vendor selection. I have developed a reputation for asking blunt questions, and really dissecting the answers I get. I frequently find that these answers gloss over significant security exposures, some of which can have a material impact on the customer.
A case in point this week was one of my customers who has a website and secure portal provided by a vendor that offers hosting services to a particular industry. Based on concerns expressed by someone who had visited my customer's website, I performed a vulnerability scan, and got back a rather long list of identified issues. At my request, the customer sent the list off to the provider, who reviewed the list and responded a few days later.
The analysis of this vendor's response revealed some familiar patterns I see frequently. They are important to watch out for in any answers you get from your vendors as you ask them questions about their security practices:
"We haven't had a security incident in some time (or ever)"
This is a classic response. It is usually interpreted as, "Our security must be fine because nobody is getting in." Well, to quote folks in the financial industry, "Past performance is not an indicator of future success." Further, it is quite possible that a stealthy hacker has been in the vendor's network for some time without anybody realizing.
"Our [insert name of upstream provider] has great security"
In the case of this vendor, its services run on top of Amazon Web Services (AWS), well known for having tight (if not impenetrable) security. The vendor even provided links to the AWS security page in its response. Unfortunately, this vendor provides the software that runs on the AWS platform, for which Amazon cannot take responsibility.
Relying primarily on the upstream provider's security is much like a homeowner not using deadbolt locks because the local police force is highly rated. My county has a great police force, but all of my doors have deadbolts!
"We publish our list of security measures"
The vendor's email included a link to a security page for this particular customer, listing an impressive array of measures -- including an SSAE 16 data center, encrypted file storage and forced SSL transfers. Unfortunately, these measures only apply to the secure portal, not to the main site (known in the sales world as a "bait and switch").
Sadly, a vulnerable website can be "weaponized" by a hacker to deliver malware to visitors. Of equal concern is that fact that claimed security measures often don't equal achieved security measures. Vendors can claim anything, but it doesn't mean they really achieve it.
"We had problems before, but our security measures are better now"
This particular vendor was honest about an issue which occurred as a result of a prior WordPress bug, and claimed to have better measures in place to ensure that patches were applied. Again, vendors can claim anything, but that does not make it true. In this case, while the vendor claimed to have current software releases, my scan indicated otherwise.
I have intentionally omitted the industry in this case, because I did not want to unfairly single out a vendor that is likely one of the majority in how it handles security. Exposures can exist with any vendor, large or small, and regardless of industry. My primary point is that, fairly or not, the responsibility for ensuring the security of your vendors lies with you. Your customers expect it, and they will blame you -- not an upstream provider -- for any failures.
Reading between the lines
So, how do you spot a vendor that is not delivering good information security? Here are some suggestions:
- Scan your vendors, just as I did in the above example. There are plenty of tools to help with this, my favorite of which is Qualys, which provides a number of free scans. Scan your hosted sites (or the vendor sites) and relay the findings to your vendor. Look in the response for some of the common "wiggle" answers I mentioned above, and have a frank dialogue with the vendor. Vendors often require advance notice of this so that it does not trigger security alarms, but I personally prefer the "ignorance is bliss" approach, since how the vendors react will demonstrate how well their monitoring tools work.
- Look for vendors that have a dedicated security officer. Good security requires at least one individual in a company focusing on it. If the vendor doesn't have one, or if the security officer happens to also be the CEO or CTO, be suspicious about the true commitment to security.
- Conduct annual third-party reviews. You should have a formal process in place to evaluate your vendors on a yearly basis, even if you are small (and this is mandated for PCI DSS and HIPAA-regulated companies). This process should include a formal, written response from each vendor about its security measures.
To be honest, getting such a response may take work, because the vendors often are not anxious to participate. I had one recently decline to answer, stating flatly that the company wasn't sure the customer's business was worth the trouble. Insist and persist. Once you have a response, look for red flags. You can check my resource page for a list of items to include in a third-party review.
- Let Google be your friend. A periodic search for information about your vendor, including financial strength, management changes, security incidents, litigation, etc., can speak volumes about how well the company is doing. You often need to look beyond the first few response pages to get a complete picture. I have found important vendor information on response page 20.
- Remember that change can be good. If the vendor is not up to par, find a new one. We will not change this insecure information security culture unless we begin to vote with our wallets.
Bottom line: It is unfortunate that you, as a customer, must take responsibility for the security of your vendors, and their vendors. The business you save, however, will be your own.
This article is published as part of the IDG Contributor Network. Want to Join?