Viewing Online Reports

Access Risk Management generates over 25 online reports for user activity, role usage and risks, executions, and properties. These reports can help you determine where risk lies within your organization so you can take remediation or mitigating actions.

User Reports

User-based reports provide summary and detailed views of the risks associated with user privileges and actions.

User Summary

Purpose

The User Summary report provides a breakdown of all the active users in the system and key data points for the risks associated with the users. These include the number of roles that are assigned, the number of risks users have access to, and how many of those risks have been executed. Report viewers can also drill down for specific users to review the User Risk Level Details and User TCode Level Risk Details reports and User Remediation.

Use Case

The User Summary report is generally used to identify which users to target during remediation projects. Many organizations prioritize the most impactful changes first, which can include users that have access to high-risk conflicts and/or are executing those risks on both sides so there is a potential of inappropriate activity having occurred.

User Risk Summary by Rating

Purpose

The User Risk Summary by Rating report focuses on the risks in the environment. This summary shows all the risks in the system, information on how many users have access to that risk, and whether there have been executed transaction codes associated with the risk. Report viewers can drill down to the User Risk Level Details or User TCode Level Risk Details to see the users who have access to these risks.

Use Case

The User Risk Summary by Rating report is used by organizations to help identify what risks they want to focus on first with remediation efforts. A common approach is to go after high-risk conflicts first, and then within the high risks, they might choose to look at those that are being executed at the highest rate since that will likely be a more complex remediation effort.

User Risk Level Details

Purpose

The User Risk Level Details report shows all of the risks within the system and the users who have access to those risks. Additional information included is related to the risk, such as Risk Name, Risk Rating, and Risk Description, along with utilization information.

You can see summary-level details on the total transaction codes executed by the user for each of the business functions associated with the risk. Since each business function can contain multiple transaction codes, you will want to access other reports to see the specific transaction codes that are being executed.

The drill-down options from this report are the User TCode Level Risk Details, User Authorization Object Level Hit Details, User Remediations, and Execution Summary for that particular risk and user.

Use Case

This report is often used as a starting point when reviewing the specifics of a risk that a user has access to. The utilization bucket contains key data points used to pick what risk and user to examine.

A common scenario is to review a risk that is being executed on both sides and the summarized utilization. The summary-level utilization data can pinpoint if there are scenarios in which a user is using one function significantly more, so maybe you want them to keep that access but find someone else to take over responsibilities for the other function. In other situations it may be evident that someone is using both functions evenly, in which case you might want to look at applying mitigating controls if there is no way to remediate the risk.

Once you identify the specific user and risk you want to review, you can drill down into the more granular reports to view the transaction codes and authorization objects to which user has access to help make decisions on risk.

User TCode Level Risk Details

Purpose

The User TCode Level Risk Details report provides a granular view into what is causing a user to have access to a risk. Some things you will be able to identify on this report are the user, what risk they have access to, what transaction codes they have access to from each side of that risk, how many times they have executed each transaction code, and what role(s) gave them access to that transaction code. This report allows you to drill down further to the User Authorization Object Level Hit Details, Role Member TCode Executions, and User Remediations.

Use Case

Once you identify a specific risk to review for a user, this report shows details around that risk to assist decisions. Understanding what transaction codes a user has actually executed and where that access is coming from provides insight into how to deal with the risk either through remediation or mitigating controls assignment(s).

Another possible use case is for organizations to review their Display Only roles. If a transaction code appears in a role marked as display-only, additional investigation is recommended. In this scenario, you will use the User Authorization Object Level Hit Details report to identify if the role is giving additional authorizations or if that user is getting them from other roles or transaction codes. Since SAP has more transaction codes than authorization objects, this cross-pollination of authorizations is not uncommon.

User Authorization Object Level Hit Details

Purpose

The User Authorization Object Level Hit Details report drills down to the most granular layer of security role data. This report shows every authorization object to which the user has been assigned (shown in the columns starting with SAP) compared to the access searched for in the rulebook (shown in the columns starting with Rule).

Use Case

This report is heavily used to understand why a user has access to a risk. A common findings is that a transaction code associated with a risk is coming from a Display Only role on the User TCode Level Risk Details report. This may look like a false positive, however, there are two possible explanations that this report can help identify:

1. The Display Only role is giving more than display access. This will be clearly indicated when you go to this report since the same role will appear throughout the Role Name column.

2. The transaction code is coming from the display role and the create or change authorizations are coming from a different role the user has assigned. Since there are more transaction codes in SAP than there are authorization objects, this cross-pollination or sharing of authorizations is common. This is identified because you will see the different roles giving access in the Role Name column.

User Remediations

Purpose

The User Remediations report is used to reduce risk in the system by identifying what roles users have assigned but are not utilizing. The report indicates if any of the transaction codes associated with the access has been executed. This report also identifies how many risks are associated with that role and how many of those risks fall into the High or Critical risk rating.

Important

If a risk is on this report, it simply means that a transaction code in the role is associated with a business function. It does not mean that there is an inherent risk in that role, so this report is a good first step to removing unnecessary access in the system that has the potential for that risk.

Use Case

Organizations use this report when doing an initial cleanup or periodic review to ensure users do not have unnecessary roles that they are not using. Since only the utilization stored in SAP is initially imported to Access Risk Management, which is generally three months, organizations should allow some additional months to collect utilization data and then remove the roles that are not being used. If the end goal is reaching a state of least privilege, this is a common first step to reducing the unneeded access in SAP.

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 anyones 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.

Execution Reports

The execution reports shows the transactions codes and who executed them.

Execution Summary

Purpose

The Execution Summary report is used to show all transaction codes that users have executed along with the total number of executions. This is a good way to see a high-level view of what access in SAP is being used.

Use Case

This report is generally used for reference to understand transaction code usage.

Execution Summary Monthly

Purpose

The Execution Summary Monthly report is used to show all transaction codes that users have executed, the total number of executions, and in which month transactions were executed. This is a good way to see a high-level view of what access in SAP is being used with the addition of the time it was executed.

Use Case

This report is generally used for reference to understand transaction code usage.

Property Reports

Use the property reports to keep track of the data used to generate the reports.

Snapshot Properties

Purpose

The Snapshot Properties shows the information that was used to create the risk snapshot or dashboard reports. This includes the account information, user who scheduled the snapshot, the rulebook(s) used, along with the dates and times of the security and utilization extracts.

Risk Descriptions

Purpose

The Risk Descriptions is a reference table to show the risks, risk rating, and description that are defined in the rulebook.

Business Function Descriptions

Purpose

The Business Function Descriptions is a reference table to show the business functions, function names, and the description that is defined within the rulebook.

Mitigating Controls

Purpose

The Mitigating Controls table in the Properties section is a reference table to show the different mitigating controls in the system along with the objective and description defined for those mitigating controls. This is used as a reference to know more information about the mitigating control in place for a risk/user since most reports only indicate the mitigating control code.

Customizing Your View

For the User Based, Role Based, and Execution reports, select EDIT GRID at the top to choose which columns are displayed.

Filtering Your View

You can filter your reports view in two ways. Depending on the type of report, you can use the top filter buttons to add specific users, risks, roles, or TCodes. You can also select the Filter icon on a column to create a query.

Filtering by Users, Risks, Roles, or TCodes

Select the Filter button to see the selection screen for the item you are filtering on.

The example above shows how to filter on TCodes in the Execution Summary Monthly report. Select the TCodes filter button to see the selection window. Select + Add TCodes and add the TCodes you want to filter on. Select Apply. The report will change to the new filtered view.

If the report supports more than one filter, you can combine them. The example above allows you to add filters for both Users and TCodes. Including Users and TCodes will update the report to show you if those users have those TCodes.

Filtering by Queries

Select the Filter icon on a column to create a query.

Scheduling Report Snapshots

All online reports are part of the Risk Snapshot job. To schedule this, select SCHEDULE JOBS and choose RISK SNAPSHOT.

The information that will need to be populated to schedule the risk snapshot are:

• Repeat - Used to determine if this is a one-time job or scheduled to reoccur. The options are to not have it repeat and just run once or schedule it to run monthly, weekly, or daily. If you schedule a job to run on a recurring basis, the Security Extract and Utilization Extract will only allow you to have them set to live data. You can review all recurring jobs in the Recurring Tasks section of the application.

• We recommend running the risk snapshot at least monthly to ensure you are capturing the historical information around user access and monthly utilization data since SAP only retains it for three months.

  • Many organizations choose to run the snapshot more frequently, such as weekly if weekly transports to production are done or daily if a project is taking place that has constant updates being made in SAP.

• Report Name - Name for the report. The default will include the date/time, user who scheduled the job, and the rulebook included. As a free text field, this can be customized.

• Email when done - Email to receive notification of completion of the risk snapshot job. This will default to the user who is scheduling the snapshot.

• Security Extract - Select if you want to use live data, which will run a new security extract to base the snapshot off, or a previously completed security extract.

• Rulebooks - Select which rulebook(s) to use for the analysis.

• Months of Utilization - Select how many months of utilization to include on the snapshot. This will default to the maximum, which is 12 months. You can select a shorter time.

• Live Utilizations - If selected, the system will run a new utilization extract for any months missing within the period selected to include. Note that SAP stores this data for three months by default so you will most likely get blank extracts for months older those three.