More than 95% of SAP systems deployed in enterprises are exposed to vulnerabilities that could lead to a full compromise of business data, a security firm claims.
Onapsis, a Boston-based company that specialises in SAP security audits, also found that the average time-to-patch for SAP vulnerabilities is more than 18 months — 12 months for SAP to issue fixes and 6 months for companies to deploy them.
This suggests that many companies are falling behind on SAP security, even though these systems hold some of their most critical and confidential information. The claim will provide food for thought for delegates at SAP’s Sapphire event in Orlando.
Security assessments
Based on hundreds of security assessments, Onapsis determined that the most likely attack scenarios for compromising SAP systems are these: pivoting from a lower-security system to a critical one to execute remote function modules; creating backdoor accounts on the SAP J2EE User Management Engine by exploiting vulnerabilities to gain access to SAP portals and other internal systems; and exploiting vulnerabilities in the SAP RFC Gateway to execute operating system commands with SAP admin privileges to obtain or modify information in SAP databases.
One of the challenges organisations face is that they cannot reliably use vulnerability management products for SAP as they do for other IT systems, according to Carsten Eiram, chief research officer at vulnerability intelligence firm Risk Based Security.
“The reason is that tracking SAP product vulnerabilities is very difficult due to SAP’s antiquated policy regarding disclosure: They provide information about vulnerabilities to customers only via an access restricted portal,” Eiram said via email. “Furthermore, customers are not permitted to share this information with other parties like vulnerability databases.”
This forces many companies to keep track of SAP security information themselves, instead of relying on security products, which might partially explain why many of them are slow in deploying SAP patches, Eiram said.
One patch, one hole
SAP released 391 security patches last year, of which half were marked as high priority, according to Onapsis. But problems may be even more common than they seem: one security patch does not equal one vulnerability.
The SAP Support Portal contained 388 Security Notes in 2014, said researchers from ERPScan, another company that specialises in SAP security. Each note covered a patch for one or more security vulnerabilities, so the number of individual vulnerabilities is actually higher, they said via email.
Eiram’s company recorded 389 SAP vulnerabilities in its own vulnerability database last year, but he, too, said that number is probably too low.
All statistics, including those from the Common Vulnerabilities and Exposures (CVE) database, suggest that the number of vulnerabilities found in SAP products increased in 2014 from previous years. But counting vulnerabilities has never been an accurate method to gauge the security of a product or a software vendor’s development practices.
“To get a better picture of SAP as a vendor and their products, it’s more interesting to look at response times, like time-to-patch, and the types of vulnerabilities being addressed in the products,” Eiram said.
Based on an analysis of 56 vulnerabilities that third parties reported to SAP, the vendor is not fast at developing and releasing fixes, Eiram said. The company’s average time to produce a patch for those issues was around 8 months — the maximum was 765 days and the minimum 37 days.
Fairly basic
According to Eiram, a quick glance at the vulnerability entries for last year shows that the majority of them are “fairly basic” ones like cross-site scripting (XSS), hard-coded credentials, directory traversals, and missing or improper permission checks. These are issues that a proper security development lifecycle should normally iron out, he said.
ERPScan has also identified cross-site scripting as being the type of flaw that pops up most often in SAP advisories. The company even released a guide to help administrators protect their systems against attacks exploiting such flaws.
SAP defence
SAP defended its security practices.
“SAP has a comprehensive product security strategy across the enterprise that rests on three pillars: ‘Prevent – React — Detect’,” SAP said in an emailed statement. “An important component of this strategy is the ‘Secure Software Development Lifecycle,’ which provides a comprehensive framework of processes, guidelines, tools and staff training. Thus, we are able to ensure that security software is an integral component when it comes to the architecture, design and implementation of SAP solutions.”
Onapsis’s claim that more than 95% of SAP systems are exposed to vulnerabilities is false, and Onapsis is seeking to alienate SAP customers while promoting its own products, SAP said.
Regardless whether that 95% figure is exaggerated, the insecure SAP product deployments are only part of the problem.
SAP is more like a framework on top of which organisations build their own custom systems, said Alexander Polyakov, the CTO of ERPScan, via email. This means that SAP systems are different in every organisation, and in addition to platform vulnerabilities, there are also issues in the custom programs that make up around 50% of SAP implementations, he said.
Those custom programmes often have the same types of vulnerabilities that are commonly found in SAP products: XSS, missing authorisation checks and directory traversal, according to Polyakov.
Many companies outsource the development of their custom SAP-related programs, and security is definitely not a strong point of outsourcing firms, which are typically focused on minimising development time and costs, the ERPScan researchers said.
Lucian Constantin, IDG News Service
Ltd
