Remediating SOD Risk in SAP Access Control (GRC)
Access Risk Analysis is a tool within SAP Access Control that enables you to define user access risk (via way of a rule set) and to identify access risk (or simulate for potential risk). It also provides you with system functionality to remediate the risk or mitigate it via assignment of a mitigating control. This approach applies to any version of SAP Access Control, but the screenshots below were taken from version 10.x.
Like any other risk process, the reviewer has four options: accept; transfer; mitigate or remediate. This document details our strategy and approach to risk remediation. Our position is that you should always attempt to remediate a risk before attempting to mitigate it. Remediation removes the risk (or the residual level is acceptable) from the system and does not rely on the use of a compensating control. The latter is typically a manual control that requires a person to take regular action, and that can be subject to human error. Accepting and transferring risk should be your last resorts. Of course, your decision would involve a cost-benefit analysis as it makes no sense to spend more resources on the control than the real cost of the risk (from a financial, reputation, legal and compliance perspective)
When a risk has been identified, someone has to take action to resolve it. Depending on your master data setup, GRC automatically displays the risk definition, including who is responsible (risk owner); the respective business process; as well as mitigation owners/monitors. That information is necessary to enable you to know who to contact to discuss the risk and receive advice. Some of this interaction will occur outside of GRC.
Table of Contents
Risk Violation Count is Massive (Why?)
Be aware that the first time you run a risk analysis, the number of violations will likely be very high. Users may have access creep due to change in job function that caused them to retain old access. Also, roles may have been built with too much access, and maybe, at the time, the business may not have had adequate tools to identify these risks. Many organizations undergo a security redesign project once they have implemented GRC due to the number of inherent conflicts in their roles. In the end, they find it easier to completely rebuild security (get it right and clean the first time) than trying to resolve the issues and clean the existing roles. In some cases, companies are aware of the issues but mistakenly believe implementing GRC will fix it: all GRC does is to give you the number of violations and offer remediation or mitigation suggestions.
For example, in the screenshot below, there are over 200,000 conflicts, a daunting number when you consider having to fix all those violations. After all, where would you start? Remember a risk violation is one rule in the risk definition being met. Therefore, if a risk has two functions and both functions have two actions you then have 4 rule violations. If a user happens to have all four actions they too have four violations. If there are 50 derived roles, you will see the violation count increase to 200 (4 x 200). On further analysis (not visible in this screenshot) the bulk of the issues is caused by derived roles. By cleaning the imparting roles, the number of violations will reduce substantially.
Where to start the remediation process?
Your security role design, as well as access provisioning strategies, will impact how you approach remediation. The diagram below assumes position-based security is used in your organization. Depending on the authorization concept and access management in your system, the number of circles will vary. For example, you may not have user business roles or composite roles.
When approaching risk remediation, use the diagram below as a reference and work your way from the inside out.
- Single Roles: focus on remediating conflict in your imparting roles and other non-derived single roles. You can fix the derived roles when you distribute the change from the imparting roles (assuming you have followed SAP standard security rules and have not added additional authorizations to your derived roles). Single role clean up will involve removal of transactions and other authorizations.
- Composite Roles: by this stage, you expect that none of the single roles have an inherent conflict. You cannot remediate risk in a composite role if the single role has a conflict. Your choice to remediate at this point is to remove roles assigned to the composite role. Another option is to remove access from the single role (it may not cause an inherent conflict in the single) if the access is not required and it is contributing to the violation.
- Business Roles: this assumes you have built business roles via Business Role Management for provisioning. The same principle applies as for composite roles.
- Positions: if you are using position based security then you can consider removing roles (single, derived, composite, etc.) from the position.
- Users: finally you have removed all inherited risk. The only unmitigated risk violations against the user are due to the combination of access. At this stage, you can then remove roles.
Note: Remediating inherent role conflict will take time. You will need to work with the business process owners (the business) to determine the appropriate solution. Once you identify the permissions to remove from a role, you will then need to follow your companies change management process to schedule the change and arrange a so-called transport to Production. As an interim measure, you may need to implement a mitigating control.
Who should I engage with? What should I say?
That depends on your company’s organizational model and approach to risk management. However, regardless of the approach, it is still a business decision. You will need to consider meeting with the business process owners, line managers, etc.
In starting the conversation with these stakeholders, you need to outline and explain what the risk is and why it needs to be remediated. In some cases, the conversation may be as simple as ‘Is this access required.’ You may discover over time that access creep has caused the conflict and required clean-up. For affected users, the question may be ‘Does this user need both access.’ The stakeholders identify non-compliance in job duties or decide that there is an alternative person to take some of the duties. Again, it will all depend on the business so get out there and talk to the stakeholders!
How can I decide the remediation approach?
Depending on the classification of the risks like “low”, “medium”, “high” and “critical”, the remediation approach might be different. Therefore, classification of risks has not been considered in this blog and the recommended approach might be different when remediating “critical” risks over “medium” risks. This article shall provide an idea and first approach when starting from scratch.
The diagram below has been devised to visually represent the process to deciding how to remediate the access. You may devise a similar approach and change the sequence of options depending on your organization’s policy.
Is it a Risk?
Before investing work effort into remediation, you need to verify that violation is a risk and not a false positive. You may have executed the report at Action level only, but if you re-ran it at permission level, the violation might no longer be there. Alternatively, you may look at the violation and question why it is a risk in the first place. If you realize the risk definition is incorrect, then you need to change it. The rule-set is not static and must regularly be reviewed.
Does the object need both functions?
The violation is a risk, and you need to take action. Does the object (role, position, etc. ) require both actions? To assist in this decision, you could look at the action usage reports in GRC. If it appears one of the functions is not used, then remove it. For roles, this will be a change request and users/positions it will be an Access Request. Approval from the business will be required regardless.
Is there Alternative Access?
You determined the both functions were used but, maybe, could you assign a different transaction or authorization combination to restrict access. For example, the user might have XK01/02 transactions for Vendors but does not need all views – such as payment details. Instead, they only need FK01/02 which does not include the payment details. By changing the transaction, the user can still perform their job function via a different transaction.
Is there a System Control?
Can system controls via IMG configuration, Workflow and ABAP development be implemented to remove the risk? Alternatively, can the business process be changed to include a new step? For example, add vendor confirmation via FK08/FL09 for sensitive fields to force a second pair of eyes to review the change.
Unable to Remediate?
At this stage, you have exhausted all possibilities to remediate the access and must investigate mitigation as an option. Best practice suggests always to try to find a way to remediate a risk instead of defining compensating controls. Mitigation, whether it be with the help of spot checks, reviewing postings, etc. is always a reactive way and fraudulent actions might be done in the meantime. Still, there needs to be a balance between managing risk and allowing the business to function. If you cannot remediate, refer to the document for further details on defining mitigating controls: Defining Mitigating Controls / Compensating Controls
Analyze Again (or verify your Remediation via Simulation)
Once you have remediated your risk, we recommend you re-execute your risks analysis. You need to ensure that by remediating the risk violations you did not introduce a new one. The good news with GRC is the ability to simulate access risk. Before going to the effort of role change or access change you can execute a risk simulation to test removal of the conflicting function and replacing it with an alternative. This will provide you with confidence to remediate and avoid the introduction of new risk. Using simulation will also reduce rework through continual rebuild or access change.
Finally, I’m Finished – the system is clean…
Sorry to break it to you but risk identification and analysis are continual. You must regularly plan to review your rule set to ensure the risks are valid as the system and business are in constant change.
Keep on top of the review, so you only ever have a small number of violations to respond to. Scheduling Role Re-certification in BRM, SoD and UAR Review workflow will help manage this regular review.
