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

Internal Controls

Based on the regulation, SOX requires internal controls that are based on a suitable, recognized control framework and include prevention and detection of unauthorized changes.
There are several recognized control frameworks, including: CobiT, COSO, ITIL, ISO/IEC 27000.
While each framework is different, the same basic principles apply in all:
  • Identify the Risks
  • Setup Controls to mitigate the risks
  • Monitor the activity
  • Evaluate the risks and the effectiveness of the controls. The conclusions from this evaluation must also be published in the financial reports (effectiveness of controls, material weaknesses, and changes made)


While every Oracle database environment is different, similar risks to the data exist in most:
  • Application – a bug in the application or a SQL injection attack
  • Administrator Privilege Abuse – a DBA of privileged user abusing their privileges
  • Access Abuse – an individual abusing the application password
  • Compromised Password – either a DBA or an application password that was compromised (stolen, cracked, etc)
  • Contractor / Partner – abuse of access or general lax security that leads to a breach
  • Human Element – manipulation of individuals to knowingly or unknowingly abuse their access
  • Compromised Internal Asset – an external agent compromising a desktop, mail server etc, and use it to compromise the database
  • Complex attack – attacks on networks, servers, storage, physical breaches, Oracle vulnerabilities, and more


While every Oracle database environment is different, similar controls are applied in most:
Preventive Controls:
  • Authorization Policy – a policy for approving access to the Oracle database and events that trigger its removal (e.g. termination of employment or a change in position)
  • Password Policy – Oracle password length, complexity, duration, etc
  • Least Privilege – grant minimal privileges to Oracle accounts
  • Change Control – obtain approval for changes in the Oracle database prior to performing those
Detective Controls:
  • Auditing Reconciliation – ensure actual Oracle activity matches expected activity (account logons, change control, authorization changes)
  • Access Auditing – ensure DBAs, privileged users, application accounts etc do not abuse their access or privileges
  • Intelligent Auditing – alert or report on abnormal activity (unusual programs, unusual SQLs, high SQL volume, etc)
The preventive controls are well-known and probably already implemented. The detective controls merit some more detail about practical implementations