What is SAP Cyber Security, and why is managing SoD insufficient?

SAP technology has changed radically in recent years, and this has had a direct impact on SAP security. This is what drives SAP cyber security. It is no longer sufficient to enforce strong passwords and enable audit logs in the SAP system.

What is SAP Cyber Security?

While implementing SAP GRC helps, ability to manage Segregation of Duties (‘SoD’) is not going to help if someone can compromise SAP user accounts and escalate their privileges. SoD will also not help if an intruder can simply bypass SAP authentication and authorisation controls.

Why is Managing SoD Insufficient?

SAP systems consist of many components such as the NetWeaver Application Server (ABAP and Java versions), SAP gateway and messenger server, RFC gateway, Internet Communications Manager (‘ICM’), SAProuter, and more. The systems use many different communications protocols such as DIAG, Remote Function Call (‘RFC’), and HTTP. They often has a large number of interfaces – mostly using RFC. Many of these have stored logon credentials, which are unencrypted and lack basic security controls.

SAP landscapes also tend to be complex with a large number of systems and clients and users often end up reusing their passwords across these systems. Get hold of one of them, and you have it all. Even when Single Sign On (‘SSO’) is enabled, password logon is allowed, leaving the backdoor vulnerable and open to intruders. A simple scenario will be for an intruder to get the password hash file from a less secure SAP development system, crack the password (if password is backward compatible) and then use the same credentials to logon to SAP production system. In these circumstances, the SAP system has a number of vulnerabilities, leaving it at risk of cyber attacks, data breaches and other threats.

But hold on, isn’t there a Security Operations Centre (‘SOC’) monitoring all my IT systems in order to detect security breaches and malicious intent? Well, more often than not, SAP application level security logs are not integrated with the SOC. An organisations’ SIEM solution is often not configured to monitor SAP logs – probably because they are managed in a Silo by a SAP team within the larger IT team.

And if this is not enough, all SAP systems have a large amount of custom developments, reports and transactions, which are written by SAP programmers who do not have to follow any secure coding requirements. This is because most organisations don’t have one for SAP codes! It is highly likely that these custom developments are never tested for security vulnerabilities, leaving the system unsecured and critical applications open to threats from ransomware, hackers, and other malicious activity. This, despite the fact that simple ABAP-injection may be used to take over the entire SAP system or a directory traversal vulnerability, may be used to shut down the entire system.

Organisations often fail to realise that as the number of known SAP security vulnerabilities have increased manifold. The attack surface for SAP vulnerabilities has also increased with the adoption of newer technologies, and managing complex hybrid SAP environments consisting of on-prem and cloud solutions is becoming more and more complex. The rewards for comprising the ‘crown-jewel of the IT landscape’ continues to be highly tempting. So, it is not surprising that SAP has received more (unwanted) attention from hackers looking to exploit these vulnerabilities during this decade than probably its entire lifespan.

So what should be done to improve SAP cyber security?

IT security teams need to understand the specific challenges in their organisations. Performing an SAP cyber security assessment is a good starting point. Don’t go with the traditional focus on just the SAP ERP production system – instead perform an assessment of the entire SAP landscape.

Once the security risks and vulnerabilities are identified, come up with a roadmap to address these. Identify the ones with high impact but are easy to implement – and go after them first. Have a time-bound and phased approach for the remaining. From our experience, some of the common areas that needs focus are as follows:

• Developing an SAP security baseline/ standard
• Addressing simple configuration related security vulnerabilities
• Upgrading and defining an ongoing security patching process
• Establishing a monitoring mechanism – look-out for attacks and address non-compliance immediately. This also ensures that what was fixed doesn’t break again!
• Securing RFC connections – Unified Connectivity (‘UCON’) provides a structured way
• Enforcing encryption, where possible – this is an often ignored part of SPA network and communications security (think SNC and SSL)
• Securing externally exposed parts of SAP – SAP provides multiple options using gateway & messenger server, SAProuter and WebDispatcher.

It is best to take some of the more complex areas as mini projects.

SAP has published the Secure Operations Map v3 for SAP systems. This covers various topics of interest for SAP security.

Secure Operations Map v3 for SAP Cyber Security Systems

It can serve as a useful reference point for IT security team.

Do I need to worry - my SAP is hosted on cloud?

If SAP is hosted on the cloud, who is responsible for the security of SAP system? While different models exist for SAP on cloud, in general, SAP or the hosting service provider is typically responsible for the hosting and related infrastructure security. The user organization still remains responsible for the application security. Take the example of a house in a gated community. The community provides the security services, so when a visitor comes they will contact the house owner and ask if they are expecting a visitor. The security does not check to see who the visitors are, or if they end up stealing something from the house. The house owner is still responsible for their own security.