GRC
HR
SCM
CRM
BI
Expand +


Article

 

Make Sure Ineffective Mitigation Controls in SAP Process Control Don't Live On in SAP Access Control

by Neha Garg, Senior Developer, SAP Labs India Pvt. Ltd.

December 11, 2017

In the integration scenario between SAP Access Control and SAP Process Control, mitigation controls created in SAP Process Control can be used to mitigate access risks for users in SAP Access Control. Subsequently, when an assessment in SAP Process Control finds a control is ineffective, a mechanism is required to delete the respective controls in SAP Access Control so that the data is integrated between both SAP Access Control and SAP Process Control.

SAP Access Control and SAP Process Control both share the master data created for processes and subprocesses. You can use a mitigation control created in SAP Process Control to mitigate users in SAP Access Control as well. If a user wants to perform an assessment of a mitigation control in SAP Process Control and the result is that it is deficient, the system should automatically expire every related mitigated user assigned with that mitigation control in SAP Access Control. If the mitigation control assessment is deficient in SAP Process Control, then the risk in SAP Access Control should not remain as mitigated with the same deficient mitigation controls.

New reports created in SAP Access Control automatically read the data of mitigation controls from SAP Process Control and show the details of expired mitigation controls. The user does not have to check the mitigation control data manually in SAP Access Control and SAP Process Control to identify which mitigation controls are valid and which are invalid. From the new SAP Access Control reports, you call the SAP Process Control classes to get this information regarding the mitigation controls. The reports are delivered via the SAP Access Control Support Package.

Every mitigation control should be associated with an organization, business process, and subprocess. An organization, business process, and subprocess can be created using transaction code SPRO in any SAP GRC system. These attributes are shared across SAP Access Control and SAP Process Control.

Once the organization, process, and subprocess are created (in transaction code SPRO), the mitigation control can be created by clicking the Mitigating Controls link in the NWBC setup page shown in Figure 1.


Figure 1
Mitigation control in NWBC

That opens a screen that lists all the available mitigation controls (Figure 2).


Figure 2
List of mitigation controls

You can create new mitigation controls by clicking the Create button. This action opens the screen shown in Figure 3.


Figure 3
Create a mitigation control

There are multiple tabs in the Control screen for defining the different attributes of mitigation controls (such as Access Risks, in which you associate access risks with mitigation controls, and Owners, in which you set up the mitigation controls). Click the Owners tab (Figure 4). In the Owners tab, you can define the approvers and monitors for the mitigation controls. To complete this step, click the Add Row button and then select the Access Risks tab (Figure 5). Mitigation control identifies the segregation of duties (SoD) as a known risk. (Risks are maintained under the Access Risks tab shown in Figure 5.) Mitigation control monitors and approvers are responsible for monitoring the risks associated with mitigation controls. Only monitors associated with a mitigation control definition can be selected when mitigating a risk.


Figure 4
Owner detail in mitigation control creation

The following are the control owners in an organization:

  • One control owner for the global level
  • Different control owners for regional levels
  • Multiple control owners for the local level

Now click the Access Risks tab. This tab shows the details of the risks associated with mitigation control (Figure 5).


Figure 5
Risk detail in mitigation control creation

You should assign mitigation controls to different levels of responsibility. If there is a risk violation at the regional and local levels, you should perform risk mitigation at the highest level.

To use mitigation control in an organization hierarchy, let’s say you have performed risk analysis at the organization level and the user violates all child organization rules, meets the condition of the parent rule, and only the parent rule shows up; you can perform risk mitigation in the following ways.

•           Mitigation on the user/role level

•           Mitigation on an organization level

Invalid Mitigation Control

The mitigation control shares risks, process, subprocess, owners, and controls names in both SAP Access Control and SAP Process Control. When the manual assessment is performed and the result of the assessment is deficient in SAP Process Control, it means the mitigation control is not valid and the administrator should expire/delete every mitigated user related with that mitigation control by running the invalid mitigation control report in SAP Access Control as well.

Figure 6 shows how the assessment of the mitigation control is done and used further to make sure that the data in both SAP Access Control and SAP Process Control is consistent and correct.

Mitigation controls are associated with risks, process, subprocess, owners, and control names, but you create the data for these attributes in one place (i.e., under the SPRO transaction code in the SAP GRC system), which is used by both SAP Process Control and SAP Access Control once the mitigation control is created.


Figure 6
Automatically expire mitigations assessed as ineffective in SAP Process Control

In SAP GRC, an organization’s data can be viewed by clicking the Organizations link under the setup screen as shown in Figure 7.


Figure 7
Organizations in NWBC

Clicking the Organizations link opens the screen in Figure 8. This screen shows the list of all the organizations. This is the SAP Process Control organization information screen. SAP Process Control enables organizations to document their control environments, test and assess controls, track issues to remediation, and certify and report on the state and quality of internal controls.


Figure 8
List of organizations in SAP Process Control

There can be multiple organizations (departments) in a company. Mitigation controls are always associated with an organization.

Here are two examples of how organizations have benefited from using SAP Process Control:

  • A major retailer benefited from enterprise-wide visibility of its compliance status by proactively planning and assessing the risks involved before executing its international expansion.
  • An international telecom company expanded its control testing capability, allowing the internal audit team to embrace a wider remit, which helped contribute to reduced audit fees.

The owners assigned at the organization level are reflected in the Owners tab in mitigation control to be selected as Approver/Monitor in Assignment (refer back to Figure 3).

Once the user selects an organization and clicks the Open button, the user can see the details of that particular organization, as shown in Figure 9. These details include information on users, risks, roles, owners, policies, and other attributes associated with the organization. These details differ from organization to organization and customer to customer. All these details are configured once by the system administration and can be modified at a later point in time.


Figure 9
Subprocess detail associated with the Organization data

Organizations are associated with Business Process and Subprocess data as shown in Figure 9 under different tabs.

If the user goes to the Subprocess tab, selects any subprocess, and clicks the Open button, the system displays the screen in Figure 10. In the General tab in Figure 10, you can see the Mitigating Control ID field. This Mitigation Control ID is used in SAP Access Control, while the Control field highlighted at the top is used for SAP Process Control purposes. At this level the control created in SAP Process Control is associated with the SAP Access Control Mitigation Control ID. A user can enter the mitigation control ID and save it. Later on, this mitigation control ID can be used by SAP Access Control for assigning it to any risk.


Figure 10
SAP Access Control Mitigation Control association with SAP Process Control

The user can check the result of the assessment of the control created in SAP Process Control in the Evaluation tab in Figure 11.

If the Result column in Figure 11 shows a failure, then the control is considered as deficient in SAP Process Control. Then the associated Mitigation Control IDs with this control should be deleted in SAP Access Control as well with the use of enhanced features provided in User level and Role level Invalid Mitigation report as described below.


Figure 11
Result of assessment of a control created in SAP Process Control

Identifying the Invalid Mitigation Control in SAP Access Control

Separate reports (as shown in Figure 12) are provided in SAP Access Control. These reports are provided as part of an enhancement and are delivered to companies with a Support Package. Using them you can identify the list of invalid mitigation controls by reading the data from SAP Process Control.

Under NWBC > Access Management the two reports highlighted in Figure 12 are available to identify the user- and role-level invalid mitigation controls.  


Figure 12
User and role level invalid mitigations

When you click the User Level Invalid Mitigations link, the system displays the screen in Figure 13.

In Figure 13 a new check box has been introduced for getting the information about ineffective mitigation controls found in SAP Process Control. If a user selects this check box and runs the report with the other available selection options, such as systems, user, and others, it shows the list of mitigation controls that are not valid in SAP Process Control by reading the data from SAP Process Control tables.


Figure 13
Newly introduced check box to get the Ineffective Mitigation controls found in Process Control

After selecting the Ineffective Mitigation Controls found in Process Control check box (as shown in Figure 13), the other four report options become grayed out/disabled (as shown in Figure 14). The Delete Ineffective Mitigations from Process Control check box appears in Figure 14. You have the option to select or deselect the Delete Ineffective Mitigation Controls found in Process Control check box.


Figure 14
Select the Ineffective Mitigation Controls found in Process Control check box

If only the first check box (i.e., ineffective Mitigation Control) found in SAP Process Control is checked, then the system shows the data of the invalid mitigation control by pulling it from SAP Process Control tables as both SAP Access Control and SAP Process Control are integrated. If both the check boxes are selected as shown in Figure 15, then the system deletes the invalid mitigation controls.


Figure 15
Delete the Ineffective Mitigation Controls found in SAP Process Control

After deleting the Invalid Mitigation Controls, the user sees a detailed report that provides the details of the deleted monitor and the associated risks with it as shown in Figure 16.


Figure 16
Invalid mitigations report

If you click the Role Level Invalid Mitigations link in Figure 12, the system displays the screen in Figure 17. The same kind of operation can be performed for User Level Mitigation from the Role Level Invalid Mitigations screen, but it is based on the role instead of the user. You can search the mitigation controls assigned on the basis of roles in this screen and then can find out the invalid mitigation controls as well as any associated with them.


Figure 17
Role level invalid mitigations

An email has been sent to:





 

Neha Garg

Neha Garg, senior developer, SAP Labs India Pvt. Ltd., has nine years of experience in SAP Labs. Neha is currently working with the Installed Base Maintenance Support (IMS) organization, SAP Labs, India, for SAP Access Control 5.3, 10.0, and 10.1. Neha has vast experience and has worked on multiple technologies, including JavaScript, Java, web services, OData services, SAPUI5, HANA, ABAP WebDynpro, Floor Plan Manager with ABAP WD, ABAP OO, SAP ABAP dictionary, and function modules for a broad range of SAP modules and SAP Access Control. Neha has worked in almost all the sub-components of SAP Access Control and has published one patent in the SAP Access Control area.



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ