SAP GRC ARA | How to Improve Access Risk Analysis Results

During this article we will review how to improve access risk analysis using certain functionalities within the ARA module of SAP© GRC.

Introduction

Segregation of duties (SoD) is one of the main principles used by organizations to reduce the potential fraud and the related impact. To correctly apply this principle to user access management in SAP systems, three main tools must be used:

• Define an Access Risk RuleSet (using the market standard for the system in analysis as a reference).
• Role model based on SAP best practices (aligned to business functionalities and the Risk RuleSet).
• Risk management system, where the Risk RuleSet can be uploaded to execute user & role risk analysis (for SAP the standard option would be the ARA – Access Risk analysis – module within SAP GRC Access Controls).

The use of these three tools will allow us to put in place a preventive control to monitor the segregation of duties during the assignment of access to users using access risk analysis.

Considering this situation, this article will focus on explaining how we can improve the technical configuration of our rules in SAP GRC AC ARA to have more refined risk analysis and avoid false positives, i.e., prevent the reporting of positive results when they are not really positive because not all the expected rules are met.

The two standard functionalities of SAP GRC that will allow us to do this risk analysis fine-tuning are:

• Organizational Rules.
• Supplementary Rules.

Organizational Rules

Case study

Imagine a situation where an organization considers that two activities in the purchasing process are not considered as SoD risk if they are executed by the same user for two different companies, below is each functionality and a sample transaction:

• Process Vendor Invoices (tcode FB01 – Post Vendor invoices).
• AR Payments (tcode F110 – Parameters for Automatic Payment) 

The combination of the two business tasks mentioned above often poses a business SoD risk as their assignment to the same user could lead to a risk of creating a fictitious vendor invoice and initiate payment for it.

By creating organizational rules for this SoD risk and for the organizational value Company (BUKRS), the risk analysis could be filtered so that it is only positive for companies that are considered critical.

Where can this be set up in SAP GRC?

The creation of organizational rules can be done at the following GRC link within the path Setup -> Exception Access Rules -> Organization Rules

Once configured, the following GRC AC parameters will have to be reviewed and adjusted, depending on the use we want to make of this type of rules:

• 1054 – Max number of violations supported in Organization Rule Analysis
• 2060 – Organization Rules -Maximum allowed to be generated in foreground
• 1021 – Consider Org Rules for other applications

Finally, to apply Organizational Rules to the risk analysis, the option Consider Org rule has to be ticked during the execution of the risk analysis:

Supplementary Rules

Case study

Two fictitious customer cases are explained to explain the use of the supplementary rules:

1. Purchase requisition approval: Customer 1 wants to eliminate false positives from its analysis for all risks in which the purchase requisition approval functionality is involved. PR Approver users, in addition to having access to transaction ME54, ME54N or ME55, must be maintained in a configuration table (release strategy table). Finally, the risk is only relevant if the user can be an approver for purchasing group PGX.
2. User maintenance:  Customer 2 wants positives in risk analysis only if users do not belong to the user group UG_AUTH_TEAM. User belonging to this user group are pre-approved (exceptions).

In short, in these two cases, if we consider only the user’s access level, we will be identifying access risks that are not really access risks (false positives).

What the Supplementary Rules functionality allows would be to include additional rules to the Business or IT functions that are part of the access risks, adding other conditions that must be fulfilled, to correctly identify which users really have the risk.

Where can this be set up in SAP GRC?

The creation of Supplementary Rules can be done at the following GRC link within the path Setup -> Exception Access Rules -> Supplementary Rules

The following screenshot shows an example of case study a), where a Supplementary Rule has been activated in the Purchase Requisition approval function.

Once configured, parameter 1037 – Use SoD Supplementary Table for Analysis will need to be reviewed and adjusted.

Key points

• More and more organizations are faced with the concept of segregation of duties (SoD), with SAP GRC AC being a solution to assist in the technical oversight of such risks using SAP GRC AC ARA.
• GRC AC ARA module is very powerful and flexible when it comes to configuring access risks and not only has the simple functionality of executing analysis.
• The main benefit of organizational and supplementary rules is that they allow us to refine our risk analysis and thus reduce false positive results.
• It is very important to understand the process, functions, and access SoD risks in which the organizational & supplementary rules are to be applied to validate whether this GRC ARA functionalities meets the customer’s requirements.
• Tech advice (!) – To facilitate the use and maintenance of these rules, it is important to note that both can be loaded in bulk from the general GRC configuration in the back-end system (SPRO transaction).
• Organizational Rules:
  • It is recommended to apply this type of rules only on high level risks and those that really add value.
• The proper use of this functionality is to reduce false positives, it is not recommended to use it to generate risk reports filtering by organizational values (it affects GRC system performance).
• Supplementary Rules:
  • These rules will apply to all transactions within the same function. If you want them to apply to only one of the transactions, you will have to create a new risk/function.
• These rules can be applied for one or all risks related to the modified function.
• The information in the fields of the tables to be validated is always stored in upper case (not case sensitive) and should contain the SAP USER ID relationship.