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

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