Oracle Security Blog

The Oracle Audit Vault is installed on a server, and collector agents are installed on the hosts running the source databases.  These collector agents communicate with the audit vault server. 

If the collection agents are not active, no audit data is lost, as long as the source database continues to collect the audit data.  When the collection agent is restarted, it will capture the audit data that the source database had collected during the time the collection agent was inactive.

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 refer

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

Oracle Audit Vault is aptly named; the Oracle Audit Vault is a vault in which data about audit logs is placed, and it is based on two key concepts.  First, Oracle Audit Vault is designed to secure data at its source.  Second, Oracle Audit Vault is designed to be a data warehouse for audit data. 

Certainly from an auditing and logging perspective, one of the best new features delivered by Oracle 12c is mandatory auditing of the administrative users such as SYSDBA.  This can be described as ‘always on auditing’.  By default, the following audit related activities are now mandatorily audited -

What is Oracle 12c Unified Auditing? The short answer is the view UNIFED_AUDIT_TRAIL. This view consolidates all logging and auditing information into a single source. Regardless of using either Mixed Mode or Pure Unified Auditing, the SYS.UNIFIED_AUDIT_TRAIL can be used. 

The key column in SYS.UNIFIED_AUDIT_TRAIL is AUDIT_TYPE.  This column shows from which Oracle component the log data originated -

Next in our blog series on Oracle 12 Unified Auditing is a discussion of Mixed Mode. Mixed Mode is the default auditing mode for Oracle 12c.  Oracle describes Mixed Mode auditing as a means of becoming familiar with Unified Auditing prior to migrating to Pure Unified Auditing.  Mixed Mode allows for all traditional, pre-12c log and audit functionality to co-exist with Unified Auditing.  More importantly, Mixed Mode will support any current Syslog-based logging solution.

Mixed mode auditing provides the following key capabilities –

Continuing our blog series on Oracle 12 Unified Auditing is a discussion of Pure  Mode. Mixed mode is intended by Oracle to introduce Unified Auditing and provide a transition from the traditional Oracle database auditing.  Migrating to PURE Unified Auditing requires the database be stopped, the Oracle binary linked to uniaud_on, and then restarted.  This operation can be reversed if auditing needs to be changed back to Mixed Mode. 

Continuing our blog series on Oracle 12 Unified Auditing, how do you know what mode of Unified Auditing that you are using? Use the following SQL –

SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

In Oracle 12c, a new database auditing foundation has been introduced.  Oracle Unified Auditing changes the fundamental auditing functionality of the database.  In previous releases of Oracle, there were separate audit trails for each individual component.  Unified Auditing consolidates all auditing into a single repository and view.  This provides a two-fold simplification: audit data can now be found in a single location, and all audit data is in a single format.  Oracle 12c Unified Auditing supports –

Tracking when database users last logged in is a common security and compliance requirement – for example to reconcile users and identify stale users. With Oracle 12c this analysis can now be done through standard functionality. New with Oracle12c, the SYS.DBA_USERS has a new column: last_login. 

select username, account_status, common, last_login

from sys.dba_users

order by last_login asc;

A database link is a one-way connection between two databases.  Starting with Oracle version 11.2.0.3, database session information now reports additional information for those sessions involving database links.  As often database links are created between databases of different security profiles; it is important to log session activity that includes the details of the database link.

DBLINK_INFO returns the source of a database link.  Specifically, it returns a string of the form –

SOURCE_GLOBAL_NAME=dblink_src_global_name

Knowing which person, not just which database account, has been a challenge for database logging and auditing when working with enterprise software applications such as the Oracle E-Business Suite, SAP, PeopleSoft, and OBIEE.  Knowing which application user did what and when is now much easier because of adoption of standard Oracle functionality.

Just when you thought the Oracle Database world was getting safer, Oracle will be releasing fixes for 32 database security bugs on Tuesday, October 14th.  This is in stark contrast to the previous twenty-five quarters where the high was 16 database bugs and average per quarter was 8.2 database bugs.  For the previous two years, the most database bugs fixed in a single quarter was six.

In addition to the 32 database security bugs, there are a total of 155 security bugs fixed in 44 different products.

Oracle 12c introduces several major new security features. Data redaction is one new feature and Real Application Security (RAS) is another.  Per Oracle, RAS is the next generation Virtual Private Database (VPD) and is installed with Oracle Enterprise Edition – no additional license required. RAS is a new declarative and granular authorization model and is designed to be an application security platform for end-to-end application security. For those developing APEX applications (also installed with Enterprise Edition), RAS will certainly become an integral tool.