Access Risk Analysis invalid mitigations is a new feature introduced in SAP Access Control 10.1 Support Package 09 to identify invalid mitigation assignments. You can also implement SAP Note 2160765 for availability in Access Control 10.1 Support Packages 07 and 08.

Here are two scenarios in which mitigation controls become invalid:

1. When a role assignment is removed from a user or a transaction is removed from a role, the associated risk may no longer exist. Similarly, when a risk definition is updated, the associated mitigating control may be rendered invalid. In these situations, the mitigating control assignments associated with the segregation of duties (SoD) risk are still applied to the user or role. The obsolete mitigation control assignments must be removed so that future SoD risk violations are correctly reported.
2. When a mitigating control has been assigned to a user or a role for an existing SoD risk violation, but the duration of the assignment of the mitigating control has expired, there is a need to evaluate whether to extend its validity.

You can periodically use the invalid mitigations feature to identify both user-level and role-level mitigations, delete the invalid mitigations, and also extend the expired mitigation assignments. You can remove mitigating control assignments when they are no longer applicable to a user or role or extend mitigation control assignments validity for a user or role when they have expired.

Automating this process creates efficiency by introducing effective mitigation control procedures. As a result, periodic reports for invalid mitigating controls need not be run and you do not need to manually delete obsolete mitigating control assignments for each user when there is no corresponding risk. The validity for mitigating controls can be aligned to the duration of the corresponding risk for a user or a role.

Identify Invalid Mitigations

Here is the process to identify invalid mitigations.

1. The user or role is no longer violating a mitigated access risk. When a role assignment is removed from a user or a transaction is removed from a role, the associated risk may no longer exist. Similarly, when a risk definition is updated, the associated mitigating control may be rendered invalid. In these situations the mitigating control assignments associated with the SoD risk are still applied to the user or role. The obsolete mitigation control assignments must be removed so that future SoD risk violations are correctly reported. In this case you analyze user access, see the risk no longer exists on user access, and remove the mitigation control assignment by deleting it.

2. When a mitigating control has been assigned to a user or a role for an existing SoD risk violation, but the duration of the assignment of the mitigating control has expired, there is a need to evaluate validity extension. In this case, you analyze user access, see that the risk continues to exist on user access, and choose to extend the validity.

You can use parameter 1016 to exclude the assignments that have been maintained within the selected number of days from the cleanup of invalid mitigations. There may be a scenario in which you assign mitigation controls in role simulation or user simulation. Assigning these types of mitigation controls can result in invalid mitigation assignments because the role or the updated content does not yet exist in the back end. The mitigation assignments show as invalid until the user assignments and role changes have propagated to the back-end system.

To change the parameter value, execute transaction code SPRO and click the SAP Reference IMG. Follow menu path Governance, Risk and Compliance > Access Control > Maintain Configuration Settings. This path takes you to Figure 1. Click the New Entries button and enter Mitigation in the field under the Parm Group (parameter group) column, 1016 in the field under Param ID (parameter ID), and 02 in the field under the Parameter Value column. Click the save icon. You can then close the AC Configuration settings screen.

Figure 1

Configuration parameter 1016

To identify the user-level invalid mitigations in Access Risk Analysis, follow menu path NWBC > Access Management > Access Risk Analysis > User Level Invalid Mitigations. In the screen shown in Figure 2, you need to enter the required fields, such as System, User, User Group, Custom Group, Access Risk ID, and Rule Set. For my example, enter system GI7CLNT600, User SOHAL, and Access Risk ID B004. (B004 refers to a SoD risk.)

Figure 2

Selection criteria for user-level invalid mitigations identification

Click the Run in Foreground button. This action displays the screen in Figure 3 in which the result shows the user-level invalid mitigations. Now with the same system user and risk combination, you can delete the invalid mitigations. I explain how to complete the steps to delete the invalid mitigations in the next section.

Figure 3

User-level invalid mitigation result

Delete the Invalid Mitigations

To delete the user-level invalid mitigations in Access Risk Analysis follow menu path NWBC > Access Management > Access Risk Analysis > User Level Invalid Mitigations. Enter the required fields such as System, User, User Group, Custom Group, Access Risk ID, and Rule Set (Figure 4). Select the Delete Invalid Mitigations check box. For my example, enter system GI7CLNT600, User SOHAL, and Access Risk ID B004. Select the Delete Invalid Mitigations check box.

Figure 4

Selection criteria for user-level invalid mitigations deletion

Click the Run in Foreground button. The user-level invalid mitigations data is then displayed in the Risk Analysis: User Level Invalid Mitigations result screen (Figure 5).

Figure 5

User-level invalid mitigation results for deletion

Now you can delete the user-level invalid mitigations by clicking the OK button at the bottom of the result screen.

To identify the role-level invalid mitigations in Access Risk Analysis, follow menu path NWBC > Access Management > Access Risk Analysis > Role Level Invalid Mitigations. In the screen the system displays, you need to enter the required fields, such as System, Role Type, and Role. For my example, enter system GI7CLNT600, Role Type Technical Role, and Role Z_FINANCE_ROLE01 (Figure 6).

Figure 6

Selection for role-level invalid mitigation

Click the Run in Foreground button. The Result screen (Figure 7) then shows the role-level invalid mitigations.

Figure 7

Role-level invalid mitigation result

Delete the role-level invalid mitigations in Access Risk Analysis by following menu path NWBC > Access Management > Access Risk Analysis > Role Level Invalid Mitigations. In the screen that appears (Figure 8), you need to enter the required fields, such as System (e.g., GI7CLNT600), Role Type (e.g., Technical Role), and Role (e.g., Z_FINANCE_ROLE01). You also need to select the Delete Invalid Mitigations check box.

Figure 8

Selection for role-level invalid mitigation deletion

Click the Run in Foreground button. This action displays the Result screen (Figure 9) in which the role-level invalid mitigations data is displayed.

Figure 9

Role-level invalid mitigation result for deletion

Now you can delete the role-level invalid mitigations by clicking the OK button at the bottom of the Result screen.

Mitigation Assignment for Expired User Roles

In this case you see the risk continues to exist, so you need to extend the validity.

Identify the user-level expired mitigations in Access Risk Analysis by following menu path NWBC > Access Management > Access Risk Analysis > User Level Invalid Mitigations (Figure 10). Enter data in the required fields, such as System (e.g., GI7CLNT600), User (e.g., SV_TEST10), Access Risk ID (e.g., B003), and Rule Set (e.g., Global).  

Figure 10

Selection for user-level expired mitigation assignments

Now after you click the Run in Foreground button in Figure 10,  the user-level expired mitigation assignments are displayed in Figure 11.

Figure 11

User-level expired mitigation assignments result

You can extend the validiity of the above expired user-level mitigation by selecting the Extend expired Mitigations Validity in Days check box and maintaining the number of days, as shown in the Figure 12,  along with the other selection criteria, such as System, User, User Group, Custom Group, Access Risk ID, and Rule Set. For my example, enter system GI7CLNT600, User SV_TEST10, and Access Risk ID B003. Select the Extend expired Mitigations Validity in Days check box and enter 30.

Figure 12

Selection criteria for extending validity for user-level expired mitigations

After you click the Run in Foreground button, the user-level expired mitigation assignments are displayed in Figure 13.

Figure 13

Extend the validity for the expired user mitigation assignments

By clicking the OK button, you extend the validity of the user-level expired mitigation assignmnets. They become valid and active mitigation assignments.

Identify the role-level expired mitigations in Access Risk Analysis by following menu path NWBC > Access Management > Access Risk Analysis > Role Level Invalid Mitigations. Enter the required fields such as System, Role Type, and Role (Figure 14). For my example, enter system GI7CLNT600, Role Type Technical Role, and Role TF002.

Figure 14

Selection for role-level expired mitigation assignments

Now click the Run in Foreground button to display the role-level expired mitigation assignments in Figure 15.

Figure 15

Role-level expired mitigation assignments result

You can extend the validiity of the above expired role-level mitigations by selecting the Extend expired Mitigations Validity in Days check box and maintaining the number of days, as shown in the Figure 16, along with the other selection criteria, such as System (e.g., GI7CLNT6000), Role Type (e.g., Technical Role), and Role (e.g., TF002).

Figure 16

Selection criteria for extending the validity for role-level expired mitigations

Click the Run in Foreground button to display the role-level expired mitigation assignments in Figure 17.

Figure 17

Extend the validity for the expired role mitigation assignments

By clicking the OK button, you extend the validity of the expired role mitigation assignments. They become valid and active mitigation assignments.

Joshu Madina

Joshu Madina is an associate architect at SAP Labs India Pvt. Ltd. He has a total of 11 years of experience in software development. Since 2005 he has been working at SAP Labs and involved in various phases of development and maintenance of SAP Access Control 4.0, 5.3, 10.0, and 10.1. He has expertise in Emergency Access Management, Access Risk Analysis, Mitigations, Access Request, Business Role Management, and SAP security and authorization concepts.

You may contact the author at joshu.madina@sap.com.

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