As SAP closes its 3,000th security vulnerability, ERP experts expound on the dangers of these vulns and enterprises’ continued head-in-the-sand attitude about them. See full article here
On the occasion of SAP recently closing its 3,000th vulnerability, experts in the niche field of enterprise resource planning (ERP) security report that, though SAP vulnerability numbers may be dipping, the risk of SAP exploits is actually on the rise. The severity of security notes released by SAP have increased in importance, these experts say, and most enterprises still don’t realize the true scale of the risks they face from criminals seeking to exploit some of their most mission-critical systems and data.
If you’re an attacker, why would you lose time trying to break into a file server or web application or a wireless access point if you can go directly to the systems that fully store their most sensitive data, and you have really low chances of being detected?
Mariano Nunez, CEO of Onapsis
Last week, security researchers with ERPScan released a report to mark the occasion of SAP’s patching of its 3,000th vulnerability. Among its conclusions, the report indicated that the number of vulnerabilities in SAP products within enterprises is usually much higher in proportion to other software portfolio assets than security practitioners think. According to ERPScan, SAP vulnerabilities account for 5% of all vulnerabilities ever published on the Internet.
Meanwhile, ERPScan notes that, though SAP’s secure development lifecycle is improving and the numbers of security updates it releases per year are on a downward trend, the numbers themselves may indicate more improvement than really exists. Part of the issue is that not all SAP vulnerabilities have CVEs attached to them, because many smaller patches are hidden within Service Packs.
While the number of vulnerabilities closed by SAP Security Notes per year is decreasing, SAP moves a lot of vulnerabilities to Service Packs, leaving in security notes only highly critical issues and the issues which were found by external researchers. So, in previous years, only about 10% of monthly published vulnerabilities were found by external researchers, but now up to 60 to 70 are found by them in more recent updates.
Alexander Polyakov, CTO of ERPScan
Nunez agrees that SAP’s outreach to customers about code security is improving, and he says that the shift four years ago to a monthly security patch cycle was key for helping customers plan their updates. But he also warns customers to understand that, because more security fixes are hidden in service packs, the security notes that do come out now are proportionally more important than in years past. “If they’re highlighting specific notes that you should pay attention to, then they’re probably more sensitive or more critical than what you used to get before.”
Additionally, he says that SAP customers may be lulled into a false sense of security by the company itself through some of the updating tools it offers to customers.
To give you an idea, there is a tool called RSECNOTE that is an SAP program you can run in your SAP environment to find unpatched vulnerabilities, but that will only tell you the notes or patches that are critical and easy to implement. In real life, that is actually telling you about less than 20% of the patches that you’re actually missing.
This kind of issue contributes to what both Polyakov and Nunez agree to be an oblivious attitude that enterprises hold about the scope of their SAP vulnerability risks. In particular, some of the top risks organizations face with SAP revolve around configuration vulnerabilities, because SAP is so customizable. Slight configuration tweaks are difficult to carry out, because they could break important business processes.
At the very least, you have to reboot the system to reconfigure it. For example, to close a vulnerability in the authentication protocol of the SAP Software Deployment service, the new versions of client and server software have to be installed, and it can sometimes be quite challenging. It is harder to monitor, check, and control than simply apply patches, which usually close only typical issues, such as XSS or Directory Traversal.
One customer Nunez helped found that it was justifiably worried about breaking systems due to configuration tweaks — just a minute of downtime could cost the company $22 million, according to its estimates. There’s no easy answer to that problem, but he suggests that organizations start by identifying its most valuable SAP systems and then conducting a security assessment of its biggest configuration and patchable vulnerabilities.
Prioritize them based on risk, probability, and impact to the business, and make a top 10 or top 20 list of issues to start raising the bar against potential attackers. Because one thing we see is people are still exposed to vulnerabilities that may be five or 10 years old with public exploits available.