Lessons From The Heartbleed Bug

What should credit unions take away from this code vulnerability?

Do you remember the Heartbleed bug? The one that took advantage of an overrun vulnerability in the OpenSSL cryptographic library and affected 17 % (500,000) of SSL (Secure Sockets Layer) web servers? Many websites we trusted to keep sensitive information secure failed to do just that.

Let me preface this post by saying I am not an expert on cybersecurity, nor do I play one on Television. However, a basic grasp of the infection, its beginnings, and the lessons learned can be had by even the most technologically averse among us. Heartbleed resulted from improper input validation in the implementation of the Transport Layer Security (TLS) heartbeat extension. At a basic level, the software was allowing more data to be read than should have been allowed.

The specifics of the bug are fascinating, though beyond the scope of this article. Suffice it to say that because of a flow in the OpenSSL, one of the world’s most widely used security libraries, Jim Zemlin, executive director at The Linux Foundation, tells Information Security Media Group, the bug coerced websites into over sharing saved information.

Welcome back, Erik Payne the website might say to the bug. Here’s relevant information tied to your account: username, password, birthday, social security number, bank account information etc. Thanks to inflated character limits, the bug could gain access to a variety of personal information before the website’s code would hit its limit.

Many corners of the Internet shared information on how to respond to these vulnerabilitiesfor further reading on the subject, allow me to recommend this Forbes article,but the nature of the problem was ultimately very simple: Those who maintained OpenSSL were underfunded, understaffed, and failed to find a mistake in their code for more than two years.

In recent days, the Open SSL Project a volunteer effort that works to improve cryptographic functionality received funding from the Core Infrastructure Initiative (run by giants in the field of technology)that will allow the project to hire two additional full-time core developers to work on OpenSSL as well as enough funding to run a third-party security audit of the OpenSSL code base a retro fix to a long-term problem. How this investment plays out in the future remains to be seen.

In retrospect, the issues with the code and coders may have been self-evident. OpenSSL is one of the largest online security libraries. Yet, it was maintained by one full-time employee and a handful of volunteers. Additionally, the project received on average just $2,000 in yearly donations, according to Steve Marquess, co-founder and president of the OpenSSL Software Foundation. That’s chump change for those tasked with securitizing a chunk of the Internet.

The lessons here for credit unions are twofold:

First, institutions should not underestimate the scale to which they operate online. According to Callahan & Associates Peer-to-Peer data as of fourth quarter 2013 (the most recent data available), 72.6% of members used their institution’s online banking feature; 35.6% used a mobile banking option. When you consider that credit unions had approximately 96.6 million members as of fourth quarter 2013 and 98.5 million by first quarter 2014, those members who use some form of online or mobile banking represent some 70 million individuals, perhaps more.

Second, as the previous figures suggest, online and mobile are channels that will continue to grow, especially as the next generations rely even more on technology. Securing data is an area that necessitates funding and ever-increasing personnel if members are to trust mobile banking. Credit unions should be constantly evaluating, re-evaluating, and improving their online and mobile banking software platforms. This may be self-evident in nature but, as OpenSSL demonstrates, not always in practice.

June 6, 2014

Keep Reading

View all posts in:
More on:
Scroll to Top
Verified by MonsterInsights