There’s more to database auditing than simply reporting what happened to the database last week. Today, a database auditing tool would be considered lacking if it couldn’t identify exactly what data in the database had been changed, when the change occurred, what application or transaction made the change, where the application had been initiated from, and who initiated the application or transaction. But that’s not all. It should be able to identify in real-time—not just historically— when a company policy has been violated—meaning when someone is deleting data they aren’t authorized to, or even when someone is behaving in an unusual way (such as browsing files that aren’t part of their projects). Finally, the audit software should then respond in a way that’s policy-driven (e.g., creating an alert).
Why audit your database? Is this another boring, unnecessary task your overworked IT department will eventually get around to? Definitely not. Your data, the information sitting in your database, is among your company’s most valuable assets. If it were in any other form, you’d lock it in a vault protected by security cameras so you could see who went near the vault, who entered it, and who physically examined your asset. That, metaphorically speaking, is what database auditing tries to provide. It ensures the integrity of your data.
Database auditing has moved a long way from being a glorified reporting tool, and regulations have driven much of that evolution. A result of corporate scandals and the need to ensure companies apply best practices, the regulations have emerged at multiple levels, including:
• Industry, where the Payment Card Industry (PCI) is an example
• State, where California’s SB 1386 is an example
• Federal, where the Sarbanes-Oxley Act (SOX) and Health Insurance Portability and Accountability Act (HIPAA) are examples
• International, where examples are the Directive 95/46/EC of the European Parliament, the Council of 24 October 1995 on privacy, and the Japanese Financial Instruments and Exchange Law (FIEL).
Because compliance failures can be expensive, each organization must ensure its database auditing policy supports applicable regulations or frameworks.
The simplest type of database auditing involves reading database logs. While it would be easy to produce a report about what happened to the database, this wouldn’t really satisfy our initial discussion of the characteristics of a good auditing tool because it would always be historical. It couldn’t warn us that a policy violation was occurring in our database— only that one had occurred. It also would be unable to warn us if unusual activity was occurring. For example, if someone without appropriate authorization was changing the payroll file, we’d be unaware of it until the log files were analyzed the next day or next week. The logs don’t include all the information that’s needed for an audit. So, for example, if someone were to read sensitive data, this unauthorized activity wouldn’t appear in the re-do logs. The final problem with log data is that much of it isn’t intended for monitoring or auditing purposes, so time is wasted while this additional data is read.
DB2 and other databases come with their own trace utilities you can use to: