Skip navigation.

Security Blogs

Oracle E-Business Suite Database 12c Upgrade Security Notes

When upgrading the Oracle E-Business Suite database to Oracle Database 12c (12.1), there are a number of security considerations and steps that should be included in the upgrade procedure.  Oracle Support Note ID 1524398.1 Interoperability Notes EBS 12.0 or 12.1 with RDBMS 12cR1 details the upgrade steps.  Here, we will document steps that should be included or modified to improve database security.  All references to steps are the steps in Note ID 1524398.1.

Step 8

"While not mandatory for the interoperability of Oracle E-Business Suite with the Oracle Database, customers may choose to apply Database Patch Set Updates (PSU) on their Oracle E-Business Suite Database ...".

After any database upgrade, the latest CPU patch (either PSU or SPU) should always be applied.  The database upgrade only has the latest CPU patch available at the time of release of the database upgrade patch.  In the case of, the database upgrade will be current as of July 2013 and be missing the latest five CPU patches.  Database upgrade patches reset the CPU level - so even if you had applied the latest CPU patch prior to the upgrade, the upgrade will revert the CPU patch level to July 2013.

From a security perspective, the latest PSU patch should be considered mandatory.

Step 11

It is important to note from a security perspective that Database Vault must be disable during the upgrade process.  Any protections enabled in Database Vault intended for DBAs will be disabled during the upgrade.

Step 15

The DMSYS schema is no longer used with Oracle E-Business Suite and can be safely dropped.  We recommended you drop the schema as part of this step to reduce the attack surface of the database and remove unused components.  Use the following SQL to remove the DMSYS user --

Step 16

As part of the upgrade, it is a good time to review security related initialization parameters are set correctly.  Verify the following parameters are set -

o7_dictionary_accessibility = FALSE
audit_trail = <set to a value other than none>
sec_case_sensitive_logon = TRUE (patch 12964564 may have to be applied)
Step 20

For Oracle E-Business Suite 12.1, the sqlnet_ifile.ora should contain the following parameter to correspond with the initialization parameter sec_case_sensitive_login = true -





Tags: Oracle E-Business SuiteDBA
Categories: APPS Blogs, Security Blogs

What can the Oracle Audit Vault Protect?

For Oracle database customers the Oracle Audit Vault can protect the following:

  • SQL statements logs – Data Manipulation Language (DML) statement auditing such as when users are attempting to query the database or modify data, using SELECT, INSERT, UPDATE, or DELETE.
  • Database Schema Objects changes – Data Definition Language (DDL) statement auditing such as when users create or modify database structures such as tables or views.
  • Database Privileges and Changes – Auditing can be defined for the granting of system privileges, such as SELECT ANY TABLE.  With this kind of auditing, Oracle Audit Vault records SQL statements that require the audited privilege to succeed.
  • Fine-grained audit logs – Fine Grained Auditing activities stored in SYS.FGA_LOG$ such as whether an IP address from outside the corporate network is being used or if specific table columns are being modified.  For example, when the HR.SALARY table is SELECTED using direct database connection (not from the application), a condition could be to log the details of result sets where the PROPOSED_SALARY column is greater than $500,000 USD.
  • Redo log data – Database redo log file data.  The redo log files store all changes that occur in the database.  Every instance of an Oracle database has an associated redo log to protect the database in case of an instance failure.  In Oracle Audit Vault, the capture rule specifies DML and DDL changes that should be checked when Oracle Database scans the database redo log.

The Audit Vault also supports –

  • Database Vault – Database Vault settings stored in DVSYS.AUDIT_TRAIL$ such as Realm audit, factor audit and Rule Audit. 
  • System and SYS – Core changes to the database by privileged users such as DBAs as recorded by AUDIT_SYS_OPERATIONS.
  • Stored Procedure Auditing – Monitor any changes made to PL/SQL and stored procedures.  Standard reports are provided to stored procedure operations, deleted and created procedures as well as modification history.

If you have questions, please contact us at

Reference Tags: AuditingOracle Audit VaultOracle Database
Categories: APPS Blogs, Security Blogs