cancel
Showing results for 
Search instead for 
Did you mean: 

User SoD risks/Repors

0 Kudos

Hello All,

We have GRC 10.0 system connected to ECC system, there is a change in ECC system so we need to update the GRC system accordingly. I would like to know your suggestions for that.

ECC is connected to GRC system and running fine this point in time. New company code was created in ECC system and users will be separated for newly created CC soon. So we need update the GRC system ruleset for old and new company code users.

Requirement is Business users should have access to their respective CC related roles only, if old CC users have access to new CC roles then it should be high risk and vice versa.

Please add your thoughts.

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Pravin,

One of the ways in which this can be done is:

Function 1 - Contains t-codes and auth objects related to old co codes.

Function 2 - Contains t-codes and auth objects related to new co codes.

Risk 1 - the conflicting functions for this risk are Function 1 and 2.

In case you do not want to disturb the existing set up create a new rule set and have these for them.

Let me know if I am correct in assuming your business scenario.

Thank you.

Regards,

Praman.

0 Kudos

Hi Praman,

Thank you for your reply.

We don't want to disturb existing rule-set by adding new functions/risks. Is there any workaround for this with supplementary rule set or organizational rules.

Regards,

Pravin

0 Kudos

Hi Pravin,

Yes you can create new rule set and create the required functions or risks that cater to the new business requirement.

Regards,

Praman

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Pravin,

This sounds like you need new security roles that are restricted at org level BUKRS for the various CCs.  Are new roles being developed for the specific CCs?  It sounds like these new roles are going to be implemented soon and then assigned to the users appropriately.

If you are looking for a way to report on who has access to which CCs, then I recommend creating new "Critical Permission" risks.  The permissions to check would be F_BKPF_BUK, or any other objects that include field BUKRS.  This would check for users who have the specified permission values, just like a SUIM query performed directly in ECC.  You could have Critical Permission Risk "ZCP_1000" which checks for access to company code 1000, and then you could have Risk "ZCP_2000" which checks for access to company code 2000.  Then, you would want to compare the users from the reports and flag anyone who is on both reports.

The issue with creating a new SOD risk, which would essentially perform the report comparison automatically, is that they require tcodes to be specified as well.  There are MANY tcodes that call CC-related auths, and listing them all out would be laborious, although you could use the Action Usage History report from GRC to tell you which tcodes the company utilizes.

Again, not sure if I am understanding your requirement, but this is how I would approach it.

-Ken