Many corporations and medium-sized companies manage their business processes with SAP solutions. Data leaks and sabotage of SAP systems can have disastrous consequences for these companies. Yet SAP risks are often completely underestimated. This post provides a generally understandable insight into some selected SAP security risks.
SAP systems have many specific risks that cannot be captured with “normal” IT security tests. As a result, many of these risks remain undetected in security concepts and conventional penetration tests. Out of ignorance, concepts and tests often focus on the operating system, the database, data transfer encryption, and open ports. However, this falls short.
What are the SAP-specific risks?
First, you need to know that SAP has developed an entire arsenal of proprietary technologies. This includes your own programming language (ABAP), your own ERP server solutions, your own complex communication protocols, your own client with many features, your own web server, your own database, your own database architecture, your own routers and much more. Each of these proprietary technologies has specific risks that need to be known.
In addition to the risks associated with assembling and hardening these various technologies, there are also some organizational challenges.
SAP releases new security patches every second Tuesday of the month. Using the patches, attackers can very quickly determine which vulnerability is the basis of the patch. This is also reflected in the fact that exploits can sometimes appear on the Internet within a few hours after the release of such patches. Companies must therefore establish a process that enables a quick response. Under no circumstances should critical patches be put on the back burner. Patches are of course not an SAP-specific problem. But you can't briefly shut down an SAP system (like the operating system of a laptop). After all, the company wants to remain productive. Companies should therefore establish a patch process that carefully balances the availability of systems against the risks of current patches. Although this is completely obvious and known to all security experts, it is hard to believe how often we find during our analyses that a large number of (older) patches were only applied shortly before our project.
Not only the SAP standard, but also third-party solutions are vulnerable to vulnerabilities, as we repeatedly discover during our security tests. Due to the large number of providers, there is no established process in this area for the regular release of security patches. In fact, many third-party providers don't even know what vulnerabilities their applications have until customers order a penetration test that also includes their solutions. Command injections, hard-coded user accounts and passwords, pseudo-cryptographic methods, and directory traversal vulnerabilities are common in such solutions.
Unfortunately, hardly any company carefully checks third-party solutions or updates for security risks before installing them. Supply chain attacks on SAP are thus opened the door.
Another very common source of security gaps is proprietary developments, some of which companies have been running on their systems for decades. Hardly any company has sufficient programming guidelines for secure development. The risks of vulnerabilities in in-house developments are in principle the same as with third-party solutions. From simple data leaks to vulnerabilities that lead to a complete system crash, you can find everything in source code analyses. However, the errors often lie not only in the code, but also in the architecture, especially when interfaces are involved.
SAP customers are also increasingly using cloud solutions, as SAP is intensively promoting this issue. However, since these solutions work completely differently than classic on-premise ERP systems, errors easily creep in, which, for example, result in arbitrary user accounts gaining access to cloud applications or source code appearing on GitHub.
Most of the risks described above exist regardless of whether customers operate their SAP themselves, host it with third parties, or have it hosted by SAP (SAP RISE).
It is therefore advisable to have a comprehensive security concept specifically for SAP solutions and to call in specialists who are demonstrably familiar with SAP security. The use of automated security scanners alone does not help, because most (medium-sized) companies are overwhelmed by the sheer mass of results from various SAP security areas alone.
If you would like to learn more about SAP-specific security risks and countermeasures, we recommend that you attend the Cyber Defense Roundtable in Frankfurt in May, which we are helping to organize.
For more information, see https://cdrt.net.
