cancel
Showing results for 
Search instead for 
Did you mean: 

Note 1600667 - SoD - How to do this:Permissions are different, can segregated by security?

sanneval1
Explorer
0 Kudos

Hi experts,

Can you please give examples how you have done the segregation by security? Our customer is going thru user level risk remediation phase and we have problems to "clean" risk H017 and transaction PT60. This risk and transaction is mentioned in note 1600667 Transactions that conflict with themselves. So can someone please give examples or hints how to segregate this by security?

Accepted Solutions (0)

Answers (1)

Answers (1)

Colleen
Advisor
Advisor
0 Kudos

Hi Sanna

My thoughts and approaches to customers with this

1. Check permission level - select conflicting actions are in 2 different functions. However, check if the permissions are different. Within PT60 find out what is the conflict and can P_ORGIN or other permission with different infotype or activity levels make a difference. If so, running report at permission level clears it for you

2. Treat it as a critical action - remove the action from one of the functions and define it individually as a function and then create a customer critical action risk. You can then limit which users have access to PT60 and manage the risk that way. In this case you are making changes to your master data as well as potentially performing role and user mitigations.

3. Mitigate the Rule Violation for the Risk at Role Level. Define a Critical Action mitigating control intended for PT60 transaction code. For all roles with the assign the control as rule Id level. This can exclude the roles and users from the report with the self-conflicting risk but still pick up the rest of the segregation of duties risks.

4. Implement additional system control through additional authorisation check or other control - try to apply an additional authorisation check (i.e. user exit in customer code) to perform a check for one of the functions. This would then allow you to pursue option 1 - the action definition can be updated to include the additional authorisations check and clear the violation at permission level. Risk will still show at action item in the report but this would be a false positive.

5. Implement some form of other system control (e.g. check user id cannot be same user) to enforce 4 eyed principle. If in place, remove the action from the rule set or again option 3 to mitigate at rule violation level for the risk.

In items 2 and 3, you would then focus on reduced who has PT60 as well and review what they do.

Regards

Colleen

sanneval1
Explorer

Hi Colleen,

Thanks for very informative and promt answer. I think approach 1. or 2. might work for us.

This was really helpful, thanks again 🙂

Regards

Sanna