(Historical page)
OTIS Home?

OTIS Audit Service and ISIL Audit Methods

The purpose of the OTIS audit service and the ISIL audit methods is to provide applications with a mechanism for holding end users accountable for their actions within the application. It should support the detection of violations, misuses, and abuses of security policies.

The primary purpose of the OTIS audit service is to provide a mechanism that allows an application to log audit events. It provides no tools for audit analysis or forensics. Sentinel, or a similar log management system, is the ultimate consumer of audit events. As such, Sentinel (or other system) is responsible for performing analysis on the audit events, generating audit reports, and archiving the events for long term storage.

Conformance to XDAS

The XDAS specification defines an open audit message taxonomy and format. The OTIS audit system will conform to the XDAS taxonomy and format. Benefits of XDAS are as follows:

  • It is very well documented, with instructions on what to do and tips for users/developers describing why something should be done in a particular way.
  • It defines a good set of events, event classes, and result conditions. This common even definition facilitates effective filtering, correlation, and reporting on the data.
  • It defines a standard record format.
  • It defines security and best practices guidelines for auditing.

The ISIL audit methods which allow an application to log audit events will enforce the XDAS taxonomy and message format so that downstream consumers of the events (such as Sentinel) get high quality data.

The XDAS architecture requires that audit messages be sent to a daemon process via a secure local IP channel. The daemon then forwards the messages to a variety of destinations (flat file, syslog, database, network endpoint, etc.) via connectors which have been configured by an administrator. To conform to this protocol, the ISIL "log audit event" method will transparently connect to the daemon and transmit audit events as specified by XDAS. At a minimum, the ISIL SDK will need the following daemon connection information:

  • Daemon port
  • Daemon host address (this would allow us to route all log events to a remote daemon instead of a local one all the time)
  • Credentials (probably needs to be some form of mutual authentication so that the application can be sure it is sending audit events to the intended target, and so that the daemon can ensure that the application is authorized to send audit events)

It may also be required that the communication channel between the daemon and the application support optional encryption using SSL.

The XDAS architecture also supports event filtering. Event filtering must be configured only by an auditor, not by applications. The daemon may be configured by an auditor to apply various filters to audit events it receives. However it may be desirable for some filtering to be "pushed" from the daemon into the application space in order to avoid unnecessary transmission of data. Thus, the ISIL auditing methods may need to provide a mechanism for receiving audit filters from the daemon.

An application logging to XDAS must be prepared to respond to the following conditions:

  • Failure of the audit subsystem. It should be configurable as to whether the application will halt, cache the audit event, or continue as normal (this may depend on the type of event being logged).
  • Notifications from the audit subsystem. The audit subsystem may want an application to abort or rollback the event that is being logged or perhaps halt. Again, the application behavior must be configurable.

Use Cases

Requirements

The ISIL Audit methods are the methods called by an application to log audit events. It must provide the following:

  1. A way for an application to create an audit event that conforms to the XDAS taxonomy specification.
  2. Formatting of audit event records so they conform to the XDAS event record format specification. Record formatting should be transparent to the application which generates the event.
  3. A way for an application to send audit events to an XDAS daemon as described above. The ISIL audit methods will handle the protocol transparently.

There will be an OTIS Audit Service that can act as an XDAS daemon. It must be able to do the following:

  1. Allow an application to establish a connection for logging audit events. Mutual authentication should be used to ensure that the application has rights to log audit events, and to assure the application that the OTIS audit service is a valid destination for audit events.
  2. Receive audit events via the XDAS event logging protocol.
  3. Store or forward audit events to any combination of the following (which must be specifiable via configuration):
    • Store the events to a flat file
    • Store the events to syslog
    • Store the events to LAF
    • Store the events to an SQL database (via ODBC)
    • NOTE: The service will NOT forward events to Sentinel. If a customer has Sentinel, they may substitute the Sentinel service for the OTIS event capture service and have all of the same benefits and more.

Architecture

API Design

Log Event Methods

Using Log4x

Many application developers are already familiar with how to use log4x. The learning curve for auditing may be decreased if they could use log4x methods to log their audit events. Using log4x would probably introduce the following best practices application developers:

  • The application should only use a special "audit" logger to log audit events.
  • The application should pass to the logger some special objects that are defined in ISIL. These objects are basically beans that define all the data that is needed to properly record a particular event. Some of the fields are required and some are optional. These objects will make it easier for the developer to know what information they must include and what information can be included if it is available. These objects should be hierarchical, with the child objects ultimately relating to fairly specific types of audit events and, in particular, events defined in the XDAS spec. All applications should use this common set of objects.
  • The ISIL log4x appender will extract the data from the ISIL logger object, format the audit event record, and send it to the XDAS daemon.
  • The object that is passed to the log appender will also have a callback object inside it (e.g., there should be a getCallback method on the interface). The callback is use to communicate audit subsystem status back to the application, as follows:
    • The interface of the audit status callback will include a way for the appender to indicate which failure action to take (e.g., halt, continue as normal). This way, the configuration of what to do on audit subsystem failure can be controlled by the auditor. Example Method: onError(int failureMode, String errorDescription), where failureMode is the failure mode of operation as configured by the auditor.
    • The interface of the audit status callback also needs to have a way of notifying that things are OK again, so the application can return to normal operation. Example Method: onRecovery()
    • For completeness, it would also make sense to have a method to tell the application that the audit message was logged successfully, in case it needed to know this. Example Method: onSuccess()
  • The ISIL log appender should reuse the same connection to the XDAS deamon across multiple calls to the appender.
  • Need more detail about how will we lock down the Log4x configuration so that:
    • Audit event data isn't sent to other appenders.
    • Audit event data is prevented from getting to the ISIL log4x appender.