The Access Risk Analysis (ARA) component provides Access risk management. SAP Access Control delivers a fully automated security audit and segregation of duties (SOD) analysis tool. Delivered with several risk catalogs or rule sets to define access risks, SAP Access Control helps you to identify, analyze, and resolve SOD and audit issues related to regulatory compliance. You can use SAP Access Control to run reports for real-time ad-hoc risk analysis and offline batch risk analysis. As a compliance team member, to eliminate a conflict, you can use risk simulation analysis to develop the appropriate remediation strategy by simulating changes to user access or role design. During the risk analysis process, you can select and apply mitigating controls if a suitable control has been defined in the mitigating control catalog.
Employees who wish to manage access risk must follow a three-stage approach. By applying this method, it is possible to implement a process for access risk management. The process is constructed of three phases containing a total of six steps, as shown in the figure. The first step of the access risk management process begins with identifying risks in your business processes and then classifying those risks. This step is called Risk Recognition. The purpose of Risk Recognition is to determine and classify risks. You can then construct rules that determine the existence of these risks in analyzed objects, such as users, roles, profiles, and HR objects.
Let's explore the first step of the process: Risk Recognition. We illustrate this by using the example of identifying payroll risk.
For the following example, imagine yourself in the role of a business process owner. As a Business Process Owner you along with Business Process Experts are key participants in identifying access risks in business processes. In addition, Senior Officers can help to align on risks between different business areas.
As an example of risk recognition, let's consider the scenario of payroll risk identification. The payroll process includes all activities that are used to create a payroll run. It considers all changes within the personnel administration process, such as salary changes, or the assignment of another tax class. This process ultimately triggers a series of actions. These actions include the creation of salary statements, making salary payments to personnel, and posting all relevant information to financial accounting and controlling.
The payroll process contains the following steps, which must be separated from each other from an access granting perspective:
- Run payroll simulation (HR).
- Release payroll (HR).
- Run productive payroll.
- Prepare bank transfers using preliminary program for data medium exchange (FI).
- Use the Payment Media workbench to create a payment file for final bank transfer (FI).
If authorizations are not properly controlled and duties are not segregated, a user could exploit this vulnerability to realize a financial gain by performing one of the following conflicting activities:
- Modify payroll master data, such as salary information (PA30), and then process the payroll (PA03, PAUX).
- Change employee HR benefits (HRBEN0083), then process payroll (PA03, PAUX) to improve their own financial situation.
- Modify time data (PA63) and process payroll (PA03, PAUX), resulting in fraudulent payments.
- Enter false time data (PA71) and perform payroll maintenance (PA03, PAUX).
- Print salary statements to printers to which unauthorized persons have access.
As a business process owner you must identify such conflicting activities or critical actions/critical permissions on the business side. Then, you define the issues in SAP Access Control as an access risk. An access risk is one or more actions or permissions that create the possibility of irregularity when they are assigned to a user, role, profile, or a HR object.
Access management experts grant access to conflicting actions included in an SOD access risk in the way to minimize giving all conflicting actions to one person. A company must segregate access to conflicting actions and monitor cases of granting access to critical actions, permissions. SAP Access Control provides a functionality to facilitate these tasks. Having access risks defined in SAP Access Control you can analyze a user, role, profile, or a HR object for access risks, and act further to eliminate or mitigate risks.
After identifying access risks in business processes, you can start the Rule Building and Validation.
The following figure shows the main components of a rule set and other examples of segregation of duty risks.
On the Rule Building and Validation step, business process owners, security administrators, and technical liaisons configure SAP Access Control system to enter identified access risks. The process involves extra, more detailed, workshops at the Business Process level, the functional and process experts must review each relevant risk and all associated elements. Security administrators and technical liaisons support the technical part of the process regarding the SAP Access Control system.
In SAP Access Control, an access risk includes one or more functions. Each function is defined regarding the relevant actions and permissions required to perform that business function in a specific solution. For example, the following task poses a risk (see Risk A) "User can maintain vendor master data and initiate payment runs." For this risk, two functions are relevant: Function 1 "Maintain Vendor Master Data" and Function 2 "Process Vendor Invoices." Both functions involve specific tasks and require certain permissions related to the stated risk. One person or role performing both functions can pose an access risk, as it can lead to conflicts of interest or irregularities. Access risks are associated with business processes and all the components come together to form rules. Access rules represent all the possible combinations of the actions and the permissions from functions for each access risk. Rules are collected in a rule set.
SAP Access Control supports three different types of risk:
- Segregation of duty risk based upon a combination of actions from two or more conflicting functions. Assignment of combination of action or permission from one function with action or permission from another function of the same SOD Risk can constitute the SOD Risk
- Critical action risk where access to a single action can constitute a risk
- Critical permission risk where having a specific authorization or permission can constitute a risk
In addition to a rule set, critical roles, and critical profiles can be defined when individual roles and profiles pose an access risk to your company. For example, a critical role could be a user role that has excessive system access rights, such as an administrator role.
You do not have to create a new rule set for every business process, there is a predefined rule set content with access risks. The SAP delivered rule set is accumulated from best practices, clients, and SAP's own experience. Standard rule set content is delivered for SAP Solutions. For example, SAP S/4HANA, SAP ERP, SAP CRM, and SAP HANA Database. These rules include risks for processes such as Basis, Finance, HR and Payroll, Material Management, Native HANA Privileges, and many more.
Review the predefined rule sets to determine if they are applicable to the monitored environment. In case if you have specific or unique requirements not covered by the delivered data, you can incorporate new custom risks and functions into the rule set. Also it is possible to change existing predefined access risks, functions data for the specific actions and permissions that are relevant for analysis in a company. The delivered rule set content is intended to be a template, which can be used to accelerate the implementation process. It provides you with a starting point from which you can customize the rule set to fit your implementation of specific business scenarios, business processes, and business functions.
The main steps of the rule building process are summarized in the preceding figure. To build rules, you must define the following objects:
- Business processes. For example, Procure to pay, Order to cash, HR and payroll.
- Rule set ID to assign a new risk to the rule set.
- Functions. While defining functions, assign actions and permissions to the functions and specify a business process for the functions.
- Risk. While defining a risk, assign functions to the risk, specify the rule set and business process for the risk.
Rule Building and Validation - Create a Function
From theory to practice: how do you now create functions in the system? To create functions, use the Functions app.
While creating a function, you specify the following attributes:
- Function ID
- Business Process
- Analysis Scope (Single or Cross System)
- Description
The Analysis Scope determines if the function can be used to define a Cross System Risk. In function details, you add actions and permissions. You can find function examples with actions included on the preceding screenshot. An action can be:
- An SAP transaction code
- A Web Dynpro application
- A Fiori UI5 application
- An Odata Service
Each action, permission is linked to a specific system via a connector group that represents several target systems. The connector group under the column system is used to provide a link to one or more technical systems against which a particular action, permission can be used. For an action, permission to be considered for analysis it must have the status "Active". All active items will be considered as part of the ruleset after rules generating.
On the preceding screenshot, you see an example of how to specify permissions for the functions.
- Add/Remove authorization objects, fields, and values.
- Conditional Logic Operators.
- Permission Group references a T_Code, Web Dynpro app, Fiori UI5 app, or Odata Service for ABAP systems.
- Permission references specific Authorization Objects required for SAP actions as defined in SU24.
- Active/Inactive status value determines if an object will be included in generated Access Rule.
After creation, a function can be modified or deleted. A detailed audit log of changes to the function definition can be captured on the Change History tab of the function. A function approval workflow to send a function for approval can be configured.
Rule Building and Validation: Create an Access Risk
After creating the function, you can now proceed to use the Access Risk app to create access risks.
Use the Access Risks app to create access risks. While access risk creation you specify the following attributes of an access risk:
- Access Risk ID
- Risk Type (Segregation of Duties, Critical Action and Critical Permission)
- Business Process
- Description (short)
- Risk Level
- Status
- Long Description
- Control Objective
In access risk details, you assign corresponding functions, rule sets, and risk owners. To be considered in risk analysis, a new risk, function, or an edited existing risk, function must be generated in one of the following:
- the list of all risks in Fiori interface
- the list of all functions in Fiori interface,
- using the program GRAC_GENERATE_RULE.
After creation, a risk can be modified or deleted. A detailed audit log of changes to the risk definition can be captured on the Change History tab of the risk. A risk approval workflow to send a risk for approval can be configured.