GRC AC 10.1 /10 - Creation and Transport of Mitigating Controls

1. Before creating mitigating controls you need to create a Root Org entry, this replaces the Business Units in previous AC versions. Navigate to the IMG under Shared Master Data Settings and create a Root Org as shown below:

    2. You will need to:

• Create User in SU01 master in GRC.
• Run the user sync jobs in GRC.
• NWBC - Access Management - Access Control Owners - Create an entry and select owner type as Mitigation Monitor or Mitigation Approver

• NWBC- Master Data – Organization - Assign user in Owner tab. After assigning the user to the organization then user can be maintained as Mitigation Approver/Monitor during Mitigation Control creation workflow.

    

3. Now create mitigation control from NWBC -> Setup -> Mitigation Controls -> Create

In SP13, when we are adding actions in the reports tab, an error message pop-up as shown below.

Without the report the mitigation saves without issue. I am also adding the Action value by clicking F4, searching and then adding it. To resolve this implement SAP Note: 1902129 - Unable to save Mitigation control after adding AC Report

Mitigation Monitor: Mitigation monitor is the one who would be checking whether mitigation is being performed. This monitoring can be done either manually or alerts can be sent to the monitor. "Reports" which are maintained in reports tab of mitigating control, will trigger an e-mail to the Mitigation approver if control monitor does not run that report with in the frequency mentioned.

Alerts can be set through the program mentioned below by executing the Tcode GRAC_ALERT_GENERATE.

Mitigation Approver: Mitigation Approvers are assigned to controls and are responsible for approving changes to the control definition and assignments when workflow is enabled. In GRC 10.0 we have predefined workflow for this. We need to maintain the below configuration settings in SPRO.

Below mentioned standard workflows needs to be enabled.

Issues with Deletion of Mitigation Controls or MC assignments:

When deleting Mitigation Controls or Mitigation control assignments, we used to a get a message task executed but deletion was not happening. After implementing the steps mentioned below issue was resolved.

1.Run transaction SM30

2. Display the view GRFNPARENT in change mode

3. Add new line

4. Entity = SUBPROCESS

5. Parent = ORGUNIT

Mitigation Control Assignment Workflow

In GRC we have standard SAP provided workflow for Mitigation control assignment. I have come across few queries w.r.t this workflow as the mitigation assignment approver is not able to view the details as the "VIEW DETAILS" button is greyed out as shown in below screen.

SAP has confirmed that this is the standard functionality and has release a note to inform all the users. Please check the below note for the same.

1911146 - View Details is grey out in the Mitigation Control Assignment Approver screen

Mitigation Controls - Deleting Root org. Issues

When few users tried to delete the root organizations which were created as part of creating mitigation controls through Tcode PPOM, they were getting some error message as shown below.

Assignment to subordinate objects (Organizational unit ABCD, for example), not possible

Resolution:

Execute the report RHRHDL00 and from here try to delete the root. orgs and the issue will be fixed and they will be removed. But one thing to make sure is all the all the objects under the root org are deleted prior to this.

Transport Organizational Units & Mitigation Controls

There is no Transport Mechanism to move the Business Units/Organizational Units & Mitigation Controls
from one Landscape to another Landscape in GRC Suite, because it is Master Data.

There is no Download & Upload functionality available for these Controls to move from one Landscape
to another.  Organizational Units & Mitigation Controls are tied together as these are shared among
GRC Access Controls & Process Controls.

You need to recreate it in Destination Environment as Transport/Movement is not possible.

When you create the Organizational Unit with the Description in GRC, the System will generate a 
unique number for Organization Unit, which will be different for each system.  That was the
reason, we need to recreate Organizational Unit in each System.

But, Mitigating Control Assignments of User/Role/Profile/User Org/Role Org can downloaded from

one Landscape & can upload it to  another Landscape.

Most convenient way to change existing mitigations is to use standard ABAP program for download and upload.

Go to SA38 and use the following programs:

GRAC_UPLOAD_MIT_ASSIGNMENTS

GRAC_DOWNLOAD_MIT_ASSIGNMENTS

Once you have downloaded the full list into an Excel file you can do your adjustments and upload it again. 

GRC 10.1 - Significance of EAM Configuration Parameters

Purpose

This document is to explain the details and significance of configuration parameters used in Governance Risk and Complaince - Emergency Access Management 10.0. 

Overview

The configuration parameters have impact on the behavior of the application. With each configuration, the application flow changes. So the proper combination of the configurations is required so that the application runs smoothly.

Available Configuration Parameters

Go to SPRO->Governance, Risk and Compliance->Access Control->Maintain Configuration Settings 

EAM related configuration starts with 4000. Till now the configurations till 4015 is available.

Explanation of Configuration Parameters

Following is the explanation for each configuration parameter:

(1) 4000 (Application Type): It specifies whether the user is using ID based or Role based application. If the parameter value is 1 then Firefighter will be assigned Firefighter ID otherwise if the value is 2 then Role based application is set.

(2) 4001 (Default Firefighter Validity Period (Days)): When you provide valid from and valid to dates as you assign a Firefighter Role or Firefighter ID to a Firefighter, these dates will be applied to the assignment, overriding the Default Firefighter Validity Period setting. Initially the Firefighter ID or Role assigned is from the current date. When you omit the “to date” and you have not set Default Firefighter Validity Period, the assignment will be active until 12/31/9999. When you omit the to date and you have set a Default Firefighter Validity Period, then the assignment you are assigning will remain active until the current date, plus the number of days you specified for the Default Firefighter Validity Period.

(3) 4002 (Send Email immediately): If the Send Email Immediately is set to Yes, the Firefighter Login Notification is sent to the Controller immediately as the firefighter login.

(4) 4003 (Retrieve Change Log): The Change Log information for Firefighter ID is captured from the SAP Change Log that is stored in the CDHDR/CDPOS tables. The Retrieve Change Log parameter specifies whether you to capture Change log information. The parameter value can be set to YES, or NO. If this parameter is set to YES, then only the Change Log information (including document number, old value, new value etc.) are captured when Firefighter log sync program is executed.

(5) 4004 (Retrieve System log): The System log information is captured from SM21. If the parameter is set to YES then only the System Log information is captured for Firefighter ID in GRC Box.

(6) 4005 (Retrieve Audit log): The Audit log information is captured from SM20. If the parameter is set to YES then only the Audit Log information is captured for Firefighter ID in GRC Box.

(7) 4006 (Retrieve OS Command log): The Changes in SM49 is captured in OS Command log. If the parameter is set to YES then only the OS command changes are captured for Firefighter ID in GRC Box.

(8) 4007 (Send Log Report Execution Notification Immediately): If the Send Log Report Execution Notification Immediately is set to Yes, the Firefighter Log Report Notification is sent to the Controller immediately as the logs are updated in GRC Box. If the Send Log Report Execution Notification Immediately is set to No, the Firefighter Log Report Notification is sent depending on the frequency (Hourly/ Daily / Weekly) of the corresponding background job. Then the separate background Job for Report GRAC_SPM_WORKFLOW_SYNC needs to be scheduled.

(9) 4008 (Send FirefightId Login Notification): The Send FirefightID Login Notification option specifies whether to send Login Notification emails to Controllers with information about when a Firefighter session was started and by whom. If this parameter is set to NO then no Login notification will be sent even if parameter 4002 is set to YES. Also the Login notification always sent as an Email, for this no workflow is initiated. If this parameter is set to YES then controllers for the Firefighter ID in question will receive an Email.

(10) 4009 (Log Report Execution Notification): The Log Report Execution Notification parameter specifies whether Log Report notifications that contain information about Firefighter activity should be sent to the Controllers. If this parameter is set to NO then no log notification in form of email or workflow will be generated even if parameter 4007 is set to YES.

(11) 4010 (Firefighter ID role name): There are many users in a system. To distinguish Firefighter ID from a normal user this Role is has to be assigned in the plug-in system. If the Application type is 2 i.e. Role based application is used, then there is no need to set this parameter.

(12) 4012 (Default users for forwarding the Audit Log workflow): This parameter is introduced in SP06. In case of EAM log notification workflow the controller can forward the workitem to any user. This user can submit the SPM/EAM Audit review. It should not be possible to forward to any user but only to other controller. So a customizing is provided for it whether the workitem could be forwarded to controllers only or to all users.

(13) 4013 (Firefighter ID owner can submit request for Firefighter ID owned): The Parameter is introduced in SP08.This parameter is used in Access request to allow or disallow the owner to submit the request for Firefighter ID owned by him.

(14) 4014 (Firefighter ID controller can submit request for Firefighter ID controlled): The Parameter is introduced in SP08.This parameter is used in Access request to allow or disallow the controller to submit the request for Firefighter ID for which he is the controller.

(15) 4015 (Enable Decentralized Firefighting): This parameter is introduced in SP10. In SP10 De-centralized version of EAM is provided. So this customizing entry will be used whether to use De-centralized version or not. If this parameter is set to YES then the Firefighter can use logon pad available in plug-in system directly. The Firefighter IDs available for that system will be available there for Firefighter to Login. 

Related Content

Related Documents 

https://service.sap.com/instguides - > SAP BusinessObjects Governance, Risk and Compliance (GRC) -> Access Control -> Release 10.0 -> Maintaining Configuration Settings Guide - SAP AC 10.0

Related Notes

SAP Note:1632953 - EAM Audit review workflow could be forwarded to other users

SAP Note: 1668255 - Firefighter ID role name for Param ID: 4010

SAP Note: 1768556 - Customizing changes for Decentralize Firefighting

SAP Note: 1659219  - UAM: FFID owner & controller can create own request for FFID

GRC 10.1 - BRM - Steps to Configure Role Methodology

Steps to Configure Role Methodology

This will explain the steps that needs to be follow which configuring Role Methodology. This will include teh following steps.

1. Create BRF+ Rule.
2. Assign Condition Group Type to BRF+.
3. Define Role Methodology Process and Steps.
4. Associate Role Methodology Process to Condition Group.
5. Creating Role Approval Workflow.

Role MethodologyConfiguration Introduction

1. Role Methodology is the process followed for role creation and maintenance operation
2. It is an existing feature in Access Control
3. The well defined role management process that aligns with the Organization policies of an Organization can be  configured in the Role Methodology
4. The Methodology customizing steps like “BRF+ Rule Creation” and “Methodology Process Definition” are not necessary when the default methodology process is used for role creation
5. These steps are required while creating customized methodology process
6. BRF+ Rule Creation:
   Business Rules Framework plus (BRF plus) provides a comprehensive application programming interface (API) and user interface (UI) for defining and processing business rules
7. BRF+ is the rule engine that evaluated the various attributes of the role
8. Condition Groups link the BRF+ rules and the Role Methodology

Role Methodology Configuration Steps

Seting up Role Methodology

1. Create BRF+ Rule
2. Assign Condition Group Type tp BRF application and function
3. Define Role methodology Process and step
4. Associate Role Methodology Process to Condition Group

Create BRF+

1. Create BRF+ Application and function for the Application
2. Execute transaction SA38 and run the program GRAC_GENERATE_ERM_BRFRULE or select the option Generate BRF Plus Applications, Approvers and Methodology Functions

Define the BRF+ Application by giving Application name, Methodology Rule ID and Approvers Rule ID.

After executing the program verify the log for any errors. If errors are present, then they need to be fixed before proceeding to next step.

1. Execute the TCODE: BRF+
2. Select My Applications and search for the application that was just created
3. Expand the Application and Function Nodes
   

Create a Decision Table by entering name and other related attributes

The decision table provides the rule for evaluation; so for each function, a decision table is required

 

 

Create Condition Columns for the Decision Table

Click Insert Column button and select From Context Data Objects

 

 

Select the conditions that need to be evaluated

Create Result Columns by clicking Insert Column from Data Object

Search for Result Column

Select Condition Group (GRAC_CNDGP) object from the search result

The result is the end product of the role execution

Review the conditions and results

Click OK to confirm the definition

By Defining the Conditions and Results the definition of the Decision Table is complete

 

Once the values for the Condition and Result Columns are defined, enter values for the Decision table used for rule execution

Click Insert New Row to create the values; enter values for the columns

Select Direct Value Input

Enter Value for the columns

Activate the Decision Table

 

 

Associate the Decision Table to Function by selecting it in the Top Expression of Function

Activate the function

Assign Condition Group Type to BRF+

1.Navigate to IMG by executing SPRO

2.Navigate to GRCà ACà Role Management

3.Select activity “Assign Condition Group to BRF+ Rules”

4. Select Condition Group Methodology

5.Enter the BRF+ Application and Function and save

 

 

 

Define Role Methodology Process and Steps

Select the Define Methodology Processes and Steps option under Role Management in IMG

Assign steps to Methodology Process

 

 

 

Associate Role Methodology Process to Condition Group

1. Select the “Associate Role Methodology Process to Condition Group” option from the IMG customization

2. Associate the Condition Group to the Methodology Process

   

   Creating Role Approval Workflow

         1.Role Approval Workflow needs to be maintained if Approval step is there in Role Creation methodology

2. The default workflow process can be used to set up Role Approval Workflow Process

3. Select the maintain MSMP Workflow option from IMG

4. Select the Role Approval Workflow Process from  Step 1 in the MSMP Workflow Configuration and open it in Change Mode

 

Creating Role Approval Workflow

Maintain the approver rules in the Maintain Rules step.

In Step 5, maintain the Stage settings and select the Agent ID as GRAC_ROLE_APPROVER or the approver rule create in BRF+

Save and activate the workflow

 

GRC 10.1 - MSMP Workflow - User Access Review(UAR) Workflow Configuration and Description

User Access Review (UAR)  Workflow Configuration and Description 

Purpose

The purpose of this document is to explain the User Access Review Workflow in detail and the Configuration settings required to implement the same. 

Overview  

The User Access Review (UAR) feature provides a workflow-based review and approval process for user access requests. The periodic reviews of user access are performed by business managers or role owners, and the system automatically generates the requests based on the company’s internal control policy.  The review asses roles assigned to users and the frequency of use for that role by the user. 

Concept

                      

 Key Users for UAR

Administrator	This person has the Admin role assigned for Access Control.  They can perform UAR-specific administrator tasks, such as cancelling UAR requests and regenerating requests for rejected users. As well as Admin review before generating workflow for request.
Reviewer	This term refers to the approver at the Reviewer stage.  The Reviewer may be the user’s manager or the role owner.
User’s Manager	The direct manager of a user as defined in the User Details Data Source.
Role Owner	The role owner specified in CUP master data.
Coordinator	The Coordinator is assigned to Reviewer.  They monitor the UAR process and coordinate activities to ensure the process is completed in a timely manner.

 IMG Configurations for UAR

1. Log onto the backend system.
2. Enter transaction SPRO.
3. Click SAP Reference IMG button.
4. Navigate to Governance, Risk and Compliance ==> Access Control ==> Maintain Configuration Settings.
5. The following fields can be maintained there for UAR:

• The Request Type can be maintained in IMG under Governance, Risk and Compliance-> Access Control-> User Provisioning-> Define Request Type.
• The Priority can be maintained in IMG under Governance, Risk and Compliance-> Access Control-> User Provisioning-> Maintain Priority Configuration.
• The reviewers for the UAR can be either the Manager of the User or the Role owner for the Role.
• Admin review required can be

YES	The request will go to the Administrator before it is generated for the Manager or Role owner (based on previous selection) to review.
NO	The request will bypass Administrator review and be directly generated and go to the Reviewer

 NOTE:  If the User does not have a manager or, the role owner does not have an owner, selecting No on Admin review will not generate workflow for request . And the  role owner / manager must have a coordinator assigned to him. This mapping is defined in Manage Coordinator link under Access management tab.

Generate data for UAR

1. Log onto Access Control Application
2. Navigate to location( shown in below figure)

                                              
                                                                                                                    Figure 2
                 3. Click on Create button and enter the following data for the fields then, Click Next (Figure 3)| Schedule Name | Enter the name for the UAR job.                                          

                                         
                                                                                                 Figure 3 

               4. Define Variants/Filters for selection then, Click Next

                   As shown in Figure 4 below you may select any number of variants available via dropdown menu and entry fields to specify the size and target of your request. 

                                  
                                                                                                                                      Figure 4
                 5. Shows summary then, click Finish

                 6. Job is created and status is displayed as:

                                    Completed: The job is completed                                                                             

                                    Terminated: The job is terminated by the Administrator

                                     In Planning: The job is currently working on the Request or if it is a reoccurring job then it would remain in this status

Admin Review

If Admin review is selected to Yes in the section 4 of Configuration IMG for UAR then you may review the request here before it can be processed further to the reviewers. This also allows you to add reviewers and coordinators if not defined for role or user.

  To Access Admin Request:

               1. Navigate to (Figure 5):NWBC-> Access Management->Compliance Certification Reviews-> Request Review

                                                                       
                                                                                              Figure 5
                 2. Search for a job using criteria specified in the filters such as Process Type, User ID, Reviewer and Coordinator ID, Date, and Job ID (Figure 6).

                 3. Click Search

               This shows the Request Number, the Job ID, Type of request, the reviewer for the Request, the coordinator for the request and, the status for the request (Figure 6)

                 4.  Select the request you want to edit, then click Change Reviewers button to assign the reviewers and coordinator for the request or Cancel request button to cancel the request.

                                  

                                                                                                                                  Figure 6

                                                                                                                               
                   5. Select the Reviewer and Coordinator from the list or enter the ID the, Click OK.

                                        

                 6. Save your entries.

Manage Coordinators                                                                                   

Under this link you can manage the coordinators and reviewers for your requests. This lists coordinators for the reviewers as well as their ID, name, and email.

                1. Navigate to Access Management-> Compliance Certification Reviews
                2. You can select a Coordinator then, Click Open or Delete

                3. Click Create, to create a new coordinator

                4. Enter ID or select from menu.

                5. Save your work

                6. Now you need to run another background job ”Update UAR workflow” to generate UAR requests. This step is mandatory only if you are generating requests after admin review

UAR Workflow

Workflow settings for UAR

To manage the workflow for the request:

1. Navigate to Governance, Risk and Compliance ==> Access Control ==> Workflow for Access Control ==> Maintain MSMP Workflows.
2. Select the Process ID SAP_GRAC_USER_ACCESS_REVIEW.
3. Click on Display/Change button to toggle between edit modes

                             3.1.    You may define Global Escalation rules and Escape conditions here (Elective Step):
                                  
                                                                                                      Figure 8
4. Click Next
5. Enter the Maintain Rules: These can be Function Module/ BRF plus/ ABAP Class / BRF plus Flat rules. These can be an initiator, routing, agent, or notification   rule

                                               

                6. Click Next, Enter Maintain Agents
                    Here you may define Agents for the workflow stages. These agents can be for notification or approval purpose. Agent Type may be:
                          Directly Mapped Users: Approvers selected from the Approver definition.
                          PFCG Roles                 : Users with specific role will be selected
                          PFCG User Groups    : Approvers selected from PFCG User Groups assigned to users (SU01 Groups tab)
                          GRC API Rules            : Approvers selected from the associated function module (FM).

                                                      
                                                                                                        Figure 9: Maintain Agents
 

                                                                                         
                                                                     Figure 10: Add Users to Approver Groups
                 7.   Click Next, Enter Variables & Templates
                      Maintain Templates for notification and Approval
 
                                                  
                                                                                        Figure 11: Variables & Templates
                  
                 8. Click Next, Enter Maintain Paths 
                 9. Click Add then enter the fields for Path ID and Path Description
                 10. Select the Path, then click Modify or ADD to define path stages 
                 11. Click Next, Enter Maint Route Mapping
                      Used for mapping the Logical Path (Initiator) to an Actual Path

                 12. Click Next, Generate Version
                 13. Click:
                        Save: Saves changes to the database
                        Save/Simulate: Save changes to the database and run a simulation to check for errors.
                        Activate: Generate Active Versions

Update Workflow for UAR Request

              1. Log onto front end Access Control Application.

              2. Navigate to Access Management-> Background Jobs-> Background Scheduler

              3. Click on Create button and enter the following data for the fields:

                    Schedule Name: Enter the name for the UAR job.

                    Schedule Activity: Update Workflow for UAR request

                    Recurring Plan: Select the radio button. If Yes then, provide date range and time.

                    Start Immediately: If not a recurring job, select whether you want it to start immediately or provide a date and time for the job to start.

              4. Click Next then, Click Finish.

Reviewing UAR Requests

Once the Request Workflow has been updated the request follows its workflow path and gets to the right reviewer

Reviewers Inbox and Outbox

The request once generated is sent to reviewer’s inbox and outl

To work on the Request

              1. Navigate to: My Home-> My Profile-> Work Inbox

Searching for UAR Requests

The requests are sent to the Reviewers inbox and email (if the email address is configured into the system)

Working on the Request

              1. Click on the request you would like to work on

              2. Click Administration (Open will just let you view the request and not let you work on it)

              3. Select the Request you would like to work on and you may take the following actions

                     a. Approve: You approve the request and the Role is not removed

                     b. Remove Role: Role is removed from the user

                     c. Forward: The request can be forwarded to another reviewer with a Note.

                     d. Reject Role: You reject  to work on role for the user

                     e. Reason: Reason for rejection. Maintained in IMG under: T-Code: SPRO->  Governance, Risk, and Compliance-> User Provisioning-> Maintain Review Rejection Reasons

                     f. Add Comment: Click Add Comment to add comment with the review request

                     g. Cancel Rejection: You may cancel the rejected role/user prior submitting. *Only applicable in rejected roles/user view*

              4. Submit the Request

Related Content

 

Related Notes

 SAP Note: 1732890 - GRC 10.0 - Update Workflow for UAR request job does not trigger the workflow

SAP Note: 1620493 : GRC 10.0 UAR Background Job stuck

SAP Note: 1620495 : GRC 10.0 UAR - Submission failure of request