Auditing Architectures - Implementing Database Security and Auditing - page 376

Auditing, especially in a database environment, involves a lot of data.
Production databases can create vast amounts of granular data (more on
this later in this chapter). If you just want to cross off a task in some project
plan, you may put a solution in place that merely helps you collect and
archive this information. If this is all you do, then you are truly creating a
false sense of security because you have not created a process through which
you use the auditing information to improve security.
In order to elevate security using auditing, you must implement a prag-
matic solution and you must be able to use the data that is collected
through the auditing mechanisms. Data is not useful unless you can extract
actionable information from the data. In the case of security, this means
that your auditing solution must allow you to mine the information to
expose anomalies, intrusions, mistakes, bad practices, policy violations, and
so on. If you cannot explain to yourself how these (or at least one of these)
goals can be achieved using the audit trails, then your implementation
becomes part of the problem rather than part of the solution.
In order not to fall into this false sense of security trap, you must realize
that an auditing solution (and therefore the architecture put in place) has
two important parts: the part that collects the information and the part that
uses the information. The solution architecture must effectively support
both of these, because without one or the other, your auditing solution is
ineffective. The sections in this chapter explore some of the attributes your
auditing architecture must possess for the information to be properly col-
lected and to be usable, ensuring that your auditing solution helps you
achieve your goals.

13.2 Opt for an independent/backup audit trail

All databases have auditing features, and you can create audit trails using
any of the databases. In addition, numerous third-party solutions focus on
auditing and create an audit trail based on database activities. These systems
are external to the database and audit database activity using one of three
methods described in the next section. However, regardless of which
method is used, in all such systems the audit trail is an external and inde-
pendent audit trail—as opposed to an audit trail created by the database.
An independent audit trail is more valuable than an audit trail that is
created by the database. Philosophically, an independent and external audit
trail is aligned with a defense-in-depth strategy. Technically, an independent
trail is harder to compromise, is not going to be sensitive to bugs and vul-
nerabilities that the database may have (which can be one of the reasons for