Best Practices: Secure Oracle Configuration and Database Auditing

Posted on: May 24th, 2016

In our last post, we shared the 4 most important areas of database security and discussed how to safeguard your Oracle environment with best practices for Authentication and Access Controls.

In this post, we continue with a breakdown of Oracle database security best practices for Secure Oracle Configuration and Database Auditing.


Secure Oracle Configuration

Secure Listener Configuration

Listener authentication should be local OS user. Implement standard configuration for inbound connection timeout and sqlnet expire timeout.

Listener Ports

Do not use default ports for Oracle listener configuration. Change the default listener port to prevent default SQL attacks.

Configuration for Oracle external procedures

External procedures can be used for SQL injection/hacks. They need to be secured for application-specific use only.


Perform regular Oracle security patching. MiCORE recommends applying patches at least twice per year. You can check the Oracle Technology Network (OTN) security site for details on security alerts released by Oracle.

Non-Production Data Refreshes

Leverage data cleansing and data masking procedures for data migration from production to non-production environments.

Secure Backups

Implement policies for data encryption for operational procedures such as RMAN backups or data exports.


Ensure that PII elements are identified and Column encryption is in place. Create metadata repository for PII elements in Oracle databases.


Database Auditing

Monitor your environment and identify potential attacks by implementing a unified auditing policy. Basic auditing should be configured for all databases and system operations. Centralize audit data and create reports so you can view the audit records.

Select the right type of auditing for your Oracle database based on your specific needs:

  • Statement level auditing: Audits on the type of SQL statement used, such as any SQL statement on a table (which records each CREATE, TRUNCATE, and DROP TABLE statement)
  • Privilege level auditing: Audits use of a particular system privilege, such as CREATE TABLE
  • Object level auditing: Audits specific statements on specific object, such as ALTER TABLE on the EMP table
  • Fine-grain auditing: Provides added functionality of auditing specific columns that hold sensitive information such as PII or salaries, as well as using event handlers which allows you to write a function that send email alerts to security administrators when unauthorized updates are made to audited table elements.

Proactive Security Assessments

In addition to the ongoing auditing discussed above, we recommend performing a holistic review of all security components of your Oracle databases once per year. The holistic security assessment should include a high-level analysis of:

  • Database user accounts
  • Password policies
  • Operational procedures
  • Data migration and refresh
  • Database configuration
  • Oracle security patches
  • Database access control

Compare your current configuration with Oracle best practices for secured and hardened database environments.

You may also choose to analyze the current environment based on the Center for Internet Security (CIS) benchmarks.


Click Through Image: Click here to start your Oracle Database Security Assessment with MiCORE