In recent years, there has been a drastic change in the focus of SAP technology – transition to S/4 HANA, increasing adoption of SAP cloud solutions, changes in user experience (read SAP Fiori) and increasingly complex SAP landscape are some of the common themes across all organisations using SAP. This has a direct impact on SAP security challenges.
The attack surface has increased, and the rewards for comprising the ‘crown-jewel of the IT landscape’ continues to be tempting. So, it is not surprising that SAP has received more (unwanted) attention from hackers during this decade than probably its entire remaining lifespan.
This has not gone unnoticed – organisations are rapidly building up defences. The business as well as compliance teams have invested in SAP GRC as well as cyber security solutions. But one key player seems to have completely ignored this drastic change to SAP security challenges – Auditors!
SAP auditors – now and then:
A large number of auditors (both external as well as internal) are still doing what they did 10 years back – auditing the tip of the iceberg. A typical SAP system audit (which was often an IT general controls audit) 10 years back, covered SAP password parameters, standard SAP user (such as SAP and DDIC) security, audit log settings, client settings, access to critical BASIS transactions, and sample audit of user access and transport approvals & documentation. This was generally limited to PRODUCTION systems only. And that is what a large number of audit teams continue to do today.
Back then, SAP used to be a black box hidden from users and only accessible through these little utilities called SAP Logon Pads. It was mostly an internal system and not known to have security vulnerabilities (because no one had tried to look for one). Hackers had no clue what SAP was and they largely ignored it.
That’s why there’s no time to lose in upgrading to GRC 12.0. Organizations that start planning the move now will not only ensure the smooth continued running of their GRC applications, but will also feel the benefits of the upgrade earlier:
Fast forward to last decade – users can access SAP from the Internet, through their laptops (using SAP Logon Pad as well as web browsers), their mobiles and other mobility devices. Many critical activities like approving a PO can be performed using mobile apps remotely from user own device. Many of these SAP systems have complex interfaces with other SAP and non-SAP systems. And to top it all off, thousands of security vulnerabilities have been reported in various SAP solutions in just a few years.
But the auditors continue to stick to the same SAP systems audit program. And that means, they will often fail in their role of being the third and final line of defence for an organisation.
Let’s see some examples of what the current SAP systems audit is missing. Consider the following questions:
- Having strong password control is good and necessary. But what if I can simply get the passwords stored in SAP tables and decrypt it to get user passwords?
- Locking down the Production system and clients will prevent unauthorised changes to my live operational system. But what if I can use a less secured development system to hop into the Production system with escalated privileges?
- All transport requests are approved to make sure only authorised changes are moved to Production system. But what if the developers can hide critical changes in these transports which are not visible to the naked eyes of the approver?
- The SAP system has been secured. But what if SAP Gateway lets a rogue client/program execute remote RFC calls to make unauthorised changes to vendor bank account details, or create a super user in SAP systems?
- SAP Gateway has been secured. But what if there are unused RFC connections with stored user credentials which can be misused?
- SoD ruleset was approved by the business and is working fine. But is it sufficient when you move from ECC to S/4 HANA? How does the Fiori App and S/4 HANA deployment model impact the effectiveness of SoD ruleset?
There are hundreds of such questions which many of the auditors will find difficult to answer based on their existing SAP system audit work program.
What should auditors do?
To address these new challenges, auditors needs to relook at the way SAP system audits are performed. It is not a job for a ‘generalist’ IT auditor – but instead ‘specialist SAP’ IT auditors are required to look into these areas. Or, the existing auditors need to be trained to understand the new security challenges in SAP.
SAP has published the Secure Operations Map v3 for SAP systems. This covers various topics of interest for SAP security.
This can serve as a useful reference point for auditors to determine whether they are really providing the assurance that they should.
What if my SAP is hosted on cloud?
Another disconcerting view seems to suggest that if SAP is hosted on cloud then SAP manages the security of the SAP system, and therefore organisations need not bother with it. While different models exist for SAP in the cloud, in general, SAP or the hosting service provider is typically responsible for the hosting and related infrastructure security. The organisation still remains responsible for the application layer. Take an example of a house in a gated community. The community provides the security services, so when a visitor comes they will probably 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.
The message is clear – auditors are expected to provide the assurance that the SAP system is secure! And they need to change the approach to SAP system audits to provide this assurance.
