Oracle Applications DBA Blog

Oracle Applications Security Checklist

Often the default installation of Oracle Applications itself might not be secure enough specially when you are doing a production installation. Also since your applications would be likely to be subject to audits its vitals that you secure your installation as far as feasible. The default installation of Oracle Applications comes with a number of default password both at the application level and at the database level to point out a example. The current post speaks about the general checklists which can help in securing your Oracle Applications installation. The list is not an exhaustive one and also it does not deal with the exact technical steps required in implementing the checks.

• Change the passwords for the seeded Oracle Applications accounts. A base installation of Oracle Applications comes with more that 20 seeded applications accounts. You must change the passwords for them and preferably disable most of them with the exception SYSADMIN and GUEST.
• Change the passwords for database user accounts which includes the APPS,APPLSYS and the database user ids for all the products installed with Oracle Applications. You must use FNDCPASS to do this change. In case you are on RUP3 you could also user the 'ALLORACLE' option to the password for all the schemas in one go.
• Avoid creation of a APPS Read Only Schema. It is a general practice to create a READ ONLY SCHEMA in Oracle Applications inheriting read only access to objects accessible to the APPS. This only results in the newly created user having access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID. So do not create any such account on your production unless you date your auditor.
• Implement Validate Node Checking. By default this is enabled in all default installations starting from 11.5.10 onwards. In case this is not there you can implement the same through sqlnet.ora. Though it may be a tedious job in cases you have to access your Database from a large number of hosts. But again on production systems it is vital that you implement this check.
• The APPLSYSPUB account has a default password which cannot be changed. The sole purpose of having this account is to enable the login validation in Oracle Applications. Check and ensure that no unnecessary objects are associated or accessible with this schema.
• Change the password for the GUEST application user, The password for the GUEST account should be changed from the default of ORACLE or GUEST. Change this using metalink Note ID 396537.1.
• Enforce password polices like expiry time while creating a new Oracle Applications user.
• Oracle Applications release 11.5.10 introduced a new User Management(UMX) module. When new users are created via this module it ensures a strong password policy to be adopted for them by default. Implement UMX if you are on 11.5.10 or higher. It also streamlines your responsibilities mapping.
• Avoid using generic Oracle Applications user accounts, for the propose of scheduling concurrent programs or running batch jobs.
• You must also enable logging for your Oracle Applications Database listener. This helps you trace back all connections to your database and detect any unwarranted ones.
• The default installation of Oracle Applications does not have a password associated with the database Listener. You must change this and make sure that at least that your database listener is password enabled.
• Upgrade to the latest certified database with your version of Oracle Applications, for e.g. with 11.5.10.2 upgrade to the 10g release 2.Upgrading to the latest certified database release comes with the advantage of a fewer security risks.
• Apply the latest Critical Patch Updates which are release by Oracle at every quarter. A CPU release addresses priority security threats identified by Oracle. Most of the CPUs are cumulative in nature.
• Review and apply the latest Security Alerts released by Oracle pertaining to Oracle Applications.
• Implement autoconfig in your Oracle Applications, though autoconfig is implemented by default in all latest releases of Oracle Applications ion case your installation is not autoconfig enabled you must implement it as autoconfig includes the latest security fixes also.
• Enable auditing at the database level to include user sessions database links as well as audit sessions even if you do not plan to implement a full fledged auditing of your database considering the overheads involved.
• Enable Oracle Applications Audit Trails to include at least the critical Oracle Applications Tables. Be careful not to overdo the auditing as it can severely impact the performance of your applications. Also enable the sign-on audit to from level in Oracle Applications.
• Disable all access to the developers to production. This might not earn you a lot of friends but surly will go a long way in securing your Oracle Applications and pleasing the auditor.
• Review and remove any unused database links that may exist in your Oracle Applications Database.
• Disable indexing for your Oracle Applications web server. This will restrict the information available as well as block access to unwanted areas.
• In case you are implementing advanced configurations like DMZ in your Oracle Applications, it would be recommended that you also implement reverse proxies and firewalls so as not to expose your web application tier completely to the outside world.
• In case of cloned instances that is from production to test/development you must ensure that you change the passwords for all application and database user accounts after the cloning process. This prevents anyone from decrypting the passwords from a relatively unsecured development environment.
• You Oracle Applications can only be secure as far as the operating system it runs on is secure. Ensure you have strong password for the root applmgr and oracle users. Also ensure that you do not have unnecessary permissions on your filesyetms. Additionally you can also enable auditing for your OS users root applmgr and oracle.
  

Additional References
Pete Finnigan's Oracle security weblog
http://www.integrigy.com/oracle-security-blog
Metalink Note ID 189367.1 Best Practices for Securing the E-Business Suite

Posted by Sam at 10:33 PM | Permalink | Comments (2) | TrackBacks (0)

Auditing In Oracle Applications

Auditing in any production application is required due to various statutory or security obligations. Oracle Applications, an ERP which is backbone of the Organization implementing  it, it becomes all the more indispensable. Auditing aims at detection, prevention as well as track down any change which requires further investigation.

In Oracle Applications auditing can be done at two levels

• Oracle Applications Users Level.
• Oracle Applications Database/Schema Level.

In addition to the above you could also enable the standard Oracle RDBMS audit feature using 
the SYS.AUD$ table. In the current post however we will talk about only the auting 
capabilities of Oracle Applications.

Oracle Applications User Auditing

Sign On Audit
In Oracle Applications user level auditing can be done by enabling the Sign Audit profile option. This option can either be set at the user level, responsibility level or the Form level. To enable this kind of auditing you must set a value for the system profile option Sign-On: Audit Level.



Based upon the level of Sign Auditing selected the System capture all or some of the 
following information.

• The users who sign on to the system
• The Sign in and Sign Out times
• Responsiblities they choose
• The forms they use
• Duration of using the form or responsibility
• Terminals used for sign on.

You can get this information from the system by running one of the standard Oracle  Applications reports which are

• Signon Audit Users
• Signon Audit Responsibilities
• Signon Audit Forms
• Signon Audit Concurrent Requests
• Signon Audit Unsuccessful Logins

Additionally you could also setup notifications for unsuccessful logins by setting the  Sign-On: Notification system profile option to YES.



You can also use the monitor users window to have a user level auditing. However you can view the information only of those users for whom sign on auditing has been enabled.



Oracle Applications Database/Schema Level

Oracle Applications also allows to track down changes made to the data in oracle applications. For this purpose Audit Trails are setup and used. The trails track the audited  table by creating a shadow table for each of the audited table. Internally this mechanism uses database triggers to populate the shadow tables. The Following steps are involved for  setting up a audit trail in oracle applications.

Define Audit Groups
The first step involves defining your audit group. An audit group is a set of tables and  columns that you wish to audit. You can choose either to enable auditing of all or some of the  columns of a table except LONG,RAW and LONG RAW. You could have multiple audit groups and a  same object can also be a part of different audit groups.

Define Audit Installations
In this stage you choose the registered ORACLE IDs that you wish to audit. Before you can 
define your audit installation you must have denied your audit groups.

Define Audit Table and Columns
After defining the audit groups and audit installations you can choose the tables and columns 
for which you wish to enable auditing. You can use the audit tables to do this.



Run the Audit Trail Update Tables Report
You must run a concurrent request Audit Trail Update Tables Report so that your audit trail  definitions and the required shadow tables are created. This report is also responsible for building database triggers for your audit installations.



Disabling Auditing
You can disable auditing at anytime by changing the audit group state through the Audit Groups 
window to either Disable - Interrupt Audit, Disable -  Prepare for Archive or Disable - Purge Table. You must run the Audit Trail Update Tables Report after making the selection.

Posted by Sam at 12:43 PM | Permalink | Comments (6) | TrackBacks (0)