Unexpected results for permission level risk analyis at role level

[patrick_weyers]

Dear all,

We are experiencing unexpected results for a permission level risk analysis at role level.

Example: Role P:Y:FI_D_AR_ACCOUNTING___:DWAG

This role has been generated in the backend. It contains (among others) the following authorization objects:

S_TCODE

Standard: TCD: F-30, FEBA, etc.

F_BKPF_BUK

Standard: ACTVT 01, 02, 03, 07, 08 BUKRS 0001, 0002, etc.

Changed: ACTVT 01, 02, 03, 08, 10, 77 BUKRS 0001, 0002, etc.

Inactiv Standard: ACTVT BUKRS 0001, 0002, etc.

F_FEBB_BUK

Standard: ACTVT 02, 03 BUKRS 0001, 0002, etc.

Risk analysis on action level reports risk on rule S0CG016 (action F-30 vs. action FEBA).

The permission level rule for the above mentioned action level rule is S0CG01601 and it is defined as follows:

Permission Object Field Value Function Conditon System Status

S_TCODE: TCD: F-30 F0FI06 AND ERP Enable

S_TCODE: TCD: FEBA F0FI13 AND ERP Enable

F_BKPF_BUK: ACTVT: 1 - 2 F0FI06 AND ERP Enable

F_FEBB_BUK: ACTVT: 2 F0FI13 AND ERP Enable

Risk analysis on permission level reports no risk. From my understanding, it should report a permission level risk, as the authorization objects defined in the role match the permission level checks of rule S0CG01601.

There are no mitigating controls in place.

What could be the reason for this result?

Many thanks!

Patrick

[koehntopp · Accepted solution]

These are Org fields - you'd need to define org level risks in order to see those.

[patrick_weyers · Accepted solution]

Hi Frank,

Thanks for your answer! I am not sure I can follow you, though.

I am vaguely familiar with org level rules and I believe those are not applicable here.

Of course, the authorization objects contain references to org levels (such as object F_BKPF_BUK, which references company codes).

However, the risk definition (as can be seen from the permission rule definition above) only relates to activities 1-2 for F_BKPF_BUK and activity 2 for F_FEBB_BUK. We are not using any org fields in the risk definition.

I still fail to understand why RAR does not report this as a rule violation...

Many thanks again and regards

Patrick

[Former Member · Accepted solution]

Dear Patrick,

Please check in the function of the t-code whether any values are enabled for BUKRS- Field with AND condition. If any values are enabled in GRC with ACTVT 1-2 AND BUKRS with values zzzz then conflicts will not throw unless both the conditions are satisfied. It means the role should have both ACTVT 1or2 and company code value mentioned in GRC function

If the t-code in GRC function is enabled only with F_BKPF_BUK - ACTVT 1-2 and BUKRS is left disabled then definitely conflicts will be thrown at permission level for the auth object F_BKPF_BUK - ACTVT 1-2 for the roles.

We faced similar issue with one of our clients and since they do not want org rules for the time being, we have disabled this authorization object for the t-codes which requires company code restrictions as additional restriction

Best Regards,

Srihari.K

[patrick_weyers · Accepted solution]

Hi Srihari,

Thank you for your response!

No values are enabled for the BUKRS field in the function definitions. I double-checked this and you can confirm this by looking at the permission level rule in my original post further above.

RAR really only looks at F_BKPF_BUK - ACTVT 1-2 and F_FEBB_BUK - ACTVT 2, which are both contained in the role. That is why I don't understand why no conflict is reported.

What else could be the reason for this behaviour?

Thanks and regards

Patrick

[Former Member · Accepted solution]

Dear Patrick,

As per the stated settings, RAR should throw the conflicts as the auth object values are available in the roles. Can you please do a full synch once for the roles and then re-run analysis again for this role. Also, please check if the profiles of the role is generated successfully

There may be chance that role might not have got synch in GRC data base

Thanks and Best Regards,

Srihari.K

[patrick_weyers · Accepted solution]

Hi Sri,

Thanks again for your efforts!

In fact, we were able to solve the problem now. We adapted the standard rule set using MS Excel. During the process, for some of our function-permission definitions, the leading zeros for activity codes got stripped away! Hence RAR wasn't able to generate the correct permission level rules and subsequently didn't report expected risks for SOME of our roles.

After correcting the formatting for all rules, the risk analysis now appears accurate!

Best regards

Patrick