Meeting with C-Level for many years, discussing SAP security, I get the following message in return:
“we spent several expenses on SAP implementation and you want to say that it is not a secure system?”
No matter how you look at it, the question is on point. After all, a powerful vendor, a lot of implementation partners, huge competences, development of the tool and permanent support of the manufacturer.
The answer is simple– SAP is secure, but under conditions…
It is the customer who is responsible for the proper parameterization of the system. There are a lot of configuration settings whose incorrect definition can lead to a number of dangerous situations.
Example:
default account passwords should be changed and highly privileged profiles (e.g. SAP_ALL) should be removed.
The important thing is that if you delete the default account - it will be recreated automatically (with the default password). The SAP account * should therefore have the password changed and the login / no_automatic_user_sapstar parameter set to 1 (no possibility to restore the automatic SAP account *).
It is therefore the customer who is responsible for adapting these parameters to his needs.
In addition, in technical terms, SAP regularly responds to vulnerabilities found by publishing security notes that effectively load holes and risks. However, it is up to the client to properly upload the note, and this is not always simple and quick.
Example:
Communication without encryption – often forced by complicated environments connecting to the system. Just listen on the internal network to get the content communication.
Note the above architecture. Don't forget all the layers, also those "under" the application layer. Therefore, proper parameterization of the DB or OS is crucial so that a clever user cannot circumvent their authorizations.
Observing SAP implementation projects, one can get the impression that security issues, if addressed at all, are treated with neglect. I have not seen an SAP implementation that would comprehensively deal with the creation of such a concept of permissions, in which the topic of critical authorizations and permission conflicts would be a leading element.
All in all, you can't be surprised if the implementation has to be completed on time and on budget - the most important elements of such an implementation is the quick launch of business functionalities (and I don't argue with that in any way).
After all, SAP provides predefined roles and profiles, and it's very easy to get started with them. This is a shortcut that can backfire in audits, or (worse) in successful user abuse.
Speaking of them - users in mature systems where they have historically "traveled" around the organization they have too many permisstions. This is a consequence of this "journey" and a specific feature of SAP - positive entitlements. In SAP you can't just subtract the powers, the vector is only positive. In addition, deauthorization in the role will propagate to other users immediately.
All this means that when the person - lets call him Brown - works in the organization for many years - roles are more often added than taken away. And here we come to the not-so-pleasing value:
This is average value of used authorizations in the systems, which we had the opportunity to test for safety. It means neither more nor less that 90% of authorizations are simply unnecessary. And this is a simple way to critical accesses and permission conflicts, and thus the first cape of red lights in audits.
Authorization conflicts – here the matter is by definition simple.
"Maintain the 2-eyes rule for critical processes."
Nevertheless, as standard, there are one hundred and several dozen thousand transactions in SAP. We are not able to verify what all transactions mean without appropriate automatisms. Not only that, a person with knowledge in his field of modules will not know about others, and cross-module conflicts are a nightmare.
In the above example pay attention to the column "Transactions”.
Are you able to answer the question of what risk is associated with such a set of transactions using this nomenclature?
What if I told you that there could be hundreds of these conflict sets?
Then the issue gets complicated.
Less than a quarter of SIEM systems monitor business applications in organizations globally (HPE/2016 study). Without laborious risk definition, it is impossible to create a risk definition in a simple way so that the SOC can interpret 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 groups of logs go "around" SAP.
Each of these logs presents specific challenges related to, for example, incorrect classification of events, overwriting or lack of readability. And this makes the SAP monitoring challenges not so easy.
Example of an attack
We encountered clever abuses made by the administrator who processed the orders of goods and their settlements (for fake accounts) using a previously prepared user. The procedure lasted about a year, and would have gone unnoticed if not for greed (but not today).
The administrator assumed that it was enough to create a user's backdoor in such a way as to cover the traces as much as possible. The process is simple:
I change the technical user type to "service". (It should be added here that a technical user is one who often has a lot of privileges and no one should be able to log in to him in dialog mode via SAP GUI).
After this change by SU01 we assume a backdoor user.
Here we just add SAP_ALL, and there are no limits to our actions.
Finally, cleaning up and returning 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 check SAL:
We find:
Of course, you can use ready-made tools such as SAST Security Radar (more at https://lukardi.com/pl/sap-data-security/security-intelligence/), which has such scenarios sewn in libraries, now such action will not go unnoticed.
And here is the whole set of alerts, e.g.:
SAP is secure in itself. However,it depends on the actions of the client how we will take care of data security issues. In this specific context, it is impossible to ignore the benefits of inventories, which are dedicated tools for SAP Security.
author: Tomasz Jurgielewicz
e-mail: tomasz.jurgielewicz@lukardi.com
-------------------------------------------------------------------------------------------------
IT IS ALSO WORTH READING ABOUT SAP SECURITY:
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
