SAP Security - Where to Start from?
- Security
For many years, when meeting with C-Level, discussing SAP security, I get this message back:
"we spent several million zlotys on SAP implementation and you want to say that it is not a secure system?"
Any way you look at it - the question is on point. After all, a powerful vendor, a host of implementation partners, great competence, development of the tool and permanent support of the manufacturer.
The answer to the question is simple - SAP is secure, but...
"But" No. 1 - configuration
It is the customer who is responsible for properly parameterizing the system. There is a mass of configuration settings, the incorrect definition of which can lead to a number of dangerous situations.
Example:
The passwords of default accounts should be changed, and highly privileged profiles (e.g., SAP_ALL) should be deleted.
The important thing is that if you delete the default account - it will recreate itself automatically (with the default password). The SAP* account should therefore have its password changed and the login/no_automatic_user_sapstar parameter set to 1 (no automatic reconstitution of the SAP* account).
It is therefore the customer's responsibility to adjust these parameters to suit his needs.
On the technical side, in addition, SAP regularly responds to vulnerabilities found by publishing security notes that effectively load holes and risks. However, it is up to the customer to properly upload the note, and this is not always easy or quick.
Example:
Communication without encryption - often even forced by complex environments connecting to the system. Just listen on the internal network to get the content of the communication.


Pay attention, to the above architecture. Do not forget all layers, including those "under" the application layer. So, proper parameterization of the DB or OS is key, so that a clever user will not be able to bypass his authorizations.
"But" No. 2 - authorizations
Observing SAP implementation projects, one gets the impression that security issues-if they have been addressed at all-are treated in a low-key manner. I have not seen an SAP implementation that comprehensively addressed the creation of such a concept of authorizations, in which the topic of critical authorizations and authorization conflicts would be a leading element.
All in all, one may not be surprised if the implementation has to finish on time and on budget - the most important elements of such an implementation are the rapid deployment of business functionality (and I am not arguing with this in any way).
After all, SAP provides predefined roles and profiles, and it's very easy to start working with them. This is a shortcut that can backfire in audits, or (worse) in effective abuse by users.
If we are talking about them - users in mature systems, where they have historically "traveled" through the organization, have too much power. This is a consequence of this "journey", and a particular feature of SAP - positive permissions. In SAP, you can not simply subtract authorizations, the vector is only positive. In addition, the subtraction of authorization in a role will propagate to other users momentarily.
All this makes when the proverbial Blacksmith works in an organization for many years -. roles are more often added than taken away. And here we come to a value that is not pleasing to the eye:
10%
It is average value of authorizations used in the systems, which we had the opportunity to study for safety. This means no less than that 90% authorizations are simply unnecessary. And that's a straight path to critical access and privilege conflicts, thus the first cape of red lights in audits.
Conflicts of authority - Here the matter is simple by definition.
"Maintain the 2-pair-of-eyes rule when implementing critical processes."
Nevertheless, there are one hundred and tens of thousands of transactions in SAP as standard. We are not able to verify what all the transactions mean without appropriate automations. Hardly a person with knowledge of his scope of modules will not know about others, and cross-module conflicts are a nightmare.


In the above example note the "Transactions" column.
With the help of this nomenclature, are you able to answer the question of what risks are involved in such a set of transactions?
What if I told you that these sets of conflicts could be hundreds?
Then the issue gets complicated.
"But" No. 3 - monitoring
Less than a quarter of SIEM systems monitor business applications in organizations globally (HPE/2016 survey). It is impossible to create risk definitions in a straightforward manner without strenuous risk definition so that the SOC can intepret critical events.
The multitude of SAP log sources is also an element supporting the lack of transparency of what is happening in the system.


Above is an example of what log groups go "around" SAP.
Each of these logs presents its own challenges related to, for example, incorrect classification of events, overwriting, or lack of readability. And that makes the challenges with SAP monitoring not so easy.
Example of an attack
We encountered clever abuses, carried out by an administrator, who processed orders for goods and their settlement (to fake accounts) using a previously prepared user. The procedure lasted about a year, and would have gone unnoticed if not for greed (but about that not today).
The administrator assumed that it would be enough to create a backdoor of the user in such a way as to cover his tracks as much as possible. The process is simple:


I change the type of technical user to "service". (Here it should be added that a technical user is one who often has a lot of privileges, and no one should be able to log into it in dialog mode via SAP GUI).
After this change by SU01, we set up a backdoor user.


Here we just add SAP_ALL, and there is no limit to our actions.
Finally, clean up and return the technical user to System mode. The whole thing takes no more than 5 minutes. Let's look at the traces in the system. Let's take a look at SAL:




And there:
- no profile info SAP_ALL
- no info about changing technical user into service mode
- in red the creation of a user (yes, SAL in red shows the creation of each user, so in the maze of daily activities it is easy to miss).
You can, of course, help yourself to ready-made tools like SAST Security Radar, which has such scenarios sewn into its libraries, in now such an action will not go unnoticed.


And here a whole set of alerts, such as:
- Changing the mode to service and technical user dialog login,
- add SAP_ALL.
SUMMARY
SAP is secure in itself. However, it is up to the customer's actions to take care of data security issues. In this particular context, it is impossible to ignore the inventory benefits of dedicated SAP Security tools.
The more comprehensively security topics are addressed (i.e., both monitoring, authorization and technical issues are provided) - the lower the risks to your data.
More from the category
- Security



Tomasz Jurgielewicz
Head of Security Department at Lukardi. For the past 10 years, he has led a team of SAP Security specialists, providing comprehensive services and tools to secure SAP systems and optimize licenses. Experience in the areas of: - identification of authorization conflicts and authorization reorganization, - identification of SAP vulnerabilities, - integration of SIEM solutions with SAP, - optimization of SAP licenses.