Because of the way the applications are architected, anyone having access to one or more of these functions are connected to the database with the SAME privileges as a database user having the APPS login. A user connecting logged into the applications having access to one of these functions has the same full DML and DDL privileges as a database administrator that has the password to the APPS login. Such application user has an unrestricted ability to execute any DML or DDL commands as if they were directly logged into the database as APPS.

Let’s look at two of these Functions:

First Example – Alerts form

Second Example – Collections Plans

Both of these forms not only have the ability to enter and execute a SQL statement, but they also have the ability to execute an Operating System Script such as resetting a password.

Tying this back to the control related to privileged users for database accounts. The focus of the control over privileged users for database account is normally exclusively focused on database users and roles. However, what we’ve identified above, is that application users can gain access to the APPS login without actually having access to the password for the APPS account – merely by having access to one or more Functions that can be assigned to a Role (Responsibility) at the application tier.

To get to the gist of this article… if there were one or more users at the application tier that were assigned access to one or more these Functions, yet they weren’t identified by management and approved as a privileged user, it is definitely a control deficiency. The likelihood and impact of such control deficiency would determine if such as deficiency would be classified as a material weakness.

In order to prevent the deficiency from being classified as a material weakness two things HAVE to be in place:

1. Software that identifies who has access to these Functions
2. Software that develops a full audit history of any activity done through these Functions

First, you need to have installed software or use an external cloud or SaaS solution to identify who has access to these Functions. Without having an understanding who has access to these Functions so management can review and approve – you must conclude this is a material weakness. The access that the user has is unlimited – they could completely destroy the database, reset any password they want, and add data to or make changes in any table in the instance.

One could argue, perhaps, based on the users who have access to one or more of these functions that management could ‘approve’ (i.e. accept the risk) the group of users who have this access in Production. This would be a hard sell given we typically find many more users in IT that have such access (including developers and business analysts) as well as end users.

The other argument we’ve heard is the technical expertise needed to take advantage of this access is high. As you can see from the first form, all you need to know is how to execute a basic SQL statement (update in the example) and what fields you need to update. Suffice to say, it would be easy for most IT users to identify what tables and columns contain the supplier bank account data or other data.

When we analyze who has access to these Functions, we typically find 20 – 25 functions are assigned to someone. There are approximately 65 such Functions throughout the system. Further, we have documented flaws with Oracle’s ability to identify and keep current with the publishing of these Functions . To gain reasonable assurance that users haven’t used these Functions, you’d need a full detailed audit trail of all activity from within these forms. However, such detailed activity is not provided as part of the core applications – it has to be built via a third party tool. Without the ability to identify WHAT a user has done with these Functions, you have no ability to identify the impact. The potential impact is limitless, therefore, there is no way to identify mitigating controls.

Conclusions:

Admittedly this is a complicated topic. It may be that Oracle E-Business Suite (EBS) is the only ERP system on the market that has this risk (I have no basis of knowing if others allow this). However, it is a risk specific to EBS that must be taken into account in the review of the design and operating effectiveness of the controls over privileged users. Because most organizations have not addressed this risk (am estimating 98% based on my experience and as a SWAG) auditors should be assessing this risk as a material weakness in 98% of their audits, however, I have yet to see it happen once.

I believe this is the case because of the lack of expertise specifically in EBS risks and controls and because auditors are unwilling to admit to clients and the PCAOB that audits in prior years weren’t complete. This is what I refer to as institutional bias and the incestuous nature of the relationship between external audit firms and their clients.