with oracle, sometimes you need to fill in the · pdf filewith oracle, sometimes you need to...

With Oracle, Sometimes You Need to Fill in the Blanks

2014 ERP Risk Advisors 1

Organizations that use Oracle E-Business Suite rely on the quality and completeness of the guidance

provided to them by Oracle through My Oracle Support (MOS). There are several documents that

organizations should know like the back of their hand and should have documented their compliance

with the recommendations in detail. One such document is MOS Note 403537.1 – Secure Configuration

Guide for Oracle E-Business Suite. Compliance with this document prior to going live is a necessity.

Because of changes being introduced by users, DBAs, security administrators, developers, and via

patches provided by Oracle, compliance needs to be reviewed and re-tested on a regular basis.

Over the last 10 years we have uncovered several issues with this document. We have published our

findings from time to time and Oracle has acknowledged use of our feedback in their documentation

(see Appendix A). Recently we have identified four other issues that we’d like to address that frankly

has us questioning the quality and completeness of the document as well as questioning the quality and

completeness of the internal processes that should be influencing this document.

First, let’s cover some background:

Background Related to Oracle’s Documentation Organizations running Oracle E-Business Suite rely on the quality of internal procedures by the software

vendor and guidance provided by them. Oracle has generally been weak in their external guidance

related to risks in their E-Business Suite applications. We believe it is likely that much of what was

initially published in their ‘Best Practices for Security Oracle E-Business Suite’ was taken from guidance

provided by other firms. The earliest version we have is version 3.0 for release 11i.

Figure 1 - First page of 189367.1_version 3.0



Version 3.0 was published in 2004:

Figure 2 - Revision History page 189367.1_version 3.0

In that document Oracle provides guidance to ‘consider auditing the database tables’ as per this

guidance.

Figure 3 - 4 of 189367.1_version 3.0

Following are the references to Appendix A and Appendix B from this same document:



Figure 4 - Appendix A: Security Setup Forms_189367.1 version 3.0



Figure 5 - Appendix B_page 1: Security Setup Forms that Accept SQL Statements _189367.1 version 3.0

Figure 6 - Appendix B_page 2: Security Setup Forms that Accept SQL Statements_189367.1 version 3.0



We wonder how much of these best practices come from the “References & More Resources” quoted in

Appendix G.

Figure 7 - Appendix G from 189367.1 version 3.0.5

When Oracle updated the document in 2011, they changed the name to take out “Best Practices” and

since have called it “Secure Configuration Guide.” Following is Oracle’s version 3.1.0 of this same

document:

Figure 8 - Version 3.1.0 MOS Note 189367.1 updated September 2011

Following is the document history section of version 3.1.0:



Figure 9 - Document History section of 189367.1 Version 3.1.0

From the above, you can see that version 3.0.5 was published in July 2007 and version 3.1.0 was

published in September 2011. Oracle waited over four years to make an update to this document. I find

it hard to believe there were no substantive changes to the applications or underlying technology that

required a change to this document in over four years. The question you have to ask is - what process

does Oracle have internally for identifying security risks that should prompt a change to this document?

I’ve come to the conclusion that there are some significant gaps in whatever process(es) they have

defined.

Following is Appendix C from 189367.1 version 3.0.5 (July 2007)



Figure 10 - Appendix C from 189367.1 version 3.0.5 (July 2007)

This Appendix identifies the database logins and schemas that come seeded upon installation of the

applications.

Following is the same Appendix from version 3.1.0 (September 2011)



Figure 11 - Appendix C from 189367.1 version 3.1.0 (September 2011)

Notice the differences between the two… look closely… there are none. Four years and two months and

there is supposed not one new database login that has been introduced. This is hard to believe. This

would mean no structural changes to the database in over four years and no new applications being

introduced in over four years.

Release 12 versions Shortly after releasing the Release 12 version of this document, in version 1.1.0, as we indicated above,

Oracle changed the name of the document from “Best Practices for Securing Oracle E-Business Suite” to

“Secure Configuration Guide for Oracle E-Business Suite Release 12”



Figure 12 - Release 12 version 1.1.0 MOS 403537.1 - referred to as the Secure Configuration Guide

Let’s look at how the guidance has changed from the 11i version above:

Figure 13 - Release 12 version 1.1.0 MOS 403537.1 - page 23

This section is comparable to the two paragraphs we have highlighted above (Figure 3 - Page 24 of

189367.1_version 3.0) above with the headings “Limit Access to Security Related Forms” and “Limit

Access to Forms Allowing SQL Entry.”



The latest version doesn’t include a recommendation to “auditing database tables listed” that was

contained in earlier versions. Why? Why has Oracle removed the recommendation to audit the

database tables listed? Is monitoring of the activity in these forms no longer necessary?

From my perspective, the only way to effectively mitigate the risks in these forms IS TO MONITOR the

activities, yet they dropped this guidance in this version. You CANNOT rely on limiting access to these

forms alone. Some users will have access to these forms and pages in a production environment and

the only way to mitigate the risk of the users that have access to these IS TO MONITOR the activities.

Their guidance is simply to ‘know exactly which users have access to these screens.’ Is there nothing

else an organizations needs to do to minimize or monitor risks? Oracle HAD provided the correct

guidance in the Release 11i version of this document. This baffles me…

I believe this lack of guidance is a significant flaw in the document that needs to be remedied. This is the

first of five major problems I see with this document.

Having the above history, now let’s take a look at four other issues I see outstanding related to the

current document.

Four other issues with the current version of the “Secure Configuration Guide

for Oracle E-Business Suite Release 12”: We have identified four other major issues that remain outstanding:

1. Three functions that accept SQL injection have not been identified

2. One of the tables referenced in the document is actually a view

3. A significant table necessary to monitor risks is not included

4. The ability to decrypt encrypted credit card and bank account data is not included

First Issue: Three functions that accept SQL injection aren’t included

The latest version doesn’t include three functions we have identified that allow SQL injection. These

include “Define Custom SQL Fields”, “AutoAccounting Rules”, and “Delete Constraints”. We uncovered

these issues in our work more by chance then by thorough review. I wonder if there are more forms

that allow SQL injection or an operating system to be executed through it that we or Oracle haven’t

identified. The question we have to ask is – why isn’t Oracle reviewing for these types of risks as part of

their development process, peer review process, or release management process? How could it be that

new forms that allow SQL injection in them are being deployed and no one asks the question – should

we add it to the Secure Configuration Guide?

Second Issue: Table reference is actually a view

Here is an excerpt from 1334930.1 which now hosts the high risk tables and is referenced in 403537.1:



Figure 14 - Excerpt from 1334930.1

As we work with customers to deploy our favorite trigger based application (CaoSys’ CS*Audit) to

monitor the activities within these forms, we review the guidance put out by Oracle so that our

monitoring and control design is as complete as possible. When we went to map the table

“JTF_FM_QUERY” we noticed that no such table exists. Therefore, we looked at Oracle’s Technical

Reference Manual (TRM) through their etrm portal. What we found is this…

From etrm – this is a VIEW, not a table.

Figure 15 - etrm for JTF_FM_QUERY

JTF_FM_QUERY could have been a table at one point, based on the above, since the description says

“This view refers to the table JTF_FM_QUERY storing information about the fulfillment queries”.

However, the view Select statement at the bottom of the page clearly refers to the table

JTF_FM_QUERIES_ALL. One can only conclude that the initial documentation was either inaccurate or

the documentation was not updated when the table was changed to a view. JTF_FM_QUERY could

have been a table in 11i or an earlier version and then changed to a view in Release 12. That may



account for part of the confusion. If that was the case, this document should have been updated when

Oracle made the Release 12 version.

This begs the question – is Oracle implementing their own guidance? If they had implemented their

guidance according to this document, they would have noted that this was a view and not a table. So this

causes me to again question the internal controls within Oracle as they run their own software to manage

their business as well.

Third Issue: Table Missing from Guidance

One of the forms that allow SQL injection that we published after being alerted to it by Daryl Geryol of

Navillus Partners is the Collection Plans form in the Quality module. Daryl and I did a webinar in 2009 to

illustrate the way this form can be used to commit fraud. Our example illustrates how a password can

be reset. Any password could be reset using this scheme – the CFO, a buyer, the AP Manager, or

SYSADMIN as we have illustrated. Let’s take a look…



Here are screen shots from that webinar:

Figure 16 - Definition of a Collection Plan

In this case we are defining a Collection Plan to ‘collect’ quality data.



Figure 17 - Collection Plans - Actions

Note that this form allows both a SQL script and an operating statement script to be executed. In our

example, we are executing an Operating System script.



Figure 18 - Operating System script text

In this example we are executing an Operating System script to reset the password of the SYSADMIN

login.

The tables supposedly related to this form were supposedly added in Sep 2011:

Figure 19 - Header of MOS Note 1339430.1 document

Figure 20 - Change log of MOS Note 1334930.1



Figure 21 - Specific tables to monitor related to Collection Plans

The problem is that neither table (QA_PLANS or QA_CHARS) contains the data of the SQL statement or

OS script that is allowed in the form. The table that contains the text is the ALR_ACTIONS table. Here is

the etrm for that table:

Figure 22 - etrm for ALR_ACTIONS table_page 1



Figure 23 - etrm for ALR_ACTIONS table_page 2

When saving the Actions in the Collection Plans form, the OS script text and the SQL statement text are

stored in the “Body” column of the ALR_ACTIONS table. Organizations which have been relying on the

guidance of Oracle since 2011 assuming that auditing the QA_PLANS and QA_CHARS table is sufficient to

audit SQL injection or an ad hoc SQL statement, would have been misled. This again begs the question

- is Oracle implementing their own guidance? As we noted above, if Oracle had implemented their

guidance according to this document, they would have noted that the data related to this field is not in one

of these two tables. So this causes me to again question the internal controls within Oracle as they run

their own software to manage their business as well.



Fourth Issue: Document Hasn’t Been Updated for the Ability to Decrypt Credit

Card and Bank Account Data Oracle provides its customers the ability to decrypt certain encrypted credit card and bank account data

that is likely subject to PCI-DSS compliance and other compliance requirements.

The following is a list of concurrent programs that can decrypt encrypted data in any instance –

production and non-production:

Decrypt Credit Card Data

Decrypt External Bank Account Data

Decrypt Transaction Extension Data

Decrypt Credit Card Transaction Data

Payments Scheduled Decryption

These are also contained in a seeded Request Group:

Decrypt Sensitive Data Request Set

Risks: These concurrent programs and request set can decrypt credit card and external bank information (i.e.

supplier bank accounts). The programs could be run in either a production or non-production

environment. Once unencrypted, the data could be easily stolen through a variety of mechanisms –

direct database query, through application access (form or HTML page), use of SQL forms, or running a

concurrent program.

To understand the current risk in your production and non-production environments, ask the IT

department these questions:

1. Do any users have access to these concurrent programs or the request set?

2. What controls are in place to prevent someone from adding these concurrent programs or the

request set to another Request Group?

3. What controls are in place to prevent someone from registering the same executable (e.g.

IBY_CREDITCARD_DECRYPTION) as another Concurrent Program

4. What controls are in place to prevent someone from entering one of these executables for an

existing Concurrent Program to which they have access already?

5. What controls are in place to someone from setting up a new executable calling the same code

(i.e. oracle.apps.iby.scheduler)?

6. What controls are in place to someone from changing an existing executable to call the same

code – particularly an executable to which they already have access through a concurrent

program assigned to them?

7. How are you mitigating the risks related to ad hoc SQL statements in forms that allow SQL

injection? Do you know who has access to these forms? Are you monitoring the activity in these



forms via log-based or trigger-based software? (See more in MOS Note: 403537.1 and

1334930.1)

8. Are there any unsecured database logins that could provide someone with privileges to any of

the underlying tables related to these forms?

To understand how many users have the ability to execute on one of these first six schemes, you’d need

to understand who has access to maintain users, change or add request groups, change or add

concurrent programs and change or add executables. These forms are typically found in the System

Administrator, Application Developer, Application Administration, and System Administration

responsibilities. However, they could be added to any menu which is why monitoring the activity in the

Menus form is critical.

Recommendations: Following are recommendations related to these risks:

Your provisioning process should consider these risks. Ideally, no one has access to these

concurrent programs in any environment. How are you preventing access to these in your non-

production environments where more users have access

Identify which request groups and request sets, if any, contain these concurrent programs.

Remove from ALL request groups

Identify who has access to add or change data in the Concurrent Programs, Request Groups, and

Executables forms.

Each of these concurrent programs should be disabled. This would mean they couldn’t be used

even if they are assigned to a request group.

Changes to these objects (Concurrent Programs, Request Groups, and Executables) should be

monitored via a trigger or log-based solution that provides near-real time visibility to changes.

Particular attention should be given to the re-enabling of these programs or removing the end-

date of the request group(s) that contain these programs.

Your cloning process should change or scramble the data when cloning to non-production

environments – especially when the security in your non-production environment(s) is less

stringent then in production.

An IT quality or IT audit function should be tracing 100% of the changes made through these

forms to the approved changes to test for unapproved changes.

In introducing the ability to decrypt credit card and bank account data Oracle has introduced a series

of risks that organizations need to take seriously. If your organization has credit cards stored, the

risks are significant and the impact on PCI-DSS compliance could be serious.

Conclusion



I have identified five major issues with this document. Why isn’t Oracle updating their documentation

when they release new forms that allow SQL injection? Could it be the problem is with their

development standards and peer review process? Are they not identifying these risks as part of their

development process? If so, isn’t that a bigger concern. Perhaps this is why they have backed off

making ‘best practice’ recommendations.

Why doesn’t Oracle see the ability to decrypt credit card and bank account data as a security risk?

How is it these deficiencies exist in their documentation (failure to identify that JTF_FM_QUERY is a view

and that they aren’t monitoring the ALR_ACTIONS table) and have gone unnoticed for over three years

from the release of this gudiance in September 2011? The only logical conclusion is they are not

implementing and testing their own guidance.

Over the past few years, we have noted deficiencies in the easiest of these recommendations – seeded

application users and seeded database users. We have also identified four new functions which allow

SQL injection that have not been updated in their documentation. At one point, there were five, but

two of them have been since added to their documentation. We have published the three functions

above.

My concern is that organizations relying on this guidance have a false sense of ‘security’ if they follow

this guidance. Following this ‘guidance’ is certainly necessary at a minimum, but additional risks exist

that Oracle isn’t adding to their documentation. We’d love to see Oracle increase its effectiveness

which can only be done by taking a hard look at their internal standards and setting a regular schedule

for testing their guidance and updating this documentation. Compliance with this document is

necessary, but with Oracle, sometimes you need to fill in the blanks…



About ERP Risk Advisors: ERP Risk Advisors is a leading provider of Risk Advisory services for organizations using Oracle Applications. We provide consulting and training services related to compliance, security, risk management, and controls. We also assist organizations in implementing GRC-related software from industry-leading companies.

About Jeffrey T. Hare, CPA CISA CIA: Jeffrey Hare, CPA CIA CISA is the founder and CEO of ERP Risk Advisors. His extensive background includes public accounting (including Big 4 experience), industry, and Oracle Applications consulting experience. Jeffrey has been working in the Oracle Applications space since 1998 with implementation, upgrade, and support experience. Jeffrey is a Certified Public Accountant (CPA), a Certified Information Systems Auditor (CISA), and a Certified Internal Auditor (CIA). Jeffrey has worked in various countries including Austria, Australia, Brazil, Canada, Germany, Ireland, Mexico, Panama, Saudi Arabia, and United Kingdom. Jeffrey is a graduate of Arizona State University and lives in northern Colorado with his wife and three daughters. You can reach him at [email protected] or (970) 324-1450. Jeffrey's first solo book project "Oracle E-Business Suite Controls: Application Security Best Practices" was released in 2009. Jeffrey has written various white papers and other articles, some of which have been published by organizations such as ISACA, the ACFE, and the OAUG. Request these white papers here. Jeffrey is a contributing author for the book “Best Practices in Financial Risk Management” published in 2009. LinkedIn: linkedin.com/in/jeffreythare Twitter: twitter.com/jeffreythare Blog: jeffreythare.blogspot.com



Appendix A – Excerpt from MOS Note 403537.1

This is Oracle’s Appendix H from their MOS Note 403537.1

with oracle, sometimes you need to fill in the · pdf filewith oracle, sometimes you need to...

Documents