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

PO9.3 - Events

As an initial step in risk assessment, CobiT PO9.3 suggests listing of events that could be harmful to the organization. When it comes to Oracle databases, we can classify these events into three categories:
  • Data theft – If sensitive data was stolen from the Oracle database, that would likely have harmful consequences. Whether done by internal or external agents, it will probably have business, legal, regulatory, or other ramifications.
  • Unauthorized modification – If data in the database was modified when it was not supposed to, that would probably be bad. Whether done by authorized personnel (fraud) or unauthorized individuals (breach), it means the data is unreliable. That can have business, legal, regulatory and other consequences.
  • Data Availability – Whether due to system outage or data destruction, not being able to access the data in the Oracle database will have serious business (and other) consequences.
But CobiT PO9.3 asks for actual realistic events so that the discussion is not theoretical. While every organization and environment will have different risks, there are some examples of common risks that are prevalent in most Oracle database environments:
  • Application – a bug in the application that allows a user to change or view data he’s not authorized to
  • Application – a bug in the application that allows injection of SQLs into the database
  • Administrator – a DBA abusing their DBA Oracle account to view or change data
  • Administrator – a DBA abusing the shared SYS Oracle account to view or change data
  • Application Account – a developer that knows the application password, use it to view or change data
  • Application Account – an application administrator that knows the application password, use it to view or change data
  • Compromised Password – a DBA, SYS, or application password was guessed
  • Compromised Password – a DBA, SYS, or application password was stolen from a file containing all the passwords (or from an email)
  • Compromised Password – the DBA used the same password for his VPN account, for the database, and in a personal blog website. The blog website was compromised and the password used to log into the VPN and into the database
  • Contractor / Partner – abuse their access to view or change data
  • Contractor / Partner – shared their password with someone that used it to view or change data
  • Contractor / Partner – store passwords in a file that was stolen
  • Contractor / Partner – their site was compromised and used to breach your organization
  • Human Element – a call to the helpdesk convinced the operator to reset the DBA’s single signon password. That password was used to get in to the VPN and then into the database
  • Human Element – a DBA was tricked into sharing his password
  • Compromised Internal Asset – a phishing email was used to compromise the DBA’s desktop. From the DBA’s desktop, the attacker used Toad (that stored the password) to log into the database
  • Compromised Internal Asset – an unsecured web server was compromised. The web server was used to launch a SQL injection attack
  • Compromised Internal Asset – an unsecured mail server was compromised. The attacker accessed a file share that contained a file with all the administrative passwords
Prevention of all these attack vectors is extremely difficult if not impossible. However, detection of a breach into the database can be done in near real-time. See Controls below for more information.

DS5.2 - Controls

CobiT DS5.2 requires construction of a security plan based on business needs, risks, and compliance requirements. The assumption is that every environment is different and, therefore, requires a different security plan.
The risks from PO9 are one of the main inputs into the security plan. Despite differences in environments, there are some good common practices that should be considered:
Preventive Controls are one type of controls that should be implemented. They are preemptive and attempt to prevent a security event from occurring. Some examples are:
  • Authorization Policy – a policy for approving access to Oracle databases, and organizational 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 implementation
Detective Controls are a reactive type of control. Their aim is to notify when suspicious activity occurred, and allow for quick response. While being reactive in nature, detective controls have a significantly higher chance of identifying the offensive activity. They are, therefore, an important control to deploy. In Oracle databases there is only one type of detective control – Database Auditing:
  • Auditing Reconciliation – capture change control changes, authorization changes, etc and ensure actual Oracle activity matches expected activity
  • Session Access Auditing – capture successful and failed logins, and ensure the Oracle accounts, programs, machines, and OS users that connect to the Oracle database are expected to
  • SQL Access Auditing – capture certain SQL activity, and ensure DBAs, privileged users, and application accounts are not abused by authorized or unauthorized individuals
  • Intelligent Auditing – alert or report on abnormal activity (unusual programs, unusual SQLs, high SQL volume, etc). This automatic analysis of the activity aims to detect anomalies that were not manually detected by other types of auditing

DS5.5 - Security Monitoring

CobiT DS5.5 requires monitoring of IT security (such as Oracle accounts and privileges). The idea is that once the initial base line of users and privileges was approved, any changes to the baseline must be detected and approved. Otherwise, there’s a slow and dangerous drift the privileges that were approved to the ones in reality.
Timely detection of changes to users, roles, and privileges will allow for a quick remediation and prevent a security event. Implementation of CobiT DS5.5 can only be done with an Oracle database auditing solution that can report and alert on changes to the Oracle security model.
To be more specific, Oracle database auditing should monitor for the creation, deletion or modifications of users, roles, privileges and profiles as well as granting and revoking of privileges.

DS5.7 - Tamper-Proofing

CobiT DS5.7 requires security technology to be tamper-proof. The guiding principle being that security technology that can be tampered with is less effective and not as reliable.
This requirement is relevant in two ways:
  • Tampering with Oracle database security must be identified. This refers back to section DS5.5 and reinforces it
  • Any Oracle database auditing solution used should be tamper-proof
Oracle database auditing solutions contain three potential weak points for tampering:
  • Data Capture – If the data capture can be tampered with to not capture certain activity (for example, by the DBA), than the auditing solution is vulnerable. Core Audit cannot be tampered with in such a way.
  • Temporary Log Storage – If the auditing solution stores audit logs on the Oracle database server, those audit logs can be manipulated. Core Audit does not store audit logs on the Oracle database server.
  • Compliance Repository – If the compliance repository can be modified, the data in it is unreliable. Core Audit uses a proprietary repository that does not have deletion or modification functionality. Additionally the compliance storage is locked and encrypted.

DS11.6 - Securing Data

CobiT DS11.6 requires securing of data. This is an overall requirement encompassing data as it enters the IT systems, processed, stored and leaves the IT systems. It can includes many parts of the IT environment, but the Oracle database is at its center. Actual implementations for Oracle databases are likely to include network and disk encryption from OAS (Oracle advanced security), but should also include detective controls.
Detective controls in Oracle databases means Oracle database auditing. For data protection we recommend:
  • DDLs – Audit of changes to users, schemas, triggers, procedures, etc. These can all affect the processing and security of the data
  • Administrative Access – Audit of access to sensitive data by DBAs & privileged users
  • Unapproved Access – Audit of access to sensitive data by the application account but not by the application
  • Abnormal Access – Audit of access to sensitive data using unusual SQLs, from unusual sources, at the wrong time of day, etc

DS13.3 - Infrastructure Activity Auditing

CobiT DS13.3 requires monitoring of the entire IT infrastructure. This is a general auditing requirement for all IT systems in an effort to detect suspicious activity, and perform forensic investigations of attacks and breaches.
Without sufficient auditing, there is little to no chance of internally detecting an attack, a breach, or fraud. Additionally, when detection is achieved (often through external sources), lack of auditing information makes it difficult if not impossible to determine what transpired.
Given that the final goal of most attacks is the data in the database, Oracle database auditing is a central component in this effort. Without Oracle database auditing, the conclusions are often that the database, and any information in it, might have been compromised. CobiT acknowledges the significance of auditing and explicitly requires auditing of the entire infrastructure to allow for the reconstruction of events.
Complete Picture is a feature in Core Audit that, without any configuration, automatically stores vital forensic information. Configuring policies is simple and can add important additional information, and adding reports and alerts will provide detection capabilities as well. Core Audit is a fully featured solution that comes built-in with everything needed for compliance and security.