Thursday, October 29, 2009

Oracle doesn't have a clue - take 2: Delegated Authority...

Here is another one.... An email from a user to one of the listservers I manage:

"Hi all. Anyone know of a means to report on current user settings for worklist
access and vacation rules? We would like to be able to review which of our
users are using worklist access and vacation rules, and to whom they have

Ideally, there would be a seeded report in Oracle. If not, perhaps some SQL or
knowledge of which tables hold this information."

Delegation of approval authority via worklist access or vacation rules could violate company policy and could subject a company to a nasty-gram from their auditors ala a control weakness in their SOX testing. If an auditor really wanted to be nasty about it, they could give an organization a material weakness (or at least a significant deficiency) IMO because this allows someone to delegate their approval authority and, in some cases, the delegation isn't recorded or reflected anywhere in the system. For example, a CFO could delegate their PO approval or Journal Entry approval authority to the janitor, their secretary, or a staff accountant who could act on behalf of the CFO to approve a journal entry, PO, or anything done via Oracle Workflow.

Cool functionality when you look at it on an operational basis. Jane Doe, CFO, takes a week off to ride on her 200 foot yacht and someone needs to approve things when she is gone so that business doesn't come to a screeching halt. Case closed, right? However, in some cases, when Jane delegates to another employee, it still looks AS IF Jane made the approval AND... no record of this delegation is made in the system... or at least there are NO REPORTS out of the box that records the delegation (I suspect the audit trail doesn't even exist...).

Nice job Oracle!!! We wouldn't want that type of information in the case of an audit, would we?

More to come...

Jeffrey T. Hare, CPA CIA CISA

SQL Forms webinar reminds me that Oracle doesn't have a clue

I did a webinar this week training auditors and other practitioners about the risks related to SQL forms and the necessary controls to monitor activity within them. Essentially these forms allow users to run any SQL statements (and in some cases OS scripts) in them. One attended said "giminy frickin christmas... you would think ORA would know that sql injection is a potential issue?
All I could say is 'amen.' I can buy into the fact that Oracle wants to allow flexibility in the use and of their applications and be 'open' in this way. However, not putting controls in place to monitor the activity done through these forms is inexcusable on many levels.

What is more inexcusable IMO is the fact that Oracle continues to put their head in the sand. I have sent letters to Charles Phillips, Steve Miranda, and Chris Leone outlining this risk among a ton of others I have identified and... not a peep. In Metalink Note 189367.1 they outline these forms, their risks, and suggest controls (i.e. trigger based audit should be deployed), but do they DO anything about it like say... build that into the core application? The answer to that is..... No.

Note 189367.1 also fails to mention one form that a colleague, Daryl Geryol, pointed out to me that allows both SQL and OS scripts. Many of us have come to love this as one of the 'undocumented features' provided by Oracle.

Hellllllloooooooooo... Oracle.... is anyone home? Your customers are suffering under the burden of identifying and addressing these undocumented features and poor design. It is time to wake up and solve these issues once and for all.

For the past two years or so I have been trying to get Oracle's attention on some of these matters. Instead of thanking me for pointing out some of these issues, I get an email from an exec asking me to take his email address of my email list. Nice strategy!!!

Jeffrey T. Hare, CPA CIA CISA