Mitigation of risk at detour path

Dear experts,
I have a scenario wherein I am using detour path for SOD violation.I want that SOD violation path goes to person depending on type of risk present in access request.
The path with HR risk should go to person X where as non-HR(ECC) risk to person Y who will do the mitigation. There are only two(one from HR and other ECC) person to do mitigation.
They are responsible for only mitigation and mitigation control id approver/monitor are different.
How could this be achieved.Please share your thought.
Thanks,
Mamoon

Hi Mamoon,
Please check the below link. This could be helpful for you.
AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls
Regards,
Madhu.

Similar Messages

CUP 5.3 SP16, detour path for SOD violations doesn't exclude critical risks

Hello,
Has anyone else had this issue:
If you set your configuration to not require mitigation of critical risks, but only SOD risks, the workflow detour path condition 'SOD violations' still triggers to go to the detour path even if the request only has critical risks. This is a bug in the workflow detour logic. First of all, CUP doesn't differentiate between SOD violations vs Critical Risks violations. If we only want the mitigation approver detour to happen for SOD risks, the detour seems to happen even if the request only has critical risks issue which doesn't require mitigation.
Since our Approver determinator for SOX approval is the RAR Mitigation Control approver, the workflow detours to SOD violations path but doesn't find any mitigation approvers on critical risks and so goes to the administrator inbox as a approver not found issue escape route.
If SAP gives the option to not require to mitigate critical risks under config>mitigation>uncheck mark mitigation of critical risks not required, then the logic for detour also shouldn't happen for critical risks under 'SOD violations' condition. This doesn't make any sense why SAP has both in the same condition when one is clearly not SOD risks. Now our workflows keep failing bc of this bc we have several roles that might have a critical transaction or so, but we can't stop it from detouring even when we do not want them mitigated or approved for SOX stage. But we still need this detour path for additional approval for the actual SOD Risks.
Will greatly appreciate any1's feedback on what they have done to resolve this.
Thanks,
A.

I was actually able to resolve the issue by adding the role approver stage first to the sox approver detour path.. this way..if the manager has roles with sod violations and updates mitigations for it, it goes to the role approver via detour path as well first and then to the sox approver stage b4 auto provisioining. So, that solved our problem. And if the request doesn't have SOD violations then it just goes to the next stage without detour which also has the role approver as the last stage.
Since I couldn't get the sox approver stage to show up after the role approver as originally anticipated since the request already had mitigation assigned at the manager level, we did the above scenario to fix the issue.
Requestor>Manager->Role Approver-->auto provisioning (without SOD violations)
Requestor>Manager> Detour (Role Approver>SOX Approver)->Auto Provisioning (with SOD violations)

CUP - Mitigation Controls in a Detour Workflow

Hello everybody,
I have a problem with a detour workflow in CUP.
I choose the detour condition: "SoD violation".
So in theory, if there is no conflicts the workflow don't take the detour path.
We supposed that the user request has an SoD conflict.
In the stage(s) before the detour, if we assign a mitigation control that mitigate the risk, the detour is still taken.
I think the workflow swich systematically to the detour if the request had a conflict, even if the risks were deleted by an Mitigation Controls assignment.
Does anyone have a solution to avoid the detour path if we mitigate the risks?
Thank you in advance!!

Ben,
This is how CUP works. There is no configuration which allows you to ignore SOD violaton even if there is mitigation. You will have to live with this for now.
Regards,
Alpesh

GRC CUP 5.3 SP16, detour path not working for SOD violations

Hi,
Something bazaar is going on in our requests processing and not sure if that's the way SAP has set it up.
We configured a detour path for requests with SOD violations to go to the additional stage of 'SOX Approver' but the first stage (manager) does the risk analysis and Mitigation assignment and then it goes to Role owner approver that approves the roles access. Once the role owner approves the roles , if the request had SOD violations, even if the mitigation was selected and approved by the manager stage, it needs to go to the SOX approver stage to approve the mitigation assignment before the request can be auto provisioned for any requests that had sod violations.
But it seems to skip the sox approver detour path stage after the role owner approval and go directly to auto provisioing. I thought that any requests that had sod violations inspite of having mitigation assignment in a previous stage can be detoured to the next path for SOX approval and then auto provisioned. Since SAP doesn't give different approval option to approve mitigation vs. approve roles, wherever you make the risk analysis mandatory, that's where the mitigation controls have to be assigned. But we want the option to detour the path to SOX approver to approve those mitigation controls b4 auto provisioning the request.
Any idea of how to fix this?
Is the detour only going to work if the mitigation wasn't assigned? But then how can you get approval for the mitigation on a different stage if the same person has to assign and approve that?
Will appreciate any feedback in this.
Thanks,
Alley

I was actually able to resolve the issue by adding the role approver stage first to the sox approver detour path.. this way..if the manager has roles with sod violations and updates mitigations for it, it goes to the role approver via detour path as well first and then to the sox approver stage b4 auto provisioining. So, that solved our problem. And if the request doesn't have SOD violations then it just goes to the next stage without detour which also has the role approver as the last stage.
Since I couldn't get the sox approver stage to show up after the role approver as originally anticipated since the request already had mitigation assigned at the manager level, we did the above scenario to fix the issue.
Requestor>Manager->Role Approver-->auto provisioning (without SOD violations)
Requestor>Manager> Detour (Role Approver>SOX Approver)->Auto Provisioning (with SOD violations)

Mitigation URI, Risk Search URI options missing in CUP 5.3 SP5

Hi Guys
In CUP 5.3 SP5 , on configuration -> mitigation , fields like
Mitigation URI, Risk Search URI, Rule Search URI ,Function Search URI
options are missing so we cannot enter their URIs. Please let me know if
this is a bug with SP5 or all these URIs will be taken by default by GRC
5.3 SP5 ? If so i didnt find a details in note 1168508. Also I have
clicked the upgrade button as per 1286904. The above URI values are to
be enter as per GRC AC 5.3 config guide.
Please help on this.

Hi Jes,
Go to CUP -> Configuration -> Risk Analysis
Select Risk Analysis and Remediation Version
under that select Version 5.3 Web Serice. give URI , username, password.
then save . then go back you will be able to see.

Org Rule anlaysis when performing mitigation from risk analysis report do not mitigate the user from management summary report message!

Hi,
When in the User Level>Mitigation screen this comment appears (*). When taking the path to ‘summary’(a) or ‘detail’ (b) doesn't change when we select the button MITIGATE RISK (**). What was the intent of the below message?
What is the intent of the message ?

Hi Pranjal,
please see note: http://service.sap.com/sap/support/notes/1972382
Regards,
Alessandro

Detour path in GRC 10

Dear Expert ,
Any idea where we can maintain Detour configuration in GRC AC 10 .
In MSMP i can see route mapping but not sure if this is place where i need cinfigure detour as it doenot have option to set detour condition .
Thanks & Regards
Asheesh

HI Asheesh,
Can you confirm whether you fixed the issue. Routing works only if we reject the request ??
I have following scenario
1. No SoDs >> Take approval from Role Owner and create user/ assign the access using workflow
2. SoDs found >> Role Owner approval and then Security team approval after this userid will be created and assign the access
I have configured as below
Maintain Paths
1.GRAC_DEFUALT_PATH . In this I have configured re routing using Functional module GRAC_MSMP_DETOUR_SODVIOL to route from Role Owner stage to Security stage
2. ZGRAC_NO_SOD_PATH . .with stage as role owner only
Maintain Route Mapping
1. Map GRAC_DEFUALT_result to Default_path
2. Map GRAC_MSMP_DETOUR_SODVIOL to Defualt Path again for any SOD violations
3. Used one more functional module GRAC_INITIATOR_SOD_VIOLATIONS to check SoDs and map No SOD result to ZGRAC_NO_SOD_PATH
Workflow is working perfectly for Scenario# where SoD exist
But for Scenario#1 , it is still following same path with 2 stages . Ideally it should go to role owner and assign the access
I believe this is due to it is just following 1 path GRAC_DEFUALT_PATH even though there are no SODs

Set SoD detour condition on path level?

Dear forum,
We have a parallel workflow where the different paths are divided by business processes.
We want that SoD free paths continue as normal. Problematic paths are sent for resolution.
The problem as I see it is that the SoD detour condition is set on request level, not path level. Both problematic and non-problematic paths will meet the condition and are pushed into the detour. The non-problematic path will get stalled, because it has to wait for mitigation approval. Is there any workaround?
Kind Regards,
Vit V.

Hi Jose,
We have different detour paths for every parallel path. But if any SoD conflict is detected, the SoD condition is met for all paths and are pushed into the detour(s). Have you successfully tested it?
Example:
Main Paths
P1
P2
P3
Stages
_1: Manager
_2: Role Owner
_3: BPO (CAD business process of role)
P1_1
P1_2
P1_3
P2_1
P2_2
P2_3
P3_1
P3_2
P3_3
Detours (1-stage with mitigation controll approver)
P1_DT
P2_DT
P2_DT
SoD detour takes place at stages:
P1_2
P2_2
P3_2
Problem 1: If the SoD conflict condition is met, all paths are pushed into their detours
Problem 2: Let say we have two paths with SoD conflicts, a third one is not. Two mitigation controlls are applied. All three paths are pushed into their detour paths for mitigation approval.
Worst case scenaro:
Conflicting path 1: Mitgation Approver 1 approves
Conflicting path 2: Mitgation Approver 1 + Mitgation Approver 2 Approves
Non-conflicting path: Mitgation Approver 1 + Mitgation Approver 2 Approves
kind regards,
vit v

ARQ: Problem with Mitigation of a Risk and Request Rejection at the same time???

Hi All,
I have configured my workflow in such a way that, when a request reaches a certain approver (who is authorized to mitigate), he has following options available (we have configured this way):
1. Submit the Request: This will simply approve the request. But I would NOT want him to approve the request if it has violations. First he should mitigate the risks and then approve the request.
May I know how I can do it? Is this the correct process?
2. Reject the Request: If he is not ok, he can reject the request. I am ok with this and no action is required.
3. Forward the Request: If he needs any business clarifications, he can forward the request to the user's manager before mitigating and approving the request. This is also ok for me.
4. Mitigate the risk: If a request has risk violations, he can mitigate the risks by clicking on "Mitigate" button on "Risk Analysis" tab.
Here is the problem I see. The straight forward what he can do is, mitigate the risks and then approve the request (Submit). However, there is one more option with him and that is, he can mitigate the risks and then changes his mind to reject the request!
If he rejects the request (after mitigating the risks), the mitigation which was done before, is not "UNDONE". Meaning, that user is mitigated though the request is rejected!
This is very confusing and this way users are simply mitigated for no reason!
May I know below things:
1. What is the best way or practice to mitigate risks in a request?
2. How above explained problem (for point#4) can be addressed?
3. How I can stop approving a request if it has violations?
Please advise on this.
Regards,
Faisal

Hi Faisal,
I try to answer your question (as always ).
You can configure that at a specifc stage the approver cannot approve if there are risks. Therefore modify the task settings for all the stages and allow/disallow "approve despite risk". For all stages where approval can be given (like role owner stage) you can activate the button so that it is possible to approve even though risks are coming up.
To make this setting workable you have also to set parameter 1072 (Mitigation of critical risk required before approving the request) to YES.
Regarding the mitigation which was set but is obsolet after rejection. There is actually a simple way to remove invalid controls. Run the risk analysis and gather information for "Invalid Mitigating Controls".
In the result you have the option to change or delete the mitigation.
Does this answer the question(s)?
Regards,
Alessandro

AC10 - Auto risk analysis and auto mitigation

Hi,
I was wondering if it is possible to
- run an automatic risk analysis at the end of an approval stage of the workflow, the same way it is possible to configure at the time of request sending?
- automatically put a mitigating control in the request for the risks found?
In our case, there is only one mitigating control for each risk and the assignment of the control is an unnecessary manual task to perform. The mitigation assignment will be approved in a seperate WF by the mitigation owner.
It seems there is no out of the box solution to this, so any alternative suggestions are welcome.
Thanks,
Daniela

Hi Daniela,
If I may give my opinion, I would probably break your question down into 2 parts.
1) Auto Risk analysis at the end of a stage - Making "Risk Analysis Mandatory" at that stage is probably the method. Unfortunately this does mean clicking one or two buttons (so not fully automated). Think AC uses this method to ensure the reviewer is aware of the conflicts caused etc.
2) Auto Mitigation - For a business access workflow in a 'Live' situation, this is probably not a good idea, as analysing and making the decision on whether to proceed with the request should really be performed by an actual person responsible for that stage in the work flow e.g. Role Owner or Security Lead etc. You would not want to mitigate all risks automatically (if I have understood correctly that you have a mitigation per risk ID). In theory, an automated mitigation process would mitigate all risks without discrimination.
On a side note, there is a configuration setting under SPRO for Access controls as follows
"Risk Analysis- Access Request : Param ID 1072 - Mitigation of critical risk required before approving the request". By enabling this configuration, you could force a mitigating control to be applied to any user requesting Critical Access.
Hope this helps.

GRC AC 10- Multiple detour for single stage path

Hi Experts,
I wanted to know about a possibility or view. Do you know anyway where we can have multiple detour activated(like first detour 1 then detour 2 check) for single stage.
Actually once we click on routing rule, we get only select single detour selection option.
Please suggest idea.
(I would like to update that we do not want system to have multiple level of approver but only single role owner stage).
Final solution is creating custom detour having ability to handle multiple scenario but we are looking for no custom initiator)
Regards,
Nishant

Hi Nis,
unfortunately in standard solution only one detour path can be added to single stage.
When we had such a challenge, like you described, we simply used custom initiator and this is truly the best option to go.
In our case we wanted to have different path (detour) for roles with special attribute an in the same time different path in case sod issue occurs. In other words we wanted to have 2 detours condition on one stage like you want to have. The option that suites our needs in the best way was to have custom initiator rule.
Filip

ARQ: Risk Mitigation Mandatory and Request Forward causing problem???

Hi,
I have a scenario where in, at a certain stage, "Risk Mitigation" is made mandatory and also "Forward Request" option is available at this stage for the same approver.
What is happening is that, when this approver tries to approve the request without mitigating the risks, it gives error message and request can not be approved. This is fine and going as per the configuration.
Now the same approver is trying to forward the request to some other person for some business reasons (with "WITH RETURN" check box checked and disabled). This request is reaching to the desired recipient as expected. But the problem is that, when after providing his comments (a business requirement before mitigating risks, if need be) if he tries to approve (submit) the request, application gives the same error message that: "Request can not be submitted. Mitigate Risk XYZ"!
Due to this, request can not be submitted and sent back to main approver! I noticed that, the request still lies on the same stage and the same stage configuration is being considered for this forwardee too!
This is keeping the request hanging as this forwadee is not authorized to mitigate the risks.
Can any one please help me resolve this?
Regards,
Faisal

Alessandro,
Thanks for your reply.
Now I see (as confirmed) that we have technical limitation or application design that when we forward a request, it DOES NOT change the stage (even I noticed this). So I was thinking that only we have "SUBMIT" button to send it back to the main approver.
But as you said, this forwardee can use the same "Forward Request" option instead of "Submit" button. This looks the option here which suits the situation.
But can you please tell me if we can do something to inform the forwardee that he must select "Forward Request" option and not Submit button?
Because, this submit button is visible and he can click it without knowing! And then this error message of Mandatory risk analysis then appears!
Is there any work around?
Please advise.
Regards,
Faisal

AE: Multiple Mitigation controls per risk

Hi,
I am currently setting up mitigation controls in CC and am wondering if it is possible to have 2 mitigation controls for a risk?
It does not look possible, because when assigning access in AE and mitigating the risks, it is only possible to choose 1 mitigation control per risk. Has anybody managed to set up AE so that you can assign more tan 1 mitigation control per risk?
Thanks

Hi Ankur,
we have multiple activties to be conducted as part of the mitigation control. We wanted to create a seperate control reference for each as they have different monitors. However this does not look possible so we have grouped the activties to one mitigation control.
Regards,
Gary

Mitigating risks during new user account creation

I have a requirement for AC 10.
Is it possible to send a message from the security admin stage to role owner stage to know whether to mitigate the risk or not without approving the request at security stage. I am unable to understand the stages to be configured so the mitigation risks can be done during the new/change account request type.
I would like to know who should be responsible for mitigating the risks while creating the request for new or change user account. If we assume that the risk is not mitigated already. Is security admin or role owner will mitigate it.

Is it possible to send a message from the security admin stage to role owner stage to know whether to mitigate the risk or not without approving the request at security stage.
It is not possible to send a notification. However, the mitigation options can be used to identify the same in the request.
I would like to know who should be responsible for mitigating the risks while creating the request for new or change user account..
This is purely based on the process that you follow in your organization/project. Here are some instances:
1. If the role framework is properly maintained (risks are mitigated at the role level, and only composites are assigned to user) - Niether the business owner nor the security person needs to mitigate the risks at users level, since all the risks are already mitigated at the role level.
2. If the role framework is not properly maintained and single roles are assigned to users - Migitation is required. However, in a few instances, the BPOs or the functional owners will perform a risk analysis, mitigate if necessary and then raise the request. This can be done in RAR manually or also can be done in CUP.
3. The mitigation tasks are completely owned by Security team and BPOs or functional owners will only approve/review.
Hope this answers your question.
Regards,
Raghu

HR Object Mitigation does not works in CUP

Hello,
We are on GRC 5.3 SP07 and have position based security. Our mitigation controls are also position based (meaning thereby that we implement mitigation control at the position level, and not to the user occupying the position).
Our CUP is also based for indirect provisioning at the position level and it works fine. The only problem is when the request comes in via CUP for roles and the role has some risks (in itself or in combination with other roles already attached to the position), and then even if the position is mitigated for that risk, the risk analysis in CUP still shows that risk (ie the tool cannot detect the mitigation applied at the position level) and because of this the request gets routed to the detour path.(the detour path is based on condition u201Cif SOD found u201C).Ideally the request should detect the risk at the position level and should neglect the resulting risk as it is already mitigated. But this does not happens.
My question is this possible at all with CUP 5.3 or am I missing some configuration.
For you reference,
At the configuration part in CUP, for risk analysis I have checked the box for u201Cconsider mitigation controlsu201D
The validity of both the roles and mitigation controls all end with 12/31/9999.
Regards,
Matt

Venky,
If the risk is mitigated at user level , the request does NOT goes to detour path. If the risk is mitigated at role level again it does NOT goes to detour path. This is because the tool is smart enough to catch user and role level mitigation from RAR. However if the risk is mitigated at HR Object level it still goes to detour path. This is probably because the CUP cannot catch the mitigation done at HR Object level done at RAR. Although ideally it should catch the mitigation applied at the position.
Regards,
Matt

Mitigation of risk at detour path

Similar Messages

Maybe you are looking for