It has barely been a month since the announcement of the Heartbleed bug, and all seems to have gone fairly quiet. What has happened in the meantime? What’s the cost of the breach? How many people and organizations did it really impact? Are there affected systems still out there today? What went wrong in the first place? What should we do going forward to prevent this from happening again?

So far, the only known or published breach due to Heartbleed is the Canada Revenue Agency. We expect more to appear, but due to the nature of the bug and the fact that exploitation doesn’t leave a trace, we will never know the true impact. What we are starting to see appear are some cost estimates of the damage. As an example, many organizations need to revoke SSL certificates and issue new certificates. Just the traffic alone for delivering certificate revocation lists can mean large bills in the several hundred-thousand dollar range. Add together all the providers that need to revoke certificates together, and the sum could be astronomical. A total figure of $500 million has been floated around. And some think that number is on the low side.

At the same time that organizations are fighting to rid themselves of the bug and its aftermath, the criticisms of the OpenSSL project leaders and its developers has begun. Robin Segglemann, who introduced the bug accidentally, has gone on record to say that OpenSSL is not reviewed by enough people. Ben Laurie, an OpenSSL developer, stated that a security audit would have found the bug. 

We live in a world dominated by open source software. We love it because it meets our needs, the innovation is out there and of course, it reduces costs dramatically. But relying on free software comes at a cost, as this recent bug has shown us. Lots of people are pointing fingers, but most of the software engineers who are contributing to open-source projects are doing it for free, in their spare time. Perhaps the OpenSSL developers should not be blamed as much as the OpenSSL users. Without better funding and testing, who is really to blame? At the time that Heartbleed was discovered, the project had one full-time developer, and a handful of part-time developers. For such a critical part of the Internet, shouldn’t others participate?

Many commercial companies are investing in open-source software. It’s a way for them to use open-source in their own products to get them to market faster. In some cases, they contribute back to the open source community. In other cases, companies participate to steer the projects in a direction that meets their needs. Either way, the open source community, or at least specific projects, are financially backed by some of the largest commercial technology companies. But just contributing money and engineering resources are not going to solve issues such as Heartbleed. Solid project management, meticulous code reviews and extensive testing are needed. These are skills that the commercial companies can and should bring to the table. We can’t afford to have new releases of critical components such as OpenSSL hit the market without an extensive period of testing and code review.

What can enterprise security executives do to protect their infrastructure and use of cloud services?

• Don’t punt on security. Make sure your staff are well-educated and understand what the weaknesses are in today’s virtualized and cloud environments. Have the right controls in place and make sure they’re enforced and that all staff follow those guidelines. 
• If you don’t feel that you understand the vulnerabilities in your infrastructure or that your staff don’t understand the issues, bring in a consultant or work with organizations that do understand the issues. Many of the standards bodies have excellent, free documentation that will help educate you and your staff. Make sure your non-IT staff understand why you need these controls.
• Encourage administrators to be vocal about weaknesses in your infrastructure. The cost of a data breach could cost you your business. According to research firm Ponemon, 60 percent of small businesses close permanently within a year of discovering a breach. Ninety percent close within two years.
• Implement access controls, role-based monitoring and data encryption to ensure that critical systems and sensitive data are protected.

In short, don’t wait until you experience a breach. Be proactive and place security at the top of your list of priorities. Many people in an organization feel that security teams are always the “guys who say no.” Be the one who says “yes, as long as the correct security policy is being followed.”