Journal Online

Auditing Enterprise Resource Planning Systems

Sean M. Price, CISA, CISSP, is an independent information security consultant located in Virginia, USA. He provides security consulting and architecture services to commercial and government entities. Price has more than 12 years of information security experience, including system security administration, user information assurance training, policy and procedure development, security plan development, security test and evaluation, and security architect activities. His security research areas of interest include access control, information flow, insider threat and machine learning. He can be reached at sean.price@sentinelconsulting.com.

Enterprise resource planning (ERP) systems enable organizations to automate organizational information flows. A well-designed and properly implemented ERP system enables an organization to drill down deep into corporate information to learn new things about the organizational data as well as provide finegrained management. For an ERP tool to be effective, it must have the necessary controls implemented to protect the confidentiality, integrity and availability of the information managed. This article introduces a methodology that can be used as a basis for defining the parameters for auditing an ERP system. Some of the common business areas supported by ERP include marketing and sales, supply chains, accounting and finance, and human resources.1 Each of these areas is functionally different, but can impact one another. This is especially the case where marketing and sales have influence over supply chains and an impact on accounting and finance. An ERP system enables an organization to manage the various data elements of these business areas to achieve consistency and efficiency in its processes. Information flows within an ERP are important factors to review during an audit. It is unlikely that an out-of-the-box ERP solution will exactly match the business processes of an organization. An organization implementing an ERP system often must reengineer its processes, customize the ERP package or do a little of both. Business process reengineering (BPR) is often necessary to decompose existing processes so they can be automated later. This activity may identify shortcomings that compel the process to be redesigned with improved efficiency. In some cases, it is possible to customize an ERP system. Customizations make use of bolt-on products, application programming interfaces and middleware to achieve the end result for the system.2 Each of these aspects implemented in an ERP system adds to the overall complexity and increases the potential for weaknesses to be introduced. Customizations that extend the

original application should be scrutinized for their compliance with security requirements. Deployed ERP systems can be found on mainframes as well as client-server systems. However, ERP largely embraces the open system model and is, therefore, most likely to be encountered in systems built on microcomputer architectures. The client-server paradigm is a common ERP implementation.3 This architecture stores information in a back-end database and uses centralized servers that contain business logic, facilitating end-user access through client applications on their workstation. ERP audits should consider the overall architecture of the parent system as well as that of the ERP tool. Loosely joined components in the architecture may introduce weaknesses and allow security controls to be circumvented. Theorizing on the ways an attacker might compromise a system, given the integration of its components, is an important activity. Viewing an ERP system from the perspective of an attacker may reveal weaknesses that had not been previously considered. ERP implementations can be very complex systems consisting of thousands of configuration items with many individual modules. Conducting an audit of such a complex system can seem like a daunting task. The best way to approach the problem is to break it up into smaller, manageable chunks that support the overall objectives of the audit. One way to formulate an audit strategy is to consider the aspects of the system that lend themselves to evaluation. Ideally, a security audit focuses on the security countermeasures in place to protect the system. The security countermeasures can be broadly categorized using a framework such as the Information Assurance (IA) model.4 The IA model identifies three security countermeasures commonly implemented to protect information systems. These countermeasures include: PeopleThis is the totality of all individuals who are responsible for the use, operation, maintenance and protection of the system,
ISACA JOURNAL VOLUME 2, 2009

and their training. Ordinary users as well as administrators and support staff are integral security aspects of the system. People also encompass managerial aspects of the information and system. OperationsThis includes all policies, standards and procedures implemented to protect a system and the information it contains. Security policies define the protection measures to be in place. Standards can be used to specify settings, configurations or actions that enable consistency across a system. Procedures are the documented details that help people conduct repeatable actions regarding system use and management. TechnologyThis encompasses the aggregate hardware and software comprising the system. Items protecting a system include operations systems, databases, applications, firewalls, routers and switches. The following sections discuss some areas that merit audit consideration within each of the countermeasures. PeoPle Interactions between users and a system can ultimately impact the security of an ERP system. An auditor may wish to consider how these interactions affect security of the information and system. Functionality Requirements An ERP system is implemented to automate manual processes and provide standardization of processes and data. Important workflows within an organization should be documented. Likewise, those aspects of the ERP system that support these workflows need to be identified as well. If the system does not fully support the established workflows, then the auditor will need to determine if the functionality requirements have not been met. An ERP system that does not meet the intended functionality requirements may result in weakly controlled business or weak internal controls. Workflow Integration The point where automated and manual workflows intersect may produce mismatched handling of information. Data flowing into the system may not be properly formatted or derived from the appropriate source leading to improper decisions or skewed data. Information feeding manual processes from the automated system may not be provided the same level of access control as it had in the system. 2
ISACA JOURNAL VOLUME 2, 2009

In this case, the security present in the system could be irrelevant when the output is insufficiently protected. Audits of an ERP system should consider all aspects of workflows, especially controls over system inputs and outputs. oPerAtIonS The policies and practices associated with an ERP system are essential elements of governance. Furthermore, insufficient operational aspects of an ERP system can raise questions regarding effectiveness or existence of information assurance controls claimed to be implemented. An auditors review of the operational aspects of an ERP system can identify significant security deficiencies not considered previously. Documentation A system with insufficient documentation is difficult to assess. The documentation for a system undergoing rapid changes is likely to become outdated quickly. Detailed, accurate and complete documentation is a good indicator of a system that is properly managed. Reviews of documentation should consider if it contains sufficient: DepthThe documentation should provide enough depth of detail so that implementation elements of the ERP system can be duplicated or evaluated by those not familiar with the system. Using the Open System Interconnection (OSI) model as a basis for evaluation, for example, auditing could be conducted at any number of OSI layers such as applications, operating systems and networking devices. An auditor needs to understand the depth to which a control is implemented to determine if the ERP has sufficient controls to prevent and/or detect security violations. BreadthFor any given topic within the documentation it should be clear to what extent a control or aspect of the system is implemented. The boundary for a given element of the system should be evident within the documentation. For instance, a system may be contained within a single building or span the globe. Knowing the extent of system elements is important when devising an approach to audit the system. Security Requirements Laws, regulations, policies and standards form the basis for the security requirements of a system. An ERP application should support existing security requirements. An auditor

should determine if a system sufficiently supports all security requirements. The inability of an ERP system to support a particular requirement should be counteracted with at least one of the following: Compensating controlsOther controls should be in place to prevent and/or detect misuse of the system. Acceptance of riskIn some cases, it may be too costly or impractical to fully meet a security requirement. Management may choose to accept risk when a security requirement is difficult or impossible to meet. Change Management Organizations that customize their ERP systems will need to maintain an effective change management process. Changes that are not properly controlled may introduce weaknesses into the security posture of the ERP system. It is also likely that applications will need periodic vendor updates to the deployed modules. The consequences of poor change management can introduce new weaknesses when they are not properly controlled or allow a known weakness to persist when they are not implemented in a timely manner. An auditor can look into recent changes to determine if they were: AuthorizedThe change was agreed upon prior to deployment and permitted by management. ControlledA process of changing systems aspects is documented and followed and provides separation-of-duty assurances. ValidatedFollow-up with regard to the change was conducted by those not responsible for implementing the change. The validation of the change provides assurance that only the targeted aspects of the change were affected, while other parts of the system were not altered. Configurations An ERP system may contain thousands of individual configuration items. These items impact the workflow and handling of information through the system. Misconfigurations may impact the confidentiality, integrity or availability of the information. Other supporting parts of the system, including operating systems, networking devices and databases, also need explicit configurations to support security in the ERP system. Configurations should be documented and periodically validated. An auditor

can assess ERP configurations by matching configuration documentation with actual settings in the system. A lack of sufficient documentation for settings is another point of view an auditor should consider. teChnology ERP systems are often very complex and may contain components from multiple vendors. Furthermore, an ERP system often relies on commodity operating systems and databases that increase overall complexity. The extent the technological components integrate or work tightly together can affect the overall security of the ERP system. Access Control Mechanisms that allow or deny access according to a policy are core security components. Access control mechanisms must support the security policy designated for the ERP system. Often, access control mechanisms from different vendors do not integrate easily. The access control mechanisms for the operating system, database and ERP application may not integrate well. The auditor needs to review the implementation of each access control mechanism to determine if weaknesses exist. It may be possible for a user to bypass controls in the ERP application through either the database or operating system if there is a mismatch in the access control implementations in either case. Audit Logs Detecting ERP misuse is an important security management activity. Misuse is detected through analysis of audit logs. Without sufficient audit collection, accountability would be difficult to achieve. The auditor should review audit settings and implementations to assess if audit logs have the capability or capacity to capture events that could be analyzed to detect ERP misuse. Correlation of audit activity in the ERP system with external audit events through the operating system or networking equipment should also be examined to determine if sufficient details are collected to detect misuse and support user accountability. Automated Workflows The ability of an ERP system to automate manual processes is the core purpose of the system. When workflows are automated through the ERP, a possibility exists that
ISACA JOURNAL VOLUME 2, 2009

certain processes may become orphanedthat is, they are erroneously left out of the system. Orphaned processes can seriously affect the ability of the ERP system to provide timely or accurate information. An auditor should review the automated processes to ensure that all workflows intended to be automated are actually implemented or have sufficient documentation indicating the supplemental manual processes. At the other extreme, an automated process may introduce weaknesses that affect other controls such as separation of duties. Furthermore, a process without sufficient checks and balances may enable a user to perpetrate a fraud. Audits of ERP workflows should include a determination of whether automated processes violate separation of duties or introduce the ability for workers to perpetrate a fraud, which means the system is not enforcing separation of duties. Identities ERP users have identities that are inherent from the application or are derived from the underlying operating system. Identities coupled with the authenticators must be properly handled by the system: InherentProviding a user with yet another account requires appropriate oversight when it is time to deprovision the user. Furthermore, it will be necessary to determine if the identity mechanism supports required security authentication attributes, such as password lifetime, complexity, length and encryption.

IntegratedAn ERP system that integrates with the host operating system for access control and user identities helps reduce managerial overhead. However, integrating identities must be handled with caution as separation of duties or least privilege can be quickly violated when excessive assignment of account rights occurs. SuMMAry ERP implementations can be very complex and critical IT investments. The magnitude of the system complexity can be handled by an auditor, by decomposing system aspects into the people, operational and technical security countermeasures. In this way, an auditor can reduce the complexity into manageable tasks to achieve the audit objectives. endnoteS Monk, E.; B.Wagner; Concepts in Enterprise Resource Planning, 2nd Edition, Thompson Course Technology, USA, 2006 2 Olson, D. L.; Managerial Issues of Enterprise Resource Planning Systems, McGraw Hill-Irwin, USA, 2004 3 Adam, F.; D. Sammon; The Enterprise Resource Planning Decade: Lessons Learned and Issues for the Future, Idea Group Publishing, USA, 2004 4 Maconachy, W. V.; C. D. Schou; D. Ragsdale; D. Welch; A Model for Information Assurance: An Integrated Approach, Proceedings of the IEEE Workshop on Information Assurance and Security, 2001
1

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. 2009 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, Mass. 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. www.isaca.org

ISACA JOURNAL VOLUME 2, 2009