During several recent penetration tests, my team and I have identified serious security vulnerabilities in systems which are fully patched, and are using reasonably secure authentication mechanisms, supported by effective session management. In many of these cases, the vulnerabilities have been identified in third-party systems and applications, often in the form of dedicated appliances, rather than being related to in-house systems.
This can often raise significant difficulties for clients, particularly those with regulatory or compliance requirements, as they cannot knowingly permit serious vulnerabilities that may allow unauthorised access to sensitive data or administrative functionality to remain unresolved in production environments; at the same time they are bound by restrictive contracts which will not permit them to address the security flaws directly themselves.
In these cases, there are a number of avenues available for such organisations:
Contact the vendor for a resolution to the issue
In an ideal world, this would be a rapid process by which the vendor would be informed of the vulnerability, with proof of concept code or process flows supplied as required. The vendor would then identify the source of the vulnerability, institute a solution, and deploy it to all affected customers, along with an appropriate press release or other industry announcement. Unfortunately, while many vendors respond positively to vulnerabilities that have been identified, the response is often slow or involves a workaround to reduce the likelihood of exploitation, without actually addressing the source of the vulnerability. In other cases however, vendors do not respond at all, or if they do, their response is negative or dismissive.
Consider an alternative solution
Sometimes there can be no recourse but to replace the system or application with an alternative one. This itself can be a complicated or expensive process, as any new system or applications will have to be planned, reviewed, tested, and implemented. There may also be specific purchasing or compliance requirements which dictate the vendors that can be dealt with. There may also be a restriction on the types of systems that can be deployed, for example open-source software may not be permitted in some organisations. On the other hand, threatening to “take your business elsewhere” can sometime galvanise a recalcitrant supplier into taking action that they wouldn’t otherwise have taken.
Publish the identified vulnerability
This can be a very controversial decision, and may open up an organisation or individual to reprisal or threats of legal action. It can however drive the information security community forward, informing other potentially at risk organisations and forcing solutions to be found where they may not have been otherwise. There are number of different procedures which can be used for publishing vulnerabilities, and many larger suppliers, such as Microsoft and Google, will have preferred mechanisms in place and may offer financial incentives to those who abide by them.
Attempt to mitigate the risk with other controls
There are some occasions where a vendor cannot be contacted, if they have ceased trading. The application or system may no longer be supported if it is out-dated software or a bespoke development for which the intellectual property is unavailable. An alternative solution may not be practical due to niche functionality, cost, or a lack of available expertise, or contractual or company policy restrictions prevent vulnerability disclosure. In these instances, organisations can seek to mitigate the risks posed by identified vulnerabilities. Some potential mitigations include, but are not limited to:
- Improved firewall and access control restrictions: by only allowing access to certain services from specified sources by trusted systems or individuals, the likelihood of a vulnerability being exploited is reduced.
- Applying standard hardening processes: by reducing the potential attack surface area and addressing any potential unnecessary information leakage issues, the exposure of an identified vulnerability can be reduced, and often the potential impact can also be reduced dramatically.
- Improved monitoring, alerting and response mechanisms: by detecting attempts to exploit identified vulnerabilities, alerting responsible individuals within the organisation, and ensuring an appropriate and proportional response, the vulnerability can sometimes be managed.
Ultimately the final response will be down to the individual organisation to determine, however it is better to consider this in advance, preferably during initial project planning phases, so that a basic policy and an appropriate planning framework can be in place, prior to issues of this type being identified.