GRC 10: SOD rule set

[Former Member]

Hi All,

We are in process of  re-mediating the user access before creating mitigation control for any risks.

Risk analysis report showing some risks where my compliance team  is not accepting them as risk and they are calling them  as false positives.

Here are the example.

We have PO control manager where he/she can  place the orders and approves the orders which was create by others but he can n't approve his/her own request

Below are the risks which are showing for the control manager in GRC.

Please suggest me how can i eliminate these type of risk(some of the authorization object fileds are not org filed so cann't use org rules for this.

Thank you in advance for your help.

Regards,

Sushma M

[Colleen]

Hi Sushma

We have PO control manager where he/she can  place the orders and approves the orders which was create by others but he can n't approve his/her own request

Based on what you say it sounds like SoD would be if you had ME21N/ME22N (Create/Change Purchase Order) with ME28/ME29 (Release Purchase Order).

However, you have then said they can't approve their own. If you have a system rule preventing this (extra validation or workflow, etc) then you have already eliminated the risk. As a result, you either don't include it in the ruleset or you build a mitigating control to reflect this. Without seeing full report, you might already have this captured.

So now, if you have an approval step between Creation/Change of Purchase Order and Goods Receipt, is the combination of ME21N/ME22N and MIGO really and SoD violation in your company? If it's not, then maybe you actually considering changing the ruleset to remove this (this would be a business decision to decide if it's actually a risk to report on)

Those above two comments cover false positive for the risk - that actual SoD definition is not valid in your solution - which you mentioned you are being told.

some of the authorization object fileds are not org filed so cann't use org rules for this.

So in this situation, you could check out ME21N/ME22N and MIGO to see if you need to update the Functional Definition and add an addition object into it. So to do this, you need to know if the objects in your function definitions are the minimum authorisations you need to perform the action. If not, you might find you actually need more authorisations to form the function.

Plant would be mandatory for purchase order and therefore goods receipting. You can check if ME21N/ME22N need M_BEST_WRK added to it for ACTVT 01 and 02. Then also check if MIGO actually needs M_MSEG_WWE (I think) based on SU24 definitions. If so, you now have $WERKS as an org value.

However, org value would only work if you are saying the users has Plant A for one object and Plant B for another - different org values. If not, this false positive scenario does not apply and an org value will not resolve your false positive.

If changing the ruleset definition (either remove the risk or update the function) OR assign a mitigating control (i.e. system control for workflow approval) then you don't have a false positive.

If it's not actually a false positive, then you can attempt to eliminate by removing access - the user can have ME21N/ME22N or MIGO but not both.

Finally, if you can't eliminate you are back to mitigating and you then need to identify an appropriate control to create and assign to the user. This might be running a report, etc

Hope this helps you. I think the key comes back to asking the business/review why they believe it is a false positive. From there make sure you have identified the actual risk/non risk

Regards

Colleen

If you the risk is valid then your options to eliminate is to remove on the the roles from the user: either they can do purchasing or goods receipting but not both.,

[Former Member]

Hi Sushma,

As Colleen said and as per your requirement , ME21N/22N and ME28N/ME29 should b in Function definition.

These t-codes do not have auth. fields, which restrict PO created by. you have to configure that through Workflow. But, as a standard approach, Org. fields are used to define Risk.

MIGO is for Goods Issue or receipt, and us definitely a Risk with PO creation. But that will be in a different Risk id(and not in PO Creation and Approval)

Regards

Plaban

[Former Member]

Thank you Colleen and Plaban for quick response.

We don't have any an approval step between Creation/Change of Purchase Order and Goods Receipt,Does it  a risk?if yes,then do we need to remediate or mitigate this risk?

And below are the some of the risk combinations which are showing as risks.please suggest me weather i can go for remediation or mitigation.

Regards,

Sushma M

[Colleen]

Hi Sushma

We don't have any an approval step between Creation/Change of Purchase Order and Goods Receipt

Does your process have a release strategy step which is the ME28 access? If so, that is an approval step

And below are the some of the risk combinations which are showing as risks.please suggest me weather i can go for remediation or mitigation.

This is a business decision. I think you are mixing up whether something actually a false positives.

A false positive means it's showing as a risk in your violation reports but it's not actually a risk to the business. If it's not a false positive then the options are to either remediate (remove the risk) or mitigate (assign a compensating control in which the residual risk is acceptable to the business).

To remove false positives you change the rule set or configure the org and supp rules

To remediate you either change the role (remove access); change the user access (remove role assignments); change the business process (might add additional step which the results in the change to the rule set)

No one here can tell you what steps your need to take. It is a conversation with the business.

Regards

Colleen