Companies looking to be Sarbanes-Oxley compliant usually undergo an initial cleaning phase in which remediation and mitigation of violations of user access and authorization-related risks take place. After the initial cleaning phase is completed, companies need to monitor and manage segregation of duties (SoD) violations on a regular basis. As a trend, such review processes are becoming decentralized to business managers. The SoD Review feature enables companies to conduct a streamlined review process on a periodic basis that includes collaboration among line managers, risk owners, internal control, and information security teams. It provides companies with an efficient workflow-based tool, which allows for real-time SoD management by exception and improves overall information security. The key features of the SoD Review in SAP BusinessObjects Access Control 5.3 are:

• Resolution of SoD violations through an automated workflow-based process for review and approval
• Support of multiple target systems for SoD analysis
• Assignment of mitigation controls integrated in the workflow
• A decentralized SoD review conducted by responsible line managers or risk owners
• Ability for line managers or risk owners to request SoD remediation from the security administrators in the same workflow
• Transaction usage information to facilitate decision making for the reviewers
• History reports to assist in monitoring the review progress
• Audit trail and reports to support internal and external audits
• Support for back-end systems integrated with SAP BusinessObjects Access Control through Real Time Agents (RTAs) as well as legacy systems

Whereas the approval workflow for the SoD Review runs in Compliant User Provisioning’s (CUP’s) workflow engine, detection and mitigation of SoD violations are executed via Web service calls to Risk Analysis and Remediation (RAR). In the Rule Architect, RAR keeps all risk master data, including risk owners. In the Control Library, it keeps all the mitigation control master data and mitigation assignment information. An SoD risk is defined in the Rule Architect as a combination of two or more functions. Functions are defined by a number of transactions in your business systems representing one business function (e.g., vendor master maintenance).

Roles and Detailed Process Flow

The SoD Review process distinguishes the following roles:

• Administrator: This user has the AE_Admin User Management Engine (UME) role assigned for CUP. He or she can perform all the CUP administrator tasks in addition to SoD Review-specific administrator tasks that I’ll explain later.
• Reviewer: This term refers to the approver in the first stage of the SoD Review workflow. Per configuration, the reviewer may be either the user’s manager or the owners of the violated SoD risks. Approvers of later stages (e.g., security team members) are simply referred to by the more general term approvers.
• Manager: The direct line manager of a user as defined in the user details data source
• Risk owner: The risk owner specified in the risk master data in RAR
• Coordinator: Coordinators are assigned one or multiple reviewers. They monitor the SoD Review process and coordinate activities with reviewers to ensure the process is completed in a timely manner.

The high-level process for an SoD Review is as follows (Figure 1).

1. Initialization: The administrator performs a number of actions in SAP BusinessObjects Access Control to initiate the SoD Review process and trigger request generation.
2. Administrator review (optional): The administrator reviews requests and checks to see if the reviewers are correctly assigned before the actual workflow tasks are sent to the reviewers.
3. Generation of workflow tasks: The administrator schedules a background job, which generates the workflow tasks for the reviewers.
4. Review stage: Requests are reviewed and actions are noted by the reviewers.
5. Additional workflow stages (optional): You can add approval stages involving additional approvers to the workflow path through configuration.
6. Security stage: A security administrator reviews decisions made by reviewers and possibly corrects them. SoD violations marked for removal by the reviewers are manually removed from the affected users through various types of potential actions.
7. Management of rejected users: If the reviewers are the user’s direct managers, then they can reject users for whom they aren’t responsible during the review. The administrator has to follow up on rejected users and regenerate requests to be sent to the correct managers.
8. Reporting and audit trails: A history report and a detailed audit trail complete the SoD Review feature in SAP BusinessObjects Access Control.

Figure 1

High-level view of the SoD Review process

The following subsections discuss the details of each SoD Review process step.

Initialization

The initialization process step contains the following tasks, all of which the administrator executes (Figure 2):

• Verify master data
• Run batch risk analysis in RAR
• Prepare function usage information
• Schedule the task SoD Review Load Data With or Without Mitigated Risks as a background job in CUP

Figure 2

Details of the initialization process step

The following master data objects have to be verified:

• If managers are configured to be reviewers: Managers and manager-user relationships are both stored in the user details data source. If this data isn’t kept up to date, requests will be sent to the wrong managers.
• If risk owners are configured to be reviewers: The risk master data in RAR’s Rule Architect also contains a Risk Owners tab, which lists the risk owners assigned to the given risk. Make sure that this information is up to date. Otherwise, requests will be sent to the wrong risk owners.
• Risk master data in RAR used for detection of SoD violations must be complete and up to date.
• Make sure that all mitigation control master data in RAR’s Control Library is up to date and in the shape you want to make it available to reviewers during the SoD Review.

SoD violations during an SoD Review are detected via offline-mode risk analysis per service calls to RAR. Offline-mode risk analysis is using the data from the results of last batch risk analysis kept in the SAP BusinessObjects Access Control server’s database. If this data isn’t up to date, run a batch risk analysis on the user level in RAR before you proceed. Also make sure that offline mode is enabled, which you can verify via menu path RAR > Configuration > Additional Options > Enable Offline Risk Analysis.

The requests sent to reviewers also contain information about how often transactions from a function causing an SoD violation were actually executed in the back-end system by the affected user during the chosen review period (typically the last six or 12 months). The preparation of this function usage information requires the following tasks to be executed in RAR (Figure 2):

• Perform alert generation job in RAR: Follow menu path RAR > Configuration > Background Job and schedule the alert generation job with all options selected. This job collects function usage information from the statistical databases STAT of the target systems. The first launch of the job marks the point in time as of which function usage information is available in the system.
• Purge usage information in RAR: If more function usage information is stored in RAR than is desired for SoD Review requests, then you should archive the data. For example, if your SoD Review process states that the prior 12 months’ usage information should be provided in SoD Review requests and RAR has 15 months available, then the oldest three months information should be purged (archived) from RAR. It is important to note that usage information purged in RAR is still accessible to RAR from the flat file that is produced but is not accessible by ERM or CUP.

To complete the initialization process step the administrator schedules the task SoD Review Load Data With or Without Mitigated Risks as a background job in CUP. This creates the request data, but the workflow tasks and notification emails are not yet sent to reviewers.

Administrator Review (Optional)

The administrator review is an optional process step and is activated during configuration of the SoD Review. Its purpose is to have the administrator check the recipients of the generated requests prior to the generation of workflow tasks and notification emails. The system displays the list of all requests generated for the current SoD Review cycle to the administrator. He can take action on each request in one of the following ways (Figure 3):

• Manually assign reviewers to requests that are currently unassigned due to missing manager data in the user details data source or risk owners in RAR’s risk master data (Figure 4). This assignment won’t update the user details data source or the risk master data, but only apply for the given request.
• Cancel requests and mark them for user rejection (Figure 5). You can apply this option to requests with missing reviewers if, for example, an administrator would like to permanently update the manager or risk owner information in the user details data source or risk master data, respectively. The administrator can regenerate requests for these users later in the Management of Rejected Users process step.
• Cancel requests completely. They will be excluded from the current SoD Review cycle until a new SoD Review cycle is initiated via execution of the SoD Review Load Data job.

Figure 3

Details of administrator review process step

Figure 4

Manual assignment of reviewers to requests without reviewers

Figure 5

Administrator review — cancellation of requests

Generation of Workflow Tasks

The administrator schedules the task SoD Review Update Workflow as a background job in CUP. The system sends email notifications to reviewers with the next execution of the periodic Email Dispatcher job in CUP.

Review Stage

The requests are first sent to the reviewers. You can provide detailed instructions for reviewers to supplement the content of the notification emails. The level of instruction for approval of periodic access reviews might be more extensive since it is an infrequent process and may involve reviewers who do not perform routine approval of requests to create or change accounts. The Instructions area of the SoD Review requests is an HTML viewer. You can see an example of an SoD Review request with an HTML page provided in the request in Figure 6.

Figure 6

Instructions for reviewers

During configuration you can select whether reviewers are the user’s managers or risk owners. Managers have the additional option to reject users for whom they aren’t responsible (Figure 7). They can mark the users in the User pane for rejection, select from one of the preconfigured rejection reasons, and provide a comment (Figure 8). These users can then enter the Management of Rejected Users process step.

Figure 7

Details of the reviewer stage process step

Figure 8

Managers can reject users who aren’t reporting to them anymore

All reviewers can see multiple line items per request (Figure 9). The number of line items per request is configurable. Each line item represents an SoD violation detected at a particular user and includes the function IDs and names defining the SoD risk.

Figure 9

SoD risk mitigation and removal from users supported by role usage information

For each SoD violation in the request, the reviewer has to decide to perform one of the following two tasks:

• Mitigate: Click the Mitigate button on the screen shown in Figure 9 to bring up the Mitigation pop-up window (Figure 10). Here the reviewer can select an available mitigation control defined in RAR for the detected SoD risk violation and assign it to the affected user.
• Propose removal: Click the Propose Removal button in the screen in Figure 9 to bring up the screen shown in Figure 11. In this screen you can see the functions causing the SoD violation and their usage information. The reviewer can mark the functions he is proposing for removal from the user’s authorizations. The actual removal happens during the security stage.

Figure 10

Mitigate an SoD line item

Figure 11

Request removal of a function that causes an SoD risk

The function ID is displayed as a hyperlink that you can click to view the details of the function (Figure 12). Next to the function name, the affected business system and a function usage counter is displayed. It tells the reviewer how often transactions from the given function were executed by the user during the review period. This information facilitates decision making for the reviewer considerably. The line items in a request can belong to multiple users and multiple systems. When the configurable maximal number of line items per request is exceeded, the system generates additional requests accommodating the remaining SoD violations and sends them all to the reviewer’s inbox.

Figure 12

Click the function ID hyperlink to reveal the details of the selected function (e.g., function GL01)

The reviewer may choose to save the request multiple times to ensure work is saved in the request. The request is not forwarded to the next workflow stage until the reviewer completes all line items of the request and clicks the Submit button.

Additional Workflow Stages

You can add additional workflow stages to the SoD Review workflow. Each additional workflow stage includes an approver. You can derive approvers using a Custom Approver Determinator (CAD) in CUP. The attributes available for CADs of workflow type SoD Review differ from those available in CUP’s standard CADs. The following attributes are available:

• Application
• Request type
• SoD Review risk (being detected)
• Priority

For more details on the use of CADs, refer to chapter 5 of the SAP BusinessObjects Access Control 5.3 Configuration Guide available in https://service.sap.com/instguides.

Security Stage

The security stage is mandatory for the SoD Review scenario because security administrators have to execute the removal of functions as proposed by the preceding reviewers. Removal of functions isn’t a trivial task and you have to execute it manually. It can involve actions taken on different levels of the security concept of the company. In the SAP back-end system, the following actions might be required for function removal:

• Removal or replacement of one or multiple roles assigned to the affected user
• Removal or replacement of single roles contained in composite roles assigned to the affected user
• Removal of transactions or authorizations in single roles assigned to the affected user

Function removals in non-SAP systems are executed likewise according to the available security features.

You can configure the security stage to display in requests only SoD violations previously marked for removal so you can focus the attention of the approvers on these line items. Another configuration option is to allow or disallow changes to the request content. If changes aren’t allowed for a stage, then the Mitigate and Propose Removal buttons aren’t available to the approvers in this stage. If changes to the request content aren’t allowed, approvers can only suggest changes to the request content per comment and forward the request to the reviewers in the previous stage (Figure 13). The reviewer would change the request content accordingly and resubmit the request. If the stage configuration allows for changes, approvers can turn mitigation into the removals and vice versa before they submit the request. Request submission by the security stage leads to closure of the request as no auto-provisioning is available for the SoD Review.

Figure 13

Details of security stages process step

Management of Rejected Users

Administrators and managers can reject users during the Administrator Review and the Review Stage process steps. Users typically are rejected because the user-to-manager relationship is not up to date or not maintained at all in the user details data source. Administrators can correct the manager data in the data source and regenerate requests for the rejected users (Figure 14).

Figure 14

Details of management of the rejected users process step

Administrators can search for rejected users by following menu path Configuration > User Review > Manage Rejections. The resulting list of rejected users, including the original request number and the reason for the rejection, is then displayed in the lower section of the screen (Figure 15). The Status column contains the current status of each user. The following statuses are possible:

• New: These are requests that the reviewer submitted
• To Generate: The user is marked for regeneration, but the generation background job has not started. You can click Cancel Generation to cancel the request generation.
• In Process: The background generation job has started and completed. You cannot cancel requests with this status because the background job has started.
• Error: The generation background job has encountered an error.
• Completed: The generation background job has completed. The new request number is updated in the New Request column.

Figure 15

Manage Rejected Users screen

The administrator selects the users for whom he wants to generate new requests and clicks the Generate Requests button (Figure 15). This only marks the users. For the actual request generation, the administrator has to schedule the task SoD Review Process Rejected as a background job in CUP. The new requests then reenter the Administrator Review process step before the corresponding workflow tasks are generated and sent to the correct managers for review.

Reporting and Audit Trails

The following SoD Review-specific reporting features are available:

• User Review Status Report
• SoD Review History Report
• SoD Review Audit Trail

The User Review Status Report allows for monitoring SoD Review requests to ensure that the process is completed in a timely manner. This report is useful for coordinators or other persons overseeing the review process. You can reach it by following menu path Informer > Analysis View > Analytical Reports > User Review Status Report (Figure 16). You can see the current stage, the number of items completed in the request, reviewer, and other helpful information. You can use the hyperlinks to display the details of the respective object.

Figure 16

Example of a User Review Status Report displaying SoD Review requests

The SOD Review History Report shows the approval decisions made for each item in the SoD Review requests. This report is helpful after a portion of the review process or the entire review process is complete. It displays actions indicated by the approvers for each line item representing an SoD violation in a specific system (Figure 17). You can set these actions to Mitigated, Remove, or Rejection, the latter referring to rejected users.

Figure 17

Example of an SOD Review History Report

You can view the SoD Review audit trail of a particular request to see the detailed activity during the lifetime of the request. Navigate to My Work > Request Audit Trail and enter your selection criteria for the request for which you are searching. The audit trail shows the history of the report from request creation to closure (Figure 18). It may be printed or downloaded and sent to internal or external auditors.

Figure 18

Example of an SoD Review audit trail

Frank Rambo, PhD

Frank Rambo, PhD, is managing a team within SAP’s Customer Solution Adoption (CSA) organization working with customers in the SAP analytics area with the objective to drive adoption of new, innovative solutions. Prior to this position, he worked eight years for SAP Germany as a senior consultant focusing on SAP security and identity management. Before he joined SAP in 1999, Frank worked as a physicist in an international research team. He lives in Hamburg, Germany.

You may contact the author at frank.rambo@sap.com.

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