2013 will be the year folks learn about Oracle's Skeletons in their E-Business Suite Closet...  
Post #1:  Why portions of Oracle are unauditable and one of the greatest security risks

Welcome to 2013!  Happy New Year to all.  2012 was a great year for ERP Risk Advisors as customers took advantage of our industry-leading expertise to implement and/or strengthen their security and controls for their Oracle environment.  Towards the end of the year I had two customers tell me representatives at Oracle thought I was 'mean' or 'too critical' of Oracle as a corporation.  Perhaps I haven't made my case clearly enough about why I believe Oracle is a colossal failure when it comes to building their applications and their GRC software so I've resolved to have 2013 be a year of transparency.  I intend to be specific about WHY I think Oracle needs to do a better job.  Some of the items will be very detailed and some will be higher level and strategic in nature.

So here goes... I'll start with a big picture item.  A customer buys software from Oracle to run their Enterprise - ERP software like Oracle E-Business Suite.  A judicious buyer would expect a reasonable audit trail to be in place for high risk transactions such that an auditor could review what happened from the inception of the transaction to the present - a fairly basic audit requirement (putting on my CIA and CISA hat).

So... if I were to tell you that an application user with access to a certain form could execute an ad hoc SQL statement or operating script directly from the applications (not using a SQL query tool and a database login), wouldn't you expect that the application would be built to provide a detailed audit trail of that activity, given the risk of that transaction?  After all, some critical transactions within the applications have that functionality - like salary changes for an employee.  So if Oracle understands that some transactions such as salary changes NEED a detailed history, it is clear that they get the concept - that being some critical transactions need to have that history.  So, if they DON'T provide that history for transactions where an application user (like a developer or a manufacturing associate) could execute an ad hoc SQL statement, what does that say?

To me it says whomever is developing such forms is TOTALLY ignorant of the most basic understanding of what controls ALL organizations using their applications needs.  And you as a buyer of their software actually thought they knew how to develop applications.  Silly you... they are a technology company.

Ok.  So now I guess I understand why Oracle thinks I am 'mean' and 'too critical'.

To be fair when I publish a harsh criticism of Oracle, I will also publish a recommendation and some practical steps for my brethren in the internal audit field.

Oracle:  If a form or any other mechanism you are using in the application layer (OA Framework page, concurrent program, etc. etc...) allows a user to enter and execute a SQL statement or an OS script, here is what I'd expect from a controls perspective.  First, a security administrator should be able to TURN OFF this feature - yes - a preventive control should be able to be put in place such that this form or mechanism would not allow the SQL statement or OS script to be executed.  Second, for those objects that a customer wants to use (and therefore, does not turn on the preventive control per #1), there has to be an audit trail of what was done (kinda like you already do in the HR module for salary changes... hint hint).

Auditors: OK.  So if you really want to be freaked out about how 'open' and 'free' Oracle software is, ready MOS notes 1893671. (for 11i) and/or 403537.1 (for R12).  So in these docs Oracle admits this flaw and has had this 'feature' identified for at least 10 year (see May 2002 copyright on 189367.1), but has done nothing about it.  The most recent release of this document (403537.1 with a last update of Oct 2012) no references a document 1334930.1 called "Sensitive Administrative Pages in Oracle E-Business Suite" which now identifies over 50 forms and pages that are 'sensitive' - many of which allow SQL injection or execution of OS script directly from the application layer.  And if your IT department didn't have the foresight to implement an appropriate EXTRA software solution to build an audit trail (as per my #2) above, you have little to no visibility about what users with access to these forms and pages are doing with them.

Jeffrey T. Hare, CPA CIA CISA
Self-appointed audit trail evangelist (maybe now you know why...)
Industry analyst, author, and consultant

About the author: http://erpra.net/leadership.html
About ERP Risk Advisors: http://erpra.net/aboutus.html

Article published by OAUG: Why Implementations Fail, Beyond the Obvious

We are excited to announce that OAUG just published an article I wrote called "Why Implementations Fail, Beyond the Obvious". The article can be downloaded at: http://erpra.net/files/ERPRA_Why_Implementations_Fail_Beyond_the_Obvious_OAUG_Insight.pdf.

Please read the article and provide any comments on my blog. Feel free to send me any questions or comments at jhare@erpra.net.

Regards,
Jeffrey T. Hare, CPA CISA CIA
CEO, ERP Risk Advisors

Basics of MOAC and Inherent limitations

In R12 of E-Business Suite, Oracle introduced Multi-Org Access Control (MOAC) to provide users with the ability to view data and process data across operating units. This new functionality is welcome by organizations that process data and want to view data across operating units – such as those that have a shared service environment. The implementation of MOAC is simple, but has some limitations. MOAC cannot be implemented in much of the world because of the need to use localizations and apply such localizations at the Responsibility level.

Inherent limitations
I queried two Payables users from in the Solution Beacon 12.1.2 Vision public domain environment – one for Austria and one for Germany. Localizations (JG: Territory and JG: Product) profile options were applied to these two responsibility in order to implement country-specific localizations for Austria and Germany. If you had a shared service center in Germany, for example, you wouldn’t be able to combine these two countries into a single responsibility using MOAC because there is no way to apply the localizations to the combined responsibility because you’d need to set the JG: Territory profile option for both Germany and Austria which the profile options form doesn’t currently support. I logged an enhancement request on behalf of client (Enhancement Request 10361672) that Oracle is currently considering. I encourage you to log an SR and throw your support behind this enhancement request.

White paper continued... Full white paper on this topic can be downloaded at: http://erpra.net/bestpractices.html

Configuration Change Management process - should end users own it?

I am dealing with a client that has end users make significant changes to the configurations in their module. They are re-implementing and I am advising them on changes to security and controls. I thought this email would be of interest to other companies so I thought I'd share a bit of it.

"I have some feedback regarding your configuration change management process that I wanted to pass on to you. I sensed some strong feeling about it in our meeting yesterday and didn't want to rock the boat so I thought email would be a better mechanism to provide you feedback and allow you to reflect on the recommendations.

I believe strongly in informed and educated end users. The more knowledgeable users are about the system, the better the processes they own. I am a strong believer that process owners 'own' the process, including how the applications work. This includes an understanding of the setups / configurations related to the module and those setups / configurations that are core to the entire suite of applications.

However, I rarely see end users have responsibility for making changes to key configurations in the application - what I call the configuration change management process. This is for two primary reasons. First, there is additional risk from an SOD perspective if end users have the ability to control the configurations for the processes they use. An example that we talked about yesterday is configurations related to the journal approval process. I'd rather not give the end user the community the ability to override a key control without it being formally documented and approved. Giving end users control over these configurations does just that. This could pose a serious problem when auditors come into to test the control under AS5 and learn that changes to the configurations may have been made without proper approval. Second, end users are typically not good gate-keepers for the change management process, are not trained on it, and are not supervised by management that has primary responsibility for implementing and controlling the change management process.

As it relates to the discussion yesterday, we specifically talked about Bob's role in the GL module. However, we also need to address the risks in other analysts like Bob throughout the application - those supporting AR, AP, HR, Payroll, Purchasing, etc. Do you have the same level of confidence in their ability as you would with Bob? What happens when Bob retires or leaves the company? Are you going to have the same level of confidence in her replacement?

The purpose of the change management process is, among other things, to protect the integrity of the system, its data, and the business processes which are supported by the system. From what I understand, part of the reason that ABC Company is re-implementing relates to configuration changes that weren't thoroughly thought through and/or tested in 11i. I am not necessarily saying that having IT manage those changes would have saved you from having to re-implement, but I can say that at least a solid configuration change management process will give you a more defined process to follow - documentation, impact analysis, test plans, approvals, etc. - and give you a better shot at maintaining the integrity of your system after you re-implement in R12.

So my recommendation is this... as part of the risk assessment process I am doing, let's have a discussion, by module, about what configurations should go through the configuration change management process, then design security and the configuration change management process to allow IT to make those changes rather than the end users. In my opinion and based on my experience, this will give ABC Company better controls (preventive versus detective) and a better chance of maintaining the integrity of the system."

Thoughts are welcome!

Regards,
Jeffrey T. Hare, CPA CISA CIA

Two new web blogs in past few days

You Tube channel has all web blogs. Links are also available on our website.

Here are the topics for the latest two:
-Impact of Responsibilities using a custom application on SLA programs
-AR Adjustment Limits System Design Flaw

Regards,
Jeffrey T. Hare, CPA CISA CIA
jhare@erpra.net
LI profile: http://www.linkedin.com/in/jeffreythare

Web-blog: Consolidations submenu design flaw

Here is the first web-blog I've done. Hopefully today's topic will be of interest to you and future topics will be as well. Today's web blog can be accessed at: http://erpra.net/bestpractices.html.

Contact me with any questions or suggestions on future blog topics at jhare@erpra.net.

Regards,
Jeffrey T. Hare, CPA CISA CIA

Change their password upon first login/admin reset

Got a question today about password resets:

"I am trying to figure something out. How do we validate that Oracle forces the user to change their password upon first login/admin reset? I thought it was something in the profile options. Thank you for the help."

My response...
Inherent in the system. Can't be turned off. Not controlled by Profile Options.

There are a lot of risk involved with password resets. With plenty of hacking / backdoor access to the database and privileged users that have the ability to reset passwords, this should be a critical control for your organization. You need a policy and related procedures on how/when p/w resets can be requested and who can reset the p/w. Then, because of the risk, the process owner (system or security administrator, security auditor, etc) should regularly check with the owner of the accounts to make sure the p/w resets were valid and not some nefarious behavior.

My two cents FWIW.

Regards,
Jeffrey T. Hare, CPA CIA CISA