Much has been written about the OpenSSL Heartbleed vulnerability, which affects the TLS heartbeat mechanism used by some versions of the OpenSSL library. Numerous open source and commercial products use affected versions of OpenSSL for their implementation of PKI, including enterprise hardware and software products.
The details and inner workings of the vulnerability are not the subject of this article - rather the effectiveness and real-world implementation of protection mechanisms against this and other similar vulnerabilities which may not have experienced the same widespread publicity.
The reality of the situation is whilst this vulnerability has been present for a number of years, apart from potential awareness by intelligence agencies, the threat became real once the vulnerability was published. The systems that have been affected range from webservers to hardware security appliances, and many products in-between.
The first task is to analyse an organisation’s hardware and software inventory to determine affected systems, components and products. As patches are created, tested and published by vendors, then tested and deployed by customers, there exists a significantly-wide window where an organisation is susceptible to compromise.
Most large vendors required at least several days before they made patches available, followed by delays in testing and deployment by the end-user. Adding to this is most patches are released from the US, meaning an overnight delay for many patches before Australian IT departments are able to commence their response.
We observed a massive quantity of OpenSSL Heartbleed attacks on our Australian-based clientele’s assets starting from 3-4 days following the publishing of the vulnerability. It is unrealistic if not impossible, depending on the products used in each environment, to be able to be completely patched within the timeframe from publishing to widespread exploitation.
Clients using Security Centric network perimeter security solutions, including managed UTM solutions were completely protected from OpenSSL Heartbleed less than 36 hours after the vulnerability was published, and well before widespread exploitation began. The protection did not require any end-user actions or testing, and prevented all services including webservers, VPNs, and custom applications from compromise and information disclosure.
The Heartbleed vulnerability is not particularly unique in its attack mechanism, and reinforces the need for defence in depth. Adequate and properly-configured perimeter security; content inspection and intrusion prevention at gateways/aggregations points; ongoing vulnerability management across all types of assets, not just Microsoft operating systems and applications; and across-the-board activity and event monitoring, logging and auditing.