AC 5.3 RAR and Organizational rules

[former_member577095]

Hi all,

we are implementing risks based on organizational rules. It is not clear in my mind how the system manages actions that do not have authorizations objects activated (at permission levels) or have authorization object activated but without organizational fileds.

In other words: I have a SOD risk containing the function called FN99. In this function there are the actions TCD01 and TCD02. For TCD01 there are not permission linked and active (just tcode), for TCD02 there is only the authorization object M_BEST_BSA. So, this function does not have any authorization objects with organizational fields (BUKRS, WERKS and so on).

If we use the RAR organzational rules, the 2 actions TCD01 and TCD02 are managed or are not considered at all since they do not have organizational fields.

Thanks in advance.

Andrea Cavalleri

[Former Member · Accepted solution]

Andrea,

Within RAR you can run either risk analysis at transaction level or at permission level.

Transaction level: Just S_TCODE || TCD authorization objects will be checked

Permission level: S_TCODE and any other authorization object included within the SoD matrix will be checked

Risk Analysis at organizational level is a further level of permission risk analysis taken into account authorization objects that include ORG fields (BUKRS, EKORG, WERKS etc.) and verifying specific values you have defined within the organizational rules.

The goal of running risk analysis at organizational level is to eliminate false positives that might be detected when you run risk analysis at permission level without taken organizational authorizations into account.

Under an organizational Rule approach, you will be detecting conflicts JUST if user U1 is able to execute transaction T1 and T2 (assuming this pair of transaction define a conflict) within the same organizational level (for example the same Company Code).

Please, check the documents have been pointed out in this post.

Hope it helps. Regards,

Imanol

[former_member577095 · Accepted solution]

Thank Imanol.

[former_member366047]

Andrea,

Both TCD01 and TCD02 should not be considered as they do not include any organizational fields. Your org rules will have to be built manually.

More information regarding org rules and their creation can be found here:

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/805a8744-42ab-2a10-5194-b45be2704722

Ankur

SAP GRC RIG

[former_member577095]

I have seen many customers that are using Organizational rules as unique way to find conflicts.

If I have correctly understood the concept, ther main risk analisys must be performed as "normal" risks (I mean risks based on function-actions-permission) and THEN, to find false/positive conflicts in the same group of organizational levels, must be used the organizational rules.

It it correct ?

Thanks

Andrea

[former_member366047]

Andrea,

Yes, that is the concept. To identify false-positives by implementing organizational rules.

Ankur

SAP GRC RIG

[former_member577095]

...then, if we have 6 countries (which means 6 groups of organizational levels) and we have 78 risks, I have to create 78 * 6 organizational rules.

Correct ?

Thanks a lot for your help.

Andrea

[former_member366047]

Andrea,

As noted in the BPX guide,

"This functionality should not be used to try to group users into reports by organizational levels in order to distribute SoD reports to various management levels. Organization level rules should only be used for exception based reporting in order to remove false positive conflicts that result from organization level segregation. Because of the sizable performance impact that organization level rules can have, they should be used minimally for only those situations where the company has made a conscious decision to segregate via org levels."

Ankur

SAP GRC RIG

[former_member577095]

Thanks for the help.

My understanding is that the organizational rules make sense only on function related to authorization objects with organizationals fileds (BUKRS, WERKS, end so on). If an action has a permission with auths objects without NON organizational fileds, the action is considered only as tcode.

Correct ?

Thanks in advance.

Andrea

[former_member366047]

Andrea,

Yes, you are correct. However, actions are transaction codes and permissions are authorization objects.

Ankur

SAP GRC RIG

[former_member577095]

I know, but M_BEST_BSA (document type in purchasing for example) is an authorization object but does not have any field of category organizational level (table USORG_DB).

That is my doubt. How GRC manages authorization objects like M_BEST_BSA in organizational rules ?

Andrea

[former_member366047]

Andrea,

I think we are going in a circle. Please view this document as it clearly explains why org rules should be used.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/805a8744-42ab-2a10-5194-b45be2704...

Ankur

SAP GRC RIG