Auditing Categories - Implementing Database Security and Auditing - page 350

event, but you should consider recording additional information. This
includes the TCP/IP address of the client initiating the connection and the
program used to initiate the connection. For example, in an Oracle envi-
ronment, you will want to know if the connection was initiated from SQL
Plus, TOAD, and such tools as opposed to a data source in Excel or a J2EE
server.
In addition to these two events, you should also record all failed login
attempts. In fact, failed login events are probably even more important than
successful logins from a security point of view. Failed login attempts are not
only recorded for auditing and compliance purposes; they are often used as
the basis for alerts and even for account lockout.
Although you may keep these three event types in the same file or table,
you will probably report on them differently. Successful logon/logoff
reports are not something most people look at unless they are doing some
kind of investigation, because these logs reflect normal operations. Apart
from investigations, an exception could be comparing files from different
periods to see if patterns are changing. However, excessive failed logins are
certainly an interesting security report, and many people periodically look
at the breakdown of these failed login attempts based on the following
dimensions:
The username
The client IP from which connections are failing
Source program
Time of day
For example, Figure 12.1 shows two views, including a breakout of
failed logins based on the login name (left) and a report showing a detailed
view of failed logins, what login name was used, which IP address the con-
nection requests came from, to which database server, and what the com-
munication type was (right).
Logon and logoff activity can be audited using database features or by
using an external database security solution. All database vendors support
this basic auditing function, and because the number of these events is
rather small (at least when compared with the number of events you may
get when auditing actual SQL calls), there is little performance penalty in
having the database perform this level of auditing.