JOnline: Emergency Access Controls in SAP Environments 

 
Download Article

 Jose Espin, CISA, CISSP, MCP, SAP Certified Security Consultant 

Under normal operating situations, IT personnel should have restricted access to the SAP production environment and a business user’s access should be based on assigned job responsibilities. However, system problems may require support personnel to have extraordinary access to resolve an issue that affects a mission-critical business function. Emergency IDs with high levels of access are often assigned to provide immediate resolution and to address problems that occur after normal working hours.

Granting temporary extensive system access to individuals with the knowledge and experience to resolve system problems that affect normal business operations is absolutely required, but the risk of granting access that could be used to commit and conceal a misstatement or to perpetrate fraudulent business transactions should also be addressed.

There are situations in which software vendors, contractors, IT personnel and key business users—all with extensive knowledge of the system and, in many cases, the business processes and related controls—obtain extensive system access for hours and even days to address system issues or to perform required improvements. In some cases, adequate controls to detect instances of unauthorized business transactions and access to sensitive information are not in place. This also has a negative impact on regulatory and compliance requirements, such as the US Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act (HIPAA), or the Gramm-Leach-Bliley Act (GLBA), that could have costly consequences for the enterprise.

This article provides a concise overview of the tools and solutions to consider when establishing acceptable IT practices to address the challenge that emergency access to SAP environments poses to many IT organizations.

Using Tools to Mitigate the Risk

Several third-party tools offer features that could help mitigate the risk of unauthorized access while providing the required emergency IDs to support SAP systems. However, it should be considered that, out of the box, SAP provides logs and utilities that could be used to monitor the use of these IDs.

SAP Standard Functionality

The following outlines some of the standard resources provided by SAP that could be used to monitor emergency IDs and facilitate compliance efforts regarding unauthorized access to sensitive information and fraudulent business transactions:

  • Security Audit Log—This is a tool designed to provide a detailed look at several security-related events that occur in the SAP system. It provides the ability to configure the events that are considered relevant and require monitoring. The different events included in the log are known as “audit classes.” There are various audit classes, but typically of most interest are the Dialog Logon and Transaction Start audit classes. If adequately configured, the Security Audit Log can be used to keep track of emergency IDs and the transaction codes that have been executed by those IDs. The transaction codes are a critical piece of data because they provide the information required to establish the transaction code (screen/group of screens) that has been used and the related business data that might have been changed in the system. Refer to figures 1 and 2.
  • Change Documents Log—The change document objects (tables CDHDR and CDPOS) provide information related to many important data changes in SAP, including the transaction codes that were executed and the user ID that was used. The Security Audit Log is still an important component because there are actions performed through transaction codes that are not recorded in the change document objects. For example, a vendor creation through transaction code XK01 is recorded in CDHDR and CDPOS. The use of XK01 is also recorded in the Security Audit Log. However, the use of FB60 to create a vendor invoice is not logged in the change document objects, but the execution of the transaction code is recorded in the Security Audit Log. The log review process would identify these activities and start an investigation to prevent the risk of issuing payments to fictitious vendors.
  • Computing Center Management System (CCMS)— This feature provides the ability to configure the use of automated messages. These messages are automatically sent when emergency IDs are used. CCMS also provides the ability to configure alerts that are automatically sent to designated individuals.

Figure 1

Figure 2

The components described previously provide the basic elements required to address emergency access. The ID that was used, date/time information, activities performed in terms of transaction codes (figure 3) and data changes (figure 4) are provided through the described SAP standard functionality. It should be taken into consideration that these features offer useful information on the usage of the ID, but the process may need support from IT personnel to extract the logs from the system and provide them to the individual who monitors emergency ID usage. The impact on system performance caused by utilizing these standard features should be minimal, given that the audit events to be captured are filtered using the assigned emergency IDs as a condition to be evaluated before storing data in the log. The change documents log is not an extra load being placed on the system because it is a necessary capability enabled by default.

Figure 3

Figure 4

Third-party Tools

There are several tools available in the market (e.g., SAP, GRC Access Controls, Security Weaver, Approva) that provide automated features to help strengthen emergency access controls and gain efficiencies in the process. Following are some of the most relevant features currently offered by these tools:

  • Assignment—The tool is used to assign the emergency ID to a specific user. The individual responsible for monitoring the ID is also specified within the tool. This information provides a period of responsibility for the actions carried with the ID and the monitoring activities that need to take place.
  • Authentication—Users access the system using their regular ID and switch to the emergency ID using the tool. Additional passwords are not required, and support users can easily obtain the required access, minimizing the response time to resolve the emergency situation. This process also forces users to provide a high-level explanation on the use of the ID before access is granted; this practice contributes to appropriate documentation, which could be used to address future problems and audits.
  • Automated notifications—The tool sends an automated notification to the individual responsible for monitoring when a user switches to the emergency ID. A second message with a log that describes the actions performed with the ID is sent when the emergency access is finalized. Since the initial notification is sent in real time, this feature makes the log reviewer aware of the ID usage and could help prevent unauthorized and unnecessary access. It also provides a streamlined process because the log is received automatically by the reviewer without the intervention of additional resources.
  • Logging—The tool provides a central location to store detailed information on the activities performed with the emergency IDs. The logs can be accessed when required to assess ID usage. A central repository that provides readily available information for more efficient audits and regulatory compliance is offered through this feature.

Implementing a Process for Emergency Access

A well-established process is necessary regardless of the tools used to address the risk related to emergency IDs. Without a formal process and assigned personnel responsibilities, an organization may fail to appropriately address the risk and adequately meet compliance requirements. The following is a list of suggested topics to consider when implementing a process that accompanies the related tools (refer to figure 5):

Figure 5

  • Least privilege and access restrictions—Users should be granted access only to those files and programs that they absolutely need to perform their assigned job functions. Placing access restrictions on emergency IDs may defeat the purpose of their creation. However, review of the logs is a key control in this process that may not always be performed, and restricting unnecessary access provides an extra layer of control to prevent unauthorized changes that otherwise could go undetected. At a minimum, access to delete logs and the ability to disable the logging or automated notifications going to the reviewers should not be granted to emergency IDs.
  • Segregation of duties (SoD)—Emergency IDs could also be used to address SoD conflicts that cannot be resolved by segregating the conflicting functions. In this case, access is granted through the use of an emergency ID. This approach helps to minimize the SoD risk because the related actions are being logged and monitored.
  • Roles and responsibilities—Each emergency ID should be specifically assigned to an individual to provide for accountability on the actions performed with the ID. Log reviewers should be responsible for assessing the activities performed with the ID based on a documented problem and a system-generated log.
  • Designated reviewer receives and reviews logs—Reviewing the log of activities performed with emergency IDs is one of the most important controls to mitigate the risk of unauthorized access. However, performing a timely and appropriate log review is often a challenge. The logs could be technical, and the log reviewers are often business users who do not have the necessary knowledge to understand them. It is essential that business and IT personnel work together in an effort to perform an adequate review of the logs. It is also important to retain evidence related to the log assessment and to keep the reviewer accountable for the review. The process should be evaluated through regular audits.
  • Root-cause analysis performed—The use of emergency IDs could be minimized through a root-cause analysis to determine the reason for the incident and how the associated events could be avoided in the future. This practice decreases the risk of unauthorized access, data processing errors, and the time and effort invested in log reviews. The use of an emergency ID should be supported by an IT problem/incident ticket that holds the documentation associated to the incident, resolution, root-cause analysis and log review.
  • Massive changes—Depending on the changes to be performed with emergency IDs, a detailed generation of the logs may not be feasible. Extensive logs generated as a result of massive changes may have an adverse impact in production environments. Preventive controls that alert the system administrator in this regard should be implemented. The possibility to activate a log that does not capture all the details, but provides enough information to evaluate the actions performed with the ID, should be considered (such as the security audit log).

Considerations When Reviewing Emergency Access Process

When performing an audit or risk assessment of SAP emergency access processes, the following is a suggested checklist that could be used in determining whether the process to address the risk posed by emergency IDs in SAP environments is adequate:

  1. Has the risk associated to superuser IDs been evaluated? A quick assessment to determine who has privileged access to the SAP system, how often they use it, and how effective the current process is to prevent or to detect in a timely manner unauthorized business transactions (including inappropriate access to sensitive information) should be performed. The risk of noncompliance with federal regulations (e.g., Sarbanes-Oxley, HIPAA, GLBA) should also be considered during this assessment.
  2. Have the reasons for requiring emergency access been determined? A root-cause analysis to determine the reasons that lead to privileged access could help to reduce emergency situations and minimize the number of individuals who require the access.
  3. Have the tools to address the risk of privileged access been evaluated? A risk assessment and analysis to determine if the usage of emergency IDs can be reduced are key steps to establish the level of automation and other requirements to appropriately address privileged access.
  4. Has the access granted to emergency IDs been restricted?Specific situations need to be analyzed to create IDs that provide appropriate access to resolve emergency situations. A stringent process should be considered to grant users unrestricted access.
  5. Is there a process in place to provide for and monitor the use of emergency IDs? A provisioning process to approve the assignment of emergency IDs and to ensure that there is an individual responsible for reviewing, through system-generated logs, the actions performed with the IDs is a key step to appropriately address the risk and meet compliance expectations. Adequate documentation and retention are necessary to provide evidence of effective controls surrounding privileged access.

Conclusion

The use of SAP-supplied or third-party tools to manage emergency IDs can help to address the related risk of personnel having elevated access, but there are important processes that need to be in place to accompany the tools and numerous considerations that should be taken into account to appropriately address the risks of emergency access.

SAP provides several logs and utilities that could be used to appropriately monitor emergency IDs. The implementation of these tools should be evaluated against the frequency and use of those IDs. A company that utilizes the IDs very often should evaluate the implementation of a more robust application that automates the functions involved in the monitoring process. A more robust third-party application may be warranted when the volume of emergency access is high since monitoring through standard SAP logs and utilities will require system reports that will probably have to be generated by IT personnel.

Root-cause analysis is a key component of the process that may help decrease the use of emergency IDs. By analyzing the reasons for frequent use of emergency access, an organization may discover that the use of the IDs could be decreased to the point that the monitoring through just standard SAP logs and utilities becomes an adequate solution that reduces the need for more costly third-party tools.

The use of emergency IDs to resolve SoD conflicts that are difficult to remove is often seen but should be closely controlled and monitored. Controls include ensuring that the concept of least privilege is enforced and those IDs created to address SoD issues have access to only the conflicting functions and do not have the ability to disable logging or automated notifications.

One of the most important controls when implementing a process to address emergency access is the appropriate review of the logs to verify that only required and authorized activities were performed. This key activity creates a closed-loop process and is often the area in which exceptions are found. Regular IT audits should include assessment of the timely and complete performance of log reviews, including follow-up on instances when the log review identified inappropriate or suspicious activities.

References

Editor’s Note

Security, Audit and Control Features SAP® ERP, 3rd Edition is available from the ISACA Bookstore. For information, visit www.isaca.org/bookstore. The appendices for the audit programs and ICQs are posted in word for ISACA members at www.isaca.org/auditprograms.

Jose Espin, CISA, CISSP, MCP, SAP Certified Security Consultant
is a manager in the Advisory Services practice of Ernst & Young LLP. He focuses on IT risk and assurance specializing in SAP security and governance, risk and compliance (GRC) solutions for SAP environments. Espin has 14 years of professional experience in the IT field across various industries— with nine years spent on application security and controls, risk assessments, and SAP postimplementation reviews and five years of experience designing and developing business applications. The author can be reached at jose.espin@ey.com.

Enjoying this article? To read the most current ISACA® Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2010 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.