Purpose
The core functionality in SAP GRC is Risk and Impact Analysis which will help the organizations to achieve their motto "GET CLEAN and STAY CLEAN". During one of the implementations I am working for we noticed lot of issues/bugs with the risk analysis functionality and based on our findings decided to write a blog which can be useful for others to consider below scenarios during implementation :smile:
Mitigation Policy Configuration - To restrict approvers from approving requests with Unmitigated Risks
First enable configuration parameter 1072 - Mitigation of critical risk required before approving the request as YES. This is applicable for both Critical Action and Critical Permission Risks.
Mitigation Policy can be configured using BRF+ to enforce the approvers to mitigate the risks before approving an access request. Under the Application Mapping, there is the Application ID: 'Request Mitigation Policy'. The BRF+ Function for this App ID is maintained by default. The BRF+ rule is created to identify which risk requires mitigation and which risk does not require. If there is no BRF+ Rule created for Mitigation Policy, then please remove the entry from IMG.
Once this entry is deleted, kindly execute the scenario again. Now the Approver cannot approve the request if risks are not mitigated. This was the purpose of un-checking the Task Setting 'Approve Despite Risks', so that risks that are not mitigated, do not get approved.
Note: If maintaining the BRF+ Rules then it is necessary to maintain the entry in SPRO.
If you want to make use of BRF+ mitigation policy with corresponding decision table and it works as below
Reference SAP Notes
1614290 - Risk Analysis Mandatory for Access Request
Locked and Expired Users
When a user account is locked or expired and when the same user try to create an access request then Risk Analysis/Impact Analysis will not return any results and this is as per design.
We identified few issues where users already have some roles assigned to their user accounts and now when they raise new requests with the roles which conflict with the existing roles or the roles requested in the request itself have violations but since users are LOCKED or EXPIRED risk analysis didn't return any violations.
We identified during our weekly risk analysis report that few users have SOD conflicts with the roles assigned to them and up on investigation this is the issue with LOCKED or EXPIRED users.
We enabled the below configuration to fix our issue :smile:
One User Request Per System
Risk analysis functionality has one limitation in access requests but SAP addressed it with One User Request Per System functionality.
Eg: Approve Purchase Request(PR) and Release Blocked Invoices
Now we have defined a rule in the system that "Approve Purchase Request and Release Blocked Invoices" as a HIGH SOD risk violation. But a smart user can raise two GRC access requests as below:
Request 1 - With Approve Purchase Request Role - Individually this request is clean and has "No Risk Violations"
Request 2 - Release Invoices Role - Individually this request is clean and has "No Risk Violations"
But once both the requests get approved, user will get access to the roles which have HIGH risk violations. This issue can be addressed in different ways:
1. Role Owners should take the responsibility when approving the roles to verify whether user really require access to that role,but system wise it will not stop them from approving these requests.
2. Enabling the risk analysis as MANDATORY before approving the request at last stage of approval so that if one request is first approved and user got the role 1, at least request 2 now shows the violations when risk analysis is run again before approving, but still if both the requests approved at the same time then still this option will not stop the user getting access to these conflicting roles.
To address this issue, SAP has given an option in the configuration which allows the users to raise ONE USER REQUEST PER SYSTEM at a given time. So, the users cannot raise a second request when there is a pending request for the same system which will help to address the issue mentioned above.
Since these days most of the customers of GRC having business roles we have identified this configuration having issues with the way it is working for business roles. We are able to get it fixed by SAP and enabled the below configuration in our system which has helped to address kind of issues discussed above :smile:
In EUP configuration, you can enable below option as One User per Request per System is part of the end-user personalization customizing so it is mainly based on the screen elements on the request.
Also implement below note to fix One User per Request per System EUP configuration issue with Business Roles.
2168444 UAM: One request per system not working correctly with business role and for IDM
Simulation Button in ARQ Request/Approval Screen
There is a button called SIMULATION in access request creation/approval screen. Actually risk analysis in ARQ will perform both Risk Analysis and Impact Analysis for the user and SIMULATION button also gives the same option.
We have noticed few issues in the way SIMULATION button is working and how using this button approver/risk reviewer can wipe out risk violations in access request though the roles selected in the request have violations :shock:
Steps to Replicate lssue with SIMULATION button:
1. Create a access request which has RISK VIOLATIONS.
2. At approval stage you can see the risk violations under RISK VIOLATIONS tab
3. Now change the approval status for the role causing violations to REJECT and then click on SIMULATION button and run risk analysis and click on APPLY button in Simulation screen.
4. Now all violations will be removed from the request. Now again change back the role approval status to APPROVE and then click on SIMULATION button and without running risk analysis and click on APPLY button from SIMULATION screen.
5. System doesn't prompt to run risk analysis and violations are wiped out :shock:
We haven't reported this issue to SAP but since this button access can be controlled using risk analysis authorization objects, we have removed this button access to our Users and Approvers from Request Submission and Request Approval Screens.
In order to hide the SIMULATION button from the Access Request creation screen, remove the following permission from the role:
Authorization Object: GRAC_RA
ACTVT: 70 (Administer)
Risk Analysis behavior during business role removal
We have identified a different risk analysis behavior during business role removal.
Below are the sequence of events:
- User has already been assigned with a Business role. This business role has a composite role which actually caused Critical Action risk violations for the user.
- To remediate this, requester raised an access request for Business role removal so that as part of removal the role causing violation also gets removed.
- Since the role which is creating violations is being removed via business role removal, ideally the risk analysis shouldn't show any violations in the request. But request still shows risk violations with the same role which is being removed from the user.
- To validate the behavior, we have created another request for removing composite role creating violations directly than through the business role and now request shows NO VIOLATIONS.
With the above steps we confirmed that during business role removal risk analysis behavior is incorrect. We have raised this to SAP and working with SAP to get it fixed.
Please implement the fix 2213465 - AC 10.X ARA: Risk Analysis for Business Role Removal
Risk Violations bypassed at Approver Stage
We have setup the configuration in such a way that no unmitigated access can be provision to the user in our production system.
All seems to be working fine however we found one scenario where approvers managed to bypass the risk violations and managed to approve the requests despite having violations in the request.
This is a product bug where if you close the browser it doesn't save the approval status change however save the risk analysis result based on the approval status. SAP has acknowledged this issue as bug and are providing the fix :smile: I will update this blog with the fix details once we get it :smile:
SOD violations are removed after re-running the risk analysis
<To be Updated>
Risk violations are not shown due to the roles not being generated
<To be Updated>
BRM Impact Analysis - Behavior
BRM Role change process involves Risk Analysis and Impact Analysis
1. Risk Analysis - To make sure that the role being created/modified don't have any SOD violations.
2. Impact Analysis - To make sure that the role being created/modified doesn't create any SOD violations for the users already assigned to it or the Composite/Business roles using it.
Issue:
BRM User Impact analysis report shows the user level violations even though the assigned role validity is expired for the user.
Eg: User A has ROLE B. In BRM I am modifying role B and the changes being made will create SOD violations for user A with other roles assigned to user A. Then Impact analysis report should show those violations in the Impact analysis report which is the intended behavior.
But Role B assigned to user A is already expired validity. Even then Impact analysis shows that user will get violations with the role which is already expired.
In general, Risk/Impact analysis doesn't consider validity dates of the roles, but if Impact Analysis report gives the report with expired roles for the user then they are FALSE POSITIVES.
Raising this issue to SAP to understand from them the behavior as well :smile: Will update the blog with the details given by SAP :smile:
BRM Role Change and ARQ Request at the same time
This issue is one of the product limitation :smile: So, I wanted to understand from other consultants as well on how they are handling this scenario
1. Role Management Team is modifying a role using BRM in Development. As part of BRM process role changes are made and Risk/Impact analysis is done.
2. Risk analysis is done against the contents of the role in BRM and Impact analysis is done for Users assigned to this role and Roles (Composite or Business) using this role and Risk/Impact analysis shows no Violations (assume)
3. Now assume that there is a pending Access Request for the same role being modified through BRM and the user in the access request will get SOD violations because of BRM role change but since the request is not yet completed and role is not yet assigned user will not be shown in Impact analysis report.
4. After Risk/Impact analysis phase in BRM there is certain time gap to finish approval and transport process and if the pending access requests with that role are approved during this time users will get that role but users will be shown in Risk analysis report after transporting the role modified through BRM.
So, there is a chance for risk violations to pass through because of this BRM role change and ARQ pending requests for the same role during that time.
Can the members of the community share their views on this scenario and how they are handling it as this is product limitation :sad:
Looking forward for all your inputs in improving this blog with all other additional details :smile:
Thanks for reading.
Best Regards,
Madhu Babu Sai
- SAP Managed Tags:
13 Comments
