Posted by: Shayna Garlick
Oracle, Oracle applications, Oracle security
Users may be worried about the obvious security risks associated with putting data in a cloud, but what about those Oracle security risks which aren’t as obvious?
Collaborate ’09 speaker Jeffrey Hare, CPA, CIA, CSA from ERP Seminars, addressed some of these risks Tuesday in his session, “Top 10 Application Security Risks and Related Best Practices for companies running Oracle E-Business Suite.”
The majority of these application risks described by Hare are internal – so, even if you’re not putting your data out on the internet, you’re certainly not free from unwanted users accessing your systems.
What did Hare list as his the top 10 risks for E-Business Suite users, and what did he recommend for dealing with them?
10. Upgrade risk: To avoid upgrade risks, Hare said end user security should be designed from scratch, using completely custom menus and sub menus. He also advised against using AZN menus.
9. Risk analysis: Hare said it’s important to look at risk analysis holistically, from outside the system to access and processes inside the system. He recommended choosing a risk analysis firm that specialized in E-Business Suite, and to make sure to take into account material risks as well as sub-material risks.
8. Relying on auditors: Be aware that many auditors do not take into account risks of sub-material fraud and often fail to look at the business process holistically. He recommended starting with Procure- to -Play, hire a firm that specializes in fraud risk to do a risk assessment beyond SOX and review their conflict matrix before hiring them.
7. Security changes- Change management process: The change management process is not something you can afford to get wrong, Hare said. It should be very specific and include menus, responsibilities, roles, request groups, functions and profile options. All security changes should go through a change management process.
6. SQL Forms: All activity in SQL forms should go through the change management process just like an UPDATE SQL statement would, including peer review and code freeze, Hare said. All activity should be audited via trigger or log-based technology.
5. High risk fraud forms: Hare said to be aware of forms subject to high fraud risk such as banks, remit to address, locations and suppliers. Define a procedure for changes and additions such as a form and procedure for new suppliers.
4. Password hacking: Hackers can get into production applications and database accounts via a published exploit code. Hare recommended reading the white paper Oracle applications 11i: Password decryption for solutions.
3. Override of workflow policy: It’s important to have a process in place regarding delegation of authority for processes such as worklist access and vacation rules, Hare said. Figure out the allowable delegation of authority within your company, and audit and trace back your changes.
2. Support personnel access: Lack of inquiry only access and non-production support instance is a problem within organizations, Hare said. He recommends using SysAdmin Views, identify high risk single functions and SOD issues and to take the same precautions with security analysts as with end users.
1. Utilities: diagnostics: Hare stressed that no one should have access to these profile options in the production environment – they should be left off the production environment and go through the change management process.
What risks and/or best practices could you add to this list? If you’re an E-Business Suite or other application user, what has or hasn’t worked in terms of security and what do you think is worth your time and investment?