Ye Bloody Gods!!! 74 percent of big business yet to fix Heartbleed flaw

happygeek 2 Tallied Votes 383 Views Share

According to new research from Venafi, apparently some 74 percent of 'Forbes Global 2000 organizations' (or the big boys of business if you prefer) have yet to properly secure their public facing servers against the Heartbleed OpenSSL threat. That's a year after the thing broke for goodness sake! Venafi found that at least 580,000 hosts belonging to this elite group of enterprises were still vulnerable as full and proper threat remediation had not been applied. They were patched, yes, but did not bother with the equally important steps of replacing private keys and revoking the old certificates. Apparently, looking at the market in general, it would seem that more than half of organizations simply have no idea how many keys or how many certificates have, or even where they are being used. If you are in the US you can be happiest, if that's the right word, as your big business boys sit just behind Germany at the top of the remediation tree with a 41 percent total. That's still pretty poor, of course, but way better than Australia on 16 percent.

Patrick Wheeler, director at Proofpoint, says “the fact that so many systems remain vulnerable to Heartbleed highlights the difficulty of basing security on patching production systems. Organizations have to balance the needs of business-critical applications with the duty to take all reasonable, industry-standard measures to protect employee and customer data. Incorporating security fixes can be all the more difficult in the case of an issue like Heartbleed, where verification of the fix is much more difficult than simply testing for a patch or a server response. The best way to address this challenge is to complement patching and effective system management with a layered approach to protect sensitive data in motion and at rest. This includes monitoring and blocking both exploits and content at the network, gateway, server and user levels, tightly integrated with threat intelligence and automated threat response capabilities.”

Meanwhile, Phil Lieberman, CEO of Lieberman Software Corporation, adds "The lack of complete or near complete remediation comes as no surprise. Because open-source based software has no standardized (and even more important) automated method of pushing repairs of defective software en masse, the lack of remediation is expected since most upgrades must be initiated by the end-customer assuming that the developer has a working update. By personal experience, we tried to update a pair of S----wall VPN/Firewalls to patch the Heartbleed vulnerability and were left with 2 bricked devices and the opportunity to spend hours arguing with an off-shore support department uninterested in resolving our problem. Given this bad experience, we are now loathe to patch any embedded system ourselves because of the risk of losing availability permanently. We replaced the bricked devices with another manufacturer that is responsible for patching their own devices by themselves. Every time I walk into our server room I see the dead S----wall devices and cringe at our stupidity buying them and in buying devices that embed open source. The other element to consider is that many organization don’t even know what devices or software they purchased that has open source with flaws (many companies don’t disclose it until too late or never). Given the lack of understanding of what is owned coupled with a lack of labour and expertise to patch them, most of the defective goods go un-remediated. There is also the issue of corporate career suicide as you explain why you bought open source (and potentially unsupported) based products and why you are loathe patching them as it may send the organization off the air permanently."

Dani AI

Generated

As noted, the thread highlights a familiar failure mode: technical teams patch software but stop short of full remediation. The replies from and add useful context — cost pressure and a reactive DFIR market both push organizations toward short-term fixes. The practical problem is process, not glamour: without an accurate inventory and a repeatable playbook, key material and TLS endpoints will remain exposed long after a patch is applied.

Recommended short-term remediation checklist (apply in this order):

  • Take inventory of all TLS endpoints and certificate/key stores (public services, load balancers, cloud apps, admin consoles, embedded appliances). Use active discovery plus CMDB and service owners to find hidden systems.
  • Apply vendor fixes or updated TLS stacks in a controlled window, but only as the first step. Immediately generate new key pairs, request new certificates and deploy them to every endpoint that used the old key.
  • Verify new certs are serving and healthy (chain, SNI, OCSP/CRL behaviour) before revoking old certificates. Revoke only after new keys are universally active to avoid outages.
  • If a device cannot be safely patched (bricked devices, unsupported firmware), place compensating controls: network isolation, TLS termination at a managed reverse proxy, strict firewall rules, and increased monitoring.

Embedded appliances and vendor-managed kit deserve special handling: test firmware updates on a representative unit, capture full backups and a rollback plan, and require vendors to provide signed update images and support SLAs. For long-term resilience, deploy centralized certificate lifecycle management, automate regular TLS scans, integrate key rotation into change control, and adopt HSM or KMS-backed private key storage. Finally, frame remediation as a quantified business decision for management: targeted, prioritized fixes and an annual rekeying schedule cost far less than DFIR, breach notification, and reputation damage.

Slavi 94 Master Poster Featured Poster

They either don't understand the risks or they just don't care about protecting sensitive data. Think heartbleed is ranked #1 critical flaw for 2014 followed by shellshocker

rubberman 1,355 Nearly a Posting Virtuoso Featured Poster

A lot of the ignoring of these issues is due to management not wanting to deal with the costs involved. They seem to take the stance that "we aren't being hacked, so why pay the price?". The old addage of "penny wise, but pound foolish" comes to mind...

happygeek 2,411 Most Valuable Poster Team Colleague Featured Poster

Talking to a number of consultants specialising in IT security, it seems that the 'big boys' are leading the way with those remediation stats. Look to the medium sized enterprises sector and remediation falls to around 10%. Their future could be, erm, interesting to say the least.

Slavi 94 Master Poster Featured Poster

I agree with rubben, could be cost issue and they'd rather not deal with it until its too late, thats why #DFIR is becoming so popular (Hey I got hacked, come and fix everything as it didn't happen)

Although it's understandable to not spend money on top of what has already been, I guess it's better to do spend some rather than be left out of business, some of those organisations' web servers are quite popular and are visited tens of thousands of times daily. That really exposes a lot of customers and the company as well, i mean even a simple XXS can be catastrophic, such as redirect user to a similiar looking page with a big red text saying please download our new protect's update it has awesome features .. well you could imagine what those features are :D

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.