Another example of Oracle not focusing on Best Practices

Look at Metalink Note 227010.1. This note is for "Script to check for Default Passwords being used for some common usernames."

Why just 'common' usernames? Why not all usernames? Why can't they maintain this document and the related test scripts for all known usernames? Would it be so difficult to put into their development QA process to update this document when a new schema is added or another type of default database user is added? It is ironic that this script published doesn't even take into account all the usernames suggested to monitor in their own "Best Practices" document - 189367.1 and 403537.1 which aren't being maintained (reference earlier blog).

Yet another example... Oracle, where is your Norman?

Manage Proxies... A great R12 'feature'

Manage Proxies is new functionality that allows delegation of security to another user. Whereas Worklist Access and Vacation Rules are a delegation of approval authority, Manage Proxies is a complete delegation of security to another user.

Fortunately, The Manage Proxies functionality is only available if the Manage Proxies role is granted to the user. This role can only be granted to a user via the User Management module.

The manage proxies functionality is extremely powerful and, therefore, extremely dangerous. Unfortunately, there isn’t any out-of-the-box report (similar to the Users of a Responsibility report) in the User Management module that provides you with a list of users that are assigned roles such as the Manage Proxies role. All inquiry related to the User Management module needs to be custom built.

Manage Proxies in the next in a long list of 'features' that may be a good idea from an operational perspective, but a nightmare from an internal controls perspective, especially without the necessary controls-related monitoring that should could 'standard' with this functionality. Oracle needs to build in the necessary monitoring and auditing requirements into the design of each of their new features. This is one area where they seriously missed the mark. Let's hope they've refined their processes and talent in Fusion Apps.

Regards,
Jeffrey T. Hare, CPA CIA CISA

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

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