A service level agreement (SLA) is used to influence the due date of an access request or workflow request based on defined conditions and rules. It allows the responsible request processor to attend to approval issues promptly based on deadlines set via due dates. This concept is integrated with emergency access management (EAM) to drive the period of approval based on the criticality of the firefighter ID.

A firefighting strategy is effective only if roles and responsibilities are performed when due. EAM is used to drive the temporary authorization of users to perform activities that are outside their normal job responsibility. In most cases, this is to ensure that business operations continue uninterrupted, especially in an emergency situation.

The onus of reviewing the activities performed by a firefighter lies with the firefighter controller. This review is designed to provide an additional layer of control in the use of a privileged account and to create awareness in the mind of the firefighter that his or her activities will be reviewed. The assignment of these privileged user accounts poses varying levels of risk to a business. Risks may be low or high depending on the operating environment. Therefore, the attention to be given to the use and review of firefighter access is also a key issue to consider in the design of your organization’s firefighter strategy.

More importantly, depending on the risk level access poses to a business, measures need to be taken to ensure that the actual action of reviewing the logs is performed. This can be challenging for a controller especially when there are numerous firefighter logs to review in a day. In such a scenario, the controller needs to prioritize the logs to review. This makes the SLA functionality for firefighter log reviews very relevant to EAM.

The SAP Access Control application allows you to manage the firefighter log review workflow based on attributes defined for the firefighter IDs via the use of SLAs. This is possible because of the seamless integration between the emergency access management business scenario and the BRFplus workbench. The BRFplus workbench is a standard tool that provides the application programming interface (API) for building business rules. These business rules are used to evaluate a number of defined criteria that drive the behavior of the output. In the context of EAM (firefighter workflow audit log review), BRFplus can be used to evaluate the criticality level assigned to a firefighter ID and consequently calculate the due date for the firefighter workflow audit log approval. A simple example of this functionality is as follows: If the criticality level of two firefighter IDs is defined as very high and high, respectively, the due date to approve the firefighter log review workflow request should be one (1) and two (2) days, respectively. Figure 1 depicts this scenario.

Figure 1

Business rule logic for firefighter workflow review SLA

In an environment in which EAM is used, it is expected that there are policies and procedures in place that compel the controller to review the activities performed by the firefighter on a regular basis. This normally requires the firefighter controller to review (and approve) the firefighter log requests in a workflow inbox. Typically, the workflow message contains different columns that include the due date. The due date is a reflection of the SLA of the firefighter workflow review request that can be calculated based on the value defined in the BRFplus application using the defined criticality level of the firefighter ID.

This concept is supported for access request management and EAM business scenarios. In this article, I focus on the latter. I discuss SLAs as they apply to EAM under the following subheads:

• Definition of prerequisites
• Maintain criticality level master data
• Maintain SLA master data
• Maintenance of BRFplus function ID and Access Control application mapping
• Configure BRFplus rule for SLA for EAM
• Simulate a business scenario

Definition of Prerequisites

I assume that the EAM functionality is properly setup and configured as follows:

Notification setting: Thefirefighter ID controller is responsible for reviewing firefighter log reports generated during firefighting sessions. In the setup of the master data for the firefighter controller, the system allows you to define the means of notification. Notification to controllers about firefighting session details can be via email, workflow, or log display.

The notification setting for the firefighter controller should be set to workflow as shown in Figure 2. This is because the firefighter log report review request is only generated when the notification type is workflow. For the email option, the controller only receives email notification about a firefighter session and for log display, the controller needs to check explicitly in the SAP GRC system. This assignment (of notification setting) is maintained via the frontend SAP NetWeaver Business Client (NWBC) (Access Management workcenter) by following menu path Access Management > Emergency Access Maintenance>Controllers (quicklink).

Figure 2

Notification setting for firefighter controller

EAM parameterization: The configuration settings related to EAM should be configured to reflect the requirements of your operating environment. Give appropriate attention to the following parameters especially as they relate to a firefighting audit log review:

• 4007 (Send Log Report Execution Notification Immediately): If the value is set to YES, the application sends notifications when the user chooses the Update Firefighter Log button (Consolidated log report quick link on Access Management workcenter) or runs the program GRAC_SPM_LOG_SYNC_UPDATE. On the other hand, if the value is set to NO, the application only collects the logs when the user chooses the Update Firefighter Log button (Consolidated log report quick link on Access Management workcenter)or runs the GRAC_SPM_LOG_SYNC_UPDATE program.The application sends the email notifications when the GRAC_SPM_WORKFLOW_SYNC program is executed.
• 4008 (Send Firefighter ID Logon Notification): If set to YES, the application sends notification to the controller when a user runs a log report.
• 4009 (Log Report Execution Notification): This controls the sending of emails or workflow after firefighter data synchronization. The possible options are YESor NO.
• 4012 (Default users for forwarding the audit log workflow): This allows you to define who can be the recipient of a forwarded firefighter log review workflow request. The possible options are all users or only users defined as firefighter controllers.

These configuration parameters can be maintained by using menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain Configuration Settings. Figure 3 shows a sample configuration setting for EAM-related parameters.

Figure 3

EAM-specific configuration settings

Workflow process activation: The workflow process SAP_GRAC_FIREFIGHT_LOG_REPORT (Figure 4) should be properly configured and activated without errors to ensure that controllers can receive log reports in their workflow inboxes. This is done via the wizard-driven Multi Stage Multi Path (MSMP) workflow configuration screen. Access it by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Workflow for Access Control > Maintain MSMP Workflow.

Figure 4

The initial screen for MSMP workflow configuration of the SAP_GRAC_FIREFIGHT_LOG_REPORT workflow process

Note Knowledge of BRFplus is a prerequisite to understanding this article because the basics (step-by-step) of creating and maintaining the standard BRFplus objects are not explained in detail. For more information on MSMP workflow and its integration with BRFplus, consult Richard Calaba’s article, “Understand and Extend SAP Access Control 10.0 Approval Workflow.” For more information on the configuration and operation of emergency access management in SAP Access Control 10.0, consult Frank Rambo’s article, “Turn Emergency Access Management into an Auditable, Centralized Process for Your SAP Landscape.”

Maintain Criticality Levels Master Data

The SLA functionality for firefighter workflow log review is driven by the criticality level defined for firefighter IDs. The criticality level is a usually a measure of how risky the business perceives the authorizations assigned to a firefighter ID. The risk associated with firefighter IDs normally differs in an enterprise system. As part of the post-installation activities, you can activate the Business Configuration (BC) Set GRAC_SPM_CRITICALITY_LEVEL that contains SAP standard criticality levels via transaction SCPR20. You can also add custom criticality levels by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Emergency Access Management > Maintain Criticality Levels for Emergency Access Management as shown in Figure 5.

Figure 5

Maintain criticality level in Customizing

A firefighter ID is a privileged but temporary user ID that is assigned to one or more users (firefighters) to process transactions in the system in the event of an emergency situation. A new or existing user ID can be defined as a firefighter ID and assigned timelines for validity. Also, the criticality levels defined in customizing can be assigned to firefighter IDs via the front end  NWBC (Access Management workcenter) by following menu path Access Management > Emergency Access Assignment > Firefighter IDs (quicklink).

For the purpose of my business scenario, Figures 6 and 7 show the assignment of criticality levels Very High and High to firefighter IDs FF_ID and FFID1 respectively.

Figure 6

Assignment of criticality level (Very High) to Firefighter ID – FF_ID

Figure 7

Assignment of criticality level (High) to Firefighter ID – FFID1

Maintain SLA Master Data

You need to define the SLA master data to reflect the timeframe for which you want to monitor the due date for the approval of the firefighter audit log. This is done in customizing by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > User Provisioning > Maintain Service Level Agreements.

Basically, you need to give the SLA a description and assign it to the appropriate workflow process ID, which in this case is SAP_GRAC_FIREFIGHT_LOG_REPORT. Also, you need to define the basis for calculating the SLA. This is known as the SLA type. The possible options are:

• Formula: This option is based on a formula and therefore offers more flexibility in usage. This is the SLA type that is applicable to building BRFplus applications for SLA.
• Fixed by number of days
• Fixed by date

Since I am using BRFplus to define the calculation of the due date, I am using the formula SLA type. For the purpose of this article, I define two SLAs as shown in Figure 8:

• SLA ID = 2 (SLA due date is 1 day)
• SLA ID = 3 (SLA due date is 2 days)

Figure 8

Definition of SLA master data

Maintenance of BRFplus Function ID and Access Control Application Mapping

The SLA rule for EAM is a standard application in SAP Access Control 10.0. The application is defined and maintained within the BRFplus workbench. Basically, you need to check for the correct function ID in the BRFplus workbench. You can identify the correct function ID by accessing transaction BRFplus or BRFplus and navigating to the appropriate function of the application as shown in Figure 9.

Figure 9

Definition of function ID

The actual mapping is done in customizing. Ensure that the correct function ID is mapped against the right access control application in customizing by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide >Governance, Risk and Compliance > Access Control > Maintain AC Applications and BRFplus Function Mapping as shown in Figure 10. Furthermore, the MSMP process ID assignment must be correctly set to SAP_GRAC_FIREFIGHT_LOG_REPORT. This ties the application to the firefighting workflow process.

Figure 10

Mapping of BRF+ function ID with application ID and MSMP process ID

The standard access control application may not be available in the application mapping table (Figure 9). This is usually the case with the client copy option used during system setup in which some objects might not be copied (from client 000) into the production clients. In such a scenario, refer to SAP Note 1637515 (Not able to find the predelivered BRFplus rules) on how to export from client 000 and import into the productive client the corresponding .xml file for the appropriate access control application.

Configure BRFplus Rule for Service Level Agreement for EAM

To configure the BRFplus logic using the standard delivered application GRAC_BRFP_SPM_SLA, you need to create a decision table as a top expression in the BRFplus workbench where you define the criteria that will be evaluated in the logic and the outcome to expect. The decision table is an object (of expression type) in the BRFplus workbench. The entries are maintained in the decision table.

Figure 11

Overview of EAM SLA application

Figure 12

Signature of EAM SLA Access Control application showing the result data object as SLA_ID

The scenario presented in my business example is simple so I am setting the mode (in the Properties tab of the function object) to Functional Mode. This allows you to seamlessly create a decision table to be used as the top expression. To do this, click the Create… button shown in Figure 13.

Figure 13

Create a decision table as the top expression

The resulting data object for the decision table should be SLA_ID and the result column is SLA_ID. The condition columns should be the criticality level (IV_CRITICALITY).This implies that the attribute criticality level will be evaluated by the logic against the firefighter log review workflow request. The decision table should return an initial value if no match is found. Figure 14 shows the decision table settings for the logic of my business example.

Figure 14

Table setting for decision table showing result data object, condition, and result columns

Next, populate the columns with the desired values. For the purpose of this article, I defined the scenarios (shown in Figure 1) as:

• If the criticality level assigned to a firefighterID is Very High (04 – IV_CRITICALITY), then the number of days for the SLA should be 1 day plus the system date (002 – SLA_ID).
• If the criticality level assigned to a firefighter ID is High (03 - IV_CRITICALITY), then the number of days for the SLA should be 2 days plus the system date (003 – SLA_ID).

Figure 15 shows examples of criticality values for decision tables.

Figure 15

Decision table entries definition

You have to save the decision table by clicking the Save button. You then receive a status message shown in Figure 16.

Figure 16

Message displayed after saving the decision table

You also need to activate the decision table by clicking the Activate button to make the decision table productive. You then receive the status message shown in Figure 17.

Figure 17

Status message for successful activation of decision table

Activate the function by clicking the Activate button and you receive a status message shown in Figure 18.

Figure 18

Status message for successful activation of function

Simulation of a Business Scenario

To test that the logic defined in the BRFplus works, I performed firefighting activities using the firefighter IDs FF_ID and FFID1. The workflow request was received in the inbox of the assigned firefighter controller as shown in Figure 19.

Figure 19

Firefighter log workflow request in Firefighter controller’s inbox

The following two scenarios show the difference between these two workflow requests.

Scenario I (Figure 20):

• Firefighter ID: FFID1 (with criticality level – High)
• Date of executing firefighting session and system date: 24:02:2013
• Due date: 26.02.2013
• Result: SLA – Due date to treat approval workflow request is 2 days (2 days + system date)

Figure 20

Firefighter log review workflow request for scenario I

Scenario II (Figure 21):

• Firefighter ID: FF_ID (with criticality level – Very High)
• Date of executing firefighting session and system date: 24:02:2013
• Due Date: 25.02.2013
• Result: SLA – Due date to treat approval workflow request is 1 day (1 day + system date)

Figure 21

Firefighterlog review workflow request for scenario II

Kehinde Eseyin

Kehinde Eseyin is a security architect. He holds a bachelor’s degree in computer science. He has about 12 years of IT security, governance framework, IS risk, and compliance experience gained by working in numerous global organizations. Over the years, he has demonstrated competencies in security design, information assurance, cyber security, data privacy, threat and vulnerability management, penetration testing, business architecture, project management, IT audit, IS controls framework, and identity and access management. You may contact the author at eseyinok@gmail.com. If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.