Forensic auditing of databases is not new, but there's a growing need for breach analysis

Adrian Lane, Contributor

August 15, 2011

4 Min Read

David Litchfield presented "Hacking and Forensicating an Oracle Database Server" at the Black Hat 2011 conference. During the presentation, Litchfield discussed a handful of ways to hack into Oracle 10 and 11 databases, demonstrated how to completely alter the database platform by injecting arbitrary code into memory, and then leveraged the database to compromise the underlying operating system. Many of the attacks and techniques are not new to the research community, but they impressed upon the audience how devastating these hacks can be.

It also nicely framed the need for forensic tools to trace what hackers have done to your system. Litchfield closed the presentation with a demonstration of his database forensic analysis tool. Ten years ago, nobody was interested in forensic auditing of databases. A couple of vendors offered database audit to complement monitoring and assessment capabilities, but there was no market because customers were not interested. Firms wanted to know whether someone was snooping through their data and did not yet understand that attackers altered database contents and functionality. They wanted to know what their employees were doing because security -- at the time -- was considered and "insider threat" problem. Customers purchased DAM products that collected SQL statements and grouped them by user.

A few years later, customers adjusted to both internal and external threats, and DAM products changed to detect specific attack patterns -- anomalous query constructs --as well as marco usage patterns to detect behavioral anomalies.

It has taken a decade, but the market now realizes that attackers alter databases. If you want to know what happened, then you will need to conduct a forensic audit -- and you can forget going to your firewall or SIEM logs for the complete picture. We also know most breaches are not discovered immediately, and, in many cases, are detected by people outside of the company. Security professionals, services firms, and enterprises are now looking for forensic auditing tools as part of their breach preparedness planning. If you are establishing a breach readiness plan, having tools on hand to analyze the database is essential to understanding what was compromised and how.

There are a couple of important distinctions worth noting, and one of them is that database auditing is different than database activity monitoring. The former is geared to be a detailed forensic examination of database state and quantification of what exactly happened to a database server following a breach. Database activity monitoring is geared to be a real-time examination of incoming queries looking for an attack. A forensic audit will commonly use system tables, memory segments, TLS logs, and -- most important -- the redo logs.

For those of you who don't know Oracle, there is a difference between the audit logs and the redo logs. The redo logs are a core component of Oracle used to maintain data accuracy and help the DBA recover the database in the event of an emergency. Some transactions need to be "rolled back" -- say, due to a disk full error -- or reapplied (i.e., rolled forward) in the event of a power failure.

Redo logs are a good source of reliable information, but they are seldom used because of several specific limitations. For example, redo logs don't store the original query; rather, they store a form of shorthand notation that makes sense to the database. Human readability was never a consideration. Second, they contain a ton of information not relevant to a forensic audit, so it needs to be filtered. Finally, redo logs could be actively used by the database or in an archived state; you need a tool that can read both because it's not always clear where the relevant events are stored.

What's important about Litchfield's tool is that it provides access to an important data source for forensic audits, and it performs the core collection, filtering, and presentation features needed to make sense of the redo logs. While it's not quite fully finished, it's a handy tool that can be downloaded and evaluated for free.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.

About the Author(s)

Adrian Lane

Contributor

Adrian Lane is a Security Strategist and brings over 25 years of industry experience to the Securosis team, much of it at the executive level. Adrian specializes in database security, data security, and secure software development. With experience at Ingres, Oracle, and Unisys, he has extensive experience in the vendor community, but brings a pragmatic perspective to selecting and deploying technologies having worked on "the other side" as CIO in the finance vertical. Prior to joining Securosis, Adrian served as the CTO/VP at companies such as IPLocks, Touchpoint, CPMi and Transactor/Brodia. He has been invited to present at dozens of security conferences, contributed articles to many major publications, and is easily recognizable by his "network hair" and propensity to wear loud colors.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights