Strategic CIO
Commentary
4/21/2014
09:06 AM
Alex Moss
Alex Moss
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Heartbleed Will Require Rehab

Patches are just band-aids. Heartbleed's long-term effects will force companies to reassess how they deploy and manage technology.

Security experts worldwide have deemed the so-called Heartbleed bug one of the most dangerous security flaws ever to crop up on the Web. While we don't know the full extent of Heartbleed's menace, the bug has the potential to cause catastrophic data breaches. 

When news of Heartbleed broke, Internet users were advised to change all their online passwords as a precaution, and enterprise IT security teams scrambled to neutralize the immediate threat by applying a patch. But like many serious conditions, the real danger posed by the Heartbleed bug is longer term and much more quiet than the initial hoopla might suggest. 

[Millions of websites, applications, and Android devices are vulnerable -- and the list keeps growing. Read 11 Heartbleed Facts.]

Because the bug was embedded in the open source OpenSSL cryptography library that is used by a sizeable percentage of the Web's secure Web servers, millions of people have been potentially affected. But what makes the Heartbleed bug difficult to combat is that we only know that data was exposed. We don't know yet how much of it has been compromised.

Open source is here to stay
The use of open source coding has been widely debated in the technology community. While Heartbleed exposes a risk inherent to its use, it would be a mistake to write open source tools off because of the bug. Contrary to some misconceptions, advocates of an open source approach genuinely work toward the common good and are committed to transparency. It's hardly a Wild West environment. 

Even on closed, proprietary platforms, serious breaches occur, often because people are lax about applying patches to known security vulnerabilities. There are well-documented cases of data security incidents happening years after a patch has been issued on a known bug.

The fact is, sometimes people are lazy about following up on these issues, and occasionally it takes a breach to remind everyone of the importance of maintaining security. As for the long-term effects of Heartbleed, the problem probably won't deter the widespread use of open source code, nor should it.

An open source approach has enormous benefits, such as ease of deployment and compatibility across multiple platforms. Just as automakers focus on vehicle design and leave tire manufacturing to third parties, developers tend to focus on creating software and rely on open source tools to secure the traffic, passwords, and other data transmitted to and from users and visitors. 

No quick fixes, but action and leadership are needed
The Heartbleed bug is still a major wake-up call. While security-sensitive developers and users are enacting the limited quick-fixes that are available to them (i.e., patching the security flaw and changing passwords), the larger issue is that most companies haven't properly catalogued the technology they're using to manage traffic to both in-house applications and purchased software.

To get a sense of the problem of addressing risk exposure without a detailed catalog of assets, consider the task of a CTO at an enterprise that uses 50,000 servers. She reads a report about the Heartbleed bug and knows it's important to apply patches, but how does she even know where to start unless she has thoroughly documented what technologies are deployed, where they are implemented, and for what purpose they are used?

The Heartbleed bug is obviously a major challenge for financial institutions, but bank websites handle a variety of tasks. A server powering a customer portal for leaving feedback on customer service might not collect highly sensitive information, whereas a compromised online banking application that collects usernames and passwords used to access accounts would obviously pose a huge risk. A catalog detailing what open source code was used to build every application and where it is deployed would give an IT team the tools they need to prioritize the cleanup. 

For all the alarming coverage of Heartbleed, so far the concerns have focused primarily on the potential for a data breach caused by the bug, which is doubtless huge, given the nature of the flaw. Heartbleed is the "ghost in the machine." Eventually, we'll hear about some real-world consequences worthy of being front-page news.

Balancing user convenience and security has been a delicate game since the inception of the Web. Heartbleed won't change that. After the short-term remedies are applied, the long-term rehabilitation -- a meticulous cataloging of technology deployments -- will have to get underway. That's going to take a commitment at the leadership level.

Find out how a government program is putting cloud computing on the fast track to better security. Also in the Cloud Security issue of InformationWeek Government: Defense CIO Teri Takai on why FedRAMP helps everyone.

Alex Moss is Managing Director of security consulting firm Conventus and a thought leader on server and endpoint infrastructure security with more than a decade of hands-on experience researching, designing, implementing, and maintaining IT and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
asksqn
50%
50%
asksqn,
User Rank: Ninja
4/22/2014 | 6:12:54 PM
Heartbleed Virus is just the tip of the iceberg
The Heartbleed bug is obviously a major challenge for financial institutions, but bank websites handle a variety of tasks. [...]

I would think what with the billions in bail out money that the banking cartel has taken from taxpayers that it would use some of its money to hire competent I.T. departments instead of applying another layer of million dollar bonuses to executive officers. 
Charlie Babcock
50%
50%
Charlie Babcock,
User Rank: Author
4/21/2014 | 9:01:27 PM
After the ER, a long term rehabilitation
Yes, recovery from HeartBleed will be "a long term rehabilitation," as well as short term emergency room visit. That's exactly right.
hgolden913
50%
50%
hgolden913,
User Rank: Apprentice
4/21/2014 | 2:23:36 PM
Re: Vetting the code
I highly recommend reading Poul-Henning Kamp's article, "A Generation Lost in the Bazaar," http://queue.acm.org/detail.cfm?id=2349257#content-comments and its full comments (http://queue.acm.org/fullcomments.cfm?id=2349257). My comment, restated, is that a  "quality improvement institute, factory and service" might help.

Open source is well established now in industry, and the problems are apparent to all. However, the benefits are seen as even greater. This creates an opportunity to improve existing open source software and future development and maintenance processes. (Not surprisingly, this same opportunity exists for closed source software.) Therefore, there should be a willingness on the part of government and industry to fund quality improvement. (I don't attempt to specify whether such organization(s) are for-profit or not-for-profit, but their products would need to be open for use without compensation for them to benefit open source developers.)

There are several approaches that should be pursued: (1) Improved training and education for developers; (2) Identification and promulgation of better or best practices (in choices of languages, tools and development processes); (3) Identification of existing software most in need of remediation or replacement; (4) Funding remediation/replacement of the most important needs; (5) Outreach to existing projects with offers to help adopt better practices; (6) Outreach to academia to encourage training in better practices; (7) Advice for starting new projects following best practices appropriate for the project size; (8) Funding development of tools to support better or best practices. (9) Review of existing tools and offering constructive suggestions for improvement, perhaps with funding.
elcaab
IW Pick
100%
0%
elcaab,
User Rank: Apprentice
4/21/2014 | 12:03:09 PM
Vetting the code
Vendors should do a better job in vetting open-source code they use in their products. Especially if these products are to be used in a critical security role.

 
Ulf Mattsson
50%
50%
Ulf Mattsson,
User Rank: Strategist
4/21/2014 | 11:23:52 AM
I think that we need to take real proactive steps

I agree that "Patches are just band-aids ", and I think that we need to take real proactive steps.

We know that the vulnerable technology has been in place on up to two-thirds of all websites for approximately two years, the damage may already be done, and organization that uses OpenSSL rushes to fix the vulnerability before hackers can steal more data.

So what can we do to try to prevent the data theft?

Waiting for better software or protocols isn't really an option.  While new software will inevitably come along, there are limited guarantees, especially in the case of open-source technology such as OpenSSL, that it will be bug-free.  In fact, we should expect that they will be breached.

The most viable option is proactive security of the data itself.  By tokenizing or encrypting sensitive data at the point of creation or acquisition, it can be made useless to potential thieves, even in memory.

There's no perfect answer to fix years of exposure, but moving forward, adopting the most proven, vendor-backed data security solutions that protect the data itself can offer significantly reduced risk over protocols alone.

Ulf Mattsson, CTO Protegrity

David F. Carr
50%
50%
David F. Carr,
User Rank: Author
4/21/2014 | 9:52:58 AM
Do you know where your (potentially vulnerable) software is?
This raises a good question for readers: does your organization have a good catalog of the commercial and open source software deployed on websites and systems that could be subject to attack? How quickly could you track down where a software module with a newly discovered vulnerability was installed and figure out what to do about it?
Research: 2014 US IT Salary Survey
Research: 2014 US IT Salary Survey
Our survey of nearly 12,000 respondents shows IT pays well -- staffers rack up a median total compensation of $92,000, and managers hit $120,000. Industry matters. And the gender pay gap is real and getting wider.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Tech Digest September 18, 2014
Enterprise social network success starts and ends with integration. Here's how to finally make collaboration click.
Flash Poll
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
The weekly wrap-up of the top stories from InformationWeek.com this week.
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.