Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SAP Cleanup of rogue user accounts without CUA

Former Member
0 Kudos

Dear Experts,

I am currently facing the situation that we had to eliminate the SAP CUA in a SAP environment due to architectural incompatibilities. One feature of the CUA was to eliminate "unknown" user accounts in the connected CUA child systems, this is what I was told at least.

This is not supported by the current implementation without CUA. There is a central user management in place built arround a non-SAP IDM system, which was previously interfaced with the CUA. It controls the "known" accounts in the SAP application systems.

Means of user creation and modification are disabled in the former "CUA child systems" despite from the SAP emergency user, its use is controlled by a documented process.

I can personally see the risk, that there are user created "locally" outside the control of the central user management. My question is:

- Is this really a valid risk?

- May we run into compliance issues, as the client is in the financial business?

- What are appropriate controls in case you see a risk in there as well?

Kind regards,

Rich

Message was edited by:

Richard Hösl

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Rich,

From the facts given i understand as under:

1] There are unknown users which has been effectively disabled.Modification,Re-creation features too has been disabled.

2]There is a central user management in place built arround a non-SAP IDM system.This controls the "known" accounts in the SAP application systems.

3]For all practical purposes the "unknown" users have been done away with going by [1 ]above.The emergency user too has authorization.

The following are relevant here:

a]There should be a documented policy for the procedures to be followed during the emergencies.You have not mentioned this.No "documented policy " means there is a risk.This should be under the "change management" umbrella.

b] Users ids that have not been used for a specified period - say 15 days-unless authorized by HR /others to cover up holidays,official tour etc,should be automatically disabled. dont know if this policy is in force.The defunct user ids generally correspond to retired,temprory employees;so HR should be involved in examining these.It will be in wisdom to notify the process-owner,under whose directions these user ids were created about the defunct ids.This will throw light on the real grass root reality.

c] There is no question of creation of user id outside the user group.If the user groups are not involved in creating the user ids a specific documented policy covering issues under which circumstances can we do,who will be authorized,if SOD considerations will be respected in such creation,what is the duration of the user ids etc.This should also be under the "change management" umbrella

d] Any deficiency in a,b,c above will land you in " non-compliance".

Hope this helps.

Regards,

Ramesh.

4 REPLIES 4

Former Member
0 Kudos

Hi Rich,

From the facts given i understand as under:

1] There are unknown users which has been effectively disabled.Modification,Re-creation features too has been disabled.

2]There is a central user management in place built arround a non-SAP IDM system.This controls the "known" accounts in the SAP application systems.

3]For all practical purposes the "unknown" users have been done away with going by [1 ]above.The emergency user too has authorization.

The following are relevant here:

a]There should be a documented policy for the procedures to be followed during the emergencies.You have not mentioned this.No "documented policy " means there is a risk.This should be under the "change management" umbrella.

b] Users ids that have not been used for a specified period - say 15 days-unless authorized by HR /others to cover up holidays,official tour etc,should be automatically disabled. dont know if this policy is in force.The defunct user ids generally correspond to retired,temprory employees;so HR should be involved in examining these.It will be in wisdom to notify the process-owner,under whose directions these user ids were created about the defunct ids.This will throw light on the real grass root reality.

c] There is no question of creation of user id outside the user group.If the user groups are not involved in creating the user ids a specific documented policy covering issues under which circumstances can we do,who will be authorized,if SOD considerations will be respected in such creation,what is the duration of the user ids etc.This should also be under the "change management" umbrella

d] Any deficiency in a,b,c above will land you in " non-compliance".

Hope this helps.

Regards,

Ramesh.

0 Kudos

Hi Ramesh,

thank you very much for your detailed reply. I'll try to describe it a bit more precise. We have a central user management in place, which automatically takes care of creation, modification and locking (E.G inactive users or users left the company) of SAP User Accounts. This is documented, but no strictly controlled from my point of view.

The possibilities in the connected SAP systems to create/modify/lock users are deactivated, so for example no use of the TA Su01 for SAP Admin staff. This is the first circumstance I do personally not trust to be true in reality. Is it possible to harden a SAP system to behave that way?

Based on the previous point, the only way to create users in the SAP should be to use the emergency user, which has the needed rights in the system. This user is controlled by a strict and documented process.

This IDM system should also take care of automated user locking, in case it recognizes users not created with it and not wanted. (so called unknown user accounts). If we do not implement this, are we endangered in terms of compliance, e.g. SAS 70?

Kind regards and many thanks,

Richard

Message was edited by:

Hösl Richard

0 Kudos

Hi Rich,

From the compliance angle,these will be acid tested under SOX audit.Here the risk is examined at the entity level from recognition,mitigation etc point of view.

The IDM system should recognize all sorts of users notwithstanding the type of creation (ie) if or not created by IDM.Otherwise there is a perceptible risk.If this risk is not properly quantified and mitigated then this leads to a situation which can lead to mis statement.You are prone to be qualified in the sox audit.

SAS 70 is the audit by your clients [ the scope is provided in the agreement or mutually agreed];its scope is usually narrow and is restricted to the client's requirement.Barring the conditions peculiar to the agreement,if you comply with sox,then automatically you clear SAS 70 too.

In essence,be it SOX,SAS 70 or else,the regulatory provisions work overtime to ensure that the best practices are in place in managing the risk.So focus on the best practices in the areas we have discussed so far.More importantly document the deatils.This will automatically render you [your firm] compliant.

Hope this helps.

Regards,

Ramesh.

0 Kudos

Hi Ramesh,

now it's quite clear, thanks a lot.

Kind regards,

Rich