Chapter 9: Auditing Databases

Background

When we refer to databases, the term typically is meant to refer to RDBMS. The more generic term database can be applied to any collection of data in any structured form. For instance, a flat file with customer records in it can serve as a database for an application. However, for this chapter, we are going to focus on auditing full-blown relational database management systems.

Databases usually are the neglected area of the audit. Typically, an audit includes a fairly in-depth review of various areas, including the perimeter, the operating system, the policies, etc. If time allows, an audit might cover one or two of the most critical databases. A lack of knowledge about auditing database makes it convenient to neglect this area. Databases are complex beasts requiring patience and technical know-how to audit and secure properly.

However, neglecting the database is a serious error. Databases are the virtual lock-boxes of the information age. Where do organizations store their most valuable assets? Not in perimeter devices, not in an e-mail system, and not in a flat file. They are stored in a database. When you hear about a security breach and sensitive data being stolen, ask yourself where did that data "live" when it was attacked? In a database!

Databases live both a blessed and a cursed existence. Databases are blessed because they are rarely exposed to the types of attacks that your web servers, firewalls, and other systems confront. Databases should be and almost always are buried deep and far behind the firewall. Most organizations are smart enough to know not to place their most valuable data out in the unsecured public network. Of course, this does not take into consideration that attacks, such as SQL injection, easily can make their way through a firewall and hit the database.

Databases are cursed for the exact same reason. Because databases are so far behind the firewall, securing and auditing your databases are considered afterthoughts, something to be done if you have extra time and maybe just on one or two critical databases. This has led to a situation in which database security typically is left in a shabby condition. The typical database administrator truly believes that the database is far enough behind the firewall that he or she doesn't have to take even rudimentary security measures.

The secured perimeter might serve as enough protection for the database in a perfect world. Unfortunately, we don't live in a perfect world, and the firewall is no longer a valid "last line of defense." Focus is shifting now to protecting data right where they sit, right in the database. As an auditor, you are likely to find that the database is the weak link in the security chain. This is great for the auditor because a few relatively simple recommendations can create vast improvements in your database security.