Database Reference
In-Depth Information
Chapter 6
Centralized Native Auditing and IPS
In larger database estates it is normal for audit trails to be sent off-host to avoid tampering and for them to be
centralized in order to provide greater oversight. It is also common for monitoring to be deployed as part of a
pre-audit compliance project, such as PCI, SAS70, or SOX. After compliance is achieved, the new audit trail also raises
the potential of automatically triggering alerts and blocking actions based on the content of the audit trail.
We will start this chapter with standard centralized syslogging and then move on to the tasks that can be achieved
once it is running. Syslog has many potential users, so I am genuinely excited that Oracle has listened to its customers
and kept it in 12c. Toward the end of this chapter we will demonstrate how to use syslog monitoring to automatically
block and kill all incoming DB Link sessions. This ability has been on the community's wishlist for a number of years,
and it can be achieved using syslog, as we shall see.
The Unified Audit Trail
12c database comes with the same audit trail as 11g, but with the additional option of turning on
Unified Audit Trail
(UAT).
UAT brings the various database audit trails together in a single view who's contents are stored in Oracle's
SecureFile format. Interestingly, unified auditing is not turned on by default in 12c, even though the familiar
audit_
trail
parameter is. In other words, SecureFiles are not used by default for audit trail.
The following example shows the default setting of
FALSE
:
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
VALUE
----------------------------------------------------------------
FALSE
The fact that this new feature is not turned on by default implies some ambiguity as to whether it will used much
in the future. Personally, I am happy with the current audit trails formats as they are. I can see the point of centralizing
DB-based audit into a single view, which is easy to do anyway. However, myself and others would prefer the audit files
to stay in plaintext and not be converted into the proprietary SecureFiles format, because doing so will make it more
difficult to use those audit files.
Syslog is still available partly due to customers and experts like ourselves fighting to keep it in. The reason we
fought for it is because it is highly usable. The problem with DB-based audit tables is that it is harder to use them to
prompt a responsive action, especially in a distributed server network. Conversely, Unix syslog is specifically designed
to be light, mobile, and easily searchable using utilities like
grep.
Additionally, syslog at the OS is the perfect place
from which to enact a response to actions in the DB, because the OS has the privileges to kill DB sessions. DB triggers
are not designed to kill their initiating session, so they can't be used for blocking an attack in the style of a “
native IPS.
”
