Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Why Patching Makes My Heart Bleed
Heartbleed was a simple mistake that was allowed to propagate through "business as usual" patching cycles and change management. It could easily happen again.
3 Min Read
Now that we have some chronological and emotional distance from the discovery and disclosure of the Heartbleed vulnerability, cyber security professionals can reflect on some elements of the root cause. As with any complex system, the cause-effect relationship is multi-faceted. At the "heart" of the matter is the reflexive upgrade/patching cycles embedded into the IT processes in most enterprises.
The Heartbleed vulnerability (CVE-2014-0160) in the OpenSSL cryptographic software library affects the security of information protected by Secure Socket Layer/Transport Layer Security (SSL/TLS). SSL/TLS supports secure communication over the Internet for applications such as web browsing, email, instant messaging (IM), and some virtual private network (VPN) implementations.
The vulnerability exists in the OpenSSL implementation of the TLS/DTLS Heartbeat extension as described in RFC 6520. Exploitation of this vulnerability allows access to memory exposing the private key used to establish the secure session. With this key, an attacker may be able to gain access to content in the secure SSL/TLS connection. This may compromise the authentication process by allowing access to usernames and passwords, as well as actual content. It can also allow an attacker to perform a man-in-the-middle attack and/or impersonate legitimate services and users.
The root cause was determined to be a programming error in OpenSSL in December 2011. The vulnerability has been "in the wild" since release 1.0.1 in March 2012. All versions of OpenSSL from 1.0.1 through 1.0.1f contain this vulnerability. OpenSSL 1.0.1g, which was released on April 7, 2014, corrects the problem. Other OpenSSL "branches" (0.9.8 and 1.0.0) are not vulnerable, since they were not affected by the programming error.
The context within which this vulnerability was introduced provides a wakeup call to cyber security and IT professionals. Thoughtful analysis leads to the following points:
A popular argument in favor of open source software is community review. The likelihood and impact of vulnerabilities, whether or not they were introduced maliciously, is thought to be mitigated by the public review process. Clearly, the time needed to discover the programming error and resulting vulnerability in the open community -- more than two years -- indicates that the process may not be effective and is certainly not timely.
Patching is driven by regulatory compliance requirements at the expense of the carefully considered introduction of changes into the environment. Many regulatory and compliance frameworks require that systems be "current" in terms of revisions/patches. This defeats the argument in many of these same frameworks for "business justification" for all changes. The DTLS functionality introduced in release 1.0.1 of SSL/TLS is not needed in many/most organizations.
Change management is not a mature or well-defined process in many organizations. Compliance mandates have led the change control and configuration management process in many organizations to focus on "filing the forms" to have the documentation ready to support an audit request. Few organizations perform meaningful testing prior to implementation in the production environment.
So what should the cybersecurity community be taking away from Heartbleed? I think there are three major action items.
Action Item No. 1: The widespread reliance on common open source software libraries creates a threat vector not assessed or accounted for in most organizations. The impact of cascading failures from single points such as OpenSSL should be assessed.
Action Item No. 2: More rigor must be implemented in the change control and configuration management process. This should focus on the business or technical need for the change, as well as the impact. The focus of this process must be to protect the integrity of production systems, as opposed to audit support.
Action Item No. 3: Compliance frameworks and standards need to recognize that the "latest" release/version is not always the most secure. This will require intelligent commentary and feedback in updating the widely varied frameworks that affect IT systems.
Heartbleed was a simple mistake that was allowed to propagate through "business as usual" patching and change management. A similar but innately malicious piece of code could easily exploit the same path.
About the Author
You May Also Like
More Insights
Webinars
