#### Disabling risk index functions

One Identity Manager provides default functions for all assignable company resources. Not all functions are required, it depends on your custom configuration of One Identity Manager. In order to exclude irrelevant functions from the risk index calculation, you can disable these functions. This means, the calculation procedures effected are reset.

To disable functions

- Select the
**Risk Index Functions** category.
- In navigation view, open the
**Risk index functions > <table> > <filter>** item.
- Select a function in the result list and run the
**Change main data** task.
- Select the
**General** tab.
- Click
**Disabled** category.
If this option is already set, you do not need to do this.

- Save the changes.

#### Start calculation

The risk index calculation is started by the following events:

- A function was changed.
- Objects in the source table have changed.
- A scheduled calculation task is being run.

###### Risk index function was modified

The moment a function changes, a calculation procedure for the effected table column (target) is set up. There is exactly one procedure set up for each table column (target), which bundles all enabled functions for the table column. Then the risk indexes are calculated.

###### Data change in a source table

Once data in the source tables changes, the risk indexes are recalculated. To do this, a calculation task is queued in the DBQueue Processor. If the **Calculate immediately** option is set for a function, the risk indexes effected are calculated immediately. In this case, the calculation is not DBQueue Processor controlled.

The following changes to the source tables trigger recalculation

- Objects are added or deleted
- The origin of an assignment has changed.
- The effectiveness of an assignment has changed.
- Risk indexes were changed
- Risk indexes were calculated

All other changes do not cause automatic recalculation of risk indexes. You can use a process plan task to calculate risk indexes so that changes made to them can take effect. This is required, for example, in order to take into account approval of attestation cases in calculated risk indexes. Functions that are not assigned to a source table are also only taken into account when scheduled recalculation is run.

###### Scheduled calculation task is run for the DBQueue Processor

To ensure that calculated risk indexes are continually update, taking all functions into account, you can configure a scheduled calculation task to calculate risk indexes. One Identity Manager provides the "Calculate risk index" schedule to do this. This schedule is disabled, by default. Enable it to recalculate the risk indexes on a scheduled basis. Adjust the activation times to suit your company’s requirements.

To enable the schedule for calculating risk indexes

- Open the Designer.
- Select the
**Base Data > General > Schedules** category.
- Select the "Calculate risk indexes" schedule in the List Editor.
- Check the box in the
**Enabled **column.
- Save the changes.

###### Related topics

#### Weighting and normalization

You can calculate the risk index for an object type using different methods.

- Highest risk index of all assigned company resources
- Average of all assigned company resource risk indexes
- Highest weighted risk index of all assigned company resources
- Sum of all normalized to 1 and weighted assigned company resource risk indexes

In the default functions, the risk indexes are calculated by the first method.

NOTE: If calculation types for both weighting and normalization are implemented in risk index functions for one and the same target column, the risk index calculation does not determine a reasonable value.

The following applies for all risk index functions of one target column: Only combine functions with the calculation type "Maximum (weighted)" and "Average (weighted)" or the functions with calculation types "Maximum (normalized)" and "Average (normalized)".

###### Weighting

In the calculation using method 3, the maximum and average values are determined of the risk index of all assigned company resources of an object type. This value is weighted with the given weighting. The highest weighted risk index is the calculated risk index.

Calculations using methods 1 and 2 arise when the weighting in all relevant functions, is given with the value 1.

To calculate risk indexes using methods 1, 2, or 3

- Select the "Maximum (weighted)" or "Average (weighted)" calculation type.

###### Normalization

In the calculations using method 4, the maximum and average values of the risk index for all assigned company resources of an object type are determined. This value is weighted. The sum of all weighted risk indexes of this object type is the calculated risk index.

The sum of the weightings must be exactly 1 with a calculation, because the range from zero to 1 must be adhered to for the resulting index. That is why, the weightings of all enabled functions for the same target column are normalized to 1. The risk index found is weighted with this normalized value. The normalized weighting is calculated from the weighting divided by the sum of all relevant weighted values. This results in the following formula for calculating the risk index:

To calculate risk indexes using method 4

- Select the "Maximum (normalized)" or "Average (normalized)" calculation type.

The weighting is only relevant if there is more than one function for a target column because the result of normalization is exactly 1. In this case, calculations using method 4 return the same result as calculating with method 1. The difference between weighting and normalization is only relevant if more than one function is enabled for a target column. This is made clear in the following example.

###### Example

Calculate the risk index for SAP user accounts from risk indexes of assigned SAP groups and structural profiles, and from SAP function risk indexes that match with the user accounts. Three SAP groups (G1, G2, G3) and two structural profiles (P1, P2) are assigned to a user account. The user account matches one SAP function (FS) exactly.

Risk Indexes

- G1 = 0.2
- G1 = 0.3
- G1 = 0.4
- P1 = 0.6
- P2 = 0.7
- SF = 0.5

Calculation type

- By method 1: maximum (weighted), weighting = 1
- By method 3: maximum (weighted)
SAP group weighting: 0.6

Structural profile weighting: 0.8

SAP function weighting: 0.7

- By method 4: maximum (normalized)
SAP group weighting: 0.6

Structural profile weighting: 0.8

SAP function weighting: 0.7

Table 8: Risk index calculation results
Highest risk index of all assigned SAP groups |
0.4 |
0.4 |
0.4 |

Weighting/Normalization |
1 * 0.4 = 0.4 |
0.6 * 0.4 = 0.24 |
(0.6 / (0.6 + 0.8 + 0.7)) * 0.4 = 0.11428 |

Highest risk index of all assigned structural profiles |
0.7 |
0.7 |
0.7 |

Weighting/Normalization |
1 * 0.7 = 0.7 |
0.8 * 0.7 = 0.56 |
(0.8 / (0.6 + 0.8 + 0.7)) * 0.7 = 0.26667 |

Highest risk index of all matching SAP functions |
0.5 |
0.5 |
0.5 |

Weighting/Normalization |
1 * 0.5 = 0.5 |
0.7 * 0.5 = 0.35 |
(0.7 / (0.6 + 0.8 + 0.7)) * 0.5 = 0.16667 |

Highest weighted value/sum normalized value (= resulting user account risk index) |
0.7 |
0.56 |
0.54762 |

#### Mitigating controls

Effective permissions of employees, roles, or user accounts are checked in the context of Identity Audit on the basis of regulatory requirements. Violation of regulatory requirements can harbor different risks for companies. To evaluate these risks, you can apply risk indexes to compliance rules, SAP functions, attestation policies and company policies. These risk indexes provide information about the risk involved for the company if this particular rule, SAP function or policy is violated. Once the risks have been identified and evaluated, mitigating controls can be implemented.

Mitigating controls are independent on One Identity Manager’s functionality. They are not monitored through One Identity Manager.

An example of a mitigating control is the assignment of system entitlements only through authorized requests in the IT Shop. If system entitlements are issued to the employee through the IT Shop, a rule check can be integrated into the request’s approval process. System entitlements that would lead to a rule violation are therefore assigned not at all or only after gaining exception approval. The risk that rules are violated is thus reduced.