What Questions do Database Auditors Ask?

This article is a plug for a product called SecureSphere, which was developed by the company providing the free article (after registration). However it does contain some useful insights

This paper presents five key questions that IT professionals must answer during a database audit to achieve compliance. These questions are as follows.

1. Is the audit process independent from the database system being audited?
2. Does the audit trail establish user accountability?
3. Does the audit trail include appropriate detail?
4. Does the audit trail identify material variances from baseline activity?
5. Is the scope of the audit trail sufficient?

The answers to these questions vary depending upon the audit mechanism employed. Unfortunately, many database audit mechanisms were not designed to meet the requirements of regulatory auditors and therefore do not adequately address these questions. This paper examines the strengths and weaknesses of alternative audit mechanisms relative to these questions. The goal is to provide the reader with information necessary to make informed choices about which audit mechanisms to deploy to satisfy regulatory compliance audits.

1) Is the Audit Independent?
To ensure audit integrity, the entire process must be independent of the database server and database administrators being audited. Since database administrators and servers are both part of the system being audited, they should not be put in a position of auditing themselves. A rogue administrator, for example, with access to audit records may easily tamper with those records to cover his tracks. Similarly, a non-administrator may exploit a database vulnerability to elevate privileges and tamper with the audit trail. The requirement for independence has three immediate implications for the design of the audit system.

2) Who is Accountable?
The database audit trail must attribute each audited database transaction to specific users. For example, a SOX compliant audit mechanism must log each change to financial reporting data along with the name of the user making the change. However, when users access the database via Web applications (such as SAP, Oracle E-Business Suite, or PeopleSoft), native database software audit logs have no awareness of specific user identities. Therefore, when native audit logs reveal fraudulent database transactions, there is no link to the responsible user.

3) Do Audit Records Include Enough Detail?
To effectively reconstruct past database events, auditors require a detailed audit trail that extends to the level of the exact query and response attributes. Consider the following alternative hypothetical audit records for a call center customer service agent named “JOHN”.

• JOHN requested DATA from the CUSTOMER database and the database returned DATA
• JOHN requested FIRST NAMES, LAST NAMES, EMAIL ADDRESSES, PHONE NUMBERS, and CREDIT CARD NUMBERS for ALL customers from the CUSTOMER database and the database returned 634,577 records

Assuming that John is authorized to access individual customer records during the normal course of his work, the first less detailed audit trail (example A) does not reveal any unusual activity. However, the second more detailed audit trail (example B) makes it clear that a suspicious event has taken place. There is no reason to access the personal information (including credit card numbers) of 634,577 customers. To fully understand the transaction, the audit trail requires complete detail.

4) Does the Audit System Identify Material Variances?
It’s not enough for the audit system to simply provide a chronological listing of all database transactions. The volume of information generated in most database environments renders such a system useless as a tool for identifying fraudulent activity. An effective audit system should deliver prioritized views of events that separate material variances from legitimate or “baseline” user activity. However, most native and external audit approaches provide un-prioritized views, forcing staff into a costly manual log inspection process.

5) Is the Scope of the Audit Sufficient?
The scope of the database audit trail should be broad enough to identify any attempt to exploit vulnerability in database platform software (application, operating system, etc.) or protocol implementations. SQL Slammer, Windows RPC vulnerabilities are two examples of the many such vulnerabilities that attackers have exploited to inflict serious damage upon database infrastructure around the world. Dedicated intrusion prevention systems (IPS) and protocol validation solutions are needed to identify such attacks. Therefore, to provide auditors with a complete picture of database activity, it’s necessary to integrate data collected from these sources into the audit trail.

180 View – IT audit demands knowledge of IT General Controls including hardware, operating systems, database management systems, networking, multimedia, etc., and the environment that houses and supports them that enable the processing of applications (such as a financial application from SAP). A database is critical to any application. The database not only stores data but also manages access and logs changes independent of an application.