Heartbleed for enterprise: an issue of unknown import

SUMMARY:

Heartbleed in the enterprise may not be a big deal but silence does not mean all is well.

heartbleedIn a recent diginomica profile, the author said: (paywall)

You won’t see anything about Heartbleed this week on Diginomica. Unlike most IT sites, it doesn’t blow with the wind.

That’s not quite true. It is more the case that we don’t discuss topics we don’t understand. However, Heartbleed is turning out to be so important that we need to say something of value. This is not easy.

The more I read about the Heartbleed vulnerability the more confused I become. None of us on diginomica are what you’d term security experts or even remotely so. From what I can gather, neither are 99% of those commenting on this topic. Like just about everyone else, we rely on what we hope are authorities in the matter to provide sage wisdom. And therein lies one dimension of a problem that appears to have far reaching consequences.

It seems to me that computer security is such a difficult topic to truly understand that it simply doesn’t get enough attention, even among the developer communities. The Register put it well when it noted that:

The crux of the matter is that OpenSSL is used by millions and millions of people, even if they don’t know it, but this vital encryption software – used to secure online shopping and banking, mobile apps, VPNs and much more – has a core developer team of just four volunteers who rely on donations and sponsorship. The library code is free and open source, and is used in countless products and programs, but Seggelmann and others point out that the project receives little help.

The ‘four developers’ mention is not the issue. I’ve seen plenty of examples of extraordinary knowledge and achievement by one developer – Tom Kite on Oracle is probably my stand out example of all time – but then so is Thomas Jung of SAP. The real problem is code support resource. This is especially true in the open source world where, according to The Register:

…and the theory goes that “given enough eyeballs, all bugs are shallow,” meaning that by making the blueprints public, flaws should be quickly spotted and fixed…

…Already people are wondering out loud why more money is not being thrown at OpenSSL, assuming that will do the trick of fixing its bugs. Freeware disk-encryption tool TrueCrypt, favored by NSA whistleblower Ed Snowden, is being audited for vulnerabilities after security researchers raised nearly $60,000 in donations to fund the effort, proving there is a demand for the scrutiny of freely available software.

The article then goes on to speculate that a full audit of OpenSSL could easily cost $15.7 million. Quite frankly, that’s chump change in the context of enterprise software development.

Compare what’s unfolding to the enterprise world, long ridiculed as ‘legacy.’ In an accompanying article, The Register listed 10 business software developers under the eye catching title: Top ten biz software vendors reveal Heartbleed exposure – VMware, Symantec and Citrix are digging, Microsoft and Salesforce are relaxing.

The title is misleading because the enterprise Big Dogs – Microsoft, SAP and Oracle are not reporting vulnerabilities while IBM is looking into it. In the case of SAP, There is a thread that appeared to express concern the company has said nothing on the topic:

As far as I can tell, SAP NetWeaver systems don’t have any built-in OpenSSL components and shouldn’t be vulnerable, but I’m not 100% sure about this.  I’m a little surprised that I can’t find any mention of Heartbleed in any of the forums today.

So, can anyone state with authority that I’m correct about this, and NetWeaver (ABAP and/or Java) systems are not inherently vulnerable to this flaw?

The thread then expands with contributions coming in from SAP security experts that imply SAP landscapes are safe from Heartbleed. All’s well then? Maybe. We cannot know for example what other systems are fed by critical SAP data that may be subject to the Heartbleed issue. Or, as put by Palo Alto Networks:

We already know the issue (an attacker can steal random 64KB chunks of memory via SSL heartbeats). But there’s a key detail often overlooked: any vulnerable SSL service on the machine compromises the entire machine. For example, the SSL VPN server an IT admin uses to remotely connect to a machine? A common VOIP service being secured by SSL? The IRC server hosted behind an SSL login? Each and every single internal and external application using a vulnerable version of SSL needs to be fully patched, or the entire server is still fully compromised. You must consider the scope of all the SSL-enabled applications, whether commercially available or built in-house that an average organization uses to understand Heartbleed’s impact.

Of greater concern to me is the impact at Amazon. Here again, the situation is murky although I did receive an update from a third party service we use that said in email:

We do our SSL Termination at Amazon’s Elastic Load Balancer service, so our first step was to liaise with Amazon to ensure they had patched all of the ELB machines in use by ourselves. As of Wednesday (April 9th) at 11:58am EST, they have confirmed all of their ELB machines were patched and no longer vulnerable.

In another email, CloudFlare said that it had patched for Heartbleed two weeks before the topic aired in the public domain. Confused? You should be.

infor amazonBut what about all the machines in use by Infor, which recently made a strong play about using Amazon for its CloudSuite. I have no issue with Infor’s choice. I admire the fact they’re proactively using services that help contain IT operating costs.

However, last year and much to the chagrin of colleagues – I asked who takes responsibility when something goes awry at Amazon? At the time, the company said that it would shoulder responsibility. In this video shot with colleague Jon Reed, the company goes further. Today? The company’s newsroom is silent on Heartbleed. Presumably there’s no threat.

And herein lies yet another problem. The enterprise community may well sit back smugly and pronounce or imply: ‘no problem here laddy,’ while the Facebook’s of the world are left twisting in the wind. The reality is open source code is frequently used inside commercial enterprise applications. It has become a mark of recognition in some circles to say you have code on GitHub and are likely ‘less legacy’ than if you don’t. What we don’t know – because no-one’s saying – is the extent to which enterprise systems are properly shielded against vulnerabilities coming in from elsewhere.

I don’t expect to see a slew of press releases on this topic from the enterprise players. Rather I expect they are feverishly examining code to ensure that their proprietary – dare I say ‘legacy’ methods – are up to the task, and responding to customer concerns on a case by case basis. If anything, I’d expect the vendors to remain silent or only talk in very carefully couched terms because the legal ramifications are far too dangerous to contemplate.

Should we take heart or remain concerned? That will be for each IT shop to determine. This story is far from over but for once, it seems that being a ‘legacy’ provider might turn out to have been a good thing.

Disclosure: at time of writing, SAP and Oracle are diginomica partners.

Featured image credit: Positively Parkinsons