Novel Vulnerability

The ubiquity, invisibility and uncertainty created by the Heartbleed cyber-bug

By Joram Borenstein

The significance of the Heartbleed software vulnerability that has been mentioned almost incessantly in the media in the past two months boils down three main concerns: ubiquity, invisibility and uncertainty. To remind you, Heartbleed was a vulnerability—or problem in the software’s source code—that accidentally made information in Web servers (and other devices such as routers) available to attackers through a fairly simple and mundane exploit.

Heartbleed was discovered jointly by a security researcher who works at Google named Neel Mehta and a Finish security company named Codenomicon.

Ubiquity: OpenSSL is an extremely popular and ubiquitous free open-source cryptographic library that is widely used in websites, mobile applications, virtual private networks and many other forms of technology, all of which together combine to form the very fabric of all of our daily interactions with Web and mobile applications, social media channels and cloud computing, the very heart (pun not intended) of our professional and personal lives. Any significant impact to OpenSSL is therefore bound to have significant implications in virtually all walks of life, regardless of location, income, demographic, age or any other characteristic.

Invisibility: The Heartbleed vulnerability is invisible. Once a vulnerable system has been identified, one needs to assume that a compromise has occurred since there is no evidence either to prove or disprove that someone manipulated the vulnerable 64K of memory that Heartbleed exposes. The burden and cost and time associated with remediating vulnerabilities such as this one are not minor; they can and do impact how the bottom line and certainly the user experience and use perception of security.

Uncertainty: Because of the invisible nature of Heartbleed, businesses and individuals alike find themselves uncertain how to proceed on a number of fronts. Questions that people have been asking in recent weeks include these:

(1) Should I move from OpenSSL to an alternative such as GnuTLS, Polar SSL, Mozilla’s Network Security Services or another?
(2) Will regulators weigh in on this issue in the same way that the Federal Financial Institutions Examination Council has already done so?
(3) How much of this remediation should I explicitly share and discuss with my customers?
(4) Should my financial institution blindly rely on all open source projects—such as the Mozilla Firefox browser, the various “flavors” of Linux operating systems, or the word processing and spreadsheet open source suite called OpenOffice—or should my institution instead take a more nuanced approach to open source projects?

While people are not abandoning open source projects by any means, the very fact that it has taken the Heartbleed incident to get the likes of Cisco, Facebook, Dell, VMWare, NetApp, IBM, Microsoft, Intel and others to join forces in the new Core Infrastructure Initiative (within The Linux Foundation) points to the fact that there is growing recognition and awareness that open source projects represent a critical portion of our computing infrastructure globally.

So, while the massive headlines about the Heartbleed vulnerabilities have passed us by more or less, it is instructive to remember why this incident had such massive global implications in an effort to avoid such incidents in the future.

Joram Borenstein ( is vice president at NICE Actimize Inc., a company in New York that provides financial crime, risk and compliance solutions for regional and global financial institutions and payments providers.