CobiT Detailed Analysis

The Control Objectives for Information and Related Technology (COBIT) is a framework created by ISACA for information technology management and IT governance. It is often used to help comply with regulations such as Sarbanes-Oxley and HIPAA
Like any compliance framework, CobiT is subject to interpretation by the organizations and implementation that follows a maturity model of gradual acceptance. This article is based on CobiT 4.1 and focuses on portions of sections that have relevance to Oracle database auditing.
Go to page123All

PO2.3 - Data Sensitivity

CobiT PO2.3 requires classifying data based on its sensitivity. The more sensitive the information, the more protection it requires.
It is up to the organization to define what data requires what protections, but highly sensitive data often requires a high level of protection as the one offered by Oracle database auditing.

PO4.10 - IT Supervision

CobiT PO4.10 calls for proper supervision of IT personnel. The purpose is to ensure that individuals are able to perform their job duties, and actually do so.
Included in the supervisory function is the need to ensure individuals do not abuse their access. When relating to Oracle databases, access abuse is when individuals with database credentials, or with access to a shared database account, use those to for purposes that are not part of their job duties.
When possible, access restrictions are a good measure to prevent such abuse. However, in Oracle environments, many accounts cannot have access that is restricted enough. The only way to prevent (or rather detect) access abuse is by using Oracle database auditing.

AI2.3 - Application Auditing

CobiT AI2.3 requires, in appropriate cases, to ensure application processing is correct, secured, and audited.
Most applications use databases to store information. Consequently, the application requirements extend to include all their components, including the Oracle database.
Applications that need to be audited and rely on Oracle databases, must have:
  • An application audit trail. In some cases, an Oracle audit trail can contain sufficient information and substitute the application audit trail
  • An Oracle audit trail for activity that is not included in the application audit trail (e.g. DBA activity)

AI3.2 - Infrastructure Change Auditing

CobiT AI3.2 requires, among other things, to audit changes in infrastructure software such as Oracle databases. For sensitive infrastructure, this requirement is extended from monitoring of changes to monitoring of all usage.
Change control monitoring (DDL auditing) is a fundamental measure for ensuring only approved changes are deployed. This is critical to avoid the slow drift from the approved base line. This requirement is echoed further in relation to the infrastructure and the application in CobiT AI3.3, AI6.4, AI7.8, and more.
Once a product like Core Audit is used for Oracle database auditing, the distance from change control auditing to complete security coverage is not large. Auditing of all usage provides a significantly enhanced security protection as is required (and appropriate) for sensitive Oracle databases.

PO9 - Risks

CobiT PO9 (9.1 – 9.6) deals exclusively with risks. Risks are the foundation of security in CobiT, as the security measure (controls) are derived from the risks.
There are three important steps in figuring out the risks:
  • List of potential risks (example below in PO9.3)
  • Assess the probability and consequences of each risk
  • Determine a reasonable approach to deal with each risks. Some risks with low probability and minor consequences can be accepted, others need to be addressed or partially mitigated