Tuesday, August 30, 2011

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

Wednesday, August 17, 2011

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!

Jeffrey T. Hare, CPA CISA CIA

Tuesday, June 28, 2011

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

Jeffrey T. Hare, CPA CISA CIA
LI profile: http://www.linkedin.com/in/jeffreythare

Tuesday, June 21, 2011

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.

Jeffrey T. Hare, CPA CISA CIA

Friday, April 1, 2011

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.

Jeffrey T. Hare, CPA CIA CISA

Tuesday, March 22, 2011

GL: Statistical Journals -- not suppport by journal approval workflow

I saw this question on OAUGnet and thought I'd respond to it...

"Can anyone verify this: In R12 G/L, the seeded Journal Approval workflow (WF) will not route a statistical journal for approval regardless of the journal's source."

Here is what I found in My Oracle Support
MOS [ID 1076823.1]
"Currently Statistical journals do not require approval as per standard functionality.

The only limitation you can make is that you can use the profile option Journals: Mix Statistical and Monetary to prevent STAT and monetary lines on the same journal.
It is not possible to restrict entry of STAT lines by user."

Not really sure I understand how this profile option 'limitation' addresses the issue, but it is there nonetheless... Sometimes support analysts just hate saying "no Oracle doesn't provide that functionality"...

Jeffrey T. Hare, CPA CISA CIA
ERP Risk Advisors
send me a linked in request - jhare@erpra.net

Friday, March 18, 2011

Does your organization maintain proper workflow history?

Reviewing docs for a client today and ran across this comment in a document "I believe that there are audit reporting requirements to provide evidence of workflow approvals of changes to compensation or position-related edits"

Question: Does your company property maintain workflow history for approvals? Let me help with another question to ask your DBAs - how often are workflow history tables purged? Your homework for the day...

Based on my experience, many organizations do not have the evidence for such approvals if an auditor asks for this type of history.

I have enabled anonymous comments to protect the identity of those responding. Please respond anonymously with any comments.

Wednesday, March 16, 2011

Ad hoc SQL statements in Production environments by a developer

I had a client email me today the following:
"Is it normal to have IT dev/support group run SQL queries in production to fix errant/stuck data in an Oracle EBS shop? As an example have an data issue that is listing the load weight as 0LB and have IT fix that through an SQL query directly in production?"

Here was my response:
"No. This is not normal for two reasons:

1. Developers should not have access to run scripts in Prod. Any scripts should be developed by the developers, executed by the DBAs in a non-prod environment, tested by an end user then executed by the DBAs in Prod.

2. May or may not be an issue... SQL scripts can either be supported or not supported by Oracle depending on how they are written. If they call a public API, generally they are supported. If there is no public API, Oracle should be providing the data fix script. Otherwise, they'll not support it and the execution of it may void your support agreement."

Thursday, February 24, 2011

Top 10 Fraud Risks in an E-Business Suite Environment

Great response to Top 10 Fraud Risks in an E-Business Suite Environment. Had some technical difficulties with GoToWebinar (a first for me). Not sure if the full webinar was recorded. Will try to post this our website as well as the slides as soon as possible. May be doing a follow up webinar.

Thanks to Steve Kost from Integrigy for hosting today's webinar.

Jeffrey T. Hare, CPA CISA CIA
LinkedIn Profile

Wednesday, February 16, 2011

Great piece: Matt Taibbi's Latest: " Why Isn't Wall Street In Jail?"

Highly recommend this read:

For those of you that spent countless hour preparing for Sarbanes-Oxley compliance and labored night and day, rest assured... it has accomplished nothing... Your only consolation is that is many of you have found gainful employment because of of SOX.

Actually, to be fair, SOX has greatly increased the awareness of, documentation of, and execution of internal controls for many organizations. It has not, however, helped cure the systemic fraud which was part of what lead to SOX.

Jeffrey T. Hare, CPA CIA CISA

Wednesday, February 9, 2011

Oracle's E-Business Suite: Overly complicated security model!

Oracle has its feet firmly planted in two security models - the 'legacy' model is that often referred to as Function Security. The 'new' model is what Oracle attempted to evolve into an RBAC model using the User Management module. What they have created is an overly complicated mess that frustrates even the most experienced security administrators.

One frustration is the background process that 'synchs' the data between the two models (there may actually be more than two...) For example, a responsibility made in the Users form doesn't show up for several minutes in the home page that you receive when you log in. And new functions added to menus often aren't 'available' to be used for several minutes after they are added to a menu.

While I hope Oracle doesn't make the same mistakes in the development of its Fusion apps, those companies planning to continue using Oracle's E-Business Suite have a rude awakening... Oracle continues to make its security model more complicated and frustrating. Double the time you anticipate developing security in your R12 implementation or R12 upgrade. You'll need it to troubleshoot issues...

Tuesday, February 8, 2011

Why doesn't Oracle provide view only access to their data via forms???

I'll continue to say it... Oracle doesn't have a clue how to build their applications to meet common GRC and internal control requirements. Those that have followed my work for long know my feelings on this topic...

In the traditional forms development standards Oracle has provided organizations with the ability to easily create a custom "read only" form by setting the QUERY_ONLY=Yes parameter. However, in OA framework forms, no equivalent process has been provided. Why not? Because they don't understand how companies have to customize (personalize) the application in the real world.

EVERY form/web page should have an equivalent inquiry form out-of-the-box. Auditors and others in the organization such as Business Analysts need access to such data in Production environments and NOT via Discoverer, OBIEE, or another other ad hoc method.

Thanks for listening to my rants...

Jeffrey T. Hare, CPA CISA CIA

Monday, January 17, 2011

The politics of a project and the impact on addressing risks

Just finishing a project where we helped design and implement application security for a global rollout of a manufacturing company. The politics of a project never cease to amaze me and every project has its own unique politics. I’ve seen it all... A well run project takes strategic vision and the proper leadership to support all the objectives. More often than not, a project is well supported from an operational perspective, but does not have the same level of support or leadership when it comes to security and controls. This is why using a firm independent form the system integrator is so important. Without a proper understanding of the risks involved in implementing the applications from a project as a whole or an individual element such as application security, management is running blind. In many cases, management does not have the experience or expertise in implementing ERP systems, in general, or the specific ERP system. Having both types of knowledge is critical to being able to effectively manage a project.
All too often, the bidding process for system integrators lends to the ‘get it done on time and on budget’ and ‘to hell’ with things like properly designed security or implementing proper internal controls PRIOR to go live. Without strong project leadership, often proper security and controls never gets implemented because post-go-live funding is difficult to attain because the ‘core’ project is over-time and over-budget.
I suspect this blog may hit a few nerves and am looking forward to any comments.