One of the most common challenges enterprises face in information security is dealing with third-party vulnerabilities. Whether it’s a security flaw located in a network appliance, a client/server program or a custom-developed application, you’re often the one on the hook to get things resolved.
Third-Party Problems Are Your Problems
I’m not talking about known security vulnerabilities that are easily fixed by applying an existing patch. Rather, I’m referring to unique security flaws that you or someone else uncovers in the process of doing business. Perhaps it’s a security flaw that is exclusive to your own environment or workflows. Such vulnerabilities include:
- An access control setting in a website content management system that enables world-writable permissions to core Web server files;
- A mobile app that doesn’t use Transport Layer Security (TLS) to transmit sensitive information across open wireless networks;
- An operating system that uses weak storage methods and doesn’t encrypt sensitive information or leaves it sitting in log or temp files that any internal user can access;
- A storage management system that improperly enforces its password policy and allows users to set weak or blank passwords;
- A public-facing enterprise resource planning (ERP) application with SQL injection that permits anyone on the Internet to extract data from the database.
When these types of security vulnerabilities surface, they can create unnecessary risks for your organization.
Regardless of whether vendors ultimately resolve the known security flaws, you’re still going to be responsible for getting things settled or finding compensating controls — and sooner as opposed to later. Even when your hands are tied, such flaws can reflect poorly on the security posture of your environment and leave your business at risk. Many people reviewing vulnerability scans or security assessment reports often won’t know — or don’t care — that you are unable to resolve certain issues directly. All that matters is the fact that the vulnerability exists.
Finding Solutions
When you become aware of security vulnerabilities that can only be resolved by an outside party, the most obvious thing to do is to forward along the information to the vendor, get feedback and hope it will provide a fix. Based on my experience, however, outside parties can be reluctant to acknowledge the security concerns. Some who do listen are often not motivated to resolve the issues. This apathy may exist because you’re not a large enough customer, because they don’t fully understand the ramifications of the risks involved or because you’re speaking with the wrong person altogether.
One of the best things that you can do is provide tangible evidence of the security vulnerability, either from your own internal testing or, ideally, from an outside party. You’ll want to include the specific areas of the system that are affected, what information or systems are being put at risk and how the vulnerability can be exploited, along with proof including screenshots, HTTP requests and responses and the tools used so it can be replicated in the vendor’s environment.
If you cannot get any resolution directly from the vendor, there are often security controls you can put in place to reduce or eliminate the risks, such as an intrusion prevention system (IPS) or Web application firewall (WAF) rules, more stringent network segmentation and network share permissions. There are likely other vendors that take security more seriously that would love to have your business. Beyond acknowledging the risk, the most important thing is to remain diligent and ensure that a fix — regardless of where it comes from — is put in place. Otherwise, it’s a breach in the making, and you don’t want to have to take that on.
Independent Information Security Consultant