How to Prepare for a ComprehensiveSystem Audit and Technical Reviewof SAP Access Control 10.0by Kehinde Eseyin, Senior SAP GRC Consultant, TurnkeyConsulting Ltd.October 28, 2013

SAPexperts/GRCLearn invaluable tricks and tips for overcoming topauditing issues specific to an SAP Access Control 10.0system.

Learning Objectives

By reading this article you will be able to:

Identify the areas of SAP Access Control that can causeconcerns during an audit of SAP Access Control

Understand the strategies and best practices to preparefor an audit of SAP Access Control

Maintain segregation of duties (SoD) rule sets andworkflow

Key Concept

A system audit is an exercise performed to gain assurancethat defined controls work as intended, thereby eliminatingthe likelihood of fraudulent or malicious activities in theenterprise system. It involves the verification of conformanceto policies and procedures through acute review of objectiveand empirical evidences. The review of the SAP AccessControl 10.0 system is usually performed pre- and post-go-live, as well as on an ongoing basis to ensure continuouscompliance. An SAP system audit normally involveschecking the controls defined in the system against what isdefined in the security policies of an organization.

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

SAP Access Control runs on the standard SAP ABAPframework with an optional SAP Java infrastructure that canbe integrated with other SAP and non-SAP systems.Therefore, the conventional audit and technical reviewapplicable to other SAP system landscapes applies to SAPAccess Control.

However, in this special report, I focus on the core capabilities

of the SAP Access Control system and the areas that canpresent audit concerns during a system review. I also exploreboth functional and technical areas that, if not properlymanaged, can expose SAP Access Control to threats andvulnerability.

After an overview of the necessities for a thorough systemreview, I discuss top strategies and best practices that youcan adopt to gain insight into different control objectives asthey relate to the audit of SAP Access Control, including thefollowing topics:

Technical installation validationActivation of Internet Communication Framework (ICF)servicesDefinition and maintenance of the segregation of duties(SoD) rule setWorkflow maintenanceChange request managementData archivingAuthorization management of technical usersFirefighter ID log-in prohibitionManagement of SoD role authorizationBackground job administration and monitoringIntegration with back-end systemsPerformance optimizationMissing indexesBusiness continuity and disaster recoveryTime zone settingDocumentation

The Importance of a SystemReview

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

The objective is to highlight specific controls that should be inplace to safeguard the infrastructure on which the user accesscontrol compliance tool of an organization rests. This isimportant because users (e.g., employees, both permanentand contract) can expose the system to malicious activitiesand events through their actions or inactions, which can havea negative impact on your enterprise’s business operation.Therefore, the application used to control user access tosystems needs to be foolproof.

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

cases.

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

The SAP Access Control tool offers functionality to addressfour broad areas of access provisioning and usermanagement; namely, Access Risk Analysis, Access RequestManagement, Business Role Management, and EmergencyAccess Management. These areas present different risk levelsto the access control infrastructure that should be mitigated byadequate compensating configuration controls and bestpractices.

The SAP Access Control system is designed to addressaccess control risk issues in the areas of risk detection, riskremediation and mitigation, risk prevention, and risk reporting.Therefore, you should adopt a risk management approach toevaluate the threats, vulnerability, and risk implications of acompromise of any kind to implemented controls in yoursystem.

Technical Installation Validation

A major risk during technical installation is that the systemmight be error prone and unusable. The preventive measuresyou can take include ensuring that the systems run the correctsoftware components and that the current support package orpatch level is installed.

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

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

The software for SAP Access Control 10.0 is bundled withProcess Control and Risk Management in the add-onGRCFND_A V1000 (GRC Foundation). You must install thiscomponent on the SAP GRC server. You also need to installtwo plug-ins, GRCPIERP and GRCPINW, on the back-endsystem that connect to the GRC system. The specificcomponent of the plug-in component installed depends on theSAP Basis version of the back-end system.

The back-end system can also be the SAP GRC system;however, the GRCPIERP software component requiresSAP_ABA and SAP_HR software components. An importantaudit concern with the installation of the SAP Access Controlfoundation software component and the plug-in softwarecomponent is that they must be on the same Support Packagelevel. The need to have the SAP GRC foundation componentand the plug-in component on the same Support Packagelevel is still relevant for systems with less than SupportPackage 10.

Suffice to say that backward compatibility is in place fromSupport Package 10. The backward compatibility adherenceimplies that you can upgrade the Support Package level of theGRCFND_A V1000 software component without necessarilyupgrading the back-end plug-in software components—GRCPIERP and GRCPINW—as long as the minimum SupportPackage level is 10. Therefore, a technical system reviewerwill be interested in gaining assurance about this consistencyand synchronization requirement with the Support Packagelevels of the foundation components and plug-in components.

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

I recommend that you extend this to confirm if the SAP kernelis up to date. The SAP kernel is a core component (databasedependent and database independent) of the SAP engine thatcontains the executable files (i.e., .exe files) used to startdifferent processes. The patching of the system should not belimited to only the SAP components; you must also patch theunderlying database system.

I recommend that you also extend a technical review to gainassurance that other relevant software components areinstalled, especially as part of the post-installation validationactivity. For example, if you need to generate a PDF-basedreport, you need to have Adobe Document Service (ADS) setup in the Java instance connected to the ABAP system onwhich the SAP GRC system runs.

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

Figure 1

The initial screen of the Support PackageManager

Figure 2

Support Package levels for different softwarecomponents

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

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

Figure 3

SAP system status and information

Figure 4

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

Kernel information

Activation of ICF Services

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

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

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

The system review interest for the system auditor is to checkthat the system is not exposed to external vulnerabilities as aresult of the activation of unnecessary ICF services. Youshould review activated ICF services to ensure that a loopholecapable of introducing threats and vulnerabilities to the systemlandscape does not exist. Typically, SAP recommends thatyou activate all ICF services within the following ICF servicenodes 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 isimplemented. You must adequately control the authorizationassigned to the user in the system.

Definition and Maintenance ofSoD Rule Set

The major risk is that access risk violations might beunderreported or overreported. As a preventive measure, youcan ensure that SoD and sensitive access rule sets reflect theapproved risk perception of the enterprise.

Auditors usually want to be assured that the SoD rule set iswell defined and properly maintained. The SoD rule set is agroup of data elements that collectively form the segregation ofduties risks and sensitive access risks in an enterprise system.It is the basis for risk analysis in an enterprise system. SAPstandard SoD rule sets are fashioned after best practices for

risk analysis based on optimal SoD in SAP and non-SAPsystems.

The SAP Access Control system comes with predelivered SoDrule sets that you can make available in the system byactivating the appropriate business configuration (BC) setsusing transaction code SCPR20. For the SAP system, thestandard rule sets are targeted at specific softwarecomponents (for example, SAP ERP Human CapitalManagement [SAP ERP HCM] or SAP Customer RelationshipManagement [SAP CRM]). BC sets related to SoD rule sets inthe SAP Access Control system include the following:

GRAC_RA_RULESET_COMMON—SoD rules setGRAC_RA_RULESET_JDE—JDE rules setGRAC_RA_RULESET_ORACLE—Oracle rules setGRAC_RA_RULESET_PSOFT—PeopleSoft rules setGRAC_RA_RULESET_SAP_APO—SAP AdvancedPlanning & Optimization (APO) rules setGRAC_RA_RULESET_SAP_Basis—SAP BASIS rulessetGRAC_RA_RULESET_SAP_CRM—SAP CRM rulessetGRAC_RA_RULESET_SAP_ECCS—SAP EnterpriseControlling Consolidation System (SAP EC-CS) rulessetGRAC_RA_RULESET_SAP_HR—SAP ERP HCM rulessetGRAC_RA_RULESET_SAP_NHR—SAP R/3 less HRBasis rules setGRAC_RA_RULESET_SAP_R3—SAP R/3 AC rulessetGRAC_RA_RULESET_SAP_SRM—SAP SupplierRelationship Management (SAP SRM) rules set

During post-installation activities, you activate only the BC setsthat you need. As part of the technical system review, youneed to review the activation log generated after the activationof BC sets for specific SoD rule sets to ensure that there wereno errors that could lead to data inconsistencies as a result ofthe BC set activation. To review the activation log generatedduring the activation of a BC set, execute transaction codeSCPR20.

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

Figure 5

Define a BC set in the initial screen for BCset activation

Figure 6

Timestamp for BC set activation log

Figure 7

Detailed log of BC set activation for an SoDruleset

Click the activation log icon . In the next screen, you can seethe activation logs grouped by an activation timestamp (Figure6).

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

It is important that errors are not reported or generated duringthe activation. If an error is generated, it can lead to datainconsistencies. You can review warning messages forappropriateness and ignore them if they do not represent acatastrophic event.

NoteIf you have an existing SoD ruleset that has been validated

and operational, you do not need to perform this post-installation task and therefore the review of the SoD rulesetBC set activation log is not applicable.

It is not sufficient to simply activate the BC set containing thestandard SoD rule set. The standard rule set may notnecessarily be fit for the purpose, and therefore, needs to bemaintained and validated by appropriate personnel. Thevalidation of the rule set normally involves the review ofdependent master data elements of a SoD rule set, such asrisks and functions (actions and permissions).

The purpose of the review of the SoD rule set content is togain assurance that the content of the rule set is correct and aprecise representation of the risk appetite and the perceptionof enterprise access risks. The review of rule set contentneeds to be very detailed to address not only the associatedtransaction codes (i.e., actions) but also the correctness of theabsolute value defined for the corresponding authorizationobjects. For example, in the definition of authorization objectvalue, 1 is not synonymous to 01.

In the same vein, the use of the value asterisk (*), forexample, does not equal any value. Rather, it means * itself.Therefore, if you want to make a permission definitionapplicable 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 optionis to use the value $.

You also need to check that the operators (AND, OR, andNOT) used in the rule set definition are properly defined. Themaintenance of the wrong value might not necessarily causean error message, but it affects the reporting of access risksbecause you are underreporting or overreporting, as the casemay be. Furthermore, adequate understanding of the operatoris important because most users are quick to misunderstandthe reporting output of the operators. For example, when theNOT operator is used in permission-definition logic, it reportsusers that have any value except the value in the rule—notthe users who do not have the value defined.

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

You should not maintain a high access risk element asmedium. This is because the risk levels can have seriousimplications in the analysis of the access risk exposurereporting to management, especially as it relates to selectioncriteria definition. Furthermore, the incorrect maintenance ofrisk levels can lead to the failure of configured controls andthe incorrect evaluation of Business Rule Framework plus(BRFplus) business rules. For example, if you define abusiness rule using the request mitigation access controlapplication to enforce the mitigation of an access risk leveldefined as high, but the attribute (i.e., risk level) of the

dependent master data (i.e., access risk) is incorrectlymaintained, the result is control ineffectiveness because thebusiness logic does not evaluate correctly.

NoteThe quick tip “Seamlessly Configure Request MitigationPolicy Rules in SAP Access Control 10.0” defines thestrategy for configuring request mitigation policy rules basedon access risk attributes, such as access risk level.

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

This assertion gives credence to the fact that the access riskissues associated with custom transactions should be treatedseriously and included in the SoD rule set. You shouldapproach the business process owner of the customtransaction code to gain an understanding of the associatedrisks of the custom transaction code and then analyze it forSoD violation possibilities.

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

NoteThe article “Update the SAP BusinessObjects AccessControl Rule Set with Custom Transactions” by SelvaKumar, vice president, Auditbots, defines the technicaldetails of the inclusion of custom transaction codes in theaccess control SoD rule set.

The maintenance of an SoD rule set is a continuous processaimed at ensuring that the rule set is a true reflection of therisk exposure of an enterprise at any point in time. One of thecontrol objectives of the technical review of the SAP system isthe existence of an effective policy and procedure ensuringthat changes to the access rule set are made in a controlledmanner. This should cover adherence to best practices ofapproving changes before the changes are moved to theproduction environment from pre-production systems.

This requirement is discussed in detail under the “ChangeRequest Management” section. You can perform themaintenance of an access rule set directly in the back-endsystem (IMG of the access control) or via the front end (SAPNetWeaver Business Client [NWBC]). Because of thesensitivity and criticality of SoD rule set data, it is important to

Figure 8

Change log setting for function and risk

ensure that the authorization to maintain the rule set data iscontrolled as much as possible.

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

Download SoD Rules: This allows you to download arule set using the programGRAC_DOWNLOAD_ACCESS_RULESUpload SoD Rule: This allows you to upload an SoDrule set using the programGRAC_UPLOAD_ACCESS_RULEGenerate SoD Rule: This allows you to generate anSoD rule set after an SoD rule set upload or transportusing the programGRAC_GENERATE_ACCESS_RULEDelete SoD Rule: This allows you to delete specificSoD rule set data via the programGRAC_DELETE_ACCESS_RULES. Another programyou can use to delete an SoD rule set isGRAC_DELETE_ACCESS_RULES_ALL, but thisprogram should be used with utmost care as it cleansup all SoD rule set-related master data from thesystem.Transport SoD Rule: This activity allows you totransport an SoD rule from the development system tothe destination systems. The maintenance of the ruleset should be treated as a transportable activity toensure adherence to change control best practices.

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

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

To display the corresponding parameter settings for thechange log, follow menu path SPRO > SAP Reference IMG >SAP Customizing Implementation Guide > Governance, Riskand Compliance > Access Control > Maintain ConfigurationSettings. Figure 9 shows a sample change log for a function

Figure 9

Change log report for a function

Figure 10

The process global settings phase in MSMPworkflow configuration

that reports on the change type, timestamp, old value, andnew value.

Furthermore, you can activate workflow as part of yourstrategies to ensure that risk and functions that are an integralpart of the SoD rule set go through the appropriate approvalrequirements before changes are successfully made. This iscontrolled by the Function Approval workflow(SAP_GRAC_FUNC_APPR) and Risk Approval Workflow(SAP_GRAC_RISK_APPR) processes, which you can maintainin the Multi-stage Multi-path (MSMP) Workflow Process wizardmaintenance screen (Figure 10). To access this screen usetransaction code grfnmw_configure_wd.

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

Following are some of the dependent configuration parametersthat can influence workflow settings for risk and functionsmaintenance in the SAP Access Control system:

Parameter 1062: Risk MaintenanceParameter 1064: Function MaintenanceParameter 1101: Create Request for Risk ApprovalParameter 1102: Update Request for Risk ApprovalParameter 1103: Delete Request for Risk ApprovalParameter 1104: Create Request for Function ApprovalParameter 1105: Update Request for Function Approval

Parameter 1106: Delete Request for Function Approval

NoteThe quick tip “2 Options for Maintaining Rule Sets in SAPAccess Control 10.0” by Alpesh Parmar, managing partner,ultimumIT Inc., in the SAPexperts GRC hub provides insightinto the different approaches to maintaining an SoD rule set.

Workflow Maintenance

Another major risk is that an approval request might not betreated in a timely manner and by the correct approver. Thepreventive measure you can take is to ensure that theworkflow mechanism is properly configured and the approvermaster data is properly maintained.

To use the workflow capability of the SAP Access Controlsystem, it is necessary to perform a few post-installationactivities. These include:

Automatic workflow customizingTask-specific customizing

Following the execution of these workflow-relatedcustomizations, you need to gain assurance that the workflowengine is working. To do this, perform a workflow verificationactivity. Follow the steps below to gain preliminary assurancethat the workflow engine is working properly.

NoteThis section does not explain how to execute the differentcustomizing activities. Refer to the appropriatedocumentation on the Service Marketplace on how toperform the different workflow activation tasks.

Enter transaction code SWU3 in the command line. In thescreen that appears, click the start verification icon (Figure11).

Figure 11

The initial screen for automatic workflowcustomization

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

Figure 12

Start of workflow verification notification

Figure 13

Business workplace inbox

Figure 14

First step in workflow verification

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

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

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

Figure 15

Inbox folder showing the status of theworkflow verification in the message body

Workflow is designed to ensure that activities within thesystem are properly reviewed and approved by the designatedindividuals before changes are made to specific information orprocesses. This can include granting access to users orchanges to master data, such as functions or assignment ofmitigating controls to users and roles. The auditor’s interest ina workflow process is who the actor (i.e., approver) is. Thisaudit concern is important because the appropriate user mustbe set up in the system to ensure that the correct personperforms the required responsibility. The approver must bereviewed for correctness and currency at defined intervals. Inthe context of SAP Access Control, the approvers are knownas agents. Broadly, agents can act as approvers and asnotification recipients of workflow-related events.

NoteThe approver can be correct, but not current (e.g., in theapprover-delegation relationship). A delegate can be correctas an approver, but not current.

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

Directly mapped users: The agents are determinedbased on a defined list of approvers who are associatedwith an approver group ID.Transaction code PFCG roles: The agents aredetermined based on the assignment of a specificPFCG role.PFCG user group: The agents are determined basedon their assignment to a defined user group on thegroups tab of the user master data (transaction codeSU01).GRC Application Programming Interface (API) rules:The approvers are determined based on business rulesdefined via any of the rule types (i.e., BRFplus,

Figure 16

Approval delegation table

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 forcorrectness and currency at specific intervals. Adequateprocedures and policies must guide the process of makingchanges to the agent master data. The change managementprocess should be leveraged as much as possible whenchanges are made to the agent master. Refer to the “ChangeManagement” section later in this article for more informationabout enforcing effective change management best practices.

Another audit concern is how the delegation of authority ismanaged within the enterprise. The approval delegationcapability is laudable because it allows another user to act inthe primary approver’s capability for a defined period of time,usually during a vacation. As a best practice, it is ideal foractors (e.g., approvers) in a business process to beunavailable over a period of time. It is a management strategyto prevent fraud and identify lapses in the business process asa result of the unavailability of the principal actor. It is commonto see individuals who are supposed to be approversdelegating their approving rights to their subordinates withoutany genuine reason.

Ideally, approving responsibilities should be delegated inspecial situations when the main approver is not available toact on an approval request. Figure 16 shows a typicalapproval delegation table. You can display the approvaldelegation table by following menu path NWBC: AccessManagement > Access Requests Administration > AdminDelegation.

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

The technical review should cover the delivery of notificationmessages to intended recipients. This is to ensure that agents(not necessarily the approvers) are only notified aboutapproval events that have taken place. This is important incertain circumstances. For example, a group of users mightneed to know about the access provisioning activities ofspecific access request attributes in order to perform specificfollow-on activities outside of SAP Access Control, such as

Figure 17

Define settings for the SMTP node ofSAPconnect

manual maintenance of data in non-SAP systems.

Also, notifications ensure that users are informed aboutpending approval decision requests in their inboxes on time toprevent unnecessary delays. To facilitate the sending ofemails, 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 inthe system over a period of time, use transaction code SOST(Figure 18). You need to review the entries in the tableappropriately to ensure that email messages are not goingunnoticed.

Figure 18

Monitor the status of email messages

Furthermore in an environment in which email messages mustbe sent to users as part of the configured process flow orbusiness requirement, the technical review should makeprovision for checking that all users have their emailaddresses maintained accordingly — for example, intransaction code SU01 where the SAP system is the datasource of the user email address attribute.

Change Request Management

Another major risk you could encounter is data andcustomization setting inconsistencies that make the systemerror prone. To prevent this, you can enforce control in thepromotion of changed data or customizations across thesystem landscape by avoiding performing customizingactivities directly in the production system.

You must configure the system landscape of the accesscontrol system to adhere to at least the three-systemlandscape, typically made up of the development, qualityassurance, and production systems. It is possible to include atest system to enforce additional control in the systemlandscape.

Figure 19 shows a typical transport route for a three-systemlandscape. The transport route diagram provides assurancethat the three-system landscape is configured and that anauditor can check it by following menu path transaction codeSTMS > Overview > Transport Routes. An auditor will beinterested in ascertaining that all configuration changes,

Figure 19

Transport route for a three-systemlandscape

Figure 20

including master data (rule sets and BRFplus rules such aslogic and master data, approvers, or user defaults) are testedbefore the changes are promoted to destination or subsequentsystems in the landscape.

This architecture discourages people from makingmodifications directly in the production system. You shouldconfigure the production system in such a way that directmodification in the production environment is impossible. Youcan review production client settings for appropriateness viatransaction code SCC4.

As I stated earlier, all transportable configuration and masterdata must be transported across the system landscape. Thisincludes the BRFplus application. BRFplus is at the heart ofthe SAP Access Control system and drives the behavior of thebusiness workflow process. To make BRFplus applicationstransportable, you first need to create a development packagevia transaction code SE21, which is consequently associatedwith the application. Note that BRFplus applications created aslocal objects cannot be transported. Figure 20 shows aBRFplus application created as a local package with theTransport button grayed out (therefore, it is not transportable).

A BRFplus application created as localobject and not transportable

Figure 21

A BRFplus application created as atransportable object

Figure 21 shows a development package (ZGRAC)associated with a BRFplus application with the Transportbutton active and therefore transportable.

A number of master data items cannot be transported in SAPAccess Control. They include reason codes, access controlowner’s definition, coordinators, and firefighter master data.You should use the authorization concept in conjunction withthe SoD concept to enforce control in the management ofnon-transportable master data. You should also review thismaster data on a periodic basis for currency and correctness.Furthermore, when there is a change request, a controlprocess must be in place that objectively reviews the impactof such changes on all dependent business processes andend users. You should also secure the development andquality assurance systems appropriately. A defined securitypolicy should address access rights, modification, and datacomposition of the non-production systems.

Data Archiving

When you are archiving data, there is a potential risk thatsystem performance might be impaired and data retentionpolicies might be flaunted. As a preventive measure, you canarchive data at defined intervals based on corresponding

regulations.

In a typical organization, aside from business requirementsand corporate policies, prevailing legal and regulationrequirements influence data retention strategies adopted by anenterprise. Further, data archiving has a laudable implicationas it relates to enhancing system performance. These reasonsmake the issue of data archiving an important technicalsystem review concept. SAP Access Control providesstandard archiving objects you can use to archive specific datain the system.

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

GRFNMSMP—Archiving for SAP Access Control 2010 requestsSPM_AU_LOG—SPM audit log archiveSPM_CH_LOG—Change log archiveSPM_LOG—Archiving for SPM log reportingSPM_OC_LOG—SPM OS command log archivingSPM_SY_LOG—SPM system log archival

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

NoteSAP Note 1719967—How to archive in GRC Access Control10.0 provides step-by-step instructions on how to archiveobjects in SAP Access Control 10.0.

Authorization Management ofTechnical Users

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

To operate SAP Access Control normally, you need to createsome 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 AccessControl system landscape is made up of the SAP AccessControl system itself and dependent back-end systems (e.g.,SAP ERP or SAP SRM). To establish communication betweenthe SAP Access Control system and the back-end systems,

Figure 22

User assignment to an RFC destination

you need to set up an RFC connection (connector) betweenthese systems via transaction code SM59.

The type of back-end system typically determines the type ofRFC destination. For example, to connect to an ABAP-basedsystem, you need to create an RFC of type 3 (ABAPconnection). On the other hand, to connect to SAP NetWeaverPortal, you need to create an RFC of the type G (HTTPconnection to external server). Normally, RFC destinationsneed a user account that is used to authenticate the call to thedestination system. Figure 22 shows a user assignment to theRFC destination of the ABAP connection type.

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

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

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

NoteSAP Note 1251255 provides information about authorizationmanagement for the WF-BATCH user.

The system audit should cover the review of the authorizationassigned to technical users, especially the RFC user and theworkflow user (WF-BATCH). Under no circumstance shouldyou assign the SAP_ALL profile (or its flavor) to thesetechnical users.

Firefighter ID Login Prohibition

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

Firefighting refers to the act of using privileged user accountsin times of emergency. This functionality is one of the mostimportant capabilities of SAP Access Control, as it seeks tocontrol the assignment of excessive authorization (includingSAP_ALL) to users. SAP Access Control allows a user tofirefight using either the firefighter ID strategy or a role-basedstrategy.

NoteIn the webinar Role- or ID-Based Firefighting: Which OptionIs Best for Your SAP Systems Landscape?, I describe anumber of concepts that you should consider when decidingon the firefighting strategy to adopt in an enterprise. Viewthe webinar

00:00

00:00

Figure 23

Dialog box confirming the prohibition ofdirect login with a firefighter ID

Role- or ID-Based Firefighting: Which Option Is Best forYour SAP Systems Landscape?

.

With the firefighter ID strategy, the ID is the user with elevatedprivileges allowing them to perform a firefighting session in thesystem. The firefighter ID is typically identified via theassignment (in the back-end system) of the role maintained inparameter 4000 in the SAP GRC system. You should log theactivities performed by a firefighter ID and enhance theprocess to send these logs to a controller via workflow forreview and approval.

Because the firefighter ID possesses elevated privileges, itshould not be used directly in the system. Instead, it shouldbe used via the assigned firefighter user. To enforce controlaround the use of the firefighter ID directly in the back-endsystem, you can implement a user exit in the back-end systemwhere the firefighter ID resides. The user exit prevents thefirefighter 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 userexit has been implemented if dependent configuration settings(SPM application type and FFID role name in the plug-insystem and the SAP GRC system) are not yet maintainedappropriately or if the plug-in software component level inSAP GRC differs from that of the back-end system. Therefore,the best way to review if this user exit has been implementedis to execute a test that attempts to log in directly to the back-end system using a firefighter ID. This action should triggerthe display of a dialog box as shown in Figure 23.

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

Segregation of Duties

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

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

It is a best practice to form a set of incompatible SoD matricesfor the SAP Access Control system (i.e., SAP Access Controlitself should have a set of activities that are segregated). Forexample, when a user who creates a function (a component ofan access risk) is also the approver of the function, controlbecomes a serious issue because this compromises the entireprocess of SoD rule maintenance. In the same vein, internalcontrol can also be a huge audit concern if the person whocreates a mitigating control can also maintain the mitigatingcontrol or assign the mitigating control to users or roles.Therefore, it is important for a system auditor to be assuredthat responsibilities are adequately segregated in the SAPAccess Control system and performed with a sense ofindependence.

SoD control is closely interwoven with user management,especially as it relates to roles and profile assignments. Atechnical review should seek to establish that the authorizationassigned to specific job roles is optimal and does not create aconflict that is unmitigated.

A number of standard configurable controls are designed toenforce SoD. These configuration settings should be reviewedfor correctness and appropriateness. Examples are:

The approver cannot approve his own requestThe firefighter ID owner can submit a request for afirefighter ID ownedThe firefighter ID controller can submit a request for afirefighter ID controlled

NoteEvery firefighter ID has an owner and controller. The owner

Figure 24

EUP setting for Approve/Reject OwnRequests

maintains the ID and approves the assignment. Thecontroller reviews the log associated with the firefighter ID.

The approver cannot approve his own request. This isconfigured in the customizing activity in which you canmaintain End User Personalization (EUP) fields by followingmenu path SPRO > SAP Reference IMG > SAP CustomizingImplementation Guide > Governance, Risk and Compliance >Access Control > User Provisioning > Maintain End UserPersonalization. Figure 24 shows an example of a typicalsetting to prevent the approver from approving his or herrequest.

You can assign the EUP setting to an approval stage in theMSMP workflow customizing to influence the behavior ofdifferent stages in a workflow path.

Following is an explanation of the parameter settings forscenarios in which the firefighter ID owner submits a requestto access an owned firefighter ID, and in which a firefighter IDcontroller submits a request to access a controlled firefighterID:

The firefighter ID owner can submit a request for afirefighter ID owned: When parameter 4013 is set to no,it disallows a firefighter ID owner from submitting anaccess request for a firefighter ID for which he is theowner. To set this parameter, follow menu path SPRO> SAP Reference IMG > SAP CustomizingImplementation Guide > Governance, Risk andCompliance > Access Control > Maintain ConfigurationSettings.

The firefighter ID controller can submit a request for afirefighter ID controlled: When parameter 4014 is set tono, it disallows a firefighter ID controller from submittingan access request for a firefighter ID for which he isthe controller. To set this parameter, follow the samemenu path referenced above.

If you cannot adequately segregate duties, the auditor shouldseek to gain assurance that effective compensating controlsare in place. This might be the case when there are certainconstraints, such as organizational structures an inadequatenumber of employees.

Background Jobs Administration

and Monitoring

When you are considering background jobs administration andmonitoring, a major risk is data inconsistencies between theSAP GRC system and the satellite system. In addition, smoothrunning of the system might be affected if administrativebackground jobs are not scheduled and executed successfully.As a preventive measure, you can schedule (in the correctorder) and monitor background jobs for successful completion.

Background jobs define programs or a collection of programsthat are executed by background work processes. Variousbackground jobs are normally scheduled in the system toensure that activities are performed properly. To achieve this,specific ABAP programs are scheduled as background jobs viatransaction code SM36. You should always have a definednaming convention for background jobs. When you aredetermining a naming convention, the following elements canbe useful:

Prefix: Indicate if the job contains customer coding (Z)or SAP standard coding (S)System/client: Indicate the involved system and clientcombination (e.g., PRD100)Organization: Indicate the involved organizationalinformation, 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 BRMJob description: Specify a speaking name for the jobitself –(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 100in the United Kingdom for the SPM component for workflowsynchronization that runs hourly will look similar toS_PRD100_UK_SPM_WORKFLOWSYNC_H. A meaningfuljob naming convention is important for finding the correct andappropriate application knowledge for further support asquickly as possible. Also, the job frequency at the end of thejob name provides basic insight about the urgency of abackground job.

A typical SAP GRC system is made up of the GRC server anda number of connected satellite systems. The satellite systemsneed to be in sync with the GRC server, so you need toschedule standard background jobs in the SAP Access Controlsystem to synchronize data between the SAP GRC systemand the satellite systems. This is designed to ensure datacurrency and consistency between the SAP Access Controlsystem and the satellite systems. Here are the major masterdata elements that you need to synchronize in the SAPAccess Control system:

PFCG authorizationProfileRoles

UsersAction usageRole usage

The implications of failed synchronization jobs can be grave,especially when the currency of data can expose the systemto fraudulent activities. For example, if one of the attributescoming from the back-end system drives the approver of anaccess request, and this information is not in sync with theSAP GRC system, the access request might be routed to thewrong approver—who might approve the access requestbased on inadequate knowledge of the risk exposure.Similarly, the detective control associated with the review offirefighter logs can be impaired if the background jobresponsible for collecting firefighting session logs and sendingthem to the controller fails to execute successfully.

An auditor will be interested in ascertaining that backgroundjobs that drive data synchronization are always executedsuccessfully as scheduled. The sequence of execution ofthese background jobs is also an important considerationduring a technical review. SAP recommends that you adoptthe following order when scheduling background jobs in theSAP Access Control system:

PFCG Authorization: ProgramGRAC_PFCG_AUTHORIZATION_SYNCRepository data (profiles, roles and users): ProgramGRAC_REPOSITORY_OBJECT_SYNC. Note that youcan synchronize the repository data (profiles, roles andusers) with programsGRAC_ROLEREP_PROFILE_SYNC,GRAC_ROLEREP_ROLE_SYNC, andGRAC_ROLEREP_USER_SYNC, respectively.Action Usage: ProgramGRAC_ACTION_USAGE_SYNCRole Usage: Program GRAC_ROLE_USAGE_SYNC

Other programs that you should schedule as background jobsare:

Batch risk analysis: ProgramGRAC_BATCH_RISK_ANALYSISFirefighter logs collection: ProgramGRAC_SPM_LOG_SYNC_UPDATEFirefighter workflow synchronization: ProgramGRAC_SPM_WORKFLOW_SYNCIDM schema update: ProgramGRAC_SCHEMA_UPDATEEAM Master Data: Program GRAC_SPM_SYNC

For the system to operate normally and optimally from atechnical perspective, you should schedule some database-dependent administrative background jobs to run at intervals.A technical system auditor should be informed that therequired background jobs that are scheduled for differentunderlying databases. For example, you should execute thefollowing database management-related background jobs for aMicrosoft SQL Server database:

Computing Center Management System (CCMS)blocking database locks statisticsCCMS check database (DBCC—database consistencychecker)CCMS update table statisticsMS SQL COLLECTOR

The status of all these background jobs should be reviewedvia transaction code SM37 as part of technical system reviewactivities.

Variants are used to eliminate the need to define the samevalues in selection criteria fields every time you execute areport. This functionality is designed to reduce both data entrytime and system processing time, which makes it common inevery SAP system environment. You should also reviewvariants for correctness and currency. Ideally, you shoulddiscontinue or adjust variants that are no longer relevant in thesystem. You can review the entries in table TBTCP to accessthe currency and relevance of defined variants.

Integration with Back-EndSystems

The next major risk is that vulnerabilities and data inaccuracyin the back-end system can impact the operation of the SAPGRC system. The preventive measure you can take is toensure that appropriate security and data accuracy is enforcedin satellite systems.

A typical SAP GRC system is not made up of just the SAPGRC box alone; rather, it contains other back-end systemssuch as SAP ERP, SAP SRM, SAP NetWeaver Portal, orMicrosoft Active Directory. These back-end systems playdifferent roles in the system landscape. In some cases, theSAP GRC system is used to provision access to the back-endsystem, or the back-end system is used as the data sourcefor user authentication and user details in SAP AccessControl. The seriousness to be accorded the SAP AccessControl system in terms of system review should also be givento the back-end system.

This is important because security breaches in any of thedependent back-end systems can have an impact on theintegrity of the SAP Access Control system. For example, ifthe SAP ERP HCM system is designed as the source of userdetails (e.g., personnel area) that drives the assignment of theapproval agent, and the data maintained in the SAP ERPHCM system is not accurate, an access request can be routedincorrectly (even though the configuration of the logic in SAPAccess Control is correct).

Therefore, a system auditor naturally wants to gain assurancethat systems connected to the SAP GRC system areperforming their role as intended in terms of functionalitydelivery and data accuracy. If the SAP ERP HCM system isthe source of a mandatory field in access request and SAP

ERP HCM is unavailable, the implication is that the SAPAccess Control system is unavailable because it also will notbe useful for access provisioning.

Performance Optimization

A major performance risk is slowness or unavailability of thesystem. To prevent this, you must create appropriate andoptimal configuration settings and parameterization.

It is important to perform preliminary sizing before theimplementation of the SAP Access Control solution. This is toensure that you have an idea of the hardware requirements,including disk size, network bandwidth, physical memory, CPUprocessing power, and I/O capacity based on the businessrequirement and environment. There should be an IT-balancedscorecard designed to measure IT performance. If you do notdefine empirical performance indicators, senior managementmight be misled on the true implications of performanceimpairment.

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

System performance: The number of active users,maximum dialog steps per hour, average response timein a dialog task, average response time at peak dialoghour, average response time in an RFC task, averageRFC response time at peak work hour, and maximumnumber of RFCs per hourHardware capacity: Maximum CPU utilization ondatabase serverDatabase performance: Average database request timein update task, average database request time in dialogtask, and average database time in RFCDatabase space management: Database size andgrowth over a defined period

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

Master data volumeTransaction data volumeConfiguration settings (customizing)Number of concurrent usersSize of the system landscape (number of systems andavailable system resources)

The reality of the business environment can also have animpact on performance—for example, the average number ofpermission level violations per object, the total number ofaccess risk and rules, and the complexity of the approvalworkflow process. The measurement of optimal systemperformance requires technical skills and standard tools suchas SAP Solution Manager. The ability to interpret standardperformance-related reports and indicator settings is veryuseful. For example, if you have an average CPU load that ismore than 90 percent, a system reviewer should be able todeduce that this represents an adverse CPU problem.

The performance of SAP Access Control can raise seriousaudit questions. Even though performance managementsounds more like a technical requirement, if performance isdegraded, it can lead to system unavailability andconsequently affect functional use of the application.

The period of downtime might represent a window toperpetrate malicious activities, especially when there are noadequate processes and controls in place to address thechallenge. Therefore, a system auditor will be interested inascertaining that the basic configurations that can enhancesystem performance are in place. For example, if theconfiguration option Enable Offline Risk Analysis is set to Yes,the tables holding the action and permission level details forall risk analysis performed will be parsed. It can become verylarge (i.e., millions of records) and significantly affect yoursystem performance adversely.

As I asserted earlier, configuration settings can influencesystem performance. This makes the review of configurationsettings an important activity during system review. Anexample is the exclusion of users and critical roles. This is toensure that risk analysis runs completely and successfully in asuitable amount of time, without significantly affecting systemresources. I acknowledge that system resources differ fromone installation to another; however, unless there is specificneed to act otherwise, it is a best practice to:

Set the default user type for risk analysis to DIALOG –Parameter 1026Include locked users (Parameter 1031), include expiredusers (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 configurationsparameters in configuration settings by following menu pathSPRO > SAP Reference IMG > SAP CustomizingImplementation Guide > Governance, Risk and Compliance >Access Control > Maintain Configuration Settings.

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

Another performance-related configuration is the definition ofthe index for fields MANDANT, UTIME, UDATE, andUSERNAME in table CDHDR, as shown in Figure 25. Thisensures that performance is not impeded during firefightingsession report generation. SAP Note 1039144 providesinformation on how to create this index. To improve theperformance of the reporting tool for emergency accessmanagement, you must index the fields MANDANT, UTIME,

Figure 25

Index for table CDHDR

UDATE, and USERNAME of table CDHDR as recommendedin SAP Note 1741151.

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

abap/heap_area_dia (limit of heap memory per dialogwork process)abap/heap_area_nondia (limit of heap memory per non-dialog work process)abap/heap_area_total (limit of heap on applicationserver)em/initial_size_MB (initial size of extended memorypool)abap/buffersize (program buffer size)

Missing Indexes

Another major risk is the possibility of data inconsistencies. Toprevent this, simply make sure that there are no missingindexes. Indexes are important objects in the management ofdatabase systems. It is essential that there are no missingindexes at the database level of the SAP Access Controlsystem. Because tables in the SAP environment are so large,data is often accessed via indexes to enhance systemperformance. The concept of missing indexes can present anaudit concern, especially because it can lead to datainconsistences in the system. You can review missing indexesvia transaction code DB02.

Business Continuity and DisasterRecoveryData loss or inability to continue business operation in theevent of a disaster is another risk. To prevent this, ensure that

Figure 26

Overview of a back-up log

an appropriate business continuity plan and disaster recoveryplan exist and are tested at defined intervals.

The impact of the unavailability of the SAP GRC systemshould be analyzed at some point. Appropriate plans shouldexist to counter possible unavailability issues with the systemin the SAP Access Control landscape, both planned andunplanned. When developing a disaster recovery plan, youneed to perform a business impact analysis to ascertain theimplications of the unavailability of the SAP Access Controlsystem in terms of qualitative and quantitative measures. Forexample, in a global implementation, what is the implication ofnot being able to provision emergency access for the salesteam when needed? You can quantify the financial lossimplications and help to advise an optimal countermeasure.

Adequate and effective backup and restore strategies mustexist to ensure business continuity.

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

Figure 27

A time zone data report

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

Time Zone Setting

The major risk here is that the difference in time zone iscapable of affecting log collection, which consequently affectscorrect reporting of firefighting session activities in the satellitesystem. The result is erosion of the detective controlcapability. The preventive measure is to ensure that the timezone of the operating system and the SAP NetWeaver engineare in sync in the SAP GRC system and the satellite systems.

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

If the time zone of the operating system and the SAPNetWeaver system are not the same, there is a possibility thatEmergency Access Management log reports will show norecords when executed—even though log data actually exists.Consequently, an auditor will be interested in ascertaining thatthe appropriate operating system time zone setting ismaintained 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 SAPNetWeaver system in the SAP GRC systemThe time zone of the operating system and the SAPNetWeaver system in the plug-in system (e.g., SAPERP system)

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

Figure 28

Dialog box to maintain time zone settings

NoteTime zone settings present a challenge because thetimestamp is assigned to transaction codes committed in theindividual system (i.e., between the operating system leveland the SAP NetWeaver level) and not necessarily acrossdifferent systems (e.g., SAP GRC and SAP ERP).

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

Click the Yes button. In the screen that appears, maintain thevalues for the System Time Zone and User’s Default TimeZone fields (Figure 29). Also, activate the time zone setting byselecting the Times Zones Active check box. Click the saveicon and restart the instance to activate the new time zonesetting.

Figure 28

Dialog box to maintain time zone settings

NoteFor more information on time zone settings in the SAPenvironment, you can review the following SAP Notes:Note 198411: Current data and information about timezonesNote 481835: Analyzing the time zone settings

Documentation

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

Documentations are an integral part of any business solutiondelivery, serving as part of the knowledge transferrequirement. As part of a comprehensive system reviewprocess, it is expected that documentation related to theproject is assessed for completeness and correctness. Thesedocumentations are designed to serve as a reference guide onthe build, design, and operation of the business solution.

Ideally, there should be documentation related to the technicalinstallation, blueprint and system design, support andoperation guide, security and authorization design, testingmaterials, and user guide. More importantly, these documentsmust be approved by a designated individual with at least onerepresentative from senior management or the project steeringcommittee. This goes a long way toward demonstratingmanagement commitment to the project.

Also, when changes are made to these documents at differentstages of the project life cycle, you need to approve andversion these changes accordingly. Review the security ofwhere the documents are stored to gain assurance that theycannot be tampered with. This document managementcapability can be harnessed via SAP Solution Manager.