Audit Trail Functionality



next up previous contents
Next: Audit Trail Mechanism Up: Audit Trail Generation Previous: Audit Trail Generation

Audit Trail Functionality

In general, a system's audit trail is a collection of audit records containing data about security relevant events, i.e., attempted violations of the security policy and changes to the security state of the system. When required, applications should be able to generate these audit records. (If the application is an audit analysis tool, the application should also be able to read the audit records.) The audit record should contain attributes such as the time of the event, the status of the event, and the subject(s) and object(s) of the event. In portability terms, a portable application should be able to generate a record (or read the record) containing this information without being concerned about the underlying implementation-dependent record format.

The POSIX.6 audit interfaces allow for this type of portability. The internal structure of the audit record is never seen; it is manipulated only through the read and write interface functions.

The interfaces to the audit trail mechanisms provide portable applications the ability to generate audit records, to select delivery locations for the records, and for some selected applications, the ability to disable and enable the recording of certain events. In most cases these will be privileged operations.

According to the POSIX.6 standard ``there are four major functional components of the POSIX.6 audit interface specification:

  1. Interfaces for an application to write records to the audit trail and control the auditing of the current process,
  2. Interfaces for reading the audit trail and manipulating audit records,
  3. The definition of a standard set of events that shall be reportable in implementations,
  4. The definition of the contents of audit records.''
An audit trail is defined in the POSIX.6 standard as a set of sequential audit records that contain information about security relevant events occurring within the scope of the POSIX.1 standard and any optional POSIX.6 interfaces and objects. This is referred to in the standard as the system audit trail and contains records generated by the system or generated by an application. Applications may also write to other audit trails. Interfaces provide the system and applications the ability to write information about security relevant events into the system or other audit trails in the form of audit records. Interfaces provide post-processing applications the capability to read records from the system audit trail or any other audit trail that may exist on the system. The internal format of the audit trail, as well as the audit record format is not defined by this standard. This is consistent with the model of providing interfaces to opaque data structures that was discussed earlier. However an audit record does have a logical structure defined so that post-processing audit applications can call on specific items in the record.

In the context of POSIX.6, audit records are generated in two ways:

  1. By a POSIX.6 implementation, to report on the use of its security relevant interfaces. This is known as system auditing and the records are known as system generated records.

  2. By an appropriately privileged application, to report on its own activities. These are known as application-generated records.
The use of a logical audit record, as well as a standard set of interfaces to write to the audit trail, and read from the audit trail, allow the system and applications to create, read and manipulate information about security relevant events. This provides conforming implementations and applications a portable mechanism to use in recognizing and reporting on security relevant events.



next up previous contents
Next: Audit Trail Mechanism Up: Audit Trail Generation Previous: Audit Trail Generation



John Barkley
Fri Oct 7 16:17:21 EDT 1994