XDAS Data Structures

Audit Record Stream

Audit Event Record

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:

• firstly, a minimum set of common information needed to support the filtering of audit events and a top level analysis across the distributed environment for the purposes of traceability and assignment of accountability.

• secondly, for events originated within a domain specific audit service and imported into XDAS, a pointer to the location and position of the original record within the originating domain audit service to support more detailed analysis using domain specific audit tools if required.

• thirdly, provision for recording detailed domain event specific information within the record itself that can be used for more detailed analysis of activity within the context of the service originating the event. When importing records, event specific information may be used instead of or in addition to the pointer to the original record.

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:

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

• The length of the audit record (generated by the implementation).

• The version_number of the service, so that analysis tools can accurately interpret the information to follow (generated by the implementation).

• The date_and_time of the event (generated by the implementation at the time at which the caller commits an audit event record to the stream or when the function to explicitly timestamp the record is called).

  The XDAS specification includes the date and time specified by reference to the start of the current epoch (0000 GMT 1 January 1970). Time is represented as the:

  • The offset in millizeconds from the beginning of the epoch

  • The uncertainty interval in millizeconds of offset

  • The uncertainty indicator as a percentage of confidence in the uncertainty interval

  • The signal or source of trusted time. This shall typically be the hostname or network address of the network time server.

  • The timezone in the format stdoffset[dst[offset][,start[/time],end[/time]]]. See Time Zone Field .

  The uncertainty interval and uncertainty indicator shall be empty by default. These are considered placeholders for future use.

• The event_number, a number which uniquely identifies the event (provided by the caller)

• The outcome of the event, i.e., its success or failure (provided by the caller)

originator_information
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.

initiator_information
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.

target_information
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.

source_reference
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.

event_specific_information
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

Originator_Information

• Location_Name
  the name of the host/service defined using the syntax and quoting rules defined in Parameter Passing Conventions .

• Location_Address
  this is a communication service end point address. Comparisons on this data should use bitwise comparison.

• Service_Type
  the service_type may include information about the particular subset of functions being provided by the originator. For example, a service provider may support different subsets of functions according to the port by which it is invoked. It is represented as a text string.

• Originator Authentication Authority
  is defined using the syntax and quoting rules defined in Parameter Passing Conventions . Examples of an authentication authority are the name of a kerberos realm, an NIS domain, and a UNIX hostname.

• Originator Name
  the originator principal name as authenticated by authentication authority. Examples of principal names are a kerberos principal name, and a UNIX username.

• Originator Identity
  the originator principal identity. Examples are the DCE UUID and a UNIX uid.

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.

Initiator_Information

• Initiator Authentication Authority
  defined using the syntax defined in Parameter Passing Conventions . Examples of an authentication authority are the name of a kerberos realm, an NIS domain, and a UNIX hostname.

• Initiator Name
  the initiator principal name. Examples of principal names are a kerberos principal name, and a UNIX username.

• Initiator Identity
  the initiator principal identity. Examples of principal identities are a DCE UUID and a UNIX uid.

Note:

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.

Target_Information

• an "object" that may be identified by a name within the originating domain's namespace. For example a file on a UNIX platform, a record within a database.

• a service with which an association is established.

  In the case of client-server operations, when an association is created then both ends may be considered to be the target of the other even though strictly speaking one side is the initiator. For events recording the creation of associations the target_information therefore records information about the remote service component. The initiator_information therefore always references the original (normally end-user) principal.

  The service may assign its own representation of the principal identity to the client (e.g., using a local account database). In this case the identity assigned needs to be recorded to support traceability at the distributed system level.

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

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

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.

• Create account
  The creation of an account representing a principal within a domain.

• Delete account
  The deletion of an account representing a principal from a domain.

• Disable account
  An action the prevents a principal account from being used within a domain.

• Enable account
  An action that permits a principal account to be used within a domain.

• Query account attributes
  The requesting of the attributes associated with a principal within a domain.

• Modify account attributes
  The modification of the attributes associated with a principal within a domain.

User Session Events

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

• Create a user session
  The establishment of a processing environment to service an end user.

• Terminate a user session
  The dismantling of a processing environment associated with servicing an end user.

• Query user session attributes
  The requesting of the attributes associated with a user session.

• Modify user session attributes
  The modification of security significant attributes of the context of a processing environment servicing an end user.

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.

• Create data item
  Creation of a data item within a domain.

• Delete data item
  Deletion of a data item from a domain.

• Query data item attributes
  The requesting of the attributes associated with a domain data item.

• Modify data item attributes
  The modification of the security attributes of a domain data item such as access control attributes, ownership, aliases.

Service or Application Management Events

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

• Install service or application
  The installation of additional or updated software on a system, e.g., an application or system service.

• Remove service or application
  The deinstallation of software on a system.

• Configure service or application
  The modification of the configuration data associated with a software component.

• Query configuration of service or application
  The requesting of information about the configuration of a service or application.

• Disable service or application
  An action that prevents an application or system service from being used, for example, inhibiting responses to service requests. It may also involve the termination (shutdown) of application processing components that are currently providing the service.

• Enable service or application
  An action that permits an application or system service to be used, for example, allowing responses to service requests. This may also involve the invocation of specific application processing components (startup).

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.

• Invoke service or application
  The invocation of a service or application (exec), e.g., operating system utility, database, accounting application, etc.

• Terminate service or application component
  The termination (exit) of the use of a service or application. This could be at the instigation of the application itself or by the intervention of the domain in response to user or administrative action.

• Query processing context
  The requesting of the attributes associated with the current processing environment.

• Modify processing context
  The modification of the attributes associated with the current processing environment.

Peer Association Management Events

• Create an association with a peer
  The creation of a communication channel and the processing context between system components.

• Terminate an association with a peer
  The closure of a communications channel and destruction of processing context between system components.

• Query an association context
  The requesting of the attributes of a context associated with a communications channel between peers.

• Modify an association context
  The modification of the attributes of a processing context associated with a communications channel.

• Receive data via an association
  Receiving data from associated peer within current association context.

• Send data via an association
  Sending data to associated peer within current association context.

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.

• Create association with data item
  Create an association with (open) a data item. This creates a binding between the caller and the data item.

• Terminate association with data item
  The termination of an existing association with (close) a data item.

• Query context of association with data item
  The requesting of the context of an association with a data item, e.g., mode of access, size limits, access path, etc.

• Modify context of association with a data item
  The modification of the context of an association with a data item or resource element.

• Query data item contents
  The requesting of the contents of a domain data item (read).

• Modify data item contents
  The modification of the contents of a domain data item (write, append, etc.).

Exceptional Events

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

• Start system
  The action of booting a system host or of changing the processing state of a system host to an operational mode.

• Shutdown System
  The action of halting the processing by a system host or of changing the processing state of a system host to a maintenance mode.

• Resource exhaustion
  The detection of resource exhaustion which has a potential impact on system operations, perhaps based upon a configurable threshold, e.g., data storage resources, communication end points.

• Resource corruption
  The detection of an integrity failure of a system resource, for example data storage resource.

• Backup datastore
  The action of making a backup copy of a datastore for the purposes of protecting availability and integrity of the data it contains.

• Recover datastore
  The action of restoring the contents of a datastore from a previously made backup copy for the purposes of restoring the availability of the contents, or the integrity of the contents, or both.

Audit Service Management Events

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

• Configure audit service
  The modification of the parameters controlling the operation of the audit service, for example, audit event filtering criteria.

• Audit datastore full
  The detection of resource exhaustion for the particular instance of the resource used to store the log of audit event records.

• Audit datastore corrupted
  The detection of a datastore integrity failure for the particular instance of the resource used to store the log of audit event records.

Event Classes

Default Event Classes

• Account management events

• User session events

• Data item and resource element management events

• Service and application management events

• Peer association management

• Data item or resource element content access events

• Exceptional events

• Audit service management events

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

Outcomes

Outcome	Outcome Description
Successful	XDAS_OUT_SUCCESS
	XDAS_OUT_PRIV_USED
	XDAS_OUT_PRIV_GRANTED
	XDAS_OUT_PRIV_REVOKED
	XDAS_OUT_PRESELECT_CRITERIA_SET
	XDAS_OUT_THRESHOLDS_SET
	XDAS_OUT_ACTIONS_SET
	XDAS_OUT_THRESHOLD_EXCEEDED
Failure	XDAS_OUT_FAILURE
	XDAS_OUT_SERVICE_UNAVAILABLE
	XDAS_OUT_SERVICE_FAILURE
	XDAS_OUT_HARDWARE_FAILURE
	XDAS_OUT_LOST_ASSOCIATION
	XDAS_OUT_ALREADY_ENABLED
	XDAS_OUT_ALREADY_DISABLED
	XDAS_OUT_SERVICE_ERROR
	XDAS_OUT_BUSY
	XDAS_OUT_DISABLED
	XDAS_OUT_INVALID_INPUT
	XDAS_OUT_ENTITY_EXISTS
	XDAS_OUT_ENTITY_NON-EXISTENT
Denial	XDAS_OUT_DENIAL
	XDAS_OUT_INSUFFICIENT_AUTHORIZATION
	XDAS_OUT_INVALID_IDENTITY
	XDAS_OUT_INVALID_CREDENTIALS

Event Selection

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

Table: Event Filtering Criteria

• Preselection criteria may be applied when an event is submitted to determine whether an event is to be audited.

• Selection criteria may be applied when an event is imported from a domain specific audit service to determine whether the event is to be imported.

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

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

Event Filters

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.

Flag
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

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.

Attribute
The event attribute or field.

Operator
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.

Note:

The event outcome codes have been structured for convenience in checking using a test for bits set.

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

Filter Action List

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

• LOG + Empty string

• ALARM + Severity Code

• ACTION + Pathname of executable or script to invoke and input parameters