The impact of being vulnerable to Heartbleed is that all past and future network traffic could be decrypted, so changing user passwords and SSL certificates is a must. However, the first step should be to update the software and the OpenSSL libraries.

-- Juan Pablo Perez-Etechgoyen, CTO, Onapsis

Heartbleed has been the focus of numerous articles and blogs over the last few months. To find out what measures can be taken to protect SAP applications from Heartbleed, I had Juan Pablo Perez-Etechgoyen, CTO at Onapsis, answer a few questions.

I read that Heartbleed was undetected for at least two years. How did so much time go by without any security companies detecting it sooner?

It's hard to say. Software vulnerabilities exist in every piece of software developed by humans; that's a fact. There are a number of details in this sense to take into account, such as how such a security-sensitive software can go unnoticed suffering from such a critical vulnerability for probably more than two years. But the truth is that a vulnerability becomes real when it's detected and reported (even though it existed for years) and to detect it, companies need to invest in extensive research in security-relevant software, which is very expensive.

What is Heartbleed’s biggest threat to SAP systems? Are SAP systems more vulnerable than other enterprise applications?

As most SAP solutions are not vulnerable to this problem, SAP system's exposure is reduced in comparison to other large-scale implementations. However, there could be some vulnerable scenarios, so Heartbleed's biggest threat would be ultimately the lack of security in the communications, specifically when transporting sensitive information. SAP systems store and process business-critical information, which is also transported through Secure Sockets Layer (SSL). Users’ passwords could be compromised with a critical impact to the business.

Other enterprise applications could have a bigger exposure to this vulnerability, depending on their use of OpenSSL libraries and versions, but this is a case-by-case analysis, such as the one not only SAP (This link is password protected), but also Oracle did.

Is making sure all users who access SAP applications change their passwords all that is needed to protect SAP systems from Heartbleed? If not, what other measures should SAP security administrators take to ward off this bug?

That’s a good start. However, it's not enough mitigation for Heartbleed. The impact of being vulnerable to Heartbleed is that all past and future network traffic could be decrypted, so changing user passwords and SSL certificates is a must. However, the first step should be to update the software and the OpenSSL libraries. Some SAP solutions are indeed vulnerable to Heartbleed, so it is critical to perform all mitigation activities.

Additionally, companies should implement an SAP update and patching process to ensure that the latest patches do not go unnoticed, exposing their SAP implementation. Continuous analysis of SAP vulnerabilities should also be performed to reduce the risk implied by the latest SAP vulnerabilities.

Could any SAP GRC solutions be vulnerable? What about SAP Audit Management or SAP Fraud Management? It would be ironic if any of these systems designed to mitigate risks were actually vulnerable to risk themselves.

As stated by SAP (This link is password protected), Heartbleed does not affect SAP NetWeaver-based products such as SAP GRC solutions and HANA-based products such as SAP Fraud Management. Development standards should be much more secure when it comes to security products, but these products suffer from security vulnerabilities such as any other product, so it is critical to analyze the security of these solutions in terms of vulnerabilities and misconfigurations, just as with any other SAP system.

There would be one vulnerable scenario if an SAP GRC solution or SAP Fraud Management is accessed through a proxy or WAF (Web Application Firewall) using a vulnerable version of the OpenSSL library. (This link is password protected.)

I read that SAP systems that use third-party software may be more vulnerable than SAP systems that don’t use third-party applications. It seems ironic that companies that use third-party software to secure SAP applications may have inadvertently made their systems more vulnerable to Heartbleed. Is this true? Will third-party providers of applications for SAP systems need to develop a patch that companies using their software should apply to their SAP systems?

In terms of Heartbleed, third-party applications may have been developed using vulnerable OpenSSL versions, and that's a problem affecting thousands of applications, not only focused on SAP-related third-party applications. Understanding if it is vulnerable or not depends intrinsically on each application. However, third-party providers are already developing patches for their products that use vulnerable OpenSSL versions. Most likely these products will not require updates to the SAP systems, but to external solutions.

Gary Byrne

Gary is the managing editor of Financials Expert and SCM Expert. Before joining WIS in March 2011, Gary was an editor at Elsevier. In this role he managed the development of manuscripts for Elsevier’s imprint responsible for books on computer security. Gary also has held positions as a copy editor at Aberdeen Group, a Boston-based IT market research company, and as an editor at Internet.com, a publisher of content for the IT community. He also gleaned experience working as a copy editor for International Data Corp., a Framingham, MA-based IT market research company. He earned a bachelor of science degree in journalism from Suffolk University in Boston. He enjoys traveling, sailing as a passenger onboard schooners, and helping his wife, Valerie, with gardening during summer weekends. He’s a fan of all the Boston sports teams and once stood behind Robert Parish in a line at BayBank. He felt small and didn’t ask for an autograph. You can follow him on Twitter at @FI_SCM_Expert. His online footsteps can also be found in the SAP Experts group on LinkedIn.

You may contact the author at gary.byrne@wispubs.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.