Browse Prior Art Database

C2 Audit Filter Disclosure Number: IPCOM000121883D
Original Publication Date: 1991-Oct-01
Included in the Prior Art Database: 2005-Apr-03
Document File: 3 page(s) / 100K

Publishing Venue


Related People

Schwendemann, W: AUTHOR [+1]


Disclosed is a description of an additional audit filter for the C2 National Computer Security Center (NCSC) auditing requirement.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

C2 Audit Filter

      Disclosed is a description of an additional audit filter
for the C2 National Computer Security Center (NCSC) auditing

      The NCSC C2 auditing requirement can severely impact system
per- formance and consume a large amount of DASD space. Although the
audit- ing requirement already specifies that the administrator must
have the capability of selecting events based on user identity, it
does not require that the success/failure of the event be taken into
consideration when creating/writing the audit record.   The current
release of AIX* 3.1 does not provide a success/failure filter for
audit records.

      Since one of the aims of the audit trail is to "detect and
deter penetration of a computer system and to reveal usage that
identifies misuse", it would be very  useful to limit the audit trail
to those events which failed because the user did not have the
appropriate privilege(s).  Having this additional filter should cause
fewer audit records to be written, saving I/O instructions and DASD
space.  After all, a malicious attempt to penetrate a computer system
is usually a sporadic event. Writing audit records which show the
user was successful will usually be of very little informational
value, unless an administrator needs to track the activity of that

      AIX allows the system administrator to group auditable events
into audit classes.  For  database manager an auditable event is
anything that  requires 'privileges' (e.g., create  database, update
table, grant/revoke,  drop database, etc.). The 'auditable event
names' are arbitrary names. For Database Manager, we chose to prefix
all our event names with "SQL_".  An event can belong to more than
one audit class. The audit class name is also arbitrary and coined by
the system admin- istrator. An example of this is as follows:
o   events
     -   SQL_create_db (create database)
     -   SQL_update (update table)
     -   SQL_grant  (grant)
     -   SQL_revoke (revoke)
     -   SQL_drop_db (drop database)
o   classes
     -   class1=SQL_create_db,SQL_drop_db,SQL_grant
     -   class2=SQL_grant,SQL_revoke
     -   class3=SQL_create_db,SQL_drop_db

      The system administrator can assign users to multiple audit
classes.  If the 'auditing' system is turned on, the user will be
audited for all the events in the audit classes that have been
assigned to them. For instance, if a user has been assigned to
class1,  and class3, they will be audited whenever the...