Auditing Architectures - Implementing Database Security and Auditing - page 375

13

Auditing Architectures

In the previous chapter you learned about the various auditing categories
that you may have to implement. You saw that auditing of the database
environment is not an all-or-nothing exercise and that you may choose to
audit many categories of data and access types, depending on the security
and compliance requirements of your organization.
In this chapter you'll explore architectural details that will help you imple-
ment a useful and pragmatic auditing solution and address security and com-
pliance requirements. You'll see that it is not enough to decide which events
and elements need to be audited, but that you also need to pay attention to
the architecture and systemic attributes of your auditing solution.

13.1 Don't create a false sense of security

Auditing is a means, not a goal. The purpose of auditing is to elevate secu-
rity and to bring you closer to compliance with various security policies and
regulations. There is no need for auditing that is devoid of such business
drivers. Therefore, whatever auditing solution you choose to implement,
make sure that it brings you closer to these goals.
A common mistake that people make involves creating comprehensive
audit trails for the purpose of creating audit trails. Having an audit trail
does not elevate security unless it is used. As an example, having a log file
(or database table) that contains 20 million line items every day does not
elevate security. In fact, it creates a false sense of security and in doing so
makes your environment less secure. If you know your database environ-
ment has no security and auditing provisions, then you are more likely to
pay attention to anomalies and various strange events than you would if
you think you have some form of security and auditing framework in place.