Businesses must bring focus to encrypting sensitive data for defense in depth, and not rely solely on securing networks and systems, which have endless vulnerabilities. Here is yet another critical vulnerability du jour: the Heartbleed bug, announced in an OpenSSL Security Advisory earlier this week. This one’s a big one—”catastrophic,” in the words of security expert Bruce Schneier – “massive”, according to the Wall Street Journal. Heartbleed—officially known as “TLS heartbeat read overrun”—is a vulnerability in 📷the OpenSSL software commonly used to secure Web traffic in transit. When exploited, the bug “allows attackers to scrape the memory of Web servers, grabbing up to 64 kilobytes of the last data communicated,” according to eWeek‘s Robert Lemos. Stolen data could include login credentials, protected information like credit card numbers or ePHI, and, even more worryingly, the servers’ SSL encryption keys themselves. And the Heartbleed bug allows hackers to make off with that data without leaving any trace in the affected server’s logs. “Half a million sites are vulnerable,” Schneier wrote. Most worryingly of all, Heartbleed has been present in OpenSSL for over two years. The OpenSSL Project has released a patch, though for many, the damage has already been done. WHAT CAN ENTERPRISES LEARN FROM THIS LATEST IN A LONG STRING OF HEADLINE-GRABBING SECURITY INCIDENTS? To us, the lesson is clear. If you want to secure your data, then you need to secure your data, not just the infrastructure that transports it and houses it. Think about it this way. Let’s say you have a very nice car, one that you certainly wouldn’t want stolen. So you only park it in locked or guarded garages and only drive it down “safe,” well-patrolled streets. Do those measures mean you can leave your car unlocked and unalarmed, with the keys inside? Can your infrastructure precautions keep your car safe if you don’t secure the car itself? We think not. Garages can be broken into, and, as Heartbleed shows, even supposedly safe transit routes aren’t always as secure as they appear. If you want to protect your car, then you have to secure the car itself. As it is with cars, so it is with data. Infrastructure vulnerabilities can appear anywhere, from the transport layer all the way to the servers. For true, end-to-end data protection, the data itself must be secured in a way that’s independent from transport and storage infrastructure, particularly the kind of Web-facing infrastructure that the Heartbleed bug exposed and that attackers commonly target. That’s why CipherCloud focuses on cloud information protection. The information is what is of value, both to you and to potential attackers, and the information is what must be locked down, using whatever measures are appropriate. Don’t assume that your roads and garages alone can keep your car safe. Identify what data you must protect, apply encryption or tokenization to them before the data leaves your premises, and keep your keys onsite. That way, even a Heartbleed won’t hurt your company. Has your organization been affected by the Heartbleed bug? Tell us your impressions in the comments. NEXT STEPS To find out more about why you need Cloud information protection, check out the following helpful resources: Why Cloud Information Protection? Taking Control of Your Enterprise Cloud Data – download this free eBook to learn about why you need cloud information protection: To retain control of your data; to prevent data theft or leaks; to simplify the complexities of strict regulatory environments, and more… Seven Steps to Protecting Your Cloud Information – This guide will walk you through the 7 steps and key actions toward a unified cloud information protection program to give your enterprise complete control over data integrity, protection and encryption.
*** This is a Security Bloggers Network syndicated blog from CipherCloud CASB+ Platform | Enterprise Cloud Security authored by CipherCloud. Read the original post at: https://www.ciphercloud.com/blog/what-enterprises-should-learn-from-the-heartbleed-openssl-flaw