<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

Oracle EBS Security, Last But Not Least

last piece.jpgWhen installing or upgrading Oracle EBS it seems that security is always the last thing on the implementation plan. As a result the security setup is given the least amount time before the go live date, if not done after going live.  With the stress of a shrinking timeline, it’s easy to miss something. With this in mind we have collected a few thoughts to help you efficiently secure your Oracle E-Business Suite Environment.


 

First is to remember the rule of least privileges. When designing access roles, it’s important that every Oracle EBS user has only the access necessary to fulfill the responsibilities of that role. You don’t want to trust that your employees can handle the keys to the kingdom or their department for that matter.  User mistakes are one reason, but it also opens you up for potential fraud.

 

For instance, if we give an AP Clerk the responsibility to create vendors and also pay those vendors within their privileges, without additional controls in place - you are putting the company at risk. It’s too easy for this AP Clerk to create their friend as a vendor; and start taking your money. It may not be long before invoices for a new vendor are being paid, despite the non-existence of the stock being invoiced by that company.  Due to this potential risk and others like it, Segregation of Duties must be used and preferably designed in advance. You wouldn’t build a boat without a plan, don’t try to build your security without one as well.

 

Second, Super Users are dangerous! We’re not saying the users themselves are dangerous, but their access is another story. Allowing ALL target type privileges, and ALL resource privileges to Oracle EBS can clearly be allowance for fraud, but more likely allows for costly user errors. 

 

More than once has it happened, a super user is created to clean up a vendor database. The Super User was meaning to delete a single vendor, then the entire vendor database was deleted by accident.  Want options for reducing the chance of this happening to you?  Limit the time a user can have super access, when an option - create a Super READ-ONLY role, and finally implement supervisory controls to maintain risk tolerance for Super Users.

 

Our third suggestion, track changes. Change tracking can act as your back up security.  You should know who is changing your data, what was changed, when it was changed; especially vendor and customer data.  Auditors generally suggest these two for continuous tracking and regular review as a means of finding fraud and errors.  This is important for financial security with the vendor data and privacy rights for customer data.

 


Perfect example, say a company has multiple plants across the country.  The plants share a vendor database, but produce different end products.  Plant one found that it could save 20% by changing the vendor it uses for a cog that only they use, so they delete the old vendor.  The problem is that plant 2 and 5 still use materials from the now deleted vendor. Using a tool like Fastpath Audit Trail you are able to find out when this happened and reverse the issue, and subsequently re-educate the culprit.

 

Your security setup may be a last step, but it shouldn’t be last on the mind.  Prepping a security design that limits user access, recognizes segregation of duties risks, and tracks the right data changes, can make the actual security implementation fast and efficient.

Watch the Webinar  The Power to Manage, Enforce,  and Optimize Oracle EBS Security