The XDAS Architecture

The Audit Record Framework implements the OpenGroup XDAS specification. XDAS provides several key features to instrumented applications: One of these features is the common audit record format. Another key feature is a standardized audit event taxonomy that allows audit records to be classified in a well-known manner. Well-known classification is one of the power points of ARF, since it allows interoperability among tools. The diagram below illustrates the software components of XDAS.

This diagram shows three colors. The light orange color indicates applications - basically clients of the XDAS library.

The OpenXDAS library contains several APIs, shown in purple in the diagram above. The submission API is the most notable, as this API is used by instrumented applications to submit audit records to the auditing system. Another important API is the filter management API, which allows audit system management applications to specify which events get transmitted, and which are simply dicarded as unimportant. The import API allows an import service to convert domain-specific audit records such as Windows WMI audit records or Unix Syslog audit records into the common XDAS format, and the pass them on to the XDAS data store. These API's make up the client-side audit instrumentation and management library.

The light green box, indicates the client-side event discrimination service. This is a daemon service running on each audit-enabled host, which manages the client-side filtering criteria - a database of filters specified via configuration and the filter management API. This service listens for audit events from each instrumented application, and forwards those events that are not filtered out to a (possibly remote) XDAS audit server.

Data Model

The standardized event types specified by XDAS are simple, but comprehensive:

These events are arranged into a two-level hierarchy, the top level of which specifies the class of event type, while the leaf level is the actual event type.

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.

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 Section 4.4.2.

Application Programmer's Interface

Full details on the OpenXDAS API can be found on the OpenXDAS website under the documentation link. The API is documented using Doxygen comments, the latest of which can be accessed from the link on the right side of the page.

Configuration

OpenXDAS is configured for remote XDAS audit server and local host persistant filters via a configuration file stored in the /etc/xdas directory - xdas.conf. This file is read by the daemon on startup for filter configuration information, and other configuration data. Configuration options will be added over time, and changes to this page will be made as appropriate.

Event Transport Service

The XDAS standard does not specify the details of the event transport service, leaving it up to individual implementations to determine the best transport service for its requirements. OpenXDAS uses the syslog transport (IETF RFC 3195) mapped onto TLS (currently an IETF draft standard).

RFC 3195 - Reliable Delivery for syslog defines a wire protocol whose XML schema is defined in a DTD. This protocol uses XML over BEEP, which is a highly configurable and open standard for data stream transport. One problem with this approach is that, while the payload of the BEEP message is very unstructured, it's also generally and practically limited to legacy sysload messages - an unstructured string with no embedded CRLF's, and a length that is generally limited to about 1K of data. Bandit ARF will attempt to conform to this wire format to the degree that we can, allowing many existing back-end syslog services to be used as a data store for the Bandit ARF event stream. Where this model breaks down is in the lack of robustness of some syslog servers. Bandit will work with the community to enhance the syslog protocol going forward. If we can't find a syslog server that meets our open source community needs, we'll implement an extended server as part of the Bandit project.

Note: While there are perhaps better wire protocols currently defined for event data, syslog is extremely pervasive, making it an ideal choice for Bandit ARF and OpenXDAS.