SAP Security Risks - System Users

[Former Member]

In many of the SAP security guides and OSS notes, SAP states that system users should be restricted to the minimum permissions needed to perform their approved activities. Assigning SAP_ALL or SAP_NEW is great for debugging, but a risk in a production environment. What are the associated risks? How can they be exploited? (ODBC connections, portal access, RFC connections, Visual Basic apps, Excel) Is the risk limited to the developers of the application also creating additional functionality for downloading data, displaying sensitive information, etc?

[Former Member]

Greg,

If the user ID is compromised there are many risks.

At the very least access to unauthorized data. At most shutting down a system. If an ID has sap_all it can do close to everything.

ID's that run background and other non-dialog processes should at lease be stripped down of security access and sensitive basis objects.

There are different kinds of exploits/back doors depending on version, in which I won't go into detail here, that can allow access to these ID's. Examples, password cracks/hacks, user buffers, debugging access other misc back doors.

The risk is to the entire instance and other instances connected to it if the ID has sap_all.

Cheers,

Ben

[Former Member]

I only used SAP_ALL and SAP_NEW as an example. Maybe excessive permissions to sensitive authorization objects would have been a better description. I realize that within SAP the authorization objects would provide the ability to display, crate, change data that should have been restricted. However, a system id would need to be more creative than a dialog user to be exploited in releases such as ECC 5.0, 4.7, SCM, etc. they would not have the ability to use the SAP GUI and normal SAP ABAP screens. So with this additional information, what is the risk of providing excessive permissions to a system user and what are some basic ways that it can be exploited? I provided some initial examples in my original post.

[Former Member]

Even if the ID does not have sap_all it may still have some sensitive objects.

One often overlooked area is the ability to submit jobs using another ID's authority (S_BTCH_NAM). A user could create a new job and have it run under one of these powerful ID's.

Also depending, on parameter settings and specific auths, a user can temporarily get the access of one of these ID's via the user buffers. Thus they are getting the powerful access and using the sapgui.

Cheers,

Ben

[Former Member]

If you know the ID & PWD of a system user, it's a reasonably simple task to knock up some VBA in something like excel to connect to SAP via RFC & execute Function Modules under that ID.

There are a few example data retrieval proofs of the above concept & it's not a huge leap to go from that to executing FM's that can change or delete stuff if you have a basic understanding of ABAP.

As Ben said, another easy one would be to schedule jobs using a powerful ID, though that should be restricted for most users.

[Former Member]

Hi Greg,

In addition to what Alex and Ben have said about the buffering / rfc / job administration / debugging / etc, it might be advisable to design processes such that system users and their services only do mundate, boring & generic tasks which do not represent a security hazard or compliance risk. Then only give the users running those tasks the bare minimum which they need to deliver the data from A to B or whatever before the dialog user can take over again for the less mundate steps where a decision is required. That also makes analysis and forensics based on users easier.

The reason why I say that is because us bean-counters (accountants + auditors) have a tough time finding preventative controls in the system when the inherently risky updates (vendor data, payments, etc) all have a generic system user as their author. The consequence is expensive compensating controls and lots of red ink and substantive testing of the transaction data... believe me, that is very boring and not fun at all!

Another (more security related) reason for it, is that active dialog users would have a chance to notice when something strange happens to their user account (e.g. password reset) or their payslip is intercepted, or their colleague who is on holiday is still working... or whatever else they have access to, and could report it to the appropriate admin. Generic system users are not security alert, dont go on holiday and in many cases a reset password will go unnoticed and without consequences, so more monitoring is required to cover the same risk.

The wider their system, security and application access gets => the tougher it becomes to monitor them and what they have done (another mundate boring task) => the more substantive testing will be demanded by the auditors (they love that BTW! It is their bread and butter after corporate scandals, SOX, Basel II, etc) and they will be less likely to backoff when you want them to place reliance on your own internal IT dependent or automated controls.

That is my 2 cents worth to the topic and sorry for mentioning the "unwort" <= German for "unspeakable word".

Cheers,

Julius

[Former Member]

I am very familiar with the risks as I have several years of SAP security experience developing roles to provide only those tasks that are necessary. Working with your bean counter friends, I have been asked what is the risk and how to exploit it. I know many of the risks, but I need to document how you would exploit it when you know the userid and potentially also the password. Through loss of data through an ODBC connection in Excel or Access are potential ways. From visual basic, visual composer, portal apps, and many others there are many other ways to exploit this. I am surprised that there were not several quick answers on how to exploit the risk. Maybe we all follow best practices and never had to explain the risk and how it could be exploited to auditors.

[Former Member]

Greg,

I'm not going to get into how to exploit the risks here however if you have been doing this a couple years you should be able to document the risks yourself.

Cheers,

Ben