To understand how a business risk occurs, you must understand the methodology that both SAP Access Control and also SAP Cloud Identity Access Governance follow to identify a risk by its components.
One or more business risks can be grouped into a ruleset. This blog post covers the architecture of a ruleset and its components so that you can understand why a risk is displayed. As a role administrator, often role redesigns are triggered by SoD and critical access violations causing failure in audits. Understanding how to read and process a ruleset is therefore imperative.
Ruleset Components
A ruleset is where rules are defined in relation to specific SAP transaction codes that are/are not permitted for assignment to users. For SoD risks, the rules can define which combinations of transactions are not permitted. The rules also define which transactions are critical in nature, which may involve potentially compromising data confidentiality, system or data integrity, or system availability.
SAP Access Control uses these rules to assess users, roles, and profiles to identify access that could lead to breaches. Such breaches (conflicts or violations) can either be found in roles (due to combinations of transactions found in a role), at the user level (due to combinations of roles and thus combinations of transactions assigned to the user), at the profile level (due to conflicting authorizations within a profile itself, e.g., SAP_ALL), or at the HR position level (indirect access through the HR module).
A ruleset consists of the following components:
Access Risks
An access risk is one or more actions or permissions that, when available to a single user (or single role, profile, or HR object), creates the potential for fraud or unintentional errors. An access risk consists of one or more functions depending on the type of the risk. The following risk types are available:
- Critical action: Critical action risks consist of transactions that are considered critical. You have options to run the risk analysis at both the action level and/or the permission level. Critical action risks are created with one function only.
- Critical permissions: Critical permission risks consist of authorization objects/permissions that are considered critical. Critical permission risks are created with one function only, which cannot contain transactions.
- SoD risks: SoD risks consist of conflicting transactions along with their authorizations objects and values that are considered critical. SoD risks are created with two or more functions. Each function is combined with the OR operator.
An example of a common SoD violation occurs when the ability to create vendor master data and the ability to process accounts payable payments both belong to one role. This particular SoD conflict describes the risks that arises when a single individual is allowed to create a (fictitious) vendor, including maintaining its payment information, and then can generate (fraudulent) payments to that vendor.
Functions
A function—in governance, risk, and compliance terms—can be defined as a task that is executed in SAP, for example, purchase order maintenance or vendor master data maintenance. A function is a wrapper in the ruleset to house all the various transactions that could be executed by a user to run a particular task. For example, in SAP ERP, Transactions ME21N (Create Purchase Order) and ME22N (Maintain Purchase Order), among others, can be used for the task of purchase order maintenance and would therefore be found in the corresponding function.
As well as defining the transactions that a user could execute to run a task, the function will also contain a definition of all the authorization objects and authorization values that are required to execute each transaction. This detail is required to fully establish whether a role or a user has all the access required to execute a transaction. If they do not, then the transaction cannot be executed and would thus the risk of breach is minimized.
Ruleset Architecture
The figure below shows the systematic architecture of a ruleset with its components. Our example involves two SoD risks, consisting of two functions each. Functions can be involved in one or more risks. In this example, Business Risk 1 is defined through the functions Business Function 1 and Business Function 2. A function is defined through transactions (Actions) and authorizations (Permissions). Each action is defined with permissions. For example, Transaction SU01 requires authorization object S_USER_GRP to have the ACTVT values 01, 02, 05, or 06 for the transaction to be deemed critical. Therefore, in the ruleset, if this transaction is part of a function for user management, the transaction and its authorization values are maintained. A risk is then created when, in each function at least one action with a permission, is found.
The next figure shows an example of a common SoD conflict from a business view. In this example, the SoD “Maintain Purchase Orders versus Manage Goods Receipt” is defined through an access risk (of type SoD). The access risk contains two functions: Maintain Purchase Orders and Manage Goods Receipt. Each of these two functions have been defined with actions and permissions.
When running an SoD analysis, the SoD is caused when one of the rules is found. The rule represents every single combination of SoD that is possible in this scenario. As shown in the above figure, both functions are defined with two transactions, which thus requires four rules.
When changing the ruleset in SAP Access Control, you must execute the job GRAC_GENERATE_RULES to generate all possible combination rules via Transaction SPRO. Navigate to GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules. Without the generation of rules, content changes to the ruleset will not be available for analysis. Therefore, we recommend scheduling the job for updating rules to run frequently.
Tip: The number of rules defined for a risk is determined by a) the number of action combinations and b) the permission/field value combinations contained in each function of the risk. For more information, refer to http://s-prs.co/v203613.
SAP Standard Rulesets
SAP delivers industry standard rulesets with SAP Access Control that contain extensive sets of known SoD and critical risks. The table below provides an overview of rulesets available in SAP Access Control 12.0.
You can check the available BC sets and activate them in Transaction SCPR20.
The SAP standard rulesets form the basis of the customer ruleset. During customization of your ruleset, you should identify your business processes and adjust accordingly. SAP recommends creating custom functions and access risks in your customer namespace (e.g., starting with “Z”) and not to modify the standard predelivered objects at all. This approach also allows you to update (reimport the BC sets) the standard rules and then compare the standard against your customizations.
In SAP Cloud Identity Access Governance, SAP provides standard rulesets for various target systems (SAP ERP, SAP S/4HANA, SAP Fiori, SAP SuccessFactors, SAP Ariba, etc.) that must be requested through an incident ticket in SAP Support Portal.
SAP Note 2782388: SAP Note 2782388: IAG - How to load default standard ruleset explains how you can request that standard rulesets be loaded into SAP Cloud Identity Access Governance.
Organizational Rules
Organizational rules in SAP Access Control are used to eliminate false positives in SoD reporting based on organizational level restrictions for users. Organizational rules should not be created for mass organization level reporting; organizational rules should only be enabled for functions that you specifically need to segregate. Most companies control what data a user has access to via role assignment.
Organizational rules allow you to filter false positives from risk analysis. False positives in the context of organizational rules are caused when the risk analysis does not consider organizational levels. For example, a user can maintain master data for company code A and perform a posting for company code B. Without respecting organizational values, this scenario may involve an SoD conflict since one individual can both maintain master data and also post transactions.
To elaborate on this topic, suppose, for example, we have the following roles:
- Role A: Z_ROLE_A_1000 for company code 1000 with action FB60.
- Role B: Z_ROLE_B_2000 for company code 2000 with action FK02.
Role A contains Transaction FB60 (posting of vendor invoices) for company code 1000, whereas Role B contains Transaction FK02 (changing vendor master data) for company code 2000.
The combination of Transaction FK02 and Transaction FB60 with their permissions constitutes an SoD risk since the posting of vendor invoices and the changing of vendor master data shouldn’t be performed by the same person. A user who receives these two roles would have both transactions assigned, and thus, the risk analysis will show a risk. However, this risk isn’t really a risk since the same individual is limited in their actions by organizational level (company code). This result is a false positive, and by utilizing organizational rules, you can ensure these scenarios are not reported as risks during risk analysis.
In most cases, organizational rules are created for individual risks, but not for all risks. This limitation is mainly due to the potential performance impact that organizational rule analysis causes.
Simulating Risk During Role Building with the Risk Terminator
The Risk Terminator is a component delivered automatically with SAP Access Control. With the access risk analysis module, risk analysis should be carried out manually for every role/user change. But, what if a critical role is assigned to the user without performing risk analysis? What if critical transaction codes like Transactions SCC4, PFCG, and SPRO are added to a newly created role or an existing role?
The Risk Terminator provides the ability to keep the SAP systems free of risk. Running in the background, a popup window will appear when a role is assigned in Transactions SU01, SU10, and PFCG or when a role modification in Transaction PFCG might cause risk. The Risk Terminator resides on the backend ABAP system and uses the access risk analysis module to run an ad-hoc risk analysis. Depending on the configuration, the Risk Terminator can work as both a detective (reporting on access violations) or as a preventive (the system will prevent violations from being introduced into roles).
Whenever a change is made to an existing SAP role, or a new role is created, the Risk Terminator checks the content of the role. With the Risk Terminator, a role administrator can immediately remediate access violations during the development of roles and thus play an important part in ensuring that the system stays clean (by preventing violations from being introduced in the first place). In this scenario, the Risk Terminator is used in the development system (DEV). You can also use the Risk Terminator when assigning roles to users, a powerful feature in your productive system (PRD). When checking role assignments, the Risk Terminator runs a simulation and displays all the risks on the user level (similar to an ARM workflow). As a security administrator, you also can mitigate the risk if the risk cannot be avoided.
In the area of role development, the Risk Terminator can be a valuable asset to a role administrator in preventing SoD conflicts and preventing sensitive access violations from being introduced into roles.
As a final example, you can use the Risk Terminator in your DEV to scan role changes against the ruleset to avoid introducing risks to roles. You can also use the Risk Terminator in your PRD to simulate role assignments through Transactions SU01, SU10, and PFCG to avoid introducing risks to users.
Editor’s note: This post has been adapted from a section of the book Authorizations in SAP S/4HANA and SAP Fiori by Alessandro Banzer and Alexander Sambill.
Comments