Oracle databases auditing reliability and completeness Don Burleson

Burleson is the co-author of the bestselling book "Oracle Privacy Security Auditing: Includes Federal Law Compliance with HIPAA, Sarbanes-Oxley & The Gramm-Leach-Bliley Act GLB", by Rampant TechPress.

The IT manager must view Auditing as a homogenous system, spanning all applications and database platforms.  This is especially important with the new Federal laws that put the onus of maintaining the security and auditing policy on the custodians of the data, the IT management.  For any large company, manageability, reliability and scalability are the critical success factors for any auditing solution:

·        Performance – The solution must have a minimal performance impact with low maintenance and upgrade overhead.

·        Manageable – The SA, DBA and developer staff cannot be involved in the auditing or have any privileged access rights.  The solution must be segregated, unified and platform independent.  The solution must be flexible and easy to extend and maintain as IT databases requirements change.  The system should include centralized ability to configure and deploy across numbers of servers, and regardless of database platform.

·        Complete – The solution must be complete and comprehensive.  It should have a unified interface for all databases, regardless of platform.  This is because many applications span database platforms.  It must be reliable and have an automated and secure mechanism for long-term archival management. 
 

Ensuring a Complete Enterprise Solution

Creating an auditing architecture from diverse data sources and applications is a huge challenge.  The IT manager must ensure that every important aspect of privacy, security and auditing are covered and they must do this while making sure that their solution in easy to manage and scalable. 

An effective auditing solution must have these characteristics:

·        Reliability and completeness

·        Real-time notification of critical events

·        Consolidation of audit data streams

·        Reporting value and ease of reporting

·        Long-term retention of audit trails

·        Manageability and scalability

While simple in concept, these requirements are extremely complex and difficult to implement, especially with the huge volumes of data that must be archived.   Because auditing is required by both IT best practices and U.S. Federal laws, many IT managers adopt products designed especially for this purpose.
 

Reliability and completeness
 

Many IT shops fail to realize that a haphazard “sampling” approach to auditing is insufficient. A continuous audit is required and the audit must be archived for long-term access. 

A comprehensive solution must also have the ability to audit all possible points of entry to the data.  It must audit access from the operating system (at the data file level), from the database management layer, the network and from the application layer (Figure 1).

Figure 1 – The multi-layer data exposure issue

In a typical organization, data access occurs at many levels - - - at the end user presentation layer, at the middle tier, at the application server layer, at the web server layer, at the standalone application screens and finally, at the database level directly.

Even at the database layer we also have opportunities to bypass the application.  Ad-hoc query tools such as SQL*Plus, Crystal Reports and ODBC tools provide backdoors for legitimate users to bypass application layer auditing.

Consolidation of audit data streams
 

Very few IT shops have a single database source and it can be a nightmare to try to consolidate auditing archives from heterogeneous database platforms.  Each database product manages archives in differing formats and cross-database issues can be impossible to resolve without centralization.  Audits from different database products are archived with different character sets, different formats and different organizations (Figure 2).

Figure 2 – The problem of auditing diverse data

Here we see the problem is consolidating audit information along two dimensions, the multi-layer dimension and the multi-product dimension.  The key to success in this type of heterogeneous environment is to simplify the sources for data collection and to collect audit information at the source, the database layer.  For those using relational databases such as Oracle, SQL Server and Sybase, using the traditional “grant” access to authorize end-users allows them to access the data via alternative methods such as ODBC interfaces.

By auditing the data disclosure at the source, we eliminate the need to track access from multiple points and we greatly simplify the data auditing model (Figure 3).

Figure 3 – Cross-product data auditing

Now that we have ensured that all data access auditing is done at the source of the data, our only remaining issue is dealing with audits from multiple data sources.  This is especially problematic for shops with a mix of database architectures such as relational databases (Oracle), object-oriented databases (Ontos), network databases (CA-IDMS) and hierarchical databases (IMS).

Regardless of the database architecture or specific product, all data audits must capture this information:

·        Who – A full identification of the person viewing or modifying the data

·        Where – A log showing the specific application procedure and method used to access the data

·        When – A reliable date-time-stamp, globalized to Greenwich Mean Time (GMT)

·        What – A full listing of all data entities that were viewed or modified

·        Why – Context-based information describing how the data was disclosed

By using a database independent vendor package you can get the audit logs into an identical format and provide a unified audit trail for the all-important reporting interface.

Remember, the audit trail is a database too, and for most shops it is the single largest data repository for the entire company.  Just as you purchase a database product that is designed to meet your application needs, many companies choose an auditing solution that is specifically designed for the needs of auditing (Figure 4).

Figure 4 – A unified database for managing audit information

Now that we see the high-level architecture of the privacy auditing collection and consolidation mechanism, let’s dive deeper and explore how these giant audit databases are managed.

Get the whole story here