Previous section.

Distributed Audit Service (XDAS)
Copyright © 1998 The Open Group

XDAS Data Structures

This chapter presents a definition of the data structures needed for the Distributed Audit Service.

Audit Record Stream

The XDAS API assumes that audit event records are inserted into and read from a time sequenced stream of audit records in a common format. This stream of records is termed an Audit Stream. The organization and management of the system resources used to comprise the audit stream is implementation defined.

Audit Event Record

Information regarding an audit event is recorded in an Audit Event Record. The following section presents a definition of the portable common exchange format for audit event records. This is the format in which records are submitted to, or retrieved from, the XDAS API.

The audit record contents are represented using the UTF-8 character encoding. This does not assume that the record contents are in a form that can be displayed as readable text. In addition, manifest constants shall not be localized by any internationalization routines used within XDAS implementations.

The audit event record comprises:

Thus, the detailed information from the source domain is not necessarily required for analysis in the context of the distributed environment. For example, an agent may have created objects in a database, the distributed environment may only be interested in the fact that database objects have been created, and not specifically in the type of database object, say a trigger.

In order to be both portable and extensible, the format proposed here adopts an approach based on self-defining attributes expressed in a textual format. See Parameter Passing Conventions for the actual format.

The structure of an audit record is as follows:

The header is a mandatory component of an audit event record and contains essential information about the event to be recorded:

The originator of an event is defined as the service that detects and requests the recording of an audit event. As such it defines the security domain in which the event occurs.

The originator_information is a mandatory component of an audit event record. It is generated by the implementation on the basis of information provided by the caller when an association between the caller and the audit service is initialized.

The initiator of an event is defined as the principal that is accountable for the initiation of the action that results in the audit event.

The initiator_information is a mandatory component of an audit event record and is provided by the caller.

This defines the target on which the initiator has acted. The target may be the identity of a service with which a session has been initiated or terminated.

The target_information is an optional component of an audit event record and is provided by the caller.

The source_reference is an optional component of an audit event record and is provided by the caller. It is a pointer to the original audit event record for those records that have been imported to the XDAS service from a domain specific audit service. The intention is that this information provides the location of the audit record within the original domain if more detailed analysis is required. This information is provided by the original domain when calling the XDAS import API.

The event_specific_information is provided for primary use by applications using XDAS as their primary audit service. Event_specific_information varies from one event to the next and is specific to the context of originating security domain identified by the originator_identity

The event_specific_information is an optional component of an audit record and is provided by the caller. It may include information pertaining to the security context of originator, initiator or target.

The structure of this field is required to be textual, that is, it cannot contain any binary data except in an encoded format. If used, this must be printable UTF-8 character strings consisting of comma separated attribute=value pairs.

Originator, Initiator and Target Information


The information associated with an originator, the service that detects and records an audit event, comprises:

It is not mandatory that both the location_name and the location_address are completed, but at least one of them shall be.

The originator authentication authority, originator name and originator identity represent the authenticated identity of the originator. The originator authentication authority and originator identity are mandatory information. The originator name is optional and may be left empty.


The information associated with an initiator comprises
It should be noted that in some circumstances it may be desirable or required by regulation that events are not associated directly with individual users without an additional reference stage in the analysis. This may influence the information that is actually stored in an XDAS record. For example, an audit ID distinct from an access ID or principal ID may be used within an audit event record.
The initiator authentication authority and initiator identity are mandatory information. The initiator name is optional and may be left empty.


The target of an activity that results in an auditable event may be:

Not all events necessarily have a target. When a target is relevant to an event the target authentication authority, target name and target identity represent the authenticated identity of the target. The target authentication authority and target identity are mandatory information if a target is recorded. The target name is optional and may be left empty.

Identification of Audit Events

The identification of audit events is an important part of supporting requirements to filter and select audit events.

Audit Events may be specifically referred to by an Event Number. A set of Audit Events may be referred to by an Event Class. An XDAS defined set of generic Event Classes are listed at the end of this section.

The purpose of defining Event Classes is to facilitate the definition of filtering criteria for the control of the audit service and for facilitating the definition of search criteria for audit analysis. An audit event record only includes the Event Number. It does not include any reference to Event Class

Event Numbers

XDAS defines a minimum required set of generic event numbers. It is possible for application developers to register their own additional event numbers if they wish to utilize the services of XDAS for more domain specific auditing not catered for by the generic set of XDAS events.

A conforming implementation is required to treat as valid all the XDAS audit events and event classes defined in this specification and to provide an implementation defined method for configuring additional registered event numbers and event classes as valid.

XDAS Events

The following generic events are registered by XDAS. Not all of these events are necessarily security significant within all domains. For example the querying of attributes or configuration data is not necessarily of security significance.

Account Management Events

This set of events is applicable to the management of principal accounts. A principal may be an end-user or a service within the system, a psuedo-user.

User Session Events

This set of events is relevant to the creation and use of user sessions on the system.

Data item and Resource Element Management Events

This set of events relate to the creation and management of data items and resource elements within a domain. The type of data item or resource element is dependent upon the domain, e.g., files and directories, device special files, shared memory segments, within an operating system, tables and records within a database, messages within an email system. The term data item is used to refer to any type of resource element.

Service or Application Management Events

This set of events relate to the management of system services and applications.

Service and Application Utilization Events

These events relate to the use of service and applications. They typically map to the execution of a program or a procedure and manipulation of the processing environment.

Peer Association Management Events

Data Item or Resource Element Content Access Events

These events relate to the formation of an association between a service or application and a data item or resource element for the purpose of using its contents or services. For example, a file or directory, device special file, memory segment, communications port, etc.

Exceptional Events

These are events that are considered to be outside the generalized events listed above.

Audit Service Management Events

These are events of specific relevance to the audit service itself.

Event Classes

Audit Events may be specifically referenced by an Event Number. A set of Audit Events may be referred to by an Event Class. The concept of an Event Class is included in the XDAS solely as an administrative convenience. It provides an efficient and convenient reference to sets of audit events so that audit filters can be easily defined. An audit event record only includes the Event Number. It does not include any reference to Event Class for two reasons: its inclusion leads to redundant information in the audit record; and the mapping of event classes across administrative domains is problematic. When specified in filtering selection criteria, an event class is translated internally into the individual event numbers.
Default Event Classes
The XDAS defines a default set of event classes. Others can be defined by the implementation and configured by a system administrator to group together XDAS event numbers in a meaningful way. The default set of event classes defined by the XDAS are listed below:

The default mapping of events to these event classes is as listed in XDAS Events .


An event shall be identified by both its event number and outcome. The following outcome codes and sub-codes are defined by this specification:

Outcome Outcome Description

Event Selection

Field Event Event
  Submission Import
Length - -  
Version X X  
Date - X  
Event Number X X  
Outcome X X  
location_name - X  
location_address - X  
service_type - X  
auth_authority - X  
name - X  
identity - X  
auth_authority X X  
name - X  
identity - X  
location_name - X  
location_address - X  
service_type - X  
auth_authority - X  
name - X  
identity - X  
Source: - -  
Event_Specific: - -  

Table: Event Filtering Criteria
Event selection criteria may be applied at the two places within the XDAS architecture at which events are entered into the service:

sets out the preselection filtering criteria. An "X" indicates that the field is available for filtering; a "-" that it is not.

Event Submission Preselection Filtering

The filtering criteria for preselection of events on event submission is constrained by considerations of limiting the performance impact of evaluating the criteria on the calling application and the system as a whole.

Whilst date and time of day are valid requirements for filtering on event submission, they are not included as mandatory requirements in the table. This is because this selection can be achieved more efficiently using a scheduling service to switch event filtering criteria as a whole.

The event originator is not included in the table, even though it is a valid requirement for filtering. This filtering can be achieved more easily as an application level facility which turns auditing on or off for the application as a whole, or for subservices within an application. It is not considered to be a valid XDAS function.

Filtering by initiator auth_authority is a requirement as an auth_authority may be compromised or otherwise untrusted. However, controlling filtering by individual identity impacts performance significantly and thus, it is not a mandatory requirement in the XDAS. Such filtering is more efficiently performed on import or post-selection analysis.

Event Import Preselection Filtering

XDAS supports a much richer set of filter criteria for controlling the selection of records for import to XDAS as the performance impact is of lesser concern in this case.

Event Filters

An event filter comprises the following information:

Version Number
The XDAS version number.

Filter Name
A name by which the filter is referred to.

Filter Type
The filter applies to the event submission or event import interface, or both interfaces.

The flag which indicates whether the filter is enabled or disabled.

Expression List
A set of expressions which must all be satisfied to establish the complete filter to be applied.

Action List
The actions to be taken when the event is detected.

Filter Expression List

A filter expression list comprises a set of expressions which must all be satisfied to establish the complete expression to be applied. This specification does not assume any precedence or ordering of the evaluation of a set of filters (although an implementation may apply one for performance reasons). If an event requires auditing under the filtering criteria of any individual filter then it shall be audited, even if excluded by other filters. In the circumstance that an event is required to be audited by multiple filters then duplicate audit event records shall not be created.

An expression comprises:

Include/Exclude Flag
Events matching this expression are to be included or excluded from selection. When a filter is evaluated all inclusions are processed first and followed by all exclusions.

The event attribute or field.

The operator defines the boolean operation to be performed on the attribute. Operators are equal, greater than, less than, greater than or equal, less than or equal, not equal, test for bits set, substring.
The event outcome codes have been structured for convenience in checking using a test for bits set.

The value against which the attribute value in the event is tested.

Filter Action List

The filter action list comprises a sequence of action definitions. Each action definition comprises an action bit mask to indicate the action(s) to be taken and a text string that is used to further define the action(s).

Action Mask
The action(s) to be taken. This can be LOG, ALARM or ACTION or any combination.

Text String
A text string that provides additional information pertinent to the action to be taken. The format of this string is implementation defined.

Examples of the filter action list are

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index