Auditing Categories - Implementing Database Security and Auditing - page 362

additional burden on the database. Errors can be reported using any set of
criteria, and the information is readily available for building a baseline.
Baselining is important if your application environment is less than
perfect. Not every database and application environment is squeaky clean,
and in most environments some applications generate database errors even
in production. However, errors that are generated by the applications are
repetitive: the same errors occur at approximately the same place because
the errors usually result from bugs—and these don't change. If you base-
line errors and suddenly see errors occurring from different places or you
see completely different error codes, then you should investigate what is
going on.

12.6 Audit changes to sources of stored procedures

and triggers

In Chapter 9 you learned about database Trojans and the importance of

monitoring code changes made to triggers and stored procedures. Because
these database constructs use flexible and fully featured procedural pro-
gramming languages, it is easy to hide malicious code that would otherwise
be undetectable. Therefore, you should adopt this best practice and audit all
changes made to these constructs.
As in previous sections, this category can also be audited in several ways.
The most primitive way is based on configuration control and can be
implemented by periodically (e.g., daily) retrieving the code from the data-
bases and comparing it with the code retrieved from the previous time

Figure 12.5

Real-time source
change tracking for
procedure source
code changes.