30 Jan Privileged User Controls – SQL Injection
One of the key controls that organizations often define as part of their ITGCs relates to the identification and monitoring of privileged users. An accurate definition of what is deemed to be a ‘privileged user ‘ is a topic for another article and we see if being identified very inconsistently.
Privileged users need to be identified at the OS, database, and application level. This article will focus on privileged users at the database level. Typically privileged database users are focused on those that have a privileged seeded or custom role assigned to a named login or a generic (seeded or custom) database login. High performing organizations understand that any privileged access should be restricted to those that are database administrators.
The one account that gets significant scrutiny from auditors is the APPS account. APPS is used internally by the application to connect the application server to the database server. APPS has full DML (Insert / Update / Delete) and DDL (Data Definition Language) privileges to the database server. APPS has keys to the kingdom. If a user can log in as APPS it can do anything. Controls over the password for APPS and ability to log in as APPS are heavily scrutinized by auditors, as they should be…
However, what if a user can gain access to the same privileges as APPS without having to know the password for the APPS account? If there were one or more users who could circumvent the controls over APPS it would be a significant risk that should lead to a control deficiency and perhaps a Material Weakness.
Oracle has published such a risk dating back to at least 2002. Oracle used to publish a document called “Best Practices for Securing E-Business Suite” that has since been folded into its “Security Guide” (Part No. E22952-18).
In its original publication of this of document (Metalink 189367.1) Oracle clearly spelled out that access to certain security objects (Functions) in the application allow a user to enter a SQL statement. Following a screen shot that identifies these Functions:
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:
- Software that identifies who has access to these Functions
- 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 (we implement an installed solution from CaoSys called CS*Comply or can deliver results via a SaaS solution called CS*Proviso). 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 (we implement a solution from CaoSys called CS*Audit to do this). 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.
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.