Sarbanes-Oxley (SOX) Detailed Analysis

Sarbanes-Oxley (SOX) is a federal law that aims to ensure accurate information is provided to investors. To understand how to comply with SOX, we have to drill through multiple layers:
  • The Federal Law (SOX)
  • The SEC regulation
  • The compliance framework
  • Practical Oracle database auditing
This article shows our analysis of SOX and the different layers from the federal law to practical requirements as they relate to Oracle database auditing.
Go to page1234All

Practical Oracle Auditing

Oracle database auditing is explicitly required by the SEC regulations, by the compliance framework, and by the risk-control process.
In addition to all those, Oracle database auditing is also part of the monitoring process that helps evaluate the effectiveness of the preventive controls. As such, the Oracle audit data is part of the evidential matter the company is required to retain to support its conclusions about the effectiveness of the controls.
To deploy an Oracle auditing solution on a production Oracle database, the first and most important requirement is Full Capture with Low Overhead – the ability to capture all the Oracle SQL activity without impacting the production system.
Given that we can capture, process, store, secure, and report on the information, what should a SOX compliance Oracle auditing system provide?


The first thing the audit solution should do is help ensure that the basic preventative controls are providing the expected protection. This is important because some of these “preventative” controls are voluntary and cannot be enforced.
  • User Logons – ensure that all the users, programs, machines, etc that connect to the database are allowed to do so.
  • Change Control – ensure all changes in the database have gone through change control
  • Authorization Changes – ensure all changes to users, roles, and privileges have been approved
  • Application Account – ensure the application account is only accessed by the application program, from the application servers

Financial Records Access

Ensure DBAs, privileged users, and the application user, do not abuse their access to modify financial records.
Additionally, while not required by SOX, other SEC regulations require that confidential financial information is not accessed by unapproved individuals.
  • DBAs & Privileged Users – ensure DBAs and Privileged users do not abuse their access by accessing financial records
  • Application – ensure the application account is not used to access financial records from unapproved sources (programs or machines)

Intelligent Auditing

The auditing measures discussed for far are declarative in nature and contain a deterministic definition of items to review. Declarative auditing is limited in its scope because Oracle databases execute thousands of SQLs per second and the rules are designed to provide a manageable amount of entries for review.
Additionally, even with its limited scope, declarative auditing can sometimes produce a vast number of entries, and important information can get lost in the noise.
An important complementing type of auditing is Intelligent Auditing. Intelligent Auditing contains algorithms that analyze all the activity in the database looking for unusual patterns.
Intelligent Auditing can, therefore, detect SQL injection, Zero day attacks, abnormal activity volumes, etc. The following reports/alerts are recommended for SOX controls:
  • SQL Source Anomaly – an Oracle account, program, machine, OS user, or combination of the above that hasn’t been seen recently
  • SQL Injection – an application SQL that hasn’t been seen recently
  • Financial Record Access – a SQL accessing financial records that hasn’t been seen from this program and Oracle account
  • Time of Day – access to financial records at an unusual hour