Role Reports

The role reports give insight into role components and risks. Use the Role Summary report to get a total view of the roles in the system, then use the other reports to drill down into how those components show risk in that role.

Role Summary

Purpose

The Role Summary report provides a breakdown of all the roles in the system along with key data points around the associated risks. Some key details are related to how many users are assigned that role, how many sensitive transaction codes exist, inherent risks in the role, and whether those risks have been executed on. Users can drill down for specific roles to see more details on the Role TCode Level Risk Details report or see potential remediation actions on the Role Remediations report.

Use Case

The Role Summary report is used to identify which roles to target when initiating a remediation project. The first step during remediation is generally to remediate inherent risks in the roles and this report is used to select which roles to look at first if you want to make that decision based on risk. This can be done by filtering on the Number of Critical and High Risks or Fully Executed Critical or High Risks Count columns.

Role Ranked by Risk

Purpose

The Role Ranked by Risk report is a summary report, similar to the Role Summary, with additional information around the risks. This report focuses specifically on the roles that carry the most risk to help with remediation projects and deciding prioritization. Users can drill down to the Role TCode Level Risk Details report for specific risks to see the explicit transaction codes that are associated with the different functions in the risk.

Use Case

The Role Ranked by Risk report helps identify what roles to focus on first when performing a remediation project. A common approach is to identify the roles that have the most risk, or most executed risk, and then drill down to see the transaction code details to understand what access the role has associated with risk. You can then use this information and leverage other reports to see what transaction codes are being used and who is using them.

In conjunction with the Role Ranked by Risk report, the Role TCode Level Risk Details report can be used to identify any transaction codes in the role that are associated with risk but not being used. The Role Member TCode Executions report can show who is executing transaction codes that are being used in the role. Once you know who is using the access, you can work with the business to see if processes can be adjusted, or you may determine that remediation isn't possible and mitigation is the appropriate course of action.

Role TCode Level Risk Details

Purpose

The Role TCode Level Risk Details report gives a granular view into the cause of risk in a role. The report shows the role, the risk(s) the role has access to, the transaction codes that provide access to each side of that risk, and the total number of times users with that role have executed each transaction code. This report allows you to drill down further to the Role Authorization Object Level Hit Details and Role Member TCode Executions.

Use Case

This Role TCode Level Risk Details report is usually one of the first used reports when you are initiating a remediation project since best practice is to remediate roles with inherent risk before assigning them to users. Some common remediation steps include:

• Remove unused transaction codes from the roles. This is identified in the All TCode Execution Count column where the value equals one. Since the transaction code is not being used by anyone who has that role assigned, there should not be an impact to anyone's ability to perform their job functions if the TCode is removed. If all transactions associated with one of the business functions are removed, there is no longer an inherent risk in that role.

• If there is utilization for a transaction code, you can identify who is using that transaction code when you drill into the Role Member TCode Executions report. If you are able to identify that different users are executing transaction codes from each side of the SoD risk, you can then split the role up into multiple roles so that users keep what they are using while eliminating an inherent risk in the role.

• If there is utilization for a transaction code and the same user(s) is executing transaction codes from both sides of the risk, you can potentially remediate by changing business processes so the same users are no longer using both sides. If that isn't a possibility due to department size or headcount, you can choose to mitigate that risk. You can edit your rulebook to apply mitigating, or manual, controls to a risk or user.

• If you believe a risk is showing in a role, and for at least one of the business functions it should be display-only access, you can drill down into the Role Authorization Object Level Hit Details report to identify the specific authorization objects in the role. If there is create or change access where you believe there should only be display access, you can change the authorization objects in the role to remediate the risk.

Role Authorization Object Level Hit Details

Purpose

The Role Authorization Object Level Hit Details report allows you to drill down to the most granular layer of data when it comes to the security and role design in SAP. This report shows every authorization object the role grants access to in the columns starting with SAP, compared to the access searched for in the rulebook in the columns starting with Rule.

Use Case

This report is used to understand all the reasons why a role is being flagged as having an inherent risk. The two most common examples of inherent risks in roles that need further investigation are:

1. A role with a display naming convention showing up as having inherent risk built-in - This means that the role also has additional authorizations that are identified in the rulebook. You can see this because the columns starting with Rule Authorization show what we were testing for and the columns starting with Role identify what access is in the role.

2. A role granting access to a business function that was believed to be display-only - This is referenced in the use case section of the Role TCode Level Risk Details report. This information is reviewed similarly to example 1.

Role Member TCode Executions

The Role Member TCode Executions report shows all the roles, who has access to that role, and whether or not they have executed the transaction codes in the role.

Role Remediations

Purpose

The Role Remediations report is used to reduce risk in the system by identifying what transaction codes within the roles are not being executed. This report also shows what level of risk is associated with the unused transaction codes so you know the potential impact of removing the access.

The Role Remediation report provides best practice suggestions for managing risk associated with the transactions in the role being used. For example, the Recommendation column may suggest splitting single roles into multiple roles or breaking a composite role.

Use Case

Organizations use this report when doing initial cleanup or periodic reviews to ensure roles are not providing more access than is being used. Since Access Risk Management only pulls the utilization already stored in SAP when the initial implementation is done, generally three months, organizations should allow additional months to collect utilization data and then remove the transaction codes that are not being used. If the end goal is reaching a state of least privilege access, this is a common next step to reducing the unneeded access in SAP.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.