main

Security

Heartbleed Bug: Three steps on what to do next

April 9, 2014 — by Motty Alon2

As you’ve most likely heard, a very serious threat called CVE-2014-0160, commonly referred to as “Heartbleed” has been threatening the ultra-popular open-source OpenSSL package. Heartbleed is unique in the collateral damage it can create.

Heartbleed exposes the ugly side of open-source security components: In past events, where such Earth-shaking vulnerabilities were found, there was a vendor that would pay for the collateral damages that the vulnerability created. Who would pay for the collateral damages of this open-source vulnerability? It is likely be the users that are using OpenSSL.

It’s also a sad day for NIST and the FIPS 140-2 audit labs, and for the FIPS certification market-advocates. OpenSSL was the first open-source module that went through FIPS 140-2 validation process. FIPS 140-2 is the most appreciated token of robustness and security. However, Heartbleed may raise concerns of FIPS validation, just like the Target breach raised questions about the robustness of PCI.

What security professionals need to do:

  • Next budget planning: Whenever considering an open-source security solution vs. a commercial / proprietary one, add to your risk and cost calculations the (lack-of) indemnification for damages created by open-source vulnerabilities to your risk/cost calculations. TCO and ROI models may change considerably based on this item.
  • Next Security Review: Don’t be fooled by 3rd party audit, compliance and validation processes. Always make sure that you understand the known risks, build proper security architecture and run penetration tests. Remember that there are no free-lunches in this process.
  • Next Steps: Review your security architecture. There is always a room to improve. Have you considered Web Application Firewall? IPS solution or DLP? None of them are perfect but the multi-layer approach may save the day.

It’s also important to remember that you don’t put all your eggs in one basket. The tone in cyber-security planning is using multi-layers for data-protection. You may use OpenSSL to encrypt your sensitive data, but installing a Web Application Firewall may block both the attacks and the data that may leak from the site.

Like this article? Receive similar articles by subscribing to our blog today!

Motty Alon

2 comments

  • I2000

    April 12, 2014 at 7:05 pm

    After putting my application through WAF it becomes vulnerable.

    Reply

  • Robert Henrichs

    April 30, 2014 at 3:51 pm

    Indemnification? Who indemnifies commercial software. Your “agreement(s)” will not give you anything other than “we’ll update the software to the best of our ability”. Or less.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *