with oracle sometimes you need to fill in the blanks_final

8/10/2019 With Oracle Sometimes You Need to Fill in the Blanks_final

1/22

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.1Secure 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 fourother issues that wed 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, lets cover some background:

Background Related to Oracles 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


2/22



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 tablesas per thisguidance.

Figure 3 - Page 24 of 189367.1_version 3.0

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


3/22



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


4/22



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


5/22



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 Oracles 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:


6/22



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?

Ive 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)


7/22



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)


8/22



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


9/22


10/22



The latest version doesnt 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 lets 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 arent included

The latest version doesnt 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 havent

identified. The question we have to ask iswhy isnt 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 questionshould

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:


11/22



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 Oracles Technical

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

From etrmthis 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


12/22


13/22



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.


14/22



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.


15/22



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


16/22



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


17/22



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 Bodycolumn 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.


18/22



Fourth Issue: Document Hasnt 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 ITdepartment 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

codeparticularly 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


19/22



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, youd 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 couldnt 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

environmentsespecially 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


20/22



I have identified five major issues with this document. Why isnt 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, isnt that a bigger concern. Perhaps this is why they have backed off

making best practice recommendations.

Why doesnt 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 arent 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 recommendationsseeded

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, buttwo 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 isnt adding to their documentation. Wed 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


21/22



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


22/22



Appendix A Excerpt from MOS Note 403537.1

This is Oracles Appendix H from their MOS Note 403537.1

with oracle sometimes you need to fill in the blanks_final

Documents