Tuesday, 16 August 2011

Data Access Auditing

Data access auditing is a surveillance control. By monitoring access to all sensitive information contained within the database, suspicious activity can be brought to the auditor’s awareness. Databases commonly structure data as tables containing columns (think of a spreadsheet, only more complex). Data access auditing should address six questions:

  1.  Who accessed the data?
  2.  When was the data accessed?
  3.  How was the data accessed? (This is what computer program or client software was used?)
  4.  Where was the data accessed from (this is the location on the network or Internet)
  5.  Which SQL query was used to access the data?
  6.  Was it the attempt to access data successful? (And if yes, how much data was retrieved?)
The evidence available to the auditor is provided:
  • Within the client system (this may be infeasible – such as in web based commerce systems),
  • Within the database (including the logs produced by the database that are sent to a remote system), or
  • Between the client and the database (such as firewall logs, IDS/IPS devices and host based events and logs).
Auditing within the client entails using the evidence available on the client itself. Client systems can hold a wealth of database access tools and the logs that these create. These logs may contain lists of end-user activity that a user has performed on the database. In respect of web based systems, the web server itself may be treated as a client of sorts.

To obtain an adequate audit trail from client systems alone, all data access must have occurred using client tools under the control of the organization conducting the audit. In the event that data access can transpire using other means, it is rare that sufficient evidence will be available. This option by itself is the entirely worst option available to the auditor, but it can provide additional evidence in support of the other methods. This is chiefly used in the event of a forensic investigation.

Auditing within the database is often problematic due to:
  • A limited audit functionality of many database management systems (DBMS),
  • Inconsistent DBMS configurations and types being deployed throughout an organization, and
  • Performance losses due to enabling the audit mechanisms
Auditing within the database is without doubt better than auditing within the client, however, the best approach is a combination of auditing the client, network and the database.

Auditing between the client and the database entails monitoring the communication between the client and the database. This involves capturing and interpreting the traffic between the client and the database. Software is available for this and it may be used to provide data access auditing. The biggest issues with this type of data access auditing are:
  • Encryption between the client and the database server,
  • Privacy considerations and rights to view data, and
  • Correlating large volumes of data that also need to be parsed and processed to be useful.

No comments: