Logo Background

Oracle Application Security Hardening

  • By on November 21, 2008 | No Comments

    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.
    Previous
    Next
    » Segmentation Fault In Tkprof
Leave a Comment