One employee - two users (end user and superuser)?

[dionisio_bustillogalvez]

Dear Friends,

I have a question concerning the management of SAP users with extended permissions.

Currently all our employees access the system to fill in the worksheet, manage travel and other activities. But some of these employees also need access to the production environment to perform administrative activities in the SAP system.

This mixture of permits, end user and superuser is not acceptable from the audit point of view.

One option is to use two user codes for each employee, end user and superuser with extended permissions. But this solution has many operational problems.

Another option would be to use GRC AC Superuser Privilege Management. Expensive...

My question is if anyone has managed this in a different way that might be acceptable from the audit point of view. In our system we have around 10,000 end users and 100 users with extended permissions.

I would appreciate any feedback.

Best regards

[Colleen]

why is this not allowed? what is the actual risk?

if the end user level access is more "employee self service" then you would be limiting them to their own data.Their admin level/super level access would then be built to only grant them what they need to do their job.

I would look at auditing and monitoring of any segregation of duties as detective controls. You need to trust you employees to do their job and provide appropriate access. You can look at  SAL (security audit log), RAL (real time audit log), check critical authorisations/sod and other logging tools to check what the super user does

Without investing in GRC, you could have a process to temporarily increase their access for critical transactions and access as required (could be temporary role assignment or reference user). This would involve a process to approve access, monitor usage, etc.

Do you have a specific example of what access combination you want to grant but cannot? What sort of level access have you granted end users (could it be too powerful and causing some conflict). It does sound like your policy/rule is a bit too black and white and inflexible.

If by two user codes you mean two user IDs then this is pointless as you are effectively granting them the access. It'd be easier to keep their access on the single ID and monitor it for. You also risk using up licenses for the user.

Regards

Colleen

[Former Member]

Colleen Hebbert wrote:

why is this not allowed? what is the actual risk?

It is not allowed because it could be used to circumvent the Segregation of Duties policies.

See the PCAOB Auditing Standards for more on ITGC.

Cheers,

Gretchen

[dionisio_bustillogalvez]

Right, for auditors that is the main reason.

There is also this recommendation from the ISO 27000, that should apply for all IT systems:

9.2.3 Management of privileged access rights

e) Privileged access rights should be assigned to a user ID different from those used for regular business activities. Regular business activities should not be performed from privileged ID

For our support team, error tracking becomes much harder with single ID

Best regards

[Former Member]

Dionisio,

In my experience with Sarbanes-Oxley controls, the principle of one user ID per person per application  is pretty common and often documented in the organization's IT security policies. One variation on that is that they might have one naming convention for external users and a different one for employees, so an individual might have had more than one ID during their history at the organization, but only one at a time. The scenario that you describe would be better using a solution such as GRC Emergency Access Management. If you presented that option to your internal auditors/ internal controls team, I think they would choose it.

Regards,

Gretchen

[dionisio_bustillogalvez]

First of all, thanks for your all your comments.

It is not really about whether trusting users or not, but the difficulty of defining proper permissions for all users.

The main issue in our system is the complexity... too many processes, badly documented, and many of them based on custom transactions.

We are trying to organize and simplify this landscape but it is like fixing up a running train... packed with users, by the way. Monitoring this mess, at this time, is a nightmare. We have the Security Audit Log running and besides some critical actions (like debugging), it is really hard, and time consuming, to track "bad" behaviours.

Actually, we have GRC licensed, and we are planning to use it once we have processes and step processes (permissions) identified, and everything better planned and documented. That is the expensive part.

Anyway, if we decide, for the sake of traceability, using two user IDs for employees with superuser permissions. What problem you think could arise?

Best regards

dionisio

[Former Member]

Dionisio,

What problems can arise? Plenty. Goodness, you name it: firefighter roles not well defined, logs not being reviewed timely, too many firefighters to controllers, "rubber stamping" the logs, are some that come to mind.

But the good thing about using EAM is that you do have the logs to document what was done with the elevated access, and the logs are way better in 10x releases than in the earlier releases.

Good luck!

Gretchen