Forensics and Data Access Auditing

Data access auditing is a surveillance control that intersects with forensics and incident handling. In all events, the same level of care needs to be taken as any event can lead to a forensic engagement. By monitoring access to all sensitive information contained within the database, suspicious activity can be brought to the examiner's awareness. Databases commonly structure data as tables containing columns (think of a spreadsheet, only more complex). Data access examinations 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 forensic examiner is provided:

• Within the client system (this may be infeasible — such as in web based commerce systems or remote clients),
• 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).

An analysis within the client entails using the evidence available on the client itself and forms a standard forensic engagement. 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 review. 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 examiner, but it can provide additional evidence in support of the other methods. This is chiefly used in the event of a forensic investigation.

An examination 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 forensic tools and mechanisms

An examination 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.

Capturing data 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 examinations 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.

The issue with network capture is that this requires planning. Most organisations do not have forensic captures of all transactions.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law as well as working on his 4^th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he is helping to launch a Masters degree in digital forensics. He is starting his second doctorate, a PhD on the quantification of information system risk at CSU in April this year.