IT Audit Basics Auditing Security and Privacy in ERP Applications By S. Anantha Sayana, CISM, CISA, CIA Volume 4, 2004

Enterprise resource planning (ERP) applications have over the years become the foundation application for many large and medium enterprises all over the world. ERP systems form the core transaction processing platform for most enterprises in manufacturing and related industries. The business processes and transactions of the company happen in the ERP system. The ERP is an integrated system that holds all the data pertaining to these business processes from the beginning to the end of the chain in a unified database. ERP systems, assisted by networks and central databases, have greatly improved efficiencies of transaction processing by eliminating barriers of geography and departments.

Does all of this impact internal controls? Yes, substantially. The integrated nature of the ERP enables data entered at one part of the process cycle to be carried forward to the next part of the cycle for further processing. The acceptance of the validity of the earlier part of the data is implicit, and there is often no reverification at different stages. An example is provided in figure 1 (each box denotes a process and the department where it occurs).

Every one of these processes would have originated from different departments and may be located anywhere, but the ERP sees all the data from the common database. At process number 6, the ERP system picks up the purchase order data entered at process number 2, the goods received and accepted from process number 3, and the supplier's claims from process number 5. It then matches them all, calculates the payment due after applying all the commercial terms, and arrives at a payment amount and date. The only data that it seeks (even this can be automatically configured) are approvals for payment and the bank account from which the payment is to be made. In most stable ERP scenarios, there is no verification from base documents at this stage. Besides this, many other activities performed earlier by other systems may also be done automatically by the ERP as indicated in box 7. This is only one example. Similar process chains exist for almost all activities, such as the sales cycle or the manufacturing cycle. As is indicated, the process in box 1 can also be the result of another automated process called the material requirement planning (MRP) run that might have taken inputs from the sales forecast, manufacturing capacities, etc.

In this scenario, the impact on controls is that there is no room for checking along the way and again at the end. Two major requirements of controls emerge from this significant feature of ERP systems:

1. Every piece of data needs to be authentic and accurate at all stages of the process cycle. An error or a malicious entry at any of the stages would be carried forward all the way (subject to some validations that can be built). This requires clear definitions of who should do what and segregation of duties between people doing those duties enforced through access control. Fortunately, the major ERPs provide excellent features for defining access control to a great degree of granularity.
2. Many automatic processes and updates (postings) can happen without human intervention. These are based on the configurations in the ERP. Therefore, it is necessary that all these configurations be made and maintained correctly and in line with the control requirements of the business. Most ERPs are designed as generic solutions that can operate in many countries and businesses catering to different requirements. Therefore, there is a lot of parameterization, and many parts of the system are configurable. While this is a desirable feature offering options during implementation, it can also be the source of internal control weaknesses allowing options that were hitherto completely prohibited.

Approach to Auditing ERPs

The following would be typical prerequisites for carrying out an audit for assessing security and privacy issues in ERP:

• Understand the business and the risks specific to that business and its operations. This is the first basic step, not only in ERP audit, but in any kind of audit.
• Understand the enterprise structure. The complexity of ERP arises from the fact that it attempts to encompass the entire business cycle of the enterprise, covering all major functions and all parts of the organization in its wake, including financial accounting, human resources and management information. The mapping of the various organization units is reflected in the enterprise structure in the ERP. An accurate understanding of the enterprise structure is the first step to carrying out an audit.
• Obtain access to the system. The audit of an ERP cannot be done by having someone generate reports and show them to the auditor. The information systems (IS) auditor should verify the various settings and data in the system by seeing them in the "live" system. For this, the auditor should obtain a user ID in the production system with read-only access to all modules and features. Needless to say, the auditor would need to have a good grasp of SAP and use the access with due care.

Major Areas of Audit Relating to Security and Privacy

The following are the major areas of audit:

• Evaluating access control—All the data in the ERP are in one single database. Theoretically, it is possible with suitable access to see or modify any part of the data relating to financials, materials, human resources or sales. In a centralized system connected through a network, access to the ERP is possible from any part of the network.
  
  Like any other application, access to the data has to be secured not only at the application level, but also at the operating system, database and network levels through suitable controls. The IS auditor should carry out a review of the network, OS and RDBMS before evaluating the access controls in the application.
  
  Access control evaluation in an ERP can be a complex exercise and requires good skills with the particular ERP. Most ERPs control access though menu options, screens and authorization objects, and activity options, such as add, modify, view and delete. To simplify the access control process, many ERPs use the concept of roles, assigning standard authorizations to the roles and attaching the roles to users as per their job descriptions and duties required to be performed. As ERPs are large systems, they have many users.
• User ID scrutiny and evaluation—A good first step for auditing access control is to obtain a list of authorized users and their privileges. The IS auditor should also obtain the list of standard roles and the authorizations required for the roles.
  
  Having obtained this information, the IS auditor can get the list of users from the system through suitable menu options. (Each ERP has its own procedure for obtaining this information. Such information would be part of the audit program available with audit firms or can be obtained by discussions with the ERP consultants or by referring to books.) This can be verified with the list of authorized users. Any mismatch between these lists needs to be investigated. It is useful at this stage to obtain from the system a list of user IDs created and deleted during the period of audit and to find the appropriate explanations and supporting approvals for all these transactions.
  
  The next step is to ascertain that all the authorized users have the appropriate privileges in line with their job responsibilities. To do this, the auditor should examine the roles that have been assigned to the various users, and ensure that the roles are in sync with their current job responsibilities. The next step is to identify from the system the authorizations and privileges associated with each of the roles in use, to ensure that roles, as defined in the system, are in line with what the role is expected to be. These roles could be called by other terminology, such as profiles, in different ERPs. Some ERPs provide for a level of granularity that can be mind-boggling. To cite an example, it would be possible to define a situation where a storekeeper can create, but not update or delete, goods received notes and only for a certain category of goods at a specified location of the store. Privileges of create, update, delete and view can be associated with every object based on the field values. While this is great news to fulfill the very stringent needs of security and access control, this can easily get out of hand if the entire access control is not properly mapped, planned and documented meticulously, using all aggregation options at the appropriate levels.
  
  It is also good to approach access control evaluation from another perspective, i.e., from critical functions and activities that would be required to be carried out only by specific authorized personnel. This would require a thorough knowledge of the ERP system to identify certain critical transactions. The IS auditor can query the system to determine the users who have authorization to execute such activities and options. The IS auditor can evaluate whether the list is aligned with the approved policies of the company. Examples of these activities include the ability to execute certain sensitive reports, close or open financial accounting periods for postings, and make changes to certain sensitive masters.
  
  In addition to access control, most ERPs may also require explicit authorizations to approve certain kinds of actions. These authorizations may be associated with monetary values and other special conditions, such as approving discounts, sales, purchases and some changes. These should be verified from the system directly and compared with the organization's policies for such activities.
  
  
• Verification and evaluation of configurations relating to business processes—This is another major area of audit for an ERP system. The process flow in every business activity, and the possible options for carrying out these activities are decided by the configurations in the system. Such configurations exist literally in every process and module, and the process of evaluating them can be a long and tedious job for the auditor. The best way to do this is to approach it from the business risk perspective and identify the configurations pertaining to those processes. Each of these configurations can be seen on the system by executing certain commands or following a certain path in the menu. An audit program that lists these and the possible values and options of these is a necessary tool, without which it would be difficult to carry out this evaluation.
  
  The recent books published by ISACA on the security, audit and control of SAP, Oracle and PeopleSoft can be useful for doing such reviews. IS auditors can use these programs as the baseline and customize them to their environment based on their experience, with help from the functional consultants.
• Change management—The other factor that can influence security is change management. The way modifications are done to the programs and the configurations, the effective segregation between the development and production environments, the processes for testing, quality assurance and migration need to be reviewed by the auditor.
• Interfaces—ERPs invariably need to send or receive data from other systems. Interfaces can be simple batch uploads of data or real-time data movement from multiple systems to and from the ERP through an integration middleware platform. An interface has the potential to become a weak point that can compromise security. Audit scrutiny of interfaces is one of the important aspects of ERP security reviews. At a simple level, controls should exist to validate data before upload and verify accuracy and integrity through control totals and logs, but a review of interfaces through middlware would be a specialist exercise.
• Privacy—ERPs are such a large repository of different kinds of data that they can impact privacy issues in a significant way. Most ERPs have a human resources and personnel module, and such modules handle a lot of data about the employees of the company. The ERP can also hold information about customers, suppliers and partners.
  
  Privacy laws have been enacted in many countries, and they all have their own flavors. ERPs may operate across countries in a multinational company and deal with data about employees and customers from different parts of the world. ERPs or their CRM extensions can also collect other information, such as credit card or credit rating information, which is impacted by privacy requirements. Such companies have to take due cognizance of the laws pertaining to privacy in each of the countries in which they operate or have dealings.

Without getting into individual laws, general requirements may be grouped under a few broad requirements:

• Securing personal information from unauthorized access, ensuring its protection through the life cycle of the information and ensuring its effective destruction when it is no longer required
• Catering to the rights of the subject about whom data has been gathered, processed and stored
• Not using personal information for purposes other than those for which the information is gathered or maintained

Many of these requirements can be met only if access controls are rigorously implemented and enforced. The way to address audit is first to identify the legislation, statute or rules that are applicable. This itself may be a formidable task, spanning across countries, and there may also be industry-specific regulatory requirements. The second step is to verify what kind of personal data are stored in the ERP and then go through the audit relating to securing them.

Conclusion

Many factors need to be reviewed during an audit to ensure security and privacy in an ERP system. However, the most crucial among these is maintaining the access controls and configurations, as these are widespread and can have a significant impact. These are constantly subject to change; therefore, maintaining them is a challenge. In this context, it is necessary to carry out the audit of all aspects of an ERP comprehensively at a post-implementation review. Subsequently, the review of access controls and configurations should be carried out regularly, at least once in six months. The ideal situation would be to move this kind of audit to a highly automated process using tools to perform a continuous monitoring audit.