Saturday, January 12, 2013

Webinar Jan 17: Profile Options - What are they and why should auditors care?

Profile Options - What are they and why should auditors care?

Profile options in the Oracle E-Business Suite have significant implications on security and internal controls.  This educational webinar will give you an understanding of profile options, how they are set, and examples of issues when setting them inappropriately.  We will discuss the necessary policies, procedures, and controls needed to properly build and maintain profile options.  Finally, we will discuss audit procedures internal auditors should consider.

Sign up: https://www1.gotomeeting.com/register/741840792

Another one coming up soon:

Feb 12: SQL Forms in Oracle E-Business Suite - what are they and why should auditors care?
Registration: https://www1.gotomeeting.com/register/745316449


Friday, January 4, 2013

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