Documentation

• 1: Introduction
• 2: Event Modelling
• 3: Basic Structure
• 4: Schema Actions
• 4.1: Alert
• 4.2: Approval
• 4.3: Authenticate
• 4.4: Authorise
• 4.5: Copy / Move
• 4.6: Create / View / Delete
• 4.7: Import / Export
• 4.8: Install / Uninstall
• 4.9: Network
• 4.10: Print
• 4.11: Process
• 4.12: Search
• 4.13: Send / Receive
• 4.14: Unknown
• 4.15: Update
• 5: Object Types
• 5.1: Resource
• 5.2: Search Results
• 5.3: Shortcut
• 5.4: User
• 5.5: Virtual Session
• 5.6: VOIP
• 5.7: Association
• 5.8: Banner
• 5.9: Chat
• 5.10: Configuration
• 5.11: Criteria
• 5.12: Document
• 5.13: Email
• 5.14: File
• 5.15: Folder
• 5.16: Group
• 5.17: Group Chat
• 5.18: Object
• 6: Unstructured Data
• 7: Data Types
• 8: Meta Element
• 9: Complete Examples
• 9.1: XML
• 9.1.1: Meta (JSON)
• 9.1.2: Meta (XML)
• 9.1.3: Object Types
• 9.1.3.1: Criteria
• 9.1.3.2: Search Results
• 9.1.4: Schema Actions
• 9.1.4.1: Import (Object)
• 9.1.4.2: Network (Close)
• 9.1.4.3: Print
• 9.1.4.4: Search
• 9.1.4.5: Send (Document)
• 9.1.4.6: Send (File)
• 9.1.4.7: Alert (Network)
• 9.1.4.8: Import (File)
• 10: Glossary

1 - Introduction

This documentation describes the event-logging XML Schema herein referred to as the ‘schema’. This is a guide for anybody interested in using the schema for recording auditable events and includes details of the structure, features and common usage.

The schema aims to provide a structure for describing all forms of auditable events in a structured and consistent way. The benefit of the schema is that events translated into it are all in a consistent normalised form enabling common processing of the translated events.

Each action performed by a user, system or application component during the course of operation produces one or more events. Some of these events need to be recorded for the purposes of audit.

In order for event data to be useful each event must contain the following information:

• When did it happen? – What was the time when the event occurred?
• Who is responsible? – Who was the user and/or device that caused the event to occur?
• Where did it happen? – Where was the user and/or device located when the event happened?
• What happened? – What data was created, updated, deleted etc?

When did it happen?

It is important for analysts to be able to understand the order in which events occurred and what events are related. To do this it is vitally important that all events are recorded with an accurate time, ideally down to millisecond precision.

A single task performed by an end user may result in many events being raised by several devices. Because each device records events separately, clocks must be synchronised between devices so that it is possible for the analysts to determine the order in which events occurred across devices.

Some non-interactive events are attributable to a user but may run as scheduled jobs or as asynchronous tasks (see Run As). As a result the time of the event will not be the same as when the user interacted with the system. Where this is the case analysts may not be able to determine the exact order of events.

In some cases devices being used by an end user may be located in different time zones, e.g. a user may be interacting with a client machine in one country while the server is in a different country. For this reason all times must be recorded in UTC (a.k.a. Zulu Time denoted Z). The DeviceComplexType structure provides a means for recording the time zone of the devices involved in the event.

For consistency times should be zero filled where the source devices do not record times to the nearest millisecond, e.g. if a time is only recorded to the nearest minute then the end of the time string would be 00.000Z.

Who or what caused it?

When recording any events it is important for analysts to know the source of the event.

Most events will be raised as a result of user interaction with a device, however some occur as a result of a device process (e.g. OS start-up) or scheduled task (e.g. cron job) and therefore have no attributable user or are attributable to a processing user account.

In many cases an event may be the result of a user performing an action on a server via a client terminal.

Where an event has been raised in this way the event log should record information about the user, client terminal and device that recorded the event.

In most cases the server will identify the user via PKI or username & password authentication. The server will also be aware of the IP Address of the client computer that they have connected from.

Where an event is raised as a result of direct user interaction the user must always be recorded.

In some instances a user may be performing an action using elevated privileges or through another user account, e.g. when using sudo in Linux. In these instances it is important to capture both the user that initiated the event and the account that they performed the event as (the Run As user).

Where did it happen?

Analysis of event data often relies on knowledge about the geographic location of the user and associated devices used when the event log is generated. Because of this the schema allows for the location to be provided for each device including the client terminal in use when the event was raised.

In addition to location information other attributes of the devices involved in the generation of an event can be added including the IP address, FQDN, MAC address and Port.

What happened?

There are many different types of event that are recorded for analysis. These include user logon, log off, search, delete, view etc.

Each type of event needs to include specific data that is relevant to the event, e.g. logon would need to contain details of the user who logged on.

The schema includes a number of ‘schema actions’ that encompass most auditable events, e.g. Create, Update, Export, Send, etc. Where an event has to be recorded that doesn’t fit into one of these predefined categories then the Unknown ‘schema action’ can be used, but this should be a last resort as its content is unstructured and reduces the normalisation benefits.

Putting it all together

It can be hard to imagine what complete events look like, so a number of complete examples are available.

2 - Event Modelling

The following table provides a number of examples of how some common event types can be modelled.

3 - Basic Structure

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v3.0.0.xsd" 
  Version="3.0.0">
    <Event>
    ...
    </Event>
    <Event>
    ...
    </Event>
    ...
</Events>

The <Events> root element contains zero-to-many <Event> elements to describe each event in the set. Events can either be sent individually or in batches.

Describing an Event

As discussed in the Introduction every event must describe when it happened, who was responsible, where it happened and what happened.

The schema is intentionally very permissive with the majority of elements being optional. The reason for this is that not all systems will be able to provide the same breadth of event data and a partially populated event is preferable to no event. Enforcement of mandatory data items can be done outside of the schema.

In the various examples that follow some elements that appear in the example may be optional and are only shown as guidance.

Describing When?

To describe when an event happened a timestamp must be present on every event, see the following example.

<EventTime>
  <TimeCreated>2013-03-11T17:34:14.623Z</TimeCreated>
</EventTime>

The date and time must be in the format described in Data Types.

Describing The Source of the Event?

Each event must describe who or what is responsible for the event occurring.

The <EventSource> element describes the event source, e.g. System, Environment, Generator, User, Client, Device, etc. See the following example.

<EventSource>
  <EventId>7483983873</EventId>
  <SessionId>node0j4ii2zxu01i91g5f8odup78c30</SessionId>
  <System>
    <Name>Some System</Name>
    <Environment>Operational</Environment>
    <Organisation>Some Org</Organisation>
    <Tags>
      <Tag>critical-system</Tag>
    </Tags>
  </System>
  <Generator>Some-Event-Log-Provider</Generator>
  <Device>
    <HostName>someserver.someorg.org</HostName>
    <IPAddress>123.123.123.123</IPAddress>
    <Location>
      <Country>UK</Country>
      <Site>Big Campus</Site>
      <TimeZoneName>Europe/London</TimeZoneName>
    </Location>
  </Device>
  <Client>
    <IPAddress>121.121.121.121</IPAddress>
    <Location>
      <Country>FR</Country>
      <Site>Small Campus</Site>
      <Room>A1a</Room>
      <Aisle>A1</Aisle>
      <Desk>1</Desk>
      <TimeZoneName>Europe/Paris</TimeZoneName>
    </Location>
  </Client>
  <User>
    <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    <UserDetails>
      <Organisation>Some Org</Organisation>
    </UserDetails>
  </User>
</EventSource>

Identifying events

The system generating the event can label each event with a unique identifer that allows multiple events to be associated together (see <EventChain> below). Such an identifier need only be unique within the events generated by that system, or globally unique (e.g. a UUID). The identifier is recorded in the <EventId> element.

Sessions

Sometimes events occur as part of a session, for example a user’s session in a web application or some other grouping concept such as low level system events that take place in the same thread. To make it possible for the system receiving the events to group multiple events that are part of the same session, the <Event>/<EventSource>/<SessionId> element can be used. Each event would set this element with the current session or thread ID. The session ID may only be unique within the source system but it can be used in conjunction with the system name to group events.

An example of this can be seen in the search event here.

System

The <System> structure provides information about the name of the system that created the event, the deployment environment and the organisation that owns it. It is also possible to provide a description and classification of the system.

Generator

The generator is an application, service or specific component that created the event, such as ‘Microsoft-Accounting-Service’ or ‘Apache-HTTPD’. Event type ids (see Type ID) are unique to a particular event generator so a generator name must be included.

Devices

Devices elements, including the generator, client and server devices, provide a means of recording sufficient details about the devices involved in the generation of the event. The structure allows for the recording of the identity of the device as well as its location physically and on the network.

Physical Access (Doors)

Where entry/exit to buildings/rooms is managed by a physical access control system this element can be used to record events at the door. Some form of authentication and authorisation will be required in order for the user to pass through the door, so the outcome of that authorisation can be recorded including failure conditions.

For every door event the door authentication device is the event source. A description of the door may be added to the <EventSource> element that is specific to the door authentication device used, see the following example.

<EventSource>
  <System>
    <Name>Some System</Name>
    <Environment>Operational</Environment>
    <Organisation>Some Org</Organisation>
  </System>
  <Generator>Door Software</Generator>
  <Door>
    <Name>Main Entrance Door</Name>
    <SingleEntry>true</SingleEntry>
    <OneWay>true</OneWay>
  </Door>
  <User>
    <Id>jbloggs</Id>
  </User>
</EventSource>

The elements <SingleEntry> and <OneWay> determine the access control characteristics of the door.

Some doors only allow entry/exit from the side that the authentication device exists on to the other side (one way), and only allow one person to enter/exit at a time (single entry).

Sliding doors or hinged doors potentially allow users to pass in either direction (not one way) and also allow for multiple users to pass through despite only a single authorisation (not single entry).

The identity of the user may be resolved from the pass/access device used to a user id.

The following door events may be recorded:

• Entry – User has authenticated and entered through door.
• Exit – User has authenticated and exited through door.
• Reset – Reset of door entry system to allow passes to be used in either direction.
• None – User has authenticated but not entered or exited.

Describing Where?

A device or door typically has some form of physical location. The location can include details such as the country, site, building, room and desk/rack. It can also include details of the timezone of that physical location.

User

When sharing data within large global organisations it is important that an individual (who may have access to multiple systems across multiple parts of that organisation) can be identified. Individuals may have multiple identities within each part of the organisation due to the scope, purpose and limitations of individual systems. Examples of these many forms of identity range from door access card numbers, email addresses, user names, certificates and user IDs.

Many of these forms of identity may not be unique across all parts of an organisation so it is important to resolve this to an identifier that is unique across the organisation. For example the door systems for each building may be independent and have their own ID scheme. Therefore this local ID should be replaced with a globally unique identifer, keeping the local identifier in a Data element.

In addition to this, user details can be provided to describe which part of the organisation the user works in, e.g. country/group/unit.

Many events may be triggered by a device and not involve a specific user. In these cases it is only necessary to describe the device that the event occurred on.

Run As

Some events may be executed by a user assuming the identity of another user, e.g. use of sudo. Where this is the case it is mandatory to describe the user that the event is being executed as using the <RunAs> element.

The <RunAs> element may also be used when an event is executed by the device on behalf of a user. This can often be the case when executing scheduled tasks, e.g. overnight database clean up jobs.

As with the <User> element the <RunAs> element must contain a unique user identifier.

Interactive

For some events the user may not have been present at the time the event occurred. This can be the case for scheduled tasks or tasks that are executed from a queue, e.g. asynchronous processing. In these cases it is necessary to indicate that the event was not interactive, i.e. not triggered by a user directly. This is done using the <Interactive> element.

Data

For any event source data that cannot be described using the defined structure, <Data> elements can be used, though care should be taken to use these elements in a consistent way to allow for future processing and inspection of events.  

Describing What Happened?

Each event will describe what happened within the <EventDetail> element. The content of the <EventDetail> element will be specific to the type of event that occurred, e.g. a logon event would contain information about the type of logon, see the following example.

<EventDetail>
  <TypeId>InteractiveLogon</TypeId>
  <Description>A user has logged on.</Description>
  <Authentication>
    <Action>Logon</Action>
    <LogonType>Interactive</LogonType>
    <User>
      <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    </User>
  </Authentication>
</EventDetail>

Description

The <Description> element allows for the inclusion of a human readable description of the event type.

Type ID

The <EventDetail> element includes a mandatory TypeId element. This element identifies the unique event type as known to the generator. For example a generator may distinguish 2 types of logon event just by some id. Use of this element would be the only way to treat the two types differently. In the case of application logging the Type ID should be unique to a use case within the system, e.g. CreateDocument, DeleteRecord, DocumentSearch, UserSearch, etc.

The form of the Type IDs is specific to the generator and could be strings or numeric codes, as long as they provide a unique identifier for that type of event within that generator. Where a generator already produces some form of ID for its events, e.g. Microsoft system event codes these can be used directly, however in the absence of predefined code a human readable TypeId is preferable as it is more easily understood by human.

Having sensible Type IDs is of particular benefit when developing processes that depend upon events conforming to the schema as it allows the developer to group events by the Type ID or to have conditional processing based on the ID.

Classification

The <Classification> element can be used to describe the classification, protective marking or sensitivity of the data in the event. For example the data may be commercially sensitive or contain sensitive personal data. The element includes a number of optional elements so can be as simple as just a free text <Text> element containing something like COMMERICAL IN CONFIDENCE to multiple elements that described the protective marking in complex classification scheme.

The <Classification> element appears in a number of places in the schema as it can be used to describe the sensitivity or marking of different entities/objects. For example it can be used to describe the sensitivity of a set of audit events in aggregation, the content of a single audit event or an object that is the subject of an audit event, i.e. a document being viewed by a user.

The following are some examples of populated Classification elements:

<Classification>
  <Text>COMMERICAL IN CONFIDENCE</Text>
  <Classification>COMMERICAL IN CONFIDENCE</Classification>
</Classification>

<Classification>
  <Text>CONFIDENTIAL</Text>
  <Originator>
    <Country>GBR</Country>
    <Organisation>UK Headquarters</Organisation>
  </Originator>
  <Custodian>
    <Country>GBR</Country>
    <Organisation>Group Headquarters</Organisation>
  </Custodian>
  <Classification>CONFIDENTIAL</Classification>
  <Descriptors>
    <Descriptor>PERSONAL</Descriptor>
  </Descriptors>
  <OrGroups>
    <AccessControlGroup>Human Resources</AccessControlGroup>
    <AccessControlGroup>Managers</AccessControlGroup>
    <AccessControlGroup>Auditors</AccessControlGroup>
  </OrGroups>
  <PermittedNationalities>
    <Nationality>GBR</Nationality>
    <Nationality>USA</Nationality>
  </PermittedNationalities>
  <PermittedOrganisations>
    <PermittedOrganisation>UK Headquarters</PermittedOrganisation>
    <PermittedOrganisation>Group Headquarters</PermittedOrganisation>
  </PermittedOrganisations>
  <DisseminationControls>
    <DisseminationControl>ORIGINATOR_CONTROLLED</DisseminationControl>
  </DisseminationControls>
  <Disposition>
    <Date>2020-03-11T00:00:00.000Z</Date>
    <Process>DELETE</Process>
  </Disposition>
</Classification>

Purpose

Certain auditable events may require users to provide justification for the action they are taking, e.g. viewing a personnel record or processing a high value payment. This element provides the means to record the justification/purpose of the auditable event and possibly any authorisations that were obtained.

Schema Action

The action specific detail of the auditable event is recorded in a ‘schema action’ element, where the structure of each element is tailored to the auditable action.

The schema action element structures are defined in more detail in Schema Actions.

Event Chain

Sometimes events occur that are directly related to another event, for example when an asynchronous search is initiated by a user and at some later point they view the search results. The second event can be considered a child of the first. Event relationships like this can be recorded using the <Event>/<EventChain> element. Linking events relies on the source system uniquely identifying (within the scope of the source system) each event and recording this unique ID in the <Event>/<EventSource>/<EventId> element.

If you had an event with ID 3 that was a child of an event with ID 2 that in turn was a child of an event with ID 1 you would model it as follows:

Event 1 (grandparent)

<EventSource>
  <EventId>1</EventId>
</EventSource>

Event 2 (parent)

<EventSource>
  <EventId>2</EventId>
</EventSource>
<!-- ... -->
<EventChain>
  <Activity>
    <Id>1</Id>
    <Name>Grandparent event</Name>
  </Activity>
</EventChain>

Event 3 (child)

<EventSource>
  <EventId>3</EventId>
</EventSource>
<!-- ... -->
<EventChain>
  <Activity>
    <Id>2</Id>
    <Name>Grandparent event</Name>
    <Parent>
      <Id>1</Id>
      <Name>Parent event</Name>
    </Parent>
  </Activity>
</EventChain>

This structure can also be used to model multiple child events that have the same partent event. Where multiple events are related by some form of session (e.g. a session in a web application) and there is no concept of a parent event then the <Event><EventSource><SessionId> element should be used to group the events together.

An example of this can be seen in the search event here.

Schema Versions

It is anticipated that the schema will evole over time to accomodate new types of auditable event and to better describe existing events. Each version of the schema is marked with a unique version number using the version attribute in the <xs:schema> element. All events should be marked with the version of the schema that they are based upon using the Version attribute of the <Events> element. This allows systems processing the events to correctly interpret the structure.

Schema Versioning

The Event Logging Scheme uses the semantic versioning scheme. The version attribute value takes the form x.y.z where

• x = Major version
• y = Minor version
• z = Patch version

A change to the major version will include ‘breaking changes’ that are not backwards compatible with previous versions of the schema.

A change to the minor version will include new structural elements but will be non-breaking and backwards compatible with previous versions of the schame at that major version.

A change to the patch version means very minor non-breaking changes such as additions to enumerated types or annotation changes.

Ideally all new data should conform to the latest version of the schema to reduce the length of time legacy versions have to be supported for.

Managing Multiple Schema Versions

Systems receiving/processing data conforming to the Event Logging Schema should expect to receive data conforming to multiple historic versions of the schema as it takes time for client systems to update to the latest version.

To resolve the issue of having to process and store multiple versions of the schema, a schema uplift process can be used. This involves having a number of XSLT transformation steps to translate from each iteration of the schema to the next. For example if v1.2 of the schema has an element called <Detail> and this has been renamed ot <EventDetail> in v2.0 then the XSLT can rename the elements in the event data to bring the event record up to v2.0. The same uplift operation can be applied to historic events that have already been stored and have become out of date, or they can be uplifted on demand.

Taking this approach will reduce the number of different versions that have to be stored/processed.

4 - Schema Actions

Schema action elements are the element in <EventDetail> that describes the action specific detail of the auditable event, e.g. Import, Copy, Authenticate, etc.

System events could be modelled from various points of view, and although it makes little difference in many cases, it is certainly necessary that a decision is made and then applied consistently.

The schema is designed to express events in terms of the intent of a user wherever possible. Where there is no user, then the schema expresses events from the point of view of the device/generator creating the event.

For example, a log file from a web proxy may contain events that describe events from its point of view. Perhaps that it has not relayed a web page to an authenticated session ID due to a rule violation. In such a case, the correct way to represent the event is as a known user attempting to access a web page and being denied. Which in XML would be as a <View> with <Outcome> elements set appropriately.

Common Structural Elements

While each schema action has a structure that is specific to the auditable event action, there are a number of structural elements that are common to multiple schema actions.

Multi Object Complex Type

The Multi Object Complex Type is a structure for describing an entity or entities involved in the auditable event, for example a document, file, resource or user. The structure is described in more detail in Object Types.

The <Unknown> schema action structure should be the action of last resort, where the auditable action cannot be appropriately described by any of the other schema actions. Heavy use of this structure suggests that the scheme is deficient with respect to a type or types of event and suggestions for how the schema could be improved should be submitted to the developers.

Outcome

The majority of schema action structures include an <Outcome> element. This is used to described whether the action was successful/permitted or not, e.g. a failed logon or a user being denied access to a file.

<Success> is used to describe whether something failed or went wrong in some way, e.g. an export to removable media that failed due to lack of space. This element is used in cases of unexpected failure rather than where something has been prevented due to some rule or process, where <Permitted> would be more appropriate.

<Permitted> is used to describe whether an action was prevented due to some form of authorisation or rule, e.g. a user not being permitted access to a document due to having insufficient permissions.

In both cases a value of true is assumed so the element only needs to be included if the action was unsuccessful.

The <Description> element should be used to described the detail around the failure of the action as this will be useful to a human looking at the event.

Data

This provides a flexible structure for describing aspects of the schema action that cannot be described using the structure in the schema. This structure is described in more detail in Unstructured Data

The majority of the ‘schema action’ elements include the MultiObjectComplexType structure (or some child of it) to allow for recording various forms of objects that were involved in the event.

Defined Schema Actions

A number of schema actions are defined that aim to be broadly representative of the kinds of activity that are most likely to be of interest from an audit point of view.

Event Modelling

The schema does not aim to provide an exhaustive list of all possible computer operations.

This is because:

1. It would result in a schema that would be extremely large
2. It would result in a schema that would be constantly changing
3. It would result in a schema that would be very difficult to use

Instead, the schema should be used in such a way to describe the operation using the elements of the schema that most closely capture the nature of the kind of operation that was taking place from the user’s point of view, or where there is no user from the reporting device’s point of view.

Judgement is needed to find the best way to model a particular event.

For example, a delete operation could actually just mark a record within the database in such a way as to prevent it from being displayed and so is effectively (at least internally) an update. But from the user’s point of view it is a destructive operation - so it should be modelled as a delete.

It is important that events with similar effects are modelled similarly, in order that analytics can operate effectively. Examples that illustrate how the schema should be used are described here.

4.1 - Alert

This schema action should be used to describe events relating to alerts generated from such things as anti-virus/malware monitoring systems, intrusion detection stytems, infrastructure/network monitoring systems or other rule based alerting systems.

The enumerated <Type> of the alert must be provided to categorise the alert. The remainder of the elements are optional to allow for flexibility in describing the event action.

An example alert action for a disk usage monitoring system is as follows:

<EventDetail>
  <TypeId>err1234</TypeId>
  <Alert>
    <Type>Error</Type>
    <Description>/dev/sda1 is 100% full</Description>
  </Alert>
</EventDetail>

The following is an example of an alert from a network device performing packet filtering:

<EventDetail>
  <TypeId>4921</TypeId>
  <Description>A packet was rejected by filter xyz</Description>
  <Alert>
    <Type>Network</Type>
    <Network>
      <Source>
        <Device>
          <IPAddress>192.168.0.4</IPAddress>
        </Device>
      </Source>
      <Destination>
        <Device>
          <IPAddress>192.168.7.5</IPAddress>
        </Device>
      </Destination>
    </Network>
  </Alert>
</EventDetail>

4.2 - Approval

This schema action describes events that fit the following use cases:

• Acceptance - A user clicking accepting an acceptable use terms banner
• Approval Request - User A requesting that a more senior user approves something (e.g. approving a document or a timesheet)
• Approval - User B approving (or rejecting) the approval requested by user A for some thing or action (e.g. approving a document or timesheet)

Acceptance

An example of a user accepting a confirmation popup about the use of cookies.

<EventDetail>
  <TypeId>AcceptCookies</TypeId>
  <Description>User has accepted use of cookies</Description>
  <Approval>
    <Action>Accept</Action>
    <Subject>
      <Banner>
        <Type>AccepiableUseBanner</Type>
        <Description>Cookies enhance your online experience. Simply click 'Accept and continue to site' to agree to the use of all cookies, or change them in your settings. See our Cookie policy at http://some-domain/policies/cookies.html for more information.</Description>
      </Banner>
    </Subject>
    <User>
      <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    </User>
  </Approval>
</EventDetail>

Approval Request

An example of a user requesting approval from a more senior user (or another user with approval rights):

<EventDetail>
  <TypeId>RequestTimesheetApproval</TypeId>
  <Description>User has request the approval of their timesheet</Description>
  <Approval>
    <Action>Request Approval</Action>
    <Subject>
      <Document>
        <Title>jbloggs_20190125_timesheet</Title>
      </Document>
    </Subject>
    <Approvers>
      <Approver>
        <!-- the user with approval rights -->
        <Id>CN=John Smith (jsmith), OU=people, O=Some Org, C=GB</Id>
      <Approver>
    </Approvers>
  </Approval>
</EventDetail>

Approval

An example of a user approving a timesheet for another user:

<EventDetail>
  <TypeId>ApproveTimesheet</TypeId>
  <Description>User is approving the timesheet for jbloggs</Description>
  <Approval>
    <Action>Approve</Action>
    <Subject>
      <Document>
        <Title>jbloggs_20190125_timesheet</Title>
      </Document>
    </Subject>
    <Requestors>
      <Requestor>
        <!-- the user with approval rights -->
        <Id>CN=Joe Bloggs (jbloggs), OU=people, O=Some Org, C=GB</Id>
      <Requestor>
    </Requestors>
  </Approval>
</EventDetail>

Rejection

An example of a user rejecting a timesheet for another user:

<EventDetail>
  <TypeId>RejectTimesheet</TypeId>
  <Description>User is approving the timesheet for jbloggs</Description>
  <Approval>
    <Action>Reject</Action>
    <Subject>
      <Document>
        <Title>jbloggs_20190125_timesheet</Title>
      </Document>
    </Subject>
    <Requestors>
      <Requestor>
        <!-- the user with approval rights -->
        <Id>CN=Joe Bloggs (jbloggs), OU=people, O=Some Org, C=GB</Id>
      <Requestor>
    </Requestors>
    <Reason>Claimed too many hours</Reason>
  </Approval>
</EventDetail>

4.3 - Authenticate

This schema action describe authentication events such as operating system logon or logon to an application or website. It can also be used to describe the authentication that happens when a user passes through an access controlled door.

Operating System and Application Authentication

Operating systems and applications that require user authentication before they can be accessed should record the following actions:

• Logon – Logon to OS or application requiring authentication.
• Logoff – Logoff of OS or application.
• Lock – Lock/suspend an OS or application session.
• Unlock – Unlock/resume an OS or application session.

Details of the device in question shall be contained within the <EventSource> element. The above actions can be recorded in the <Authentication><Action> element, see the following example.

<EventDetail>
  <TypeId>InteractiveLogon</TypeId>
  <Description>A user has logged on.</Description>
  <Authentication>
    <Action>Logon</Action>
    <LogonType>Interactive</LogonType>
    <User>
      <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    </User>
  </Authentication>
</EventDetail>

There are multiple session types related to authentication events that describe local logon, remote logon etc. The logon type may be included in the <LogonType> element. Possible values for <LogonType> are defined in the AuthenticateLogonTypeSimpleType and are explained below:

• Interactive - A logon to a domain by a user.

• Network - A logon to a computer via a network, e.g. accessing a shared folder.

• Batch - A background scheduled task running as the user.

• Service - A background service running as a user.

• Unlock - A user un-locking a password protected screen lock or screen saver.

• NetworkCleartext - A network logon similar to Network except that the password is sent of the network in plain text.

• NewCredentials - When a program is run with RunAs and using /netonly any connections to other computers on the network will be as the RunAs user so will result in a NewCredentials logon to that computer.

• RemoteInteractive - A user logging on interactively to a computer over the network using Remote Desktop Protocol (RDP) or similar.

• CachedInteractive - When the user’s computer is disconnected from the network (and domain controller) a cache of their hashed credentials is used to authenticate them.

• CachedRemoteInteractive - When cached hashed credentials are used to logon to a computer over the network using RDP or similar.

• CachedUnlock - When cached hashed credentials are used to unlock a password protected screen lock or screen saver.

• Proxy - A proxy type logon.

• Other - When some other logon type is used. Use the <Data> element to provide more detail.

  <Data Name="OtherLogonType" Value="Whatever"/>
  

If an authentication action fails the optional <Outcome> element can be included in the description with a Success attribute set to false. The <Description> and <Reason> elements within <Outcome> may also be included to indicate why the action failed, see the following example.

<EventDetail>
  <TypeId>InteractiveLogon</TypeId>
  <Description>A user has logged on.</Description>
      <Authentication>
        <Action>Logon</Action>
        <LogonType>Interactive</LogonType>
        <User>
          <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
        </User>
        <Outcome>
          <Success>false</Success>
          <Description>Logon failure. Incorrect password.</Description>
          <Reason>IncorrectPassword</Reason>
        </Outcome>
      </Authentication>
    </EventDetail>

In addition to logon and logoff, there are additional authentication related events supported by the schema. These include the following:

• ChangePassword – An account password is changed.
• AccountLock – The action of locking an account, either by an administrator or as a result of multiple logon failures.
• AccountUnlock – The action of unlocking an account by an administrator.

Physical Access

This information is described as an authentication event using the schema, as shown in the following example.

<EventDetail>
  <TypeId>DoorEntry</TypeId>
  <Description>A person has entered the building.</Description>
  <Authentication>
    <Action>Logon</Action>
    <User>
      <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    </User>
  </Authentication>
</EventDetail>

4.4 - Authorise

This schema action describes the event actions relating to the management of group membership or permissions of entities such as documents or users.

Providing a user with access to a group is described as adding groups to a user as shown in the following example.

<EventDetail>
  <TypeId>AddGroup</TypeId>
  <Description>Assigning an LDAP group to a user.</Description>
  <Authorise>
    <User>
      <Id>CN=Some Person (sperson), OU=people, O=Some Org, C=GB</Id>
    </User>
    <Action>Modify</Action>
    <AddGroups>
      <Group>
        <Type>ACG</Type>
        <Id>ABC</Id>
      </Group>
    </AddGroups>
  </Authorise>
</EventDetail>

Removing access to a group is done in the same way but uses the <RemoveGroups> element.

This structure can also be used to model situations where a user is making an explicit request for access to a particular entity.

4.5 - Copy / Move

The <Copy> and <Move> elements are used to describe local copy and move operations. They both contain the same element structure and describe the source and destination for the copy/move event.

When an entity is being sent to a remote recipient then the <Send> and <Receive> actions should be used instead (see Send and Receive).

The following example shows a copy event that has failed due to a lack of necessary permissions.

<EventDetail>
  <TypeId>CopyDocument</TypeId>
  <Copy>
    <Source>
      <Document>
        <Title>Some document.</Title>
        <Path>/PathSrc/some document.txt</Path>
      </Document>
    </Source>
    <Destination>
      <Document>
        <Title>Some document.</Title>
        <Path>/PathDest/some document.txt</Path>
      </Document>
    </Destination>
    <Outcome>
      <Permitted>false</Permitted>
      <Description>User does not have write permissions to /PathDest</Description>
    </Outcome>
  </Copy>
</EventDetail>

As with all data related events, other types of data can be described for the copy or move events, e.g. files, configuration data and messages such as email.

4.6 - Create / View / Delete

Whenever data is created, viewed and deleted, an event can be described for audit purposes.

Although ‘Read’ is usually used to describe the act of viewing information it is also associated with invisible system operations where processes are reading data. For the purposes of logging auditable events it was thought that ‘View’ was a more appropriate term.

The <Create>, <View> and <Delete> events all have the same content model that describes the data in question. An example event generated when viewing a document is shown in the following example.

<EventDetail>
  <TypeId>ViewDocument</TypeId>
  <View>
    <Document>
      <Permissions>
        <Permission>
          <User>
            <Id>Some Author</Id>
          </User>
          <Allow>Author</Allow>
        </Permission>
      </Permissions>
      <Title>Some document.</Title>
      <Path>/Some path/some document.txt</Path>
    </Document>
  </View>
</EventDetail>

As with all data related events, other types of data can be described within this structure, e.g. files, folders, configuration data and web pages. Other objects can be described using the <Object> element with an appropriate <Type> to describe what they are.

Role/Permission Management

Roles, permissions, communities and access groups are all treated as types of group that a user or other system actor can belong to. Groups that are added and removed from a system are described in CRUD operations the same way as any other entity. The following example demonstrates removing an access control group.

<EventDetail>
  <TypeId>RemoveGroup</TypeId>
  <Description>Removing an LDAP group.</Description>
  <Delete>
    <Group>
      <Type>LDAP Group</Type>
      <Id>DEF</Id>
    </Group>
  </Delete>
</EventDetail>

User Management

Users that are added and removed from a system are described in CRUD operations the same way as any other entity. The following example demonstrates adding a user.

<EventDetail>
  <TypeId>AddUser</TypeId>
  <Description>Adding a User</Description>
  <Create>
    <User>
      <Id>CN=New User (nuser), OU=people, O=Some Org, C=GB</Id>
    </User>
  </Create>
</EventDetail>

4.7 - Import / Export

The <Import> and <Export> elements are used to describe import and export operations. They both contain the same element structure and describe the source and destination for the import/export event. This allows for the source and destination to be of different types, e.g. exporting a search result to a file.

Examples:

• Import
  • Data being imported into an application, such that the application now controls that data.
  • Data being imported onto a host (and thereby the host’s network) from removable media.
• Export
  • Data being exported from an application, e.g. exporting a record as a PDF document.
  • Data being exported onto removable media.

The following example shows an export event that has failed due to a lack of necessary permissions.

<EventDetail>
  <TypeId>ExportDocument</TypeId>
  <Export>
    <Source>
      <Document>
        <Id>23894728937</Id>
        <Title>My Big Document</Title>
        <Path>/path/in/document/management/system/MyBigDocument.odf</Path>
        <Pages>10</Pages>
      </Document>
    </Source>
    <Destination>
      <File>
        <Path>/file/system/path/MyBigDoc.pdf</Path>
      </File>
    </Destination>
    <Outcome>
      <Permitted>false</Permitted>
      <Description>User does not have write permissions to /file/system/path/</Description>
    </Outcome>
  </Export>
</EventDetail>

4.8 - Install / Uninstall

This action can be used for recording the installation or removal of software. Also, some systems are able to monitor for addition or removal of hardware/media. Where this is possible install/uninstall events can be used for this purpose.

The following example shows a typical event that could be recorded when hardware addition is detected. Note that the addition of hardware in this instance is not permitted due to restrictions applied to the device in question.

<EventDetail>
  <TypeId>InstallHardware</TypeId>
  <Install>
    <Hardware>
      <Type>USBMassStorage</Type>
      <Manufacturer>Some Manufacturer</Manufacturer>
      <Capacity>8589934592</Capacity>
    </Hardware>
    <Outcome>
      <Permitted>false</Permitted>
      <Description>No hardware is allowed to be added.</Description>
    </Outcome>
  </Install>
</EventDetail>

  Whenever read only or recordable media are inserted into a device this may be recorded for audit purposes. The media type may be described (e.g. DVD, CD) as well as whether or not the media is writeable. The capacity can also be specified in bytes, see the following example.

<EventDetail>
  <TypeId>InsertRemovableMedia</TypeId>
  <Install>
    <Media>
      <Type>CD</Type>
      <ReadWrite>true</ReadWrite>
      <Capacity>671088640</Capacity>
    </Media>
  </Install>
</EventDetail>

The following is an example of an event recording the installation of a piece of software:

<EventDetail>
  <TypeId>yumInstall</TypeId>
  <Install>
    <Software>
      <Name>vim</Name>
      <Version>7.4</Version>
    </Software>
  </Install>
</EventDetail>

4.9 - Network

Some network devices are able to record auditable events. Typically these events relate to network connections being made between devices and data being transferred between them.

There are several types of network device that may be capable of this. They include:

• Firewalls – Allow or block traffic between certain devices depending on configured rules. Details about what connections are blocked and allowed can be recorded.
• Message boundary filters – Allow or block transfer of messages between devices depending on configured rules. Types of messages could include emails, IM etc.

For each event, details about the source and destination device may be recorded. Where connections/transfers are blocked the rule name and associated message may also be recorded, see the following example.

<EventDetail>
  <TypeId>ABC123</TypeId>
  <Network>
    <Close>
      <Source>
        <Device>
          <IPAddress>192.168.1.2</IPAddress>
          <Port>56123</Port>
        </Device>
        <TransportProtocol>UDP</TransportProtocol>
      </Source>
      <Destination>
        <Device>
          <IPAddress>192.168.1.3</IPAddress>
          <Port>53</Port>
        </Device>
        <Application>Outlook</Application>
        <TransportProtocol>TCP</TransportProtocol>
        <ApplicationProtocol>IMAP</ApplicationProtocol>
        <Port>80</Port>
      </Destination>
    </Close>
  </Network>
</EventDetail>

The Send and Receive sub-elements should be used judiciously as there is some cross-over with the Send and Receive top level schema actions described below. Network/Send and Network/Receive should be limited to low level network events only and not higher level abstractions such as a data transfer service.

4.10 - Print

There are various events associated with printing due to the queued nature of print jobs. These events are generated by both operating systems and printers and have enumerated values for the <Action> element as follows:

• Operating System:
  • CreateJob – When a user chooses to print a document.
  • CancelJob – When a user chooses to cancel a print job in the print queue.
• Printer:
  • StartPrint – When the printer begins printing.
  • FinishPrint – When the printer finishes printing.
  • CancelPrint – When the printing is cancelled from the printer.

The description of the event shall be contained within the structure shown in the following example.

<EventDetail>
  <TypeId>PrintDocument</TypeId>
  <Print>
    <Action>CreateJob</Action>
    <PrintJob>
      <Document>
        <Title>Some document</Title>
      </Document>
      <Pages>40</Pages>
      <Size>644236</Size>
    </PrintJob>
    <PrintSettings>
      <PaperSize>A4</PaperSize>
      <Orientation>Portrait</Orientation>
      <Colour>true</Colour>
      <DeviceFonts>false</DeviceFonts>
    </PrintSettings>
    <Printer>
      <Id>printer796</Id>
      <Name>LaserJet4+</Name>
      <IPAddress>192.168.2.52</IPAddress>
      <Room>A34-2</Room>
    </Printer>
  </Print>
</EventDetail>

For all print actions the <PrintJob> element describes what is being printed. Details about the document related to the print job may be described within the <Document> element.

For print events the <Size> element contains the spooled size of the document being printed in bytes and not the original file size on disk.

The printer being used can be described using the <Printer> element when it is known which printer will be printing the document.

The IP address or host name of the printer will either be:

• The IP/host of the printer itself if it is a network printer.
• The IP/host of the computer that the printer is attached to if it is not a network printer.   If a print job fails the reason for failure can be included in the <Outcome> element, see the following example.

<EventDetail>
  <TypeId>PrintDocument</TypeId>
  <Print>
    <Action>StartPrint</Action>
    <PrintJob>
      <Document>
        <Title>Some document</Title>
      </Document>
      <Pages>40</Pages>
      <Size>644236</Size>
    </PrintJob>
    <PrintSettings>
      <PaperSize>A4</PaperSize>
      <Orientation>Portrait</Orientation>
      <Colour>true</Colour>
      <DeviceFonts>false</DeviceFonts>
    </PrintSettings>
    <Printer>
      <HostName>someprinter.someorg.org</HostName>
    </Printer>
    <Outcome>
      <Success>false</Success>
      <Description>The printer is out of paper.</Description>
    </Outcome>
  </Print>
</EventDetail>

4.11 - Process

Processes can be recorded for audit purposes such as:

• Operating system start-up/shutdown.
• Event logging system start-up/shutdown.
• Some services start-up/shutdown/install/uninstall.
• Some applications start-up/shutdown/install/uninstall.
• Scheduled jobs or batch processes such as shell scripts

Each of these events can be described using the <Process> element, see the following example.

<EventDetail>
  <TypeId>1234</TypeId>
  <Process>
    <Action>Startup</Action>
    <Type>Application</Type>
    <Command>MsWord.exe</Command>
  </Process>
</EventDetail>

The following is an example of recoding the input and output to a batch process.

<EventDetail>
  <TypeId>SplitData</TypeId>
  <Process>
    <Action>Execute</Action>
    <Type>Application</Type>
    <Command>script.sh</Command>
    <Input>
      <File>
        <Path>/sourcePath/sourceFile.txt</Path>
      </File>
    </Input>
    <Output>
      <File>
        <Path>/destPath/destFile.txt</Path>
      </File>
    </Output>
  </Process>
</EventDetail>

4.12 - Search

Performing a Search

Whenever a user performs a search the details of the search may be recorded for audit purposes. The types of searches that could be performed by a user include searching the file system, remote file shares, emails, public folders and searches for data within applications.

There are several formats of search query supported by the schema. They include:

• <Advanced> – The structure enables complex queries to be built that include combinatorial term logic.
• <Simple> – Records the terms that the search is looking for and the ones to explicitly exclude.
• <Raw> – Used for record the executed query string entered by a user or SQL applied to a database.

The ability to create a complex query may be limited by the application or device creating the event log. Where this is the case it may be necessary to use the simple or raw query format. Even if <Advanced> or <Simple> are used, the inclusion of the raw query string is desirable as it describes the search string that was actually executed.

An example search event with a raw query is shown:

<EventDetail>
  <TypeId>BasicSearch</TypeId>
  <Search>
    <Query>
      <Id>query-236</Id>
      <Raw>select * from table_x where user='jbloggs'</Raw>
    </Query>
  </Search>
</EventDetail>

The following example shows a search event with an advanced query where the query is (location != site1 AND (user==jBloggs OR user==jDoe)):

<EventDetail>
  <TypeId>BasicSearch</TypeId>
  <Search>
    <Query>
      <Id>364587</Id>
      <Advanced>
        <And>
          <Term>
            <Name>location</Name>
            <Condition>NotEquals</Condition>
            <Value>site1</Value>
          </Term>
          <Or>
            <Term>
              <Name>user</Name>
              <Condition>Equals</Condition>
              <Value>jBloggs</Value>
            </Term>
            <Term>
              <Name>user</Name>
              <Condition>Equals</Condition>
              <Value>jDoe</Value>
            </Term>
          </Or>
        </And>
      </Advanced>
      <Raw>select * from table_x where user in ('jbloggs', 'jbloggs') and location <> 'site1'</Raw>
    </Query>
  </Search>
</EventDetail>

Synchronous vs Asynchronous Searches

Some search events may be synchronous, where the results are know as part of the search action. For synchronous searches, details of the results can be included within the <Search> element. Some searches however are asynchronous, where the results are not know at the time the search is executed. For these asynchronous searches, the execution of the search should use the <Search> schema action and the retreival of the results would be modelled as separate <View>/<SearchResults> event. To link the <Search> event with the <some schema action>/<SearchResults> event the <Query>/<Id> or <Query>/<Name>element can be used, as shown in the following example.

<!-- Search event -->
<EventDetail>
  <TypeId>AsynchronousUserQuery</TypeId>
  <Search>
    <Query>
      <!-- ID to link the query execution with the subsequent viewing of the results -->
      <Id>3648595</Id>
      <Raw>select cv_blob from candidates where user='jbloggs'</Raw>
    </Query>
  </Search>
</EventDetail>

<!-- View results event -->
<EventDetail>
  <TypeId>ViewUserQueryResults</TypeId>
  <View>
    <SearchResults>
      <Query>
      <!-- ID to link the query execution with the subsequent viewing of the results -->
      <Id>3648595</Id>
      <!-- If the query detail was recorded in the initial Search event then it could be omitted here -->
      </Query>
      <TotalResults>1</TotalResults>
      <Results>
        <Document>
          <Title>J Bloggs CV</Title>
          <Path>/tmp/jbloggs_cv.pdf</Path>
        </Document>
      </Results>
    <SearchResults>
  </View>
</EventDetail>

Search Results

The schema allows for results that are returned from a search to be recorded.

The total number of results can be recorded along with a list of the displayed results. Where results are paged (e.g. in a web search) details of the currently displayed page can also be described.

The list of results can describe the type of result and provide appropriate details, see the following example.

<Search>
  ...
  <ResultPage>
    <TotalPages>10</TotalPages>
    <PerPage>10</PerPage>
    <PageNumber>2</PageNumber>
    <From>11</From>
    <To>20</To>
  </ResultPage>
  <TotalResults>100</TotalResults>
  <Results>
    <Document>
      <Title>Some Document 1</Title>
      <Path>file://Some_Path/Some%20Document.doc</Path>
    </Document>
    <WebPage>
      <URL>http://Some_Path/Some%20HTML%20Page.htm</URL>
    </WebPage>
  </Results>
</Search>

See Complete Examples for example events.

4.13 - Send / Receive

Events relating to the sending or receiving of some form of payload can be recorded with the <Send> and <Receive> elements. These events are at a higher level of abstraction than the low level <Network>/<Send> and <Network>/<Receive> elements, e.g. sending a file using some form of data transfer service.

<EventDetail>
  <TypeId>SendFile</TypeId>
  <Send>
    <Source>
      <User>
        <Id>CN=Some Person (sperson), OU=people, O=Some Org,C=GB</Id>
      </User>
    </Source>
    <Destination>
      <User>
        <Id>CN=Person2 (person2), OU=people, O=Some Org, C=GB</Id>
      </User>
      <Device>
        <HostName>otherbox.someorg.org</HostName>
      </Device>
    </Destination>
    <Payload>
      <File>
        <Name>meetingMinutes.odf</Name>
      </File>
    </Payload>
    <Outcome>
      <Success>true</Success>
    </Outcome>
  </Send>
</EventDetail>

4.14 - Unknown

This schema action structure is the action of last resort when the event cannot be accurately described with any of the other schema actions.

The structure is simply the extensible data structure allowing for most types of data to be recorded.

4.15 - Update

The <Update> event is different to the previous <Create>, <View> and <Delete> events because it is often desirable to know the before and after state of the data in question if this can be provided. Another reason for providing the before and after states of an object is that it allows for changes to individual properties to be described without the need to include all attributes of the object in question on every update.   An example showing updating configuration properties is shown in the following example.

<EventDetail>
  <TypeId>UpdateConfiguration</TypeId>
  <Update>
    <Before>
      <Object>
        <Type>Configuration</Type>
        <Data Name="FileAccess" Value="none"/>
      </Object>
    </Before>
    <After>
      <Object>
        <Type>Configuration</Type>
        <Data Name="FileAccess" Value="all"/>
      </Object>
    </After>
  </Update>
</EventDetail>

5 - Object Types

When describing what happened in an event there is usually an entity or entities involved in the event, e.g. a user deleting a document, sending an email, creating a virtual session, etc. The majority of the schema actions support acting on one or more instances of the MultiObjectComplexType, this structure describes a choice of the following entity types:

Where the entity involved in the event cannot be described by one of the predefined categories in this structure then the <Object> structure can be used as a last resort.

Common Structural Elements

The following elements are common to all of the above object types;

• Type - The type of the object in question and specific to the object type from the list above, e.g. a <Resource> object may have a type such as ‘image’ or ‘script’
• Id - An identifier for the object, e.g a document ID in a document management system
• Name - The name of the object, e.g. a filename
• Description - Human readable description of what the object is
• Classification - Any classification or restrictions placed on the object, e.g. for commercially sensitive reports or user health records (see Basic Structure)
• State - Any state information about the object, e.g. ‘Archived’
• Groups - Any groups associated with the object, e.g. group membership of a user account
• Permissions - Any permissions associated with the object, e.g. write access being granted to a list of named users or groups
• Data - An extensible structure for additional unstructured data as described in Unstructured Data
• Meta - An extensible structure for structured meta data as described in Meta Element

5.1 - Resource

This is used to describe a resource within a web site or web application, such as an HTML file, image file or script, along with the details of that resource such as size or response codes. It can represent both successful and failed access to the resource object.

5.2 - Search Results

This element is used to describe a set of search results that have a life beyond the execution of the query that generated them. For example where the execution of the query forms one event and the viewing of the results happens some time later and forms another event.

This element can be used to describe a single result within a result set, a page of results from a larger result set or a full result set.

The separate event for the execution of the search/query that produced the results should be modelled using the <Search> schema action.

See Complete Examples for example events.

5.3 - Shortcut

This should be used to describe any form of shortcut or symbolic link to another object.

5.4 - User

This is used to describe a user entity in a system. This could be the user account in a web application, the identity of a person in an access control system, a user profile in a chat application or a user account on a piece of configurable hardware.

The full details of the user can also be recorded, such as the position within the organisation, if known.

It is important to consider that the user account is not necessarily under the control of the person to whom the account has been assigned.

5.5 - Virtual Session

This object type is used to describe the session used when viewing another user’s session, e.g. screen sharing or remote assistance type activities.

5.6 - VOIP

This is used to record a voice over IP call between parties. The <PhoneNumber> element represents the phone number of the calling party.

5.7 - Association

This can be used to describe any form of association between other objects. For example in a social networking type application links are made between user accounts. This <Association> object would allow the creation/modification/deletion of one of these links to be recorded.

5.8 - Banner

This is typically used within a <View> schema action and is intended to record the details of a banner, pop-up or warning message that is displayed to a user, along with the version and contents of that message.

Its objective is to record that the user has seen a message alerting them to the terms of use for a particular system.

5.9 - Chat

This is used to describe a single message in an instant messaging application. The <SessionId> element can be populated to allow multiple events for the same chat session to be associated at a later date. This is used for direct user to user chat as opposed to <GroupChat> which is used for chatting to a group of users via a chat room.

A chat message is typically modelled within a <Create> schema action.

5.10 - Configuration

This describes any form of configuration for a system or piece of hardware, e.g. describing some or all of the configuration of a firewall. Due to the very varied nature of software/hardware configuration there is no additional predefined structure beyond the base object structure.

5.11 - Criteria

This is used to describe the criteria applied in any kind of search or filter operation along with the returned results, if known. The <Query> element is used to record the actual query terms used, either in its raw form (e.g. SQL or XPath), as a nested hierarchy of operators and expressions or as a set of simple <Include> or <exclude> elements.

For example, this may be used to describe the criteria for a query that has been stored for re-use, e.g. an <Update>/<Criteria> event where a user is making changes to a stored query but not actually executing the query.

See Complete Examples for example events.

5.12 - Document

This is used to describe any form of digital document, such as a Word document, PDF or a simple text file, along with its location and most recent created/modified/accessed times.

The <Permissions> element that is part of the base object structure can be used to define all the user/group permissions in place on the document in the case of a document management system or similar.

5.13 - Email

This object type is used to describe an email that has either been sent, received or saved in some way. It can record all parties involved in the email.

5.14 - File

This is used to describe any kind of file on a file system or file repository, e.g. a data file, log file, backup file, etc. The <Media> element can be used to describe the type of media it is stored on. The hash of the file can also be recorded using <Hash> so the actual version of the file interacted with is known. If a hash is supplied then the name of the hashing algorithm should also be supplied in the Type attribute.

The object type <Document> may be more appropriate unless the file is being referred to in its generic capacity as a file.

5.15 - Folder

This is very similar to the <File> object type except that it is used to record a folder on a file system or file repository.

5.16 - Group

This used to define a group entity, e.g. a group of users. The Group itself may have other groups within it.

5.17 - Group Chat

This is similar to the <Chat> object with the difference that it is for recording a group chat message either from a user to a chat room or from a room to a user.

5.18 - Object

This is the object type of last resort when the object involved in the event cannot be described using any of the other types. Due to the unknown nature of the object, the <Data> element structure is provided in addition to the base object structure.

6 - Unstructured Data

In some cases there may not be an adequate data structure for capturing the content of a field. In these cases data can be captured using the <Data> element content model, see the following example.

<EventDetail>
  <Data Name="infoKey" Value="Info"/>
  <Data Name="otherInfoKey" Value="OtherInfo"/>
</EventDetail>

<Data> elements can be nested to indicate hierarchy if necessary and can be included within many of the predefined data structures, for example.

<EventDetail>
  <Data Name="user" Value="Flack">
    <Data Name="role" Value="manager"/>
    <Data Name="staff">
      <Data Name="user" Value="Cuthbert">
        <Data Name="role" Value="underling"/>
        <Data Name="staff"/>
      </Data>
      <Data Name="user" Value="Dibble">
        <Data Name="role" Value="underling"/>
        <Data Name="staff"/>
      </Data>
      <Data Name="user" Value="Grub">
        <Data Name="role" Value="underling"/>
        <Data Name="staff"/>
      </Data>
    </Data>
  </Data>
</EventDetail>

Extensive use of the unstructured Data elements can lead to difficulties in processing events unless the name and value attributes have been used in a consistent way. Their use may highlight the need for changes to the schema so that the data can be captured in a common and consistent way. They can however by useful for capturing detailed domain/system specific information about an event that you would not expect to search on but that could provided extra detail if the event is included in search results.

7 - Data Types

Date and Time Fields

All date and time fields (e.g. Event time, see section 3.1) must be supplied in ISO-8601 format in the UTC time zone with millisecond precision, e.g. 2008-11-18T09:47:12.261Z. This ensures all events are in the same time zone and can be correctly ordered irrespective of the local time. The time source should be synchronised with a reliable NTP server.

Date time fields must be zero filled where data does not provide millisecond precision, e.g. 2008-11-18T00:00:00.000Z.

The ISO-8601 date time format is yyyy-MM-ddThh:mm:ss.sssZ where:

IP Addresses

IP Addresses can be provided in IPv4 or IPv6 forms.

• IPv4 - Must be specified as four sets of digits separated by full stops (e.g. 255.255.255.0 and 147.80.1.1).
• IPv6 - Must be specified as eight sets of hexadecimal digits separated by commas (e.g. 2001:cdba:0000:0000:0000:0000:3257:9652. Though it is permitted for IPv6 addresses to be surrounded by square brackets when used in a URL, these brackets must be omitted when an IPv6 address is used in isolation.

The acceptable range for each number is 0 – 255.

Port Numbers

All port numbers specified must fall within the range 0 – 65535 inclusive.

Users

Data provided within <User><Id> elements is expected to be a PKI DN.

8 - Meta Element

The <Meta> element appears in a number of places in the schema. The purpose of the <Meta> element is to allow for extensibility of events with meta data whose structure is defined outside of this schema. Such content could be site specific and thus not warrant inclusion in the event-logging schema. It may also be used for decorating events post-receipt.

The <Meta> element is of type evt:AnyContentComplexType which is basically a wrapper around an xs:any element so it can support different data structures such as JSON, YAML, XML (conforming to another schema), CSV, etc.

A <Meta> element can look like this:

<Meta ContentType="XML:MyMeta" Version="1.2">
  <MyMeta xmlns="http://myorg.mydomain.mymeta">
    <ElementA></ElementA>
    <ElementB></ElementB>
  </MyMeta>
</Meta>

The ContentType attribute is used to provide a computer readable name or key for the type of data held within <Meta>. This will allow to the system reading the event to be able to appropriately parse the content, if it is able to. The value of the attribute would be specific to the use of that type of meta data.

The Version attribute is used to optional specify the version of the structure used inside the <Meta> element. Some data formats are self describing when it comes to their version so this attribute may not be required.

Multiple <Meta> elements are supported allowing for various different types of meta data to be attached to the event.

9 - Complete Examples

In some places the <UserDetails> element has been abbreviated for clarity using an ellipsis (…). Typically the system generating the event will not know anything about a user beyond some identifier so a common practice is to decorate the event with a fully populated <UserDetails> element in the system processing the events. This approach means only one system needs to be able to resolve a user identifier into a rich set of data.

In a real-world situation, a design decision would be needed - when to leave the event more concise using only an ID and when to join with additional information. Data such as user details change slowly, but they do change, e.g. as people get promoted, change role, etc. Therefore, such a joining process would utilise the values for these additional data fields that were correct at the time the event was generated. Certain tools such as Stroom support this, and are sufficiently flexible to allow this enrichment process to take place during initial normalisation prior to storage, during analysis or at query time / inspection.

The same principle applies to Device details, etc.

Compression such as ZIP can very significantly reduce the overhead associated with highly repetitive data, and are able to allow fully enriched data to be persisted with only minimal overhead.

Event Logging schema does not suggest any level of detail, and so to be more illustrative these examples vary in the level of detail provided, e.g. within <UserDetails>.

Organisations may wish to standardise, to maximise consistency and simplify analytic development. However, in most real-world situations, the level of detail is likely to vary due to gaps in the data available to the organisation. For example, an event that describes the sending of an email from a company employee to an external email address may be expected to provide significantly more detail about the sender than the recipient within <UserDetails>.

Example files

The following are links to annotated example <Events> XML documents that are valid against the Event Logging Schema.

• Schema Actions (within <EventDetail>)
  • <Alert>
    • <Alert>/<Network> XML
  • <Import>
    • <Import>/<File> XML
    • <Import>/<Object> XML
  • <Network>
    • <Network>/<Close> XML
  • <Print>
    • <Print> XML
  • <Search>
    • <Search> XML
  • <Send>
    • <Send>/<Document> XML
    • <Send>/<File> XML
• Object Types
  • <SearchResults> XML
  • <Criteria> XML
• Other
  • <Event>/<Meta>
    • <Event>/<Meta> (JSON) XML
    • <Event>/<Meta> (XML) XML

9.1 - XML

9.1.1 - Meta (JSON)

<Event>/<Meta> (JSON)

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <!-- JSON Meta example -->
  <Event>
    <Meta ContentType="JSON:streamMeta" Version="1.2.3">
      {  
        "streamMeta":{  
          "streamId":"12345",
          "eventId":"45678"
        }
      }
    </Meta>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>
    <EventSource>
      <System>
        <Name>SPACEPRINT</Name>
        <Environment>Luna1</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>ZeroGPrinter</Generator>
      <Device>
        <HostName>prn01.luna1.lan.myorg.com</HostName>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>
    <EventDetail>
      <TypeId>BWPrint</TypeId>
      <Description>System has finished printing</Description>
      <Print>
        <Action>FinishPrint</Action>
        <PrintJob>
          <Document>
            <Title>Resume - J Coder</Title>
          </Document>
          <Pages>2</Pages>
          <Size>3410212</Size>
          <Submitted>2017-01-02T03:03:51.234Z</Submitted>
        </PrintJob>
        <Outcome>
          <Success>true</Success>
        </Outcome>
      </Print>
    </EventDetail>
  </Event>

</Events>

9.1.2 - Meta (XML)

<Event>/<Meta> (XML)

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <!-- XML Meta example -->
  <Event>
    <Meta ContentType="XML:MyMeta" Version="1.2">
      <MyMeta xmlns="http://myorg.mydomain.mymeta">
        <ElementA>value A</ElementA>
        <ElementB>value B</ElementB>
      </MyMeta>
    </Meta>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>
    <EventSource>
      <System>
        <Name>SPACEPRINT</Name>
        <Environment>Luna1</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>ZeroGPrinter</Generator>
      <Device>
        <HostName>prn01.luna1.lan.myorg.com</HostName>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>
    <EventDetail>
      <TypeId>BWPrint</TypeId>
      <Description>System has finished printing</Description>
      <Print>
        <Action>FinishPrint</Action>
        <PrintJob>
          <Document>
            <Title>Resume - J Coder</Title>
          </Document>
          <Pages>2</Pages>
          <Size>3410212</Size>
          <Submitted>2017-01-02T03:03:51.234Z</Submitted>
        </PrintJob>
        <Outcome>
          <Success>true</Success>
        </Outcome>
      </Print>
    </EventDetail>
  </Event>

</Events>

9.1.3 - Object Types

9.1.3.1 - Criteria

User is viewing a Criteria ojbect that represents the definition of a search/query that can be executed.

A View event is used here simply to illustrate the use of Criteria. Criteria can be used within other schema actions.

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <!-- View/Criteria event -->

  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>Rock Sample Database</Name>
        <Environment>Space</Environment>
        <Organisation>ACMECoolResearch</Organisation>
        <Version>R8.1</Version>
      </System>
      <Generator>db-query</Generator>
      <Device>
        <HostName>db56.serverfarm.mydomain.org</HostName>
        <IPAddress>191.181.171.161</IPAddress>
      </Device>
      <Client>
        <HostName>desktop4.moonbase-a.mydomain.org</HostName>
        <IPAddress>111.101.101.111</IPAddress>
      </Client>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>

    <EventDetail>
      <TypeId>viewSearchResults</TypeId>
      <Description>User is viewing a set of stored search results</Description>
      <View>
        <Criteria>
          <DataSources>
            <DataSource>geology-db</DataSource>
          </DataSources>
          <Query>
            <!-- 
            Provides a link back to the Search event generated when 
            the query was executed 
            -->
            <Id>query-538393</Id>
            <!-- Tree of terms and operators to describe the query -->
            <Advanced>
              <And>
                <Term>
                  <Name>size</Name>
                  <Condition>Equals</Condition>
                  <Value>large</Value>
                </Term>
                <Term>
                  <Name>colour</Name>
                  <Condition>Equals</Condition>
                  <Value>white</Value>
                </Term>
                <Term>
                  <Name>type</Name>
                  <Condition>Equals</Condition>
                  <Value>r</Value>
                </Term>
              </And>
            </Advanced>
          </Query>
        </Criteria>
      </View>
    </EventDetail>

  </Event>

</Events>

9.1.3.2 - Search Results

user is viewing a set of search results independently of the search event that generated them. the query/id element can be used to link the two events together.

this object type can be used when the results of the query are not know at the time the search is executed and the search event is created.

a view event is used here simply to illustrate the use of searchresults. searchresults can be used within other schema actions.

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <!-- View/SearchResults event -->

  <Event>

    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <!-- The source system specific unique ID for this event -->
      <EventId>1024</EventId>
      <System>
        <Name>Rock Sample Database</Name>
        <Environment>Space</Environment>
        <Organisation>ACMECoolResearch</Organisation>
        <Version>R8.1</Version>
      </System>
      <Generator>db-query</Generator>
      <Device>
        <HostName>db56.serverfarm.mydomain.org</HostName>
        <IPAddress>191.181.171.161</IPAddress>
      </Device>
      <Client>
        <HostName>desktop4.moonbase-a.mydomain.org</HostName>
        <IPAddress>111.101.101.111</IPAddress>
      </Client>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>

    <EventDetail>
      <TypeId>viewSearchResults</TypeId>
      <Description>User is viewing a set of stored search results</Description>
      <View>
        <SearchResults>
          <Query>
            <!-- 
            Provides a link back to the Search event generated when the 
            query was executed. The link can also be acheived using EventLinks below.
            -->
            <Id>query-538393</Id>
          </Query>
          <TotalResults>2</TotalResults>
          <Results>
            <Object>
              <Type>Rock</Type>
              <Id>78121</Id>
              <Name>Surpisingly Heavy Chunk</Name>
            </Object>
            <Object>
              <Type>Rock</Type>
              <Id>11418</Id>
              <Name>Possible Gold Ore</Name>
            </Object>
          </Results>
        </SearchResults>
      </View>
    </EventDetail>

    <!-- This event is linked back to its parent (the initial search) -->
    <EventChain>
      <Activity>
        <!-- Links this event to the one with EventSource/EventId[text()='1023'] -->
        <Id>92832938</Id>
        <Name>Search execution</Name>
      </Activity>
    </EventChain>

  </Event>

</Events>

9.1.4 - Schema Actions

9.1.4.1 - Import (Object)

<EventDetail>/<Import>//<Object>

The following example illustrates user jc101 importing some data into an application called Geology Image Database. The application is based on geoimg v4.1 and is running on the server geodb.servers.mycloud.myorg.

The Object is of Type Image Archive and has an id 14131A. It has a Classification of Geology.

There is no Success element in <Outcome>, so it is assumed that the action completed successfully.

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd" 
  Version="999.99.9">

  <!-- Import Object event -->
  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>Geology Image Database</Name>
        <Environment>Live</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>geoimg v4.1</Generator>
      <Device>
        <HostName>geodb.servers.mycloud.myorg</HostName>
        <IPAddress>104.105.106.107</IPAddress>
        <MACAddress>AB:CB:BC:DE:EE:FF</MACAddress>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
    </EventSource>

    <EventDetail>
      <TypeId>IMAGE-IMPORT-ARCHIVE</TypeId>
      <Description>User has imported an image archive</Description>
      <Import>
        <Destination>
          <Object>
            <Type>Image Archive</Type>
            <Id>14131A</Id>
            <Description>Crater images</Description>
            <Classification>
              <Text>Geology</Text>
            </Classification>
          </Object>
        </Destination>
        <Outcome>
          <Description>Image archive successfully imported</Description>
        </Outcome>
      </Import>
    </EventDetail>

  </Event>

</Events>

9.1.4.2 - Network (Close)

<EventDetail>/<Network>/<Close>

This example illustrates the closing of a network connection between two devices.

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd" 
  Version="999.99.9">

  <!-- Netowrk Close event -->
  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>Geology Image Database</Name>
        <Environment>Live</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>geoimg v4.1</Generator>
      <Device>
        <HostName>geodb.servers.mycloud.myorg</HostName>
        <IPAddress>104.105.106.107</IPAddress>
        <MACAddress>AB:CB:BC:DE:EE:FF</MACAddress>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
    </EventSource>

    <EventDetail>
      <TypeId>ABC123</TypeId>
      <Network>
        <Close>
          <Source>
            <Device>
              <IPAddress>192.168.1.2</IPAddress>
              <Port>56123</Port>
            </Device>
            <TransportProtocol>UDP</TransportProtocol>
          </Source>
          <Destination>
            <Device>
              <IPAddress>192.168.1.3</IPAddress>
              <Port>53</Port>
            </Device>
            <Application>Outlook</Application>
            <TransportProtocol>TCP</TransportProtocol>
            <ApplicationProtocol>IMAP</ApplicationProtocol>
            <Port>80</Port>
          </Destination>
        </Close>
      </Network>
    </EventDetail>

  </Event>

</Events>

9.1.4.3 - Print

<EventDetail>/<Print>

The following example illustrates a document with the title Resume - J Coder being printed on prn01.luna1.lan.myorg.com by user jc101.

The document is 2 pages in length and 3410212 bytes in length.

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd" 
  Version="999.99.9">

  <!-- Print event 

    The following example illustrates a document with the title Resume - J Coder 
    being printed on prn01.luna1.lan.myorg.com by user jc101.

    The document is 2 pages in length and 3410212 bytes in length.
  -->
  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>
    <EventSource>
      <System>
        <Name>SPACEPRINT</Name>
        <Environment>Luna1</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>ZeroGPrinter</Generator>
      <Device>
        <HostName>prn01.luna1.lan.myorg.com</HostName>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>
    <EventDetail>
      <TypeId>BWPrint</TypeId>
      <Description>System has finished printing</Description>
      <Print>
        <Action>FinishPrint</Action>
        <PrintJob>
          <Document>
            <Title>Resume - J Coder</Title>
          </Document>
          <Pages>2</Pages>
          <Size>3410212</Size>
          <Submitted>2017-01-02T03:03:51.234Z</Submitted>
        </PrintJob>
        <Outcome>
          <Success>true</Success>
        </Outcome>
      </Print>
    </EventDetail>
  </Event>

</Events>

9.1.4.4 - Search

<EventDetail>/<Search>

The following example illustrates a query against a database application. The action is that user jc101 execute a query select r.* from ROCK r where r.TYPE = 'r' and r.SIZE = 'large' and r.COLOUR = 'white' which returned 2 results. The Interactive field is set to false, so it may be inferred that this was an automated operation of some kind.

The results were two Objects. Both were of type Rock. The first with an id of 7811 and a name of Surpisingly Heavy Chunk and the second with an id of 11418 and a name of Possible Gold Ore.

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <!-- Search event -->
  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <!-- 
      An identifier for the user's session (e.g. a JSessionId) which can be used to group
      events that are part of the same session 
      -->
      <SessionId>5EFDA7655A8D72E7D04AC2E88E754956</SessionId>
      <System>
        <Name>Rock Sample Database</Name>
        <Environment>Space</Environment>
        <Organisation>ACMECoolResearch</Organisation>
        <Version>R8.1</Version>
      </System>
      <Generator>db-query</Generator>
      <Device>
        <HostName>db56.serverfarm.mydomain.org</HostName>
        <IPAddress>191.181.171.161</IPAddress>
      </Device>
      <Client>
        <HostName>desktop4.moonbase-a.mydomain.org</HostName>
        <IPAddress>111.101.101.111</IPAddress>
      </Client>
      <User>
        <Id>jc101</Id>
      </User>
      <Interactive>true</Interactive>
    </EventSource>

    <EventDetail>
      <TypeId>findByConstraint</TypeId>
      <Description>User has queried database using specified constraints</Description>
      <Search>
        <Query>
          <Id>query-538393</Id>
          <Description>Large, white, type 'r'</Description>
          <Raw>select r.* from ROCK r where r.TYPE = 'r' and r.SIZE = 'large' and r.COLOUR = 'white'</Raw>
        </Query>
        <TotalResults>2</TotalResults>
        <Results>
          <Object>
            <Type>Rock</Type>
            <Id>78121</Id>
            <Name>Surpisingly Heavy Chunk</Name>
          </Object>
          <Object>
            <Type>Rock</Type>
            <Id>11418</Id>
            <Name>Possible Gold Ore</Name>
          </Object>
        </Results>
      </Search>
    </EventDetail>
  </Event>

</Events>

9.1.4.5 - Send (Document)

<EventDetail>/<Send>//<Document>

The following example illustrates an application being used to transfer a file to from one user to another user.

The action is that the file samples1.zip of size 14127312 bytes was sent by the user jc101 to the user C=GB, O=WeDoRocksCo, OU=Space, CN=Tom Thumb(UID=tthumb01).

The file was transferred successfully.

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>FileSharer21</Name>
        <Description>Interactive File Sharing</Description>
        <Environment>Operational</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>fs-21-v2.2</Generator>
      <Device>
        <HostName>fs04.fs.myorg.com</HostName>
        <IPAddress>131.141.151.161</IPAddress>
        <MACAddress>A1:B1:C1:D1:E1:F1</MACAddress>
      </Device>
      <Client>
        <IPAddress>121.121.121.121</IPAddress>
      </Client>
      <User>
        <Id>jc101</Id>
        <UserDetails>
          <!-- Fully populated here to illustrate a decorated event-->
          <Id>jc101</Id>
          <StaffNumber>101</StaffNumber>
          <Surname>Coder</Surname>
          <Initials>JD</Initials>
          <Title>Mr</Title>
          <KnownAs>Jolly</KnownAs>
          <PersonType>Employee</PersonType>
          <Group>Technology</Group>
          <Unit>Geology</Unit>
          <Position>T.SD/42</Position>
          <Role>Geologist</Role>
          <GradeOfPost>E.5</GradeOfPost>
          <EmploymentType>Employee</EmploymentType>
          <EmploymentStatus>Active</EmploymentStatus>
          <Nationality>GB</Nationality>
          <Location>Moon Base Alpha</Location>
          <RoomNumber>4/31</RoomNumber>
          <Phone>11223</Phone>
          <SupervisorStaffNumber>421</SupervisorStaffNumber>
          <Organisation>ACMECoolResearch</Organisation>
          <HostOrganisation>MoonCo</HostOrganisation>
        </UserDetails>
      </User>
    </EventSource>

    <EventDetail>
      <TypeId>NormalSend</TypeId>
      <Description>A user sends a file to another user</Description>
      <Purpose>
        <Justification>Rock sample spectrum for analysis</Justification>
      </Purpose>
      <Send>
        <Source>
          <User>
            <Id>jc101</Id>
            <!-- User belongs to the organisation generating the event
            so only an Id is required -->
          </User>
        </Source>
        <Destination>
          <User>
            <Id>C=GB, O=WeDoRocksCo, OU=Space, CN=Tom Thumb (UID=tthumb01)</Id>
            <!-- User is external to the organisation generating the event so 
            a rich UserDetails element is required-->
            <UserDetails>
              <Id>tthumb011</Id>
              <Surname>Thumb</Surname>
              <Initials>T</Initials>
              <Group>Space</Group>
              <Nationality>GB</Nationality>
              <Organisation>WeDoRocksCo</Organisation>
            </UserDetails>
          </User>
        </Destination>
        <Payload>
          <Document>
            <Name>samples1.zip</Name>
            <Size>14127312</Size>
          </Document>
        </Payload>
        <Outcome>
          <Success>true</Success>
          <Description>Transfer Succeeded</Description>
        </Outcome>
      </Send>
    </EventDetail>

  </Event>
</Events>

9.1.4.6 - Send (File)

<EventDetail>/<Send>//<File>

The following example illustrates an application transferring a file to a remote server.

This reflects an automated service, so attribution of the sender and receiver is to a host, not a user.

The action is that the file /appdata/alldata/gooddata/bestdata.xml of type text/xml is being sent from myhost.mydomain.org to yourhost.yourdomain.com. This file is 12345321 bytes in size and has a digest/checksum/hash of efd1dffd90296a69a8aecd7ecb1832b7. N.B. The type of digest used is application specific and not specified in this event.

The Outcome of the event is not defined, so we assume that the transfer was successful.

<?xml version="1.0" encoding="UTF-8"?>
<Events
  xmlns="event-logging:3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd"
  Version="999.99.9">

  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>File Distribution</Name>
        <Environment>Live</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>File Distributor 1.5</Generator>
      <Device>
        <IPAddress>123.12.3.123</IPAddress>
      </Device>
    </EventSource>

    <EventDetail>
      <TypeId>File Transfer</TypeId>
      <Send>
        <Source>
          <Device>
            <HostName>myhost.mydomain.org</HostName>
          </Device>
        </Source>
        <Destination>
          <Device>
            <HostName>yourhost.yourdomain.com</HostName>
          </Device>
        </Destination>
        <Payload>
          <File>
            <Type>text/xml</Type>
            <Path>/appdata/alldata/gooddata/bestdata.xml</Path>
            <Size>12345321</Size>
            <Hash Type="MD5">efd1dffd90296a69a8aecd7ecb1832b7</Hash>
          </File>
        </Payload>
      </Send>
    </EventDetail>

  </Event>

</Events>

9.1.4.7 - Alert (Network)

<EventDetail>/<Alert>/<Network>

This example illustrates an alert being fired by from a network device performing packet filtering:

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd" 
  Version="999.99.9">

  <!-- Alert Network event -->
  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>Geology Image Database</Name>
        <Environment>Live</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>geoimg v4.1</Generator>
      <Device>
        <HostName>geodb.servers.mycloud.myorg</HostName>
        <IPAddress>104.105.106.107</IPAddress>
        <MACAddress>AB:CB:BC:DE:EE:FF</MACAddress>
      </Device>
      <User>
        <Id>jc101</Id>
      </User>
    </EventSource>

    <EventDetail>
      <TypeId>4921</TypeId>
      <Description>A packet was rejected by filter xyz</Description>
      <Alert>
        <Type>Network</Type>
        <Severity>Minor</Severity>
        <Priority>High</Priority>
        <Subject>Filter XYZ</Subject>
        <Network>
          <Source>
            <Device>
              <IPAddress>192.168.0.4</IPAddress>
              <Port>56123</Port>
            </Device>
          </Source>
          <Destination>
            <Device>
              <IPAddress>192.168.7.5</IPAddress>
              <Port>53</Port>
            </Device>
          </Destination>
        </Network>
      </Alert>
    </EventDetail>

  </Event>

</Events>

9.1.4.8 - Import (File)

<EventDetail>/<Import>//<File>

The following example illustrates how removable media use could be represented within the events-logging schema.

The action is that user jc101 has read the file E:/DCIM/Spacecam101/141516.jpg from a removable USB drive onto the workstation LUNA/LUNADESK35.

N.B. Although the user might not have actually read the object represented in the EventDetail, all read operations (including file system read/open operations and web page accesses, etc) are represented in the schema as View.
The nature of the event (type of View) can be indicated within <EventDetail>/<TypeId> as we have done in this example, and where possible a more human-readable explanation within <EventDetail>/<Description>.

<?xml version="1.0" encoding="UTF-8"?>
<Events 
  xmlns="event-logging:3" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="event-logging:3 file://event-logging-v999.99.9-documentation.xsd" 
  Version="999.99.9">

  <Event>
    <EventTime>
      <TimeCreated>2017-01-02T03:04:05.678Z</TimeCreated>
    </EventTime>

    <EventSource>
      <System>
        <Name>Space Desk</Name>
        <Environment>LunaDomain</Environment>
        <Organisation>ACMECoolResearch</Organisation>
      </System>
      <Generator>RMMaster2000 RM Control</Generator>
      <Device>
        <HostName>rmmaster.luna.mydomain.org</HostName>
      </Device>
      <Client>
        <Name>LUNA/LUNADESK35</Name>
        <HostName>lunadesk35.lunadesk.luna.mydomain.org</HostName>
      </Client>
      <User>
        <Id>jc101</Id>
        <Domain>ACMECoolResearch/Users</Domain>
      </User>
      <Interactive>true</Interactive>
    </EventSource>

    <EventDetail>
      <TypeId>ReadRM</TypeId>
      <Description>User has read a file from removable media</Description>
      <Import>
        <Source>
          <File>
            <Name>141516.jpg</Name>
            <Description>JPG Image</Description>
            <Permissions>
              <Permission>
                <User>
                  <Id>jc101</Id>
                  <Domain>ACMECoolResearch/Users</Domain>
                </User>
                <Allow>Read</Allow>
              </Permission>
            </Permissions>
            <Path>E:/DCIM/Spacecam101/141516.jpg</Path>
            <Size>5445121</Size>
            <Media>
              <Type>USBMassStorage</Type>
              <Removable>true</Removable>
            </Media>
            <Hash Type="SHA-256">66E0E8221E8B899F08658DA444064E631FA9B8ABE9068A208AFE051BD4E7B960</Hash>
          </File>
        </Source>
        <Outcome>
          <Permitted>true</Permitted>
        </Outcome>
      </Import>
    </EventDetail>

  </Event>

</Events>

10 - Glossary

ACL

Access Control List. A list or rules specifying which users, groups or systems are allowed (or deined) access to a particular object or resource.

API

Application Programming Interface. A software interface used with two applications or systems communicate.

CRUD

Create, Read, Update, Delete. Often used to describe the typical actions a user can perform in a system, e.g. creating a record, deleting a record, etc.

DN

LDAP Distinguished Name.

Decoration

The process of augmenting an event record with additional information obtained from other systems using key identifiers in the event. For example resolving an FQDN in an asset management database to provide location details.

FQDN

Fully Qualified Domain Name or Absolute Domain Name.

GMT

Greenwich Mean Time was the former international time standard, now replaced by UTC .

HTML

Hyper Text Markup Language.

IM

Instant Message or Online Chat. A form of real time messaging between users or groups of users.

IP

Internet Protocol. The network protocol that backs the Internet.

ISO-8601

The international standard for representing dates and times. ISO-8601 has a number of valid formats however the Schema uses only the full date and time format in UTC with fractional seconds, i.e.:

yyyy-MM-ddThh:mm:ss.mmmZ

See Date and Time Fields for more detail on the format used in the Schema.

For more general information on ISO-8601 see Wikipedia .

LDAP

Lightweight Directory Access Protocol. An open industry standard for accessing and maintaining distributed directory information services over a network.

MAC

Machine Access Control. The MAC address is a unique identifier assigned to a network interface controller. It allows a network attached device to be uniquely identified by the network adapter/controller that connects it to the network.

NTP

Network Time protocol. A protocol for clock synchronisation between computer systems. Typically a computer will synchronise its clock using a trusted NTP server.

Object Type

Within an event, this is the type of the object/entity that is the subject of the event. Examples of Object Type are <File>, <User>, etc.

See Object Types

PKI

Public Key Infrastructure. A set of roles, policies, software and hardware used to use and manage digital certificates and public key encryption. Public key infrastructure will typically involve public keys, private keys and trusted certificate authorities.

Schema Action

This is essentially the verb or action of the event, e.g. <Create>, <Search>, etc. Every event must have a schema action that describes what the user is doing.

See Schema Actions

UTC

Coordinated Universal Time. The international standard for regulating clocks with a time-zone offset of 0. The successor to GMT Sometimes referred to as Zulu time.

For more detail on UTC see UTC .

VOIP

Voice Over Internet Protocol or IP Telephony. The method of delivering voice communications over the internet or a local intranet rather than a traditional Public Switched Telephone Network.