Oracle is aggressive in desupporting products - most product versions are desupported within 18 months of release except for terminal releases. Oracle Database 11.2.0.3 and Oracle E-Business Suite versions 11.5.x and 12.0.x will be desupported by the end of this year. After Extended Support ends, security patches are not available for products in Sustaining Support. Running desupported versions have a security impact due to the lack of security patches and other reasons. This educational webinar reviews the current support state for the Oracle Database and Oracle E-Business Suite and examines the security impact of desupport for these Oracle products.

Oracle Databases are a target of cyber attacks by hackers looking to obtain sensitive data such as credit card numbers and personally identifiable information used in identify theft. Even though databases are not externally accessible, they are still a target as most cyber attacks penetrate the network perimeter and look for high value targets within your internal network. Based on lessons learned from recent high-profile cyber attacks, a framework and techniques for detection and prevention of these cyber attacks against database will be presented.

Oracle databases are a target of cyber attacks by hackers looking to obtain sensitive data such as credit card numbers and personally identifiable information used in identify theft. Even though databases are not externally accessible, they are still a target as most cyber attacks penetrate the network perimeter and look for high-value targets within the internal network. Based on lessons learned from recent high-profile cyber attacks, this session reviews a framework and techniques for detection and prevention of these cyber attacks against Oracle databases.

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 –

• All existing (pre-12c) auditing initialization configurations and parameters are used such as AUDIT_TRAIL, AUDIT_FILE_DEST, AUDIT_SYS_OPERATIONS, and AUDIT_SYSLOG_LEVEL
• The format of the audit records remains the same as in Oracle Database 11g Release 2
• Writes mandatory audit records to the traditional audit trails
• If the AUDIT_SYS_OPERATIONS initialization parameter is set to TRUE, writes audit records only to the traditional audit trails

With Mixed Mode, audit data can be found both in the traditional locations as well as in SYS.UNIFIED_AUDIT_TRAIL.  This is because the Unified Auditing Policy ORA_SECURECONFIG is enabled by default.  ORA_SECURECONFIG audits the same default audit settings from Oracle Database Release 11g.  Integrigy recommends to either periodically purge Unified Auditing data or disable the policy.  To disable ORA_SECURECONFIG policy follow the instructions in Oracle Support Note Doc ID 1624051.1.

The following table shows the definition of the default policy ORA_SECURECONFIG.  Note the column ‘Common’ that shows that the policy is defined for all PDBs (tenant) databases.

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Oracle 12c Unified Auditing Whitepaper Oracle 12c Unified Auditing
• Oracle Database Security Guide 12c Release 1    http://docs.oracle.com/database/121/DBSEG/auditing.htm#DBSEG493
• Why Mixed Mode is generating log data and how to disable it refer to “The UNIFIED_AUDIT_TRAIL is Getting Populated even if Unified Auditing was not explicitly enabled in 12c” Note ID 1624051.1, Oracle Corporation, 28 March 2014, https://support.oracle.com/rs?type=doc&id=1624051.1

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 -

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Oracle 12c Unified Auditing Whitepaper Oracle 12c Unified Auditing
• For a full description of each column in the view see the  Oracle Database Reference 12c Release 1 (12.1) http://docs.oracle.com/database/121/REFRN/refrn29162.htm#REFRN29162

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 -

• CREATE AUDIT POLICY
• ALTER AUDIT POLICY
• DROP AUDIT POLICY
• AUDIT
• NOAUDIT
• EXECUTE of the DBMS_FGA PL/SQL package
• EXECUTE of the DBMS_AUDIT_MGMT PL/SQL package
• All configuration changes that are made to Oracle Database Vault
• ALTER TABLE attempts on the AUDSYS audit trail table (this table cannot be altered)
• Top level statements by administrative users SYS, SYSDBA, SYSOPER, SYSASM, SYSBACKUP, SYSDG, and SYSKM, until the database opens.  When the database opens, Oracle Database audits these users using the audit configurations in the system.

The audit activity resulting from mandatory auditing can be found in SYS.UNIFIED_AUDIT_TRAIL. 

Note when the database is not writable (such as during database mounting), if the database is closed, or if it is read-only, then Oracle writes the audit records to external files in the $ORACLE_BASE/audit/$ORACLE_SID directory. 

Note: Activity and be found in SYS.UNIFIED_AUDIT_TRAIL when in pure mode and to the traditional audit trails in mixed mode.

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Oracle 12c Unified Auditing Whitepaper Oracle 12c Unified Auditing
• Oracle Database Security Guide
  12c Release 1 Guide: http://docs.oracle.com/database/121/DBSEG/audit_admin.htm#DBSEG361

Most clients do not fully take advantage of their database's auditing and logging features. For databases such as Oracle these features are sophisticated and are able to satisfy most organization’s compliance and security requirements.

This guide presents Integrigy’s framework for database auditing and logging.  This framework is a direct result of Integrigy’s consulting experience and will be equally useful to both those wanting to improve their capabilities as well as those just starting to implement logging and auditing.  Our goal is to provide a clear explanation of the native auditing and logging features available, present an approach and strategy for using these features and a straight-forward configuration steps to implement the approach.

Integrigy’s framework is also specifically designed to help clients meet compliance and security standards such as Sarbanes-Oxley (SOX), Payment Card Industry (PCI), FISMA, and HIPAA.  The foundation of the framework is PCI DSS requirement 10.2.

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 mailto:info@integrigy.com

Reference

• Integrigy Guide to Oracle Audit Vault Integrigy Guide to Oracle Audit Vault
• Presentation “Developing Value with Oracle Audit Vault Developing Value with Oracle Audit Vault

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.

There are three types of agent collectors for Oracle databases.  There are other collectors for third-party database vendors such as SAP Sybase, Microsoft SQL-Server, and IBM DB2.

 *Note if using Oracle 12c; the assumption is that Mixed Mode Unified Auditing is being used

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Guide to Oracle Audit Vault Integrigy Guide to Oracle Audit Vault
• Presentation “Developing Value with Oracle Audit Vault Developing Value with Oracle Audit Vault

The Oracle Audit Vault uses Plug-Ins to define data sources.  The following table summarizes several of the important facts about the Oracle Audit Vault database plug for Oracle databases –

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Guide to Oracle Audit Vault Integrigy Guide to Oracle Audit Vault
• Presentation “Developing Value with Oracle Audit Vault Developing Value with Oracle Audit Vault

The auditing and logging capabilities within the Oracle Database are sophisticated and able to satisfy most organizations' security and compliance requirements. However, the auditing and logging setup and usage of the data can be complex and error-prone. These slides from an Integrigy educational webinar outline the auditing and logging capabilities available at different layers of the application and provides recommendations how to configure auditing and logging to capture critical application and security events.

Several standard features of the Oracle database should be kept in mind when considering what alerts and correlations are possible when combining Oracle database and application log and audit data.

Client Identifier

Default Oracle database auditing stores the database username but not the application username.  In order to pull the application username into the audit logs, the CLIENT IDENTIFIER attribute needs to be set for the application session which is connecting to the database.  The CLIENT_IDENTIFIER is a predefined attribute of the built-in application context namespace, USERENV, and can be used to capture the application user name for use with global application context, or it can be used independently. 

CLIENT IDENTIFIER is set using the DBMS_SESSION.SET_IDENTIFIER procedure to store the application username.  The CLIENT IDENTIFIER attribute is one the same as V$SESSION.CLIENT_IDENTIFIER.  Once set you can query V$SESSION or select sys_context('userenv','client_identifier') from dual.

The table below offers several examples of how CLIENT_IDENTIFIER is used.  For each example, for Level 3 alerts, consider how the value of CLIENT_IDENTIFIER could be used along with network usernames, enterprise applications usernames as well as security and electronic door system activity logs.

Last Login

Tracking when database users last logged in is a common compliance requirement.  This is required in order to reconcile users and cull stale users.  New with Oracle12c, Oracle provides this information for database users.  The system table SYS.DBA_USERS has a column, last_login. 

Example:

select username, account_status, common, last_login

from sys.dba_users

order by last_login asc;

If you have questions, please contact us at mailto:info@integrigy.com

Reference

• Integrigy Guide to Oracle Audit Vault Integrigy Guide to Oracle Audit Vault
• Presentation “Developing Value with Oracle Audit Vault Developing Value with Oracle Audit Vault

Oracle is aggressive in desupporting products - most product versions are desupported within 18 months of release except for terminal releases. Oracle Database 11.2.0.3 and Oracle E-Business Suite versions 11.5.x and 12.0.x will be desupported by the end of this year. After Extended Support ends, security patches are not available for products in Sustaining Support. Running desupported versions have a security impact due to the lack of security patches and other reasons. This educational webinar reviews the current support state for the Oracle Database and Oracle E-Business Suite and examines the security impact of desupport for these Oracle products.

Oracle Databases are a target of cyber attacks by hackers looking to obtain sensitive data such as credit card numbers and personally identifiable information used in identify theft. Even though databases are not externally accessible, they are still a target as most cyber attacks penetrate the network perimeter and look for high value targets within your internal network. Based on lessons learned from recent high-profile cyber attacks, a framework and techniques for detection and prevention of these cyber attacks against database will be presented.

Oracle databases are a target of cyber attacks by hackers looking to obtain sensitive data such as credit card numbers and personally identifiable information used in identify theft. Even though databases are not externally accessible, they are still a target as most cyber attacks penetrate the network perimeter and look for high-value targets within the internal network. Based on lessons learned from recent high-profile cyber attacks, this session reviews a framework and techniques for detection and prevention of these cyber attacks against Oracle databases.

With the start of the new year, it is now time to think about Oracle Critical Patch Updates for 2016.  Oracle releases security patches in the form of Critical Patch Updates (CPU) each quarter (January, April, July, and October).  These patches include important fixes for security vulnerabilities in the Oracle Database.  The CPUs are only available for certain versions of the Oracle Database, therefore, advanced planning is required to ensure supported versions are being used and potentially mitigating controls may be required when the CPUs can not be applied in a timely manner.

CPU Supported Database Versions

As of the October 2015 CPU, the only CPU supported database versions are 11.2.0.4, 12.1.0.1, and 12.1.0.2.  The final CPU for 12.1.0.1 will be July 2016.  11.2.0.4 will be supported until October 2020 and 12.1.0.2 will be supported until July 2021.

11.1.0.7 and 11.2.0.3 CPU support ended as of July 2015. 

Database CPU Recommendations

1. When possible, all Oracle databases should be upgraded to 11.2.0.4 or 12.1.0.2.  This will ensure CPUs can be applied through at least October 2020.
    
2. [12.1.0.1] New databases or application/database upgrade projects currently testing 12.1.0.1 should immediately look to implement 12.1.0.2 instead of 12.1.0.1, even if this will require additional effort or testing.  With the final CPU for 12.1.0.1 being July 2016, unless a project is implementing in January or February 2016, we believe it is imperative to move to 12.1.0.2 to ensure long-term CPU support.
    
3. [11.2.0.3 and prior] If a database can not be upgraded, the only effective mitigating control for many database security vulnerabilities is to strictly limit direct database access.  In order to restrict database access, Integrigy recommends using valid node checking, Oracle Connection Manager, network restrictions and firewall rules, and/or terminal servers and bastion hosts.  Direct database access is required to exploit database security vulnerabilities and most often a valid database session is required.
    

Regardless if security patches are regularly applied or not, general database hardening such as changing database passwords, optimizing initialization parameters, and enabling auditing should be done for all Oracle databases. 

Encrypting data is a useful tool to protect sensitive data be it at rest, in motion, or in use. For an Oracle Database, encryption may be done at the storage, application, network, and backup layers. Therefore, implementing database encryption can be time consuming and difficult as there are performance considerations and challenges such as effective key management for each encryption solution. This education webinar examines available Oracle Database encryption technologies and deployment options highlighting the benefits and potential pitfalls of each encryption solution.

From the perspective of a database security consultancy, what security requirements change when you move to the Cloud? Assuming an effective database security program is in place, arguably moving to the Cloud should be an easy transition. Moving to the Cloud requires strengthening several key components of a database security program. This presentation first discusses the security differences for Oracle databases among the IAAS, PAAS, and traditional hosting delivery models. Next, the seven key components of an effective database security program are reviewed, noting what changes when databases are moved to the Cloud. In particular, the presentation focuses on what needs to be in place to effectively manage privileged users and to protect sensitive data when databases are moved to Cloud IAAS or a PAAS delivery models.

Oracle E-Business Suite (EBS) 11i and 12.0 security patches and other security improvements are no longer being provided by Oracle since these products are now under Sustaining Support. After January 2016 for 11i and October 2015 for 12.0, Critical Patch Update (CPU) security patches are not available for these versions. There are significant security risks when running a desupported EBS version due to unpatched critical security vulnerabilities and outdated technology stack components. This educational webinar examines the security impact for unsupported EBS environments and how to effectively mitigate the security risks when it is not possible to apply CPU patches and other security upgrades.