This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Schema Actions

The verb or action in an event, e.g. Import, Copy, Authenticate, etc.

1: Alert
2: Approval
3: Authenticate
4: Authorise
5: Copy / Move
6: Create / View / Delete
7: Import / Export
8: Install / Uninstall
9: Network
10: Print
11: Process
12: Search
13: Send / Receive
14: Unknown
15: Update

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.

Schema Action	Rough Description
Alert	A potentially concerning situation has been identified that requires user attention to resolve.
Approval	Events relating to the approval/acceptance/rejection or the request for approval.
Authorise	Events relating to authorisation changes, e.g. to group membership within LDAP or AD.
Copy	Making copies of entities or data.
Create	Creating new items of entities or data.
Delete	Destroying entities or data.
Export	Moving entities or data out of a controlled area (e.g. database, application or network).
Import	Moving entities or data into a controlled area (e.g. database, application or network).
Install	Installing hardware, software or removable media.
Move	Moving entities or data.
Network	Events that relate to networking between computers.
Print	Events relating to printing (i.e. making hard-copies).
Process	Generic processing events, including starting processes and services on computers.
Receive	Obtaining entities or data over the network.
Search	Search operations, e.g. querying a database.
Send	Transmitting entities or data over the network.
Uninstall	Events relating to removal of hardware, software or removable media.
Unknown	A type of event that is dissimilar to any in the schema (should only be needed in niche cases).
Update	Modification to an entity or data.
View	All events relating to accessing an entity or data.

Event Modelling

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

This is because:

It would result in a schema that would be extremely large
It would result in a schema that would be constantly changing
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.

1 - Alert

A alert being generated by a system.

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>

2 - Approval

Describes events relating to the approval (or rejection) of things, or the requests for 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>

3 - Authenticate

The action of authenticating with a system, including door control systems.

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 - Authorise

The management of authorisation group membership or permissions.

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.

5 - Copy / Move

The action of copying or moving an object/entity.

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.

6 - Create / View / Delete

The action of creating, viewing or deleting an entity or object.

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>

7 - Import / Export

The action of importing or exporting something.

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>

8 - Install / Uninstall

Recording the installation or removal of software.

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>

9 - Network

Audit events from network devices.

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.

10 - Print

The action of printing a document.

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>

11 - Process

A process such as running a shell script or a scheduled job.

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>

12 - Search

The action of executing a query, filter or 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.

13 - Send / Receive

Sending or receiving something, typically to a remote system or user.

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>

14 - Unknown

A fallback action for cases that cannot be described with the other schema actions.

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.

15 - Update

The action of updating or modifying something.

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>