Over the years, I have been involved with the implementation, audit, and review of SAP Access Control systems. In my experience on these assignments, some functional experts and end users do not give proper attention to specific activities that could expose the SAP Access Control system and connected back-end systems to undue risk. Based on this, I share some important areas that need attention when planning, implementing, and operating SAP Access Control 10.0.

SAP Access Control runs on the standard SAP ABAP framework with an optional SAP Java infrastructure that can be integrated with other SAP and non-SAP systems. Therefore, the conventional audit and technical review applicable to other SAP system landscapes applies to SAP Access Control.

However, in this special report, I focus on the core capabilities of the SAP Access Control system and the areas that can present audit concerns during a system review. I also explore both functional and technical areas that, if not properly managed, can expose SAP Access Control to threats and vulnerability.

After an overview of the necessities for a thorough system review, I discuss top strategies and best practices that you can adopt to gain insight into different control objectives as they relate to the audit of SAP Access Control, including the following topics:

• Technical installation validation
• Activation of Internet Communication Framework (ICF) services
• Definition and maintenance of the segregation of duties (SoD) rule set
• Workflow maintenance
• Change request management
• Data archiving
• Authorization management of technical users
• Firefighter ID log-in prohibition
• Management of SoD role authorization
• Background job administration and monitoring
• Integration with back-end systems
• Performance optimization
• Missing indexes
• Business continuity and disaster recovery
• Time zone setting
• Documentation

The Importance of a System Review

A technical system review should be an ongoing function to ensure that participating systems continue to operate optimally and with no bottlenecks. More important, the system that is used to manage compliance issues (i.e., SAP Access Control) should also be compliant.

The objective is to highlight specific controls that should be in place to safeguard the infrastructure on which the user access control compliance tool of an organization rests. This is important because users (e.g., employees, both permanent and contract) can expose the system to malicious activities and events through their actions or inactions, which can have a negative impact on your enterprise’s business operation. Therefore, the application used to control user access to systems needs to be foolproof.

As the access control application is designed to be the gateway and entry point for users to gain access to the system, you need to secure and protect this system with defined and infallible controls. The risk and implications of access control system noncompliance to defined controls can be so grave that it can lead to the payment of large fines or the inability of a business to continue to operate, in extreme cases.

Exposing the compliance system to risks can also lead to loss of goodwill for an organization. In fact, the failure of internal control as it relates to user access control has necessitated the creation of regulations, such as the Sarbanes-Oxley Act (with different country versions, such as J-Sox), that have continued to drive the definition of internal controls that should be in place for management to be confident that enterprise systems are not subjected to malicious acts.

The SAP Access Control tool offers functionality to address four broad areas of access provisioning and user management; namely, Access Risk Analysis, Access Request Management, Business Role Management, and Emergency Access Management. These areas present different risk levels to the access control infrastructure that should be mitigated by adequate compensating configuration controls and best practices.

The SAP Access Control system is designed to address access control risk issues in the areas of risk detection, risk remediation and mitigation, risk prevention, and risk reporting. Therefore, you should adopt a risk management approach to evaluate the threats, vulnerability, and risk implications of a compromise of any kind to implemented controls in your system.

 

Technical Installation Validation

 

A major risk during technical installation is that the system might be error prone and unusable. The preventive measures you can take include ensuring that the systems run the correct software components and that the current support package or patch level is installed.

The technical installation of SAP Access Control requires the installation of a number of certain software components, depending on the use case. The following software components are mandatory for installing SAP Access Control 10.0-specific software components:

• SAP_ABA—Cross-Application Component (Support Package 06)
• SAP_BASIS—SAP Basis Component (Support Package 06)
• PI_BASIS—Basis Plug-In (Support Package 06)
• SAP_BW—SAP Business Warehouse (Support Package 06)

The software for SAP Access Control 10.0 is bundled with Process Control and Risk Management in the add-on GRCFND_A V1000 (GRC Foundation). You must install this component on the SAP GRC server. You also need to install two plug-ins, GRCPIERP and GRCPINW, on the back-end system that connect to the GRC system. The specific component of the plug-in component installed depends on the SAP Basis version of the back-end system.

The back-end system can also be the SAP GRC system; however, the GRCPIERP software component requires SAP_ABA and SAP_HR software components. An important audit concern with the installation of the SAP Access Control foundation software component and the plug-in software component is that they must be on the same Support Package level. The need to have the SAP GRC foundation component and the plug-in component on the same Support Package level is still relevant for systems with less than Support Package 10.

Suffice to say that backward compatibility is in place from Support Package 10. The backward compatibility adherence implies that you can upgrade the Support Package level of the GRCFND_A V1000 software component without necessarily upgrading the back-end plug-in software components—GRCPIERP and GRCPINW—as long as the minimum Support Package level is 10. Therefore, a technical system reviewer will be interested in gaining assurance about this consistency and synchronization requirement with the Support Package levels of the foundation components and plug-in components.

Furthermore, it is a best practice to update the Support Package level of the systems in your landscape to the current Support Package level, as they contain fixes for known issues. This fact makes the currency of the Support Packages of SAP components a serious audit concern during a technical system review.

I recommend that you extend this to confirm if the SAP kernel is up to date. The SAP kernel is a core component (database dependent and database independent) of the SAP engine that contains the executable files (i.e., .exe files) used to start different processes. The patching of the system should not be limited to only the SAP components; you must also patch the underlying database system.

I recommend that you also extend a technical review to gain assurance that other relevant software components are installed, especially as part of the post-installation validation activity. For example, if you need to generate a PDF-based report, you need to have Adobe Document Service (ADS) set up in the Java instance connected to the ABAP system on which the SAP GRC system runs.

To display the Support Package level of your SAP Access Control system, enter transaction code SPAM. In the screen that appears (Figure 1), click the Package level button.

The next screen shows the installed components and the corresponding Support Package levels (Figure 2).

To review the Kernel patch level of your SAP system, log on to the SAP Easy Access Menu. Follow menu path System > Status. In the System: Status screen and then click the other kernel info icon  (Figure 3).

The next screen displays the kernel patch level (Figure 4).

Activation of ICF Services

The major risk is that the system might be vulnerable to Internet (i.e., external) browser-based attacks. The preventive measure is to enforce control in the activation of ICF services.

The SAP Access Control system runs on the SAP ABAP engine. After the installation of the ABAP component, ICF services are all in an inactive status. As part of post-installation activities, you need to activate a number of ICF services. The activation of ICF services is performed via transaction code SICF.

The SAP Access Control system runs via a browser-based front-end component, which makes the activation of ICF services an important post-installation activity. The status (active or inactive) of ICF services is of serious audit concern because of the security risk associated with directly accessing active ICF services via HTTP from the Internet. Therefore, it is a best practice not to activate SICF services that are not needed. You should activate ICF services on a need basis.

The system review interest for the system auditor is to check that the system is not exposed to external vulnerabilities as a result of the activation of unnecessary ICF services. You should review activated ICF services to ensure that a loophole capable of introducing threats and vulnerabilities to the system landscape does not exist. Typically, SAP recommends that you activate all ICF services within the following ICF service nodes for use of the SAP Access Control tool:

• /sap/public
• /sap/bc
• /sap/grc

It is also possible to explicitly assign a user to an ICF service. This is common when end-user logon functionality is implemented. You must adequately control the authorization assigned to the user in the system.

Definition and Maintenance of SoD Rule Set

The major risk is that access risk violations might be underreported or overreported. As a preventive measure, you can ensure that SoD and sensitive access rule sets reflect the approved risk perception of the enterprise.

Auditors usually want to be assured that the SoD rule set is well defined and properly maintained. The SoD rule set is a group of data elements that collectively form the segregation of duties risks and sensitive access risks in an enterprise system. It is the basis for risk analysis in an enterprise system. SAP standard SoD rule sets are fashioned after best practices for risk analysis based on optimal SoD in SAP and non-SAP systems.

The SAP Access Control system comes with predelivered SoD rule sets that you can make available in the system by activating the appropriate business configuration (BC) sets using transaction code SCPR20. For the SAP system, the standard rule sets are targeted at specific software components (for example, SAP ERP Human Capital Management [SAP ERP HCM] or SAP Customer Relationship Management [SAP CRM]). BC sets related to SoD rule sets in the SAP Access Control system include the following:

• GRAC_RA_RULESET_COMMON—SoD rules set
• GRAC_RA_RULESET_JDE—JDE rules set
• GRAC_RA_RULESET_ORACLE—Oracle rules set
• GRAC_RA_RULESET_PSOFT—PeopleSoft rules set
• GRAC_RA_RULESET_SAP_APO—SAP Advanced Planning & Optimization (APO) rules set
• GRAC_RA_RULESET_SAP_Basis—SAP BASIS rules set
• GRAC_RA_RULESET_SAP_CRM—SAP CRM rules set
• GRAC_RA_RULESET_SAP_ECCS—SAP Enterprise Controlling Consolidation System (SAP EC-CS) rules set
• GRAC_RA_RULESET_SAP_HR—SAP ERP HCM rules set
• GRAC_RA_RULESET_SAP_NHR—SAP R/3 less HR Basis rules set
• GRAC_RA_RULESET_SAP_R3—SAP R/3 AC rules set
• GRAC_RA_RULESET_SAP_SRM—SAP Supplier Relationship Management (SAP SRM) rules set

During post-installation activities, you activate only the BC sets that you need. As part of the technical system review, you need to review the activation log generated after the activation of BC sets for specific SoD rule sets to ensure that there were no errors that could lead to data inconsistencies as a result of the BC set activation. To review the activation log generated during the activation of a BC set, execute transaction code SCPR20.

In the initial screen for activation of BC sets, enter a value for the BC sets field by choosing a set as shown in Figure 5. You can use the input help by pressing F4. The Short Text field is automatically populated.

Click the activation log icon . In the next screen, you can see the activation logs grouped by an activation timestamp (Figure 6).

Expand a specific node of the timestamp to see details of the activation log, as shown in Figure 7.

It is important that errors are not reported or generated during the activation. If an error is generated, it can lead to data inconsistencies. You can review warning messages for appropriateness and ignore them if they do not represent a catastrophic event. It is not sufficient to simply activate the BC set containing the standard SoD rule set. The standard rule set may not necessarily be fit for the purpose, and therefore, needs to be maintained and validated by appropriate personnel. The validation of the rule set normally involves the review of dependent master data elements of a SoD rule set, such as risks and functions (actions and permissions).

The purpose of the review of the SoD rule set content is to gain assurance that the content of the rule set is correct and a precise representation of the risk appetite and the perception of enterprise access risks. The review of rule set content needs to be very detailed to address not only the associated transaction codes (i.e., actions) but also the correctness of the absolute value defined for the corresponding authorization objects. For example, in the definition of authorization object value, 1 is not synonymous to 01.

In the same vein, the use of the value asterisk (*), for example, does not equal any value. Rather, it means * itself. Therefore, if you want to make a permission definition applicable to all purchasing groups, you do not use *. Instead, you either deactivate the field for the assignment or be explicit (i.e., list the explicit purchasing group values). Another option is to use the value $.

You also need to check that the operators (AND, OR, and NOT) used in the rule set definition are properly defined. The maintenance of the wrong value might not necessarily cause an error message, but it affects the reporting of access risks because you are underreporting or overreporting, as the case may be. Furthermore, adequate understanding of the operator is important because most users are quick to misunderstand the reporting output of the operators. For example, when the NOT operator is used in permission-definition logic, it reports users that have any value except the value in the rule—not the users who do not have the value defined.

Part of the review of the SoD rule set content should address the correct assignment of the access risk to the appropriate business process. Similarly, you need to validate the access risk level to ensure correct master data attributes (e.g., risk levels) are maintained.

You should not maintain a high access risk element as medium. This is because the risk levels can have serious implications in the analysis of the access risk exposure reporting to management, especially as it relates to selection criteria definition. Furthermore, the incorrect maintenance of risk levels can lead to the failure of configured controls and the incorrect evaluation of Business Rule Framework plus (BRFplus) business rules. For example, if you define a business rule using the request mitigation access control application to enforce the mitigation of an access risk level defined as high, but the attribute (i.e., risk level) of the dependent master data (i.e., access risk) is incorrectly maintained, the result is control ineffectiveness because the business logic does not evaluate correctly.

Another audit concern in the technical review of the SoD rule set is checking for completeness. This implies that no data (including standard transaction codes) that can affect the SoD risk reporting should be left out of the SoD rule set. It is commonplace to have defined custom transaction codes in your system. As expected, the standard rule set does not contain custom transaction codes. As a matter of fact, custom transaction codes are often built to address a critical system requirement that is not met by standard system functionality.

This assertion gives credence to the fact that the access risk issues associated with custom transactions should be treated seriously and included in the SoD rule set. You should approach the business process owner of the custom transaction code to gain an understanding of the associated risks of the custom transaction code and then analyze it for SoD violation possibilities.

Table TSTSC, which can be accessed via transaction code SE16, contains all transaction codes defined in the system. You can use the prefix adopted for custom transactions in the organization to filter out the custom transaction codes and confirm if they are defined in the SoD rule set.

The maintenance of an SoD rule set is a continuous process aimed at ensuring that the rule set is a true reflection of the risk exposure of an enterprise at any point in time. One of the control objectives of the technical review of the SAP system is the existence of an effective policy and procedure ensuring that changes to the access rule set are made in a controlled manner. This should cover adherence to best practices of approving changes before the changes are moved to the production environment from pre-production systems.

This requirement is discussed in detail under the “Change Request Management” section. You can perform the maintenance of an access rule set directly in the back-end system (IMG of the access control) or via the front end (SAP NetWeaver Business Client [NWBC]). Because of the sensitivity and criticality of SoD rule set data, it is important to ensure that the authorization to maintain the rule set data is controlled as much as possible.

You can perform the following maintenance activities for an SoD rule set via customizing (IMG):

• Download SoD Rules: This allows you to download a rule set using the program GRAC_DOWNLOAD_ACCESS_RULES
• Upload SoD Rule: This allows you to upload an SoD rule set using the program GRAC_UPLOAD_ACCESS_RULE
• Generate SoD Rule: This allows you to generate an SoD rule set after an SoD rule set upload or transport using the program GRAC_GENERATE_ACCESS_RULE
• Delete SoD Rule: This allows you to delete specific SoD rule set data via the program GRAC_DELETE_ACCESS_RULES. Another program you can use to delete an SoD rule set is GRAC_DELETE_ACCESS_RULES_ALL, but this program should be used with utmost care as it cleans up all SoD rule set-related master data from the system.
• Transport SoD Rule: This activity allows you to transport an SoD rule from the development system to the destination systems. The maintenance of the rule set should be treated as a transportable activity to ensure adherence to change control best practices.

You can perform the above maintenance activities via menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Access Risk Analysis > SoD Rules.

When rule set data is maintained directly via NWBC, you need to activate the change log functionality so that the audit trail is available for an auditor to review changes made to the elements of the rule set. The activation of the change log is made by setting the configuration parameters 1001 and 1002 for functions and access risk to YES in customizing, as shown in Figure 8.

To display the corresponding parameter settings for the change log, follow menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain Configuration Settings. Figure 9 shows a sample change log for a function that reports on the change type, timestamp, old value, and new value.

Furthermore, you can activate workflow as part of your strategies to ensure that risk and functions that are an integral part of the SoD rule set go through the appropriate approval requirements before changes are successfully made. This is controlled by the Function Approval workflow (SAP_GRAC_FUNC_APPR) and Risk Approval Workflow (SAP_GRAC_RISK_APPR) processes, which you can maintain in the Multi-stage Multi-path (MSMP) Workflow Process wizard maintenance screen (Figure 10). To access this screen use transaction code grfnmw_configure_wd.

You can refer to the “Workflow Maintenance” section for more information on workflow.

Following are some of the dependent configuration parameters that can influence workflow settings for risk and functions maintenance in the SAP Access Control system:

• Parameter 1062: Risk Maintenance
• Parameter 1064: Function Maintenance
• Parameter 1101: Create Request for Risk Approval
• Parameter 1102: Update Request for Risk Approval
• Parameter 1103: Delete Request for Risk Approval
• Parameter 1104: Create Request for Function Approval
• Parameter 1105: Update Request for Function Approval
• Parameter 1106: Delete Request for Function Approval

Workflow Maintenance

Another major risk is that an approval request might not be treated in a timely manner and by the correct approver. The preventive measure you can take is to ensure that the workflow mechanism is properly configured and the approver master data is properly maintained.

To use the workflow capability of the SAP Access Control system, it is necessary to perform a few post-installation activities. These include:

• Automatic workflow customizing
• Task-specific customizing

Following the execution of these workflow-related customizations, you need to gain assurance that the workflow engine is working. To do this, perform a workflow verification activity. Follow the steps below to gain preliminary assurance that the workflow engine is working properly.

Enter transaction code SWU3 in the command line. In the screen that appears, click the start verification icon  (Figure 11).

The next screen displays a dialog box, as shown in Figure 12.

Click the green check mark icon and navigate to the business workplace view by clicking the business workplace icon . A new message appears in your inbox (Figure 13).

Highlight the message First step in workflow verification and click the execute icon. In the next screen, click the Execute background step immediately button (Figure 14).

The next screen displays a message in your inbox that the verification of workflow was completed correctly (Figure 15).

Workflow is designed to ensure that activities within the system are properly reviewed and approved by the designated individuals before changes are made to specific information or processes. This can include granting access to users or changes to master data, such as functions or assignment of mitigating controls to users and roles. The auditor’s interest in a workflow process is who the actor (i.e., approver) is. This audit concern is important because the appropriate user must be set up in the system to ensure that the correct person performs the required responsibility. The approver must be reviewed for correctness and currency at defined intervals. In the context of SAP Access Control, the approvers are known as agents. Broadly, agents can act as approvers and as notification recipients of workflow-related events.

It is expected that an auditor will be interested in how the agent master data is maintained to ensure that the workflow approval requests are routed to the appropriate approvers and that approval requests are attended to promptly. Different workflow-driven activities require you to set up agents in the system. The source of the agent master data depends on the defined agent type, which can be any of the following:

• Directly mapped users: The agents are determined based on a defined list of approvers who are associated with an approver group ID.
• Transaction code PFCG roles: The agents are determined based on the assignment of a specific PFCG role.
• PFCG user group: The agents are determined based on their assignment to a defined user group on the groups tab of the user master data (transaction code SU01).
• GRC Application Programming Interface (API) rules: The approvers are determined based on business rules defined via any of the rule types (i.e., BRFplus, BRFplus flat rule, Function module, and ABAP class).

Irrespective of the method adopted to determine the approver, the approver master data needs to be reviewed for correctness and currency at specific intervals. Adequate procedures and policies must guide the process of making changes to the agent master data. The change management process should be leveraged as much as possible when changes are made to the agent master. Refer to the “Change Management” section later in this article for more information about enforcing effective change management best practices.

Another audit concern is how the delegation of authority is managed within the enterprise. The approval delegation capability is laudable because it allows another user to act in the primary approver’s capability for a defined period of time, usually during a vacation. As a best practice, it is ideal for actors (e.g., approvers) in a business process to be unavailable over a period of time. It is a management strategy to prevent fraud and identify lapses in the business process as a result of the unavailability of the principal actor. It is common to see individuals who are supposed to be approvers delegating their approving rights to their subordinates without any genuine reason.

Ideally, approving responsibilities should be delegated in special situations when the main approver is not available to act on an approval request. Figure 16 shows a typical approval delegation table. You can display the approval delegation table by following menu path NWBC: Access Management > Access Requests Administration > Admin Delegation.

An auditor should review this table to gain assurance that every approval delegation entry is justifiable. More important, you need to establish that the delegated employee has the requisite knowledge and skill set to perform this responsibility appropriately.

The technical review should cover the delivery of notification messages to intended recipients. This is to ensure that agents (not necessarily the approvers) are only notified about approval events that have taken place. This is important in certain circumstances. For example, a group of users might need to know about the access provisioning activities of specific access request attributes in order to perform specific follow-on activities outside of SAP Access Control, such as manual maintenance of data in non-SAP systems.

Also, notifications ensure that users are informed about pending approval decision requests in their inboxes on time to prevent unnecessary delays. To facilitate the sending of emails, you need to define settings in transaction code SCOT, such as the node type, mail server host, mail server post, address type, and recipients list (Figure 17).

To review the status of email messages that are generated in the system over a period of time, use transaction code SOST (Figure 18). You need to review the entries in the table appropriately to ensure that email messages are not going unnoticed.

Furthermore in an environment in which email messages must be sent to users as part of the configured process flow or business requirement, the technical review should make provision for checking that all users have their email addresses maintained accordingly — for example, in transaction code SU01 where the SAP system is the data source of the user email address attribute.

Change Request Management

Another major risk you could encounter is data and customization setting inconsistencies that make the system error prone. To prevent this, you can enforce control in the promotion of changed data or customizations across the system landscape by avoiding performing customizing activities directly in the production system.

You must configure the system landscape of the access control system to adhere to at least the three-system landscape, typically made up of the development, quality assurance, and production systems. It is possible to include a test system to enforce additional control in the system landscape.

Figure 19 shows a typical transport route for a three-system landscape. The transport route diagram provides assurance that the three-system landscape is configured and that an auditor can check it by following menu path transaction code STMS > Overview > Transport Routes. An auditor will be interested in ascertaining that all configuration changes, including master data (rule sets and BRFplus rules such as logic and master data, approvers, or user defaults) are tested before the changes are promoted to destination or subsequent systems in the landscape.

This architecture discourages people from making modifications directly in the production system. You should configure the production system in such a way that direct modification in the production environment is impossible. You can review production client settings for appropriateness via transaction code SCC4. As I stated earlier, all transportable configuration and master data must be transported across the system landscape. This includes the BRFplus application. BRFplus is at the heart of the SAP Access Control system and drives the behavior of the business workflow process. To make BRFplus applications transportable, you first need to create a development package via transaction code SE21, which is consequently associated with the application. Note that BRFplus applications created as local objects cannot be transported. Figure 20 shows a BRFplus application created as a local package with the Transport button grayed out (therefore, it is not transportable). Figure 21 shows a development package (ZGRAC) associated with a BRFplus application with the Transport button active and therefore transportable.

A number of master data items cannot be transported in SAP Access Control. They include reason codes, access control owner’s definition, coordinators, and firefighter master data. You should use the authorization concept in conjunction with the SoD concept to enforce control in the management of non-transportable master data. You should also review this master data on a periodic basis for currency and correctness. Furthermore, when there is a change request, a control process must be in place that objectively reviews the impact of such changes on all dependent business processes and end users. You should also secure the development and quality assurance systems appropriately. A defined security policy should address access rights, modification, and data composition of the non-production systems.

Data Archiving

When you are archiving data, there is a potential risk that system performance might be impaired and data retention policies might be flaunted. As a preventive measure, you can archive data at defined intervals based on corresponding regulations.

In a typical organization, aside from business requirements and corporate policies, prevailing legal and regulation requirements influence data retention strategies adopted by an enterprise. Further, data archiving has a laudable implication as it relates to enhancing system performance. These reasons make the issue of data archiving an important technical system review concept. SAP Access Control provides standard archiving objects you can use to archive specific data in the system.

A system auditor will be interested in understanding the archiving strategy of an organization and applying that to gain assurance that data is properly archived as scheduled using the appropriate tools. SAP Access Control supports the standard archiving process of data via transaction code SARA (Archive Administration). The following archiving objects are available to archive access control-specific data:

• GRFNMSMP—Archiving for SAP Access Control 2010  requests
• SPM_AU_LOG—SPM audit log archive
• SPM_CH_LOG—Change log archive
• SPM_LOG—Archiving for SPM log reporting
• SPM_OC_LOG—SPM OS command log archiving
• SPM_SY_LOG—SPM system log archival

The archiving process dumps the archive files in the defined archive directory. Besides the issue of compliance with the archiving calendar or schedule, the security and protection of the archive file destination can represent an audit concern. The integrity of the storage location of the archived data is important to consider during your review of the system.

Authorization Management of Technical Users

The major risk here is that the technical user account might be used for malicious activities in the system. To prevent this, ensure that there is control in the authorization assignment of technical users.

To operate SAP Access Control normally, you need to create some system users and assign them to specific authorizations. Examples of these system users are Remote Function Call (RFC) users and WF-BATCH users. A typical SAP Access Control system landscape is made up of the SAP Access Control system itself and dependent back-end systems (e.g., SAP ERP or SAP SRM). To establish communication between the SAP Access Control system and the back-end systems, you need to set up an RFC connection (connector) between these systems via transaction code SM59.

The type of back-end system typically determines the type of RFC destination. For example, to connect to an ABAP-based system, you need to create an RFC of type 3 (ABAP connection). On the other hand, to connect to SAP NetWeaver Portal, you need to create an RFC of the type G (HTTP connection to external server). Normally, RFC destinations need a user account that is used to authenticate the call to the destination system. Figure 22 shows a user assignment to the RFC destination of the ABAP connection type.

The RFC user can be a powerful user because it can establish a remote connection (logon) to a destination system. Therefore, the authorization assigned to an RFC user must be properly controlled. SAP recommends that you assign the following authorization objects and values to the RFC user for SAP Access Control functions:

• ACTVT: 16
• RFC_NAME: /GRCPI/GRIA, BAPT, RFC1, SDIF, SDIFRUNTIME, SDTX, SUSR, SUUS, SU_USER, SYST, SYSU
• RFC_TYPE: FUGR

The WF-BATCH user is a communication user that is required to run the workflow engine. You must assign the standard delivered role SAP_GRAC_ALL (or its copy) to the WF-BATCH user. The authorization assigned to this user must also be well controlled.

The system audit should cover the review of the authorization assigned to technical users, especially the RFC user and the workflow user (WF-BATCH). Under no circumstance should you assign the SAP_ALL profile (or its flavor) to these technical users.

Firefighter ID Login Prohibition

An additional major risk is that a firefighter ID (with privileged authorization) might be used to log on directly to the back-end system to perform malicious activities, and the logs will not be captured. As a preventive measure, you can implement the user exit described in SAP Note 1545511.

Firefighting refers to the act of using privileged user accounts in times of emergency. This functionality is one of the most important capabilities of SAP Access Control, as it seeks to control the assignment of excessive authorization (including SAP_ALL) to users. SAP Access Control allows a user to firefight using either the firefighter ID strategy or a role-based strategy.

With the firefighter ID strategy, the ID is the user with elevated privileges allowing them to perform a firefighting session in the system. The firefighter ID is typically identified via the assignment (in the back-end system) of the role maintained in parameter 4000 in the SAP GRC system. You should log the activities performed by a firefighter ID and enhance the process to send these logs to a controller via workflow for review and approval.

Because the firefighter ID possesses elevated privileges, it should not be used directly in the system. Instead, it should be used via the assigned firefighter user. To enforce control around the use of the firefighter ID directly in the back-end system, you can implement a user exit in the back-end system where the firefighter ID resides. The user exit prevents the firefighter ID from logging on directly to the back-end system. SAP Note 1545511 defines the steps to create this user exit.

It is still possible to log on with a firefighter ID after the user exit has been implemented if dependent configuration settings (SPM application type and FFID role name in the plug-in system and the SAP GRC system) are not yet maintained appropriately or if the plug-in software component level in SAP GRC differs from that of the back-end system. Therefore, the best way to review if this user exit has been implemented is to execute a test that attempts to log in directly to the back-end system using a firefighter ID. This action should trigger the display of a dialog box as shown in Figure 23.

The dialog box displays briefly (for about two seconds) and states that you are not allowed to log on with a firefighter ID. A review of this requirement is important for giving assurance that the firefighter ID cannot be used in the system without being monitored and reported as part of emergency access management reporting, thereby eliminating the possibility of the perpetration of malicious activities in the system.

Segregation of Duties

Another risk you can encounter is the perpetration of malicious activities as a result of the possession excessive authorization. To prevent this, employ the principle of least privilege in authorization assignments. Authorization should be granted on a need-to-know basis.

SoD is included in the requirements of many regulations, including Sarbanes-Oxley. The idea is to prevent the concentration of authority to carry out critical activities in the system with specific users. One of the use cases of the SAP Access Control system is to ensure that duties are properly segregated in the enterprise systems connected to it. You should also extend this capability to the SAP Access Control system itself.

It is a best practice to form a set of incompatible SoD matrices for the SAP Access Control system (i.e., SAP Access Control itself should have a set of activities that are segregated). For example, when a user who creates a function (a component of an access risk) is also the approver of the function, control becomes a serious issue because this compromises the entire process of SoD rule maintenance. In the same vein, internal control can also be a huge audit concern if the person who creates a mitigating control can also maintain the mitigating control or assign the mitigating control to users or roles. Therefore, it is important for a system auditor to be assured that responsibilities are adequately segregated in the SAP Access Control system and performed with a sense of independence.

SoD control is closely interwoven with user management, especially as it relates to roles and profile assignments. A technical review should seek to establish that the authorization assigned to specific job roles is optimal and does not create a conflict that is unmitigated.

A number of standard configurable controls are designed to enforce SoD. These configuration settings should be reviewed for correctness and appropriateness. Examples are:

• The approver cannot approve his own request
• The firefighter ID owner can submit a request for a firefighter ID owned
• The firefighter ID controller can submit a request for a firefighter ID controlled

The approver cannot approve his own request. This is configured in the customizing activity in which you can maintain End User Personalization (EUP) fields by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > User Provisioning > Maintain End User Personalization. Figure 24 shows an example of a typical setting to prevent the approver from approving his or her request.

You can assign the EUP setting to an approval stage in the MSMP workflow customizing to influence the behavior of different stages in a workflow path.

Following is an explanation of the parameter settings for scenarios in which the firefighter ID owner submits a request to access an owned firefighter ID, and in which a firefighter ID controller submits a request to access a controlled firefighter ID:

• The firefighter ID owner can submit a request for a firefighter ID owned: When parameter 4013 is set to no, it disallows a firefighter ID owner from submitting an access request for a firefighter ID for which he is the owner. To set this parameter, follow menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain Configuration Settings.
• The firefighter ID controller can submit a request for a firefighter ID controlled: When parameter 4014 is set to no, it disallows a firefighter ID controller from submitting an access request for a firefighter ID for which he is the controller. To set this parameter, follow the same menu path referenced above.

If you cannot adequately segregate duties, the auditor should seek to gain assurance that effective compensating controls are in place. This might be the case when there are certain constraints, such as organizational structures an inadequate number of employees.

Background Jobs Administration and Monitoring

When you are considering background jobs administration and monitoring, a major risk is data inconsistencies between the SAP GRC system and the satellite system. In addition, smooth running of the system might be affected if administrative background jobs are not scheduled and executed successfully. As a preventive measure, you can schedule (in the correct order) and monitor background jobs for successful completion.

Background jobs define programs or a collection of programs that are executed by background work processes. Various background jobs are normally scheduled in the system to ensure that activities are performed properly. To achieve this, specific ABAP programs are scheduled as background jobs via transaction code SM36. You should always have a defined naming convention for background jobs. When you are determining a naming convention, the following elements can be useful:

• Prefix: Indicate if the job contains customer coding (Z) or SAP standard coding (S)
• System/client: Indicate the involved system and client combination (e.g., PRD100)
• Organization: Indicate the involved organizational information, such as abbreviations for regions (Americas, Europe, Asia) or countries (e.g., US, DE, and FR)
• Component: Involved component or application area, such as ARM, EMA, and BRM
• Job description: Specify a speaking name for the job itself –(e.g., SPM_WORKFLOWSYNC)
• Frequency: job frequency, such as Hourly (H), Daily (D), Weekly (W), Monthly (M), Quarterly (Q)

For example, a standard job in the PRD system for client 100 in the United Kingdom for the SPM component for workflow synchronization that runs hourly will look similar to S_PRD100_UK_SPM_WORKFLOWSYNC_H. A meaningful job naming convention is important for finding the correct and appropriate application knowledge for further support as quickly as possible. Also, the job frequency at the end of the job name provides basic insight about the urgency of a background job.

A typical SAP GRC system is made up of the GRC server and a number of connected satellite systems. The satellite systems need to be in sync with the GRC server, so you need to schedule standard background jobs in the SAP Access Control system to synchronize data between the SAP GRC system and the satellite systems. This is designed to ensure data currency and consistency between the SAP Access Control system and the satellite systems. Here are the major master data elements that you need to synchronize in the SAP Access Control system:

• PFCG authorization
• Profile
• Roles
• Users
• Action usage
• Role usage

The implications of failed synchronization jobs can be grave, especially when the currency of data can expose the system to fraudulent activities. For example, if one of the attributes coming from the back-end system drives the approver of an access request, and this information is not in sync with the SAP GRC system, the access request might be routed to the wrong approver—who might approve the access request based on inadequate knowledge of the risk exposure. Similarly, the detective control associated with the review of firefighter logs can be impaired if the background job responsible for collecting firefighting session logs and sending them to the controller fails to execute successfully.

An auditor will be interested in ascertaining that background jobs that drive data synchronization are always executed successfully as scheduled. The sequence of execution of these background jobs is also an important consideration during a technical review. SAP recommends that you adopt the following order when scheduling background jobs in the SAP Access Control system:

• PFCG Authorization: Program GRAC_PFCG_AUTHORIZATION_SYNC
• Repository data (profiles, roles and users): Program GRAC_REPOSITORY_OBJECT_SYNC. Note that you can synchronize the repository data (profiles, roles and users) with programs GRAC_ROLEREP_PROFILE_SYNC, GRAC_ROLEREP_ROLE_SYNC, and GRAC_ROLEREP_USER_SYNC, respectively.
• Action Usage: Program GRAC_ACTION_USAGE_SYNC
• Role Usage: Program GRAC_ROLE_USAGE_SYNC

Other programs that you should schedule as background jobs are:

• Batch risk analysis: Program GRAC_BATCH_RISK_ANALYSIS
• Firefighter logs collection: Program GRAC_SPM_LOG_SYNC_UPDATE
• Firefighter workflow synchronization: Program GRAC_SPM_WORKFLOW_SYNC
• IDM schema update: Program GRAC_SCHEMA_UPDATE
• EAM Master Data: Program GRAC_SPM_SYNC

For the system to operate normally and optimally from a technical perspective, you should schedule some database-dependent administrative background jobs to run at intervals. A technical system auditor should be informed that the required background jobs that are scheduled for different underlying databases. For example, you should execute the following database management-related background jobs for a Microsoft SQL Server database:

• Computing Center Management System (CCMS) blocking database locks statistics
• CCMS check database (DBCC—database consistency checker)
• CCMS update table statistics
• MS SQL COLLECTOR

The status of all these background jobs should be reviewed via transaction code SM37 as part of technical system review activities.

Variants are used to eliminate the need to define the same values in selection criteria fields every time you execute a report. This functionality is designed to reduce both data entry time and system processing time, which makes it common in every SAP system environment. You should also review variants for correctness and currency. Ideally, you should discontinue or adjust variants that are no longer relevant in the system. You can review the entries in table TBTCP to access the currency and relevance of defined variants.

Integration with Back-End Systems

The next major risk is that vulnerabilities and data inaccuracy in the back-end system can impact the operation of the SAP GRC system. The preventive measure you can take is to ensure that appropriate security and data accuracy is enforced in satellite systems.

A typical SAP GRC system is not made up of just the SAP GRC box alone; rather, it contains other back-end systems such as SAP ERP, SAP SRM, SAP NetWeaver Portal, or Microsoft Active Directory. These back-end systems play different roles in the system landscape. In some cases, the SAP GRC system is used to provision access to the back-end system, or the back-end system is used as the data source for user authentication and user details in SAP Access Control. The seriousness to be accorded the SAP Access Control system in terms of system review should also be given to the back-end system.

This is important because security breaches in any of the dependent back-end systems can have an impact on the integrity of the SAP Access Control system. For example, if the SAP ERP HCM system is designed as the source of user details (e.g., personnel area) that drives the assignment of the approval agent, and the data maintained in the SAP ERP HCM system is not accurate, an access request can be routed incorrectly (even though the configuration of the logic in SAP Access Control is correct).

Therefore, a system auditor naturally wants to gain assurance that systems connected to the SAP GRC system are performing their role as intended in terms of functionality delivery and data accuracy. If the SAP ERP HCM system is the source of a mandatory field in access request and SAP ERP HCM is unavailable, the implication is that the SAP Access Control system is unavailable because it also will not be useful for access provisioning.

Performance Optimization

A major performance risk is slowness or unavailability of the system. To prevent this, you must create appropriate and optimal configuration settings and parameterization. It is important to perform preliminary sizing before the implementation of the SAP Access Control solution. This is to ensure that you have an idea of the hardware requirements, including disk size, network bandwidth, physical memory, CPU processing power, and I/O capacity based on the business requirement and environment. There should be an IT-balanced scorecard designed to measure IT performance. If you do not define empirical performance indicators, senior management might be misled on the true implications of performance impairment.

Here are some examples of indicators to measure the optimal performance of your SAP Access Control system:

• System performance: The number of active users, maximum dialog steps per hour, average response time in a dialog task, average response time at peak dialog hour, average response time in an RFC task, average RFC response time at peak work hour, and maximum number of RFCs per hour
• Hardware capacity: Maximum CPU utilization on database server
• Database performance: Average database request time in update task, average database request time in dialog task, and average database time in RFC
• Database space management: Database size and growth over a defined period

Broadly, the performance of the SAP Access Control system is dependent on the following:

• Master data volume
• Transaction data volume
• Configuration settings (customizing)
• Number of concurrent users
• Size of the system landscape (number of systems and available system resources)

The reality of the business environment can also have an impact on performance—for example, the average number of permission level violations per object, the total number of access risk and rules, and the complexity of the approval workflow process. The measurement of optimal system performance requires technical skills and standard tools such as SAP Solution Manager. The ability to interpret standard performance-related reports and indicator settings is very useful. For example, if you have an average CPU load that is more than 90 percent, a system reviewer should be able to deduce that this represents an adverse CPU problem.

The performance of SAP Access Control can raise serious audit questions. Even though performance management sounds more like a technical requirement, if performance is degraded, it can lead to system unavailability and consequently affect functional use of the application.

The period of downtime might represent a window to perpetrate malicious activities, especially when there are no adequate processes and controls in place to address the challenge. Therefore, a system auditor will be interested in ascertaining that the basic configurations that can enhance system performance are in place. For example, if the configuration option Enable Offline Risk Analysis is set to Yes, the tables holding the action and permission level details for all risk analysis performed will be parsed. It can become very large (i.e., millions of records) and significantly affect your system performance adversely.

As I asserted earlier, configuration settings can influence system performance. This makes the review of configuration settings an important activity during system review. An example is the exclusion of users and critical roles. This is to ensure that risk analysis runs completely and successfully in a suitable amount of time, without significantly affecting system resources. I acknowledge that system resources differ from one installation to another; however, unless there is specific need to act otherwise, it is a best practice to:

• Set the default user type for risk analysis to DIALOG – Parameter 1026
• Include locked users (Parameter 1031), include expired users (Parameter 1028), and include mitigated risks (Parameter 1030) should be set to NO.
• Set ignore critical roles and profiles to YES – Parameter 1031

You can perform the aforementioned configurations parameters in configuration settings by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain Configuration Settings.

You also need to execute some administrative background jobs to ensure that the system perform optimally. An example of a background job is report RSBTCDEL (delete batch job). You must schedule this job in the system to ensure that the spool object and obsolete jobs are deleted in the system. For more information on this program and other standard background jobs (e.g., standard jobs or reorganization jobs), consult SAP Note 16083.

Another performance-related configuration is the definition of the index for fields MANDANT, UTIME, UDATE, and USERNAME in table CDHDR, as shown in Figure 25. This ensures that performance is not impeded during firefighting session report generation. SAP Note 1039144 provides information on how to create this index. To improve the performance of the reporting tool for emergency access management, you must index the fields MANDANT, UTIME, UDATE, and USERNAME of table CDHDR as recommended in SAP Note 1741151.

Another area of technical interest is the management of memory in the SAP Access Control system. This phenomenon is an audit interest because if your hardware cannot optimize the maximum memory consumption, you will have memory-related problems and consequently impaired system performance. In most cases, the default settings of memory-related parameters are not optimal. The following profile parameters should be reviewed via program RSPARAM in transaction code SE38 for adequacy:

• abap/heap_area_dia (limit of heap memory per dialog work process)
• abap/heap_area_nondia (limit of heap memory per non-dialog work process)
• abap/heap_area_total (limit of heap on application server)
• em/initial_size_MB (initial size of extended memory pool)
• abap/buffersize (program buffer size)

Missing Indexes

Another major risk is the possibility of data inconsistencies. To prevent this, simply make sure that there are no missing indexes. Indexes are important objects in the management of database systems. It is essential that there are no missing indexes at the database level of the SAP Access Control system. Because tables in the SAP environment are so large, data is often accessed via indexes to enhance system performance. The concept of missing indexes can present an audit concern, especially because it can lead to data inconsistences in the system. You can review missing indexes via transaction code DB02.

Business Continuity and Disaster Recovery

Data loss or inability to continue business operation in the event of a disaster is another risk. To prevent this, ensure that an appropriate business continuity plan and disaster recovery plan exist and are tested at defined intervals.

The impact of the unavailability of the SAP GRC system should be analyzed at some point. Appropriate plans should exist to counter possible unavailability issues with the system in the SAP Access Control landscape, both planned and unplanned. When developing a disaster recovery plan, you need to perform a business impact analysis to ascertain the implications of the unavailability of the SAP Access Control system in terms of qualitative and quantitative measures. For example, in a global implementation, what is the implication of not being able to provision emergency access for the sales team when needed? You can quantify the financial loss implications and help to advise an optimal countermeasure.

Adequate and effective backup and restore strategies must exist to ensure business continuity.

This strategy must be tested periodically to ensure that there are no disappointments when you restore the system. Usually, a system auditor will be interested in reviewing the back-up log directly in the system via transaction code DB12. Figure 26 shows the backup log history with return code 0000, which shows that the backup was successful for the period shown.

A technical review should also cover storage of backup media and other conventional  backup and recovery audit concerns.

Time Zone Setting

The major risk here is that the difference in time zone is capable of affecting log collection, which consequently affects correct reporting of firefighting session activities in the satellite system. The result is erosion of the detective control capability. The preventive measure is to ensure that the time zone of the operating system and the SAP NetWeaver engine are in sync in the SAP GRC system and the satellite systems.

The output of some of the log reports generated for EAM is based on the input in transaction code STAD (SAP Workload: Business Transaction Analysis) in the plug-in system. The reports in transaction code STAD are based on operating system time. Therefore, it is important that the time zone of the operating system and the SAP NetWeaver system be in sync.

If the time zone of the operating system and the SAP NetWeaver system are not the same, there is a possibility that Emergency Access Management log reports will show no records when executed—even though log data actually exists. Consequently, an auditor will be interested in ascertaining that the appropriate operating system time zone setting is maintained in the SAP GRC system and the back-end system. It is a best practice to have the same setting for:

• The time zone of the operating system and the SAP NetWeaver system in the SAP GRC system
• The time zone of the operating system and the SAP NetWeaver system in the plug-in system (e.g., SAP ERP system)

However, the time zone setting of the SAP GRC system and the plug-in system do not necessarily need to be the same. You can check the time zone setting of the SAP NetWeaver system via report TZONECHECK (Check Time Zone Data for Consistency), as shown in Figure 27.

To maintain the time zone settings in your SAP NetWeaver system, start by entering transaction code STZAC in the command line. Figure 28 displays with a dialog box.

Click the Yes button. In the screen that appears, maintain the values for the System Time Zone and User’s Default Time Zone fields (Figure 29). Also, activate the time zone setting by selecting the Times Zones Active check box. Click the save icon  and restart the instance to activate the new time zone setting.

Documentation

The last major risk is that a knowledge gap may exist related to system design, configuration, and operational activities, which can consequently impact the optimal support of the system. To prevent this, ensure that documentation deliverables are agreed upon at the project’s inception and consequently approved by senior management.

Documentations are an integral part of any business solution delivery, serving as part of the knowledge transfer requirement. As part of a comprehensive system review process, it is expected that documentation related to the project is assessed for completeness and correctness. These documentations are designed to serve as a reference guide on the build, design, and operation of the business solution.

Ideally, there should be documentation related to the technical installation, blueprint and system design, support and operation guide, security and authorization design, testing materials, and user guide. More importantly, these documents must be approved by a designated individual with at least one representative from senior management or the project steering committee. This goes a long way toward demonstrating management commitment to the project.

Also, when changes are made to these documents at different stages of the project life cycle, you need to approve and version these changes accordingly. Review the security of where the documents are stored to gain assurance that they cannot be tampered with. This document management capability can be harnessed via SAP Solution Manager.