Gunnar Assmy - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Should an OpenSSL-reliant product risk assessment be performed?

Many organizations are still vulnerable to the Heartbleed flaw. Expert Kevin Beaver explores the merits of an OpenSSL-specific risk assessment.

In the wake of Heartbleed, the new version of OpenBSD replaced OpenSSL with LibreSSL. Should we reassess the ongoing risk of products and services that rely on OpenSSL?

Heartbleed was -- and still is -- a security flaw that needs immediate attention on critical network systems.

In a world where we have so many other security issues to worry about, I don't believe the ongoing risks of products and services that rely on OpenSSL need to be of the "drop everything and focus on this" type. That said, every situation is different and every host that is impacted by Heartbleed is different. Thus, every risk is different. Only you will know how it impacts your business and what needs to be done about it. For instance, if you have critical systems that are public-facing and still vulnerable to this exploit, it should be a top priority. On the other hand, if you only have internal systems that are susceptible, it likely won't be as urgent.

As a general rule of thumb, any good information security program is going to (re)assess current and future threats and vulnerabilities as well as their resulting risks regardless of the product or platform. There's no reason to give Heartbleed and OpenSSL any more attention than you would, say, weak passwords on your firewall, missing patches on your database servers or a SQL injection flaw that hasn't yet been uncovered in your cloud service provider's environment that was deemed "secure."

However, should OpenSSL systems and products pose significant threats to your enterprise, it is critical to evaluate alternative options -- and their security risks. Organizations should at least consider LibreSSL and BoringSSL, which are forks of OpenSSL but have better backing which can, presumably, help them remain a bit more stable and secure.

The bottom line: know your network, know your applications and understand how everything working together creates business risks. Then go about doing what it takes to ensure that security incidents don't happen or at least put the proper network security controls in place to minimize their impact when they do.

Ask the Expert:
SearchSecurity expert Kevin Beaver is ready to answer your application security questions -- submit them now. (All questions are anonymous.)

Next Steps

Are LibreSSL and BoringSSL enterprise-grade OpenSSL alternative? Find out here

Uncover the incident response lessons that can be learned from Heartbleed

This was last published in April 2015

Dig Deeper on Open source security tools and software