For many versions of Risk Analysis and Remediation (RAR) — from the most recent SAP BusinessObjects Access Control 5.3 back to Compliance Calibrator 4.0 — Rule Architect is the lifeblood of the application. This tool assists companies in defining what constitutes a risk at both the business and technical levels. I will describe how Rule Architect works and key concepts to understanding functionality within Rule Architect.

Specifically, I’ll explain the building blocks of rules, including how to create functions and risks. Functions are definitions of a certain business process, such as the creation of vendors. Risks are a combination of functions that could result in physical loss or fraud, such as someone having the ability to both create vendors and process payments to vendors.

I’ll start with an overview of Rule Architect before moving on to the initial setup of Rule Architect along with its functions and risks.

Rule Architect Overview

The core of Rule Architect is the definition of functions and risks. RAR automatically generates the segregation of duties (SoD) rules based on your definition of functions and risks. At a very high level, risks are conditions that could result in physical loss, fraud, process disruption, or productivity losses. In RAR, a risk is made up of one to five functions. A function is a business process such as Customer Master Maintenance or Post General Ledger Entries. It is the definitions of functions and risks that ultimately determine your SoD rules.

Rule Architect Initial Setup

When using Rule Architect, the first piece of data to create is the Business Process ID. This allows you to group both functions and risks into logical business groupings. SAP delivers 12 standard business process IDs, but users can choose to change these or create their own. You can create business processes in RAR by going to Rule Architect > Business Processes > Create. See Figure 1 for an example of the standard business processes used.

Figure 1

Standard business processes

Defining and assigning these business processes to functions and risks is important because you can run SoD reports for specific business processes. For example, the head of your purchasing department may want to see only those risks relevant to his area. In RAR under Informer > Risk Analysis > User Level, you can limit the report to only risks for a specific business process by clicking one of the options in the Risks by Process drop-down menu (Figure 2).

Figure 2

Risk analysis

The next step in Rule Architect is to create a rule set. You can do this by going to Rule Architect > Rule Sets > Create (Figure 3). Rule sets are a way for you to group risks. You can assign a risk to one or many rule sets.

Figure 3

Rule sets

The purpose of multiple rule sets is to satisfy different reporting requirements for subsets of rules. When running a risk analysis report from the Informer tab of RAR, users can choose which rule set they want the analysis to use (Figure 4). For example, the Global rule set may include all risks, but the SOX rule set only includes those risks that are relevant for Sarbanes-Oxley.

Figure 4

Default rule set

There are several key items pertaining to reporting to keep in mind when creating rule sets and assigning risks to them:

• In RAR, you can only run management reports against the default rule set as defined in Configuration > Risk Analysis > Default Values. You can change the default rule set when running risk analysis (Figure 5). This is where you can choose specific rule sets for review.
• In Compliant User Provisioning (CUP), you only perform risk analysis for requested access against the default rule set as defined in RAR.

Figure 5

Rule set selection in risk analysis

In addition to setting up business processes and rule sets, it is imperative to upload the master data required for creating functions. This master data is required to assist in defining the function using the master data from the back-end SAP system. Specifically, there are two important files that you must download from every back-end system and upload into RAR. In each back-end system, you need to run programs /VIRSA/ZCC_DOWNLOAD_DESC and /VIRSA/ZCC_DOWNLOAD_SAPOBJ using transaction code SA38.

These programs create two text files. Next, in RAR, go to Configuration > Upload objects. The file created with the DESC program is loaded under Configuration > Upload Objects > Text Objects. You upload the file created with the SAPOBJ program under Configuration > Upload Objects > Permissions. It’s imperative this data is loaded prior to creating functions and risks.

Rule Architect Functions

After you create business processes and rule sets, you need to create the functions. Functions are made up of actions and permissions. In SAP terminology, this corresponds to transactions and authorization objects.

You create functions under Rule Architect > Functions > Create (Figure 6). The header of the function includes up to an eight-digit function ID, description, business process, and analysis scope. At the function level, the business process merely groups functions together. You use it to help search for a specific function, but it does not affect reporting.

Figure 6

Create a function

The analysis scope is very important. There are two options: Single System or Cross-System. Which one you choose determines how the system generates rules. If you select Single System, the system only generates the rules within a single system when this function is combined with another function set to Single System. If you select Cross-System, the system generates rules both within single systems and between systems. In a risk, you only have to select one function as Cross-System for cross-system rules to be generated.

Figures 7 and 8 show an example of a risk that contains two functions, VE8 and VFD. If both functions are single-system functions, the rules generate so that ME21N from system VE8 conflicts with MIGO from system VE8, and ME21N from system VFD conflicts with MIGO from VFD.

Figure 7

A risk with two functions

Figure 8

Another risk with two functions

If either function is cross-system, you get both of the previous rules. Also, ME21N from system VE8 conflicts with MIGO from VFD, and ME21N from VFD conflicts with MIGO from VE8. This is useful when you have different systems for various business processes. A typical example is that you might have completely separate systems for human resources and the core ERP system. In this case, you need to be able to report if any users can create personnel records in the HR system and then process payroll checks in the ERP system. This requires you to use cross-system rules.

Be careful creating functions as cross-system. As explained in the SAP BusinessObjects Access Control 5.3 help portal, there is a limit to how many rules you can generate for each risk. This limit is 46,655 rules for each risk. By setting a function as cross-system, you are at least doubling the rules — if not tripling or quadrupling — depending on how many systems you have loaded. This could result in hitting this limit and forcing you to break apart the rules. Therefore, only make functions cross-system if you know that you want to analyze risks across systems.

Note that creating cross-system rules is just the first step. You also must create a cross-system ID to actually run analysis for cross-system risks. You create a cross-system ID by going to Configuration > Cross System > Create (Figure 9).

Figure 9

Cross-system ID

The core of the function is the data maintained on the Action and Permission tabs. When you assign an action to a function, you must assign it with a system attached to it. There are two system methodologies you can use to load actions in the functions. The first way is to load the actions against the individual physical systems. You can create physical systems in RAR under Configuration > Connector > Create (Figure 10).

Figure 10

Physical system connector

If you only have one physical system for which you want to create rules, loading against the physical system ID is fine. However, if you have multiple systems and the same rules apply to all systems, you have to load the actions and maintain the permissions for every system. To ease the maintenance of the rules, SAP developed logical systems beginning with SAP BusinessObjects Access Control 5.2. You create logical systems under Configuration > Logical systems > Create (Figure 11). Using logical systems to load actions and permissions reduces the maintenance with functions and allows you to create rules under the 46,655 limit as described earlier.

Figure 11

Logical systems

For example, if you have a risk that has three functions — one with 20 actions, one with 30 actions, and the third with 40 actions — it would generate 24,000 rules for just one system (20 x 30 x 40 = 24,000). If you had three systems in your landscape, this would be 72,000 rules (24,000 rules per system x 3 systems), which RAR cannot handle. Therefore, if you use logical systems to load, it only generates 24,000 rules for the one logical system instead of generating for the three systems. The risk analysis continues to show the physical system where the risk occurs; the logical system just helps maintain the rules. Figure 12 shows the difference between loading rules against physical and logical systems.

Figure 12

Actions in functions with physical and logical systems

It is important to note that logical systems and cross systems must be built independently. Specifically, if you load your actions under a logical system, you cannot also set up the physical systems within that logical system as cross systems. You can read more about this in SAP Note 1178372, which you should read if you plan to use logical and cross systems together.

The second tab on the function screen is called Permissions. This corresponds to authorization objects in SAP terminology. It is not required to have permissions in your functions, but it is a best practice. By enabling permissions, you can further define what truly creates a risk by excluding users who have display or other security restrictions that actually prevent them from performing the function.

The data on the Permissions tab is automatically populated for every action based on the data uploaded previously via Configuration > Upload Objects > Permissions (Figure 13). All permissions default in disabled status (the light bulb icon is turned off). You need to determine which permissions and values you want to enable. Transaction ST01 is a good place to start identifying which permissions to enable.

Figure 13

Permissions

It is important to understand the processing logic of permissions so you can understand how SAP security, and therefore RAR, works. The first key understanding is that the logic between individual permissions is always an AND relationship. There is no way to change this. For example, in the screen shown in Figure 14, permissions M_BEST_BSA and M_BEST_EKG are enabled. This means a user must have both permissions plus transaction code ME21N to satisfy the risk that contains this function.

Figure 14

Example of activated permissions

Similarly, the logic between fields under a single permission is always an AND relationship. For example, in the screen shown in Figure 15, the ACTVT value is inherently an AND relationship with the BSART value.

Figure 15

Permission field values

This is a confusing area for people. The Condition column, in which you can choose AND, OR, and NOT, only applies to the field values for a single specific field within a permission.

So in the example in Figure 15, a user must have transaction ME21N with authorization object M_BEST_BSA with ACTVT of 01 AND 02 AND BSART of EC, FO, OR NB. Only users that have this combination are reported as having the risk. If a user only has ACTVT 01, the system does not report the user. Conversely, if a user has ACTVT 01 and 02 and only BSART EC, it satisfies the risk.

The NOT condition is misunderstood. People believe it only reports users who don’t have that single value. However, it actually reports if they have any value except the value in the rule. If they have that value along with any other value, they will be reported.

I recommend you define your permissions with OR ranges instead of using NOT. For example, say you have a document type FB that you don’t think causes any conflicts. You should define the function as indicated in Figure 16. You should include ranges with OR conditions that basically exclude the value that is not relevant (FB).

Figure 16

NOT condition values

Rule Architect Risks

Risks are much simpler to build and maintain than functions. A risk is simply the definition of which functions you believe that, when combined, create a potential for physical loss, fraud, process disruption, or productivity losses. You create risks by following Rule Architect > Risk > Create (Figure 17).

Figure 17

Create a risk

As with functions, there is a header section that contains a four-digit risk ID and description. The Risk Type can be one of three options:

• Segregation of Duties: This is the standard and contains two to five functions. This type of risk results when a user has two conflicting functional duties.
• Critical Action: This type of risk only has one function. There are some actions that are so critical that you want to report all users who have it. An example is transaction SCC4, which allows the changing of client configurations. It’s not that a combination of functions creates the risk, but the single function is risky in and of itself. The terminology is a bit misleading in that while it says critical action, if you define the function at both the action and permission level, the system considers the permissions when doing the analysis as well.
• Critical Permission: This is similar to critical action in that it only contains one function. However, in this situation, the function only has permissions (no actions). In SAP systems, there are permissions that are deemed inherently risky and anyone with these should be reported. An example is authorization object S_BTCH_ADM with a value of Y, which allows users to do background job processing.

You use the risk level to group risks and when running management reports and risk analysis. As discussed before, you use the business process to group risks together and to filter risks when running risk analysis.

You use the tabbed area within the risk to define which functions make up the risk, as well as the rule sets to which the risk belongs. The other tabs are explained below:

• Detailed description: This ensures the business can understand the risk. This area should explain in business terms why you think the combination of the two functions results in a risk.
• Control Objective: This defines why it is important that the functions are segregated and can include detailed information about what standards (e.g., Sarbanes-Oxley or internally documented control objectives) require segregation
• Risk Owners: You can use this to facilitate workflow if integrated with CUP. If workflow is configured and this tab for risk owners is populated, you can have any changes to risks be sent to the owner for approval.

After you create a risk, the final step is to click the Update Rules button at the bottom of the risk creation screen (Figure 18). The best practice is then to choose the Actions & Permissions radio button and either the Foreground or Background button. Background is recommended if the risk is fairly large (i.e., has more than two functions or has a lot of actions in the functions).

Figure 18

Update rule

Generating the rules automatically creates the rules that RAR uses. You cannot edit rules directly. You can only change rules by changing the functions and risks. Figure 19 shows an example of a generated rule.

Figure 19

Generated rule

Jayne Gibbon

Jayne Gibbon, CPA, has been implementing SAP applications since 1996 and is currently a director in the Chief Customer Office at SAP. Jayne’s focus is making customers successful with their SAP HANA deployments. She has helped more than 100 customers drive business value with SAP HANA. Prior to joining SAP in 2007, Jayne worked for two multinational manufacturing companies based in Wisconsin. While an SAP customer, Jayne led the very first implementation of Virsa’s Compliance Calibrator, which is now part of SAP Access Control. Jayne’s experience includes internal audit; computer security; governance, risk, and compliance; SAP HANA; and SAP analytics.

You may contact the author at jayne.gibbon@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.