Introduction

In order to understand the CEE Architecture, an agreement must be reached as to the definition of terms and the design goals.

Event records are provided by devices to report important events and indicate status. Currently, vendors individually determine which events and data is important. These events are then recorded using a variety of proprietary and open formats. Users are given access to these records through a variety of different protocols and interfaces.

This vendor-centric event environment places the entire burden of event analysis and audit compliance on the end user. The user and other event consumers are forced to support millions of different events described using hundreds of different formats. The end user pays for these inconsistencies with additional product, audit, support, and overhead costs.

Background

Organizations routinely undertake the expensive task of auditing their electronic systems. Some audits are performed to identify problems, reduce unnecessary overhead, or to maintain compliance with regulatory laws. Every log may contain critical information about prior and ongoing electronic events. Examples of some of these events include electronic events such as login, connect, and write, or physical events such as building access or equipment pressure readings. These electronic events reflect status, threats, and other observable environment changes that allow an enterprise to maintain constant situational and informational awareness. Today, there is no standard for representing and describing these events in logs. This is a significant data management problem, since enterprise-wide situational awareness depends on the ability to process and analyze event data. CEE addresses this audit problem by standardizing the event-log relationship by normalizing the way events are recorded, shared, and interpreted.

Event and Audit Lifecycle

There are three (3) essential components to an event or audit lifecycle:

Requirements

a collection of event or audit prerequisites. These requirements may specify the types of events that are important, what data they should contain, or what actions should be taken when the event is discovered. Requirements may come from regulatory compliance mandates, internal policy, customer specifications, as well as other sources. Most event and audit requirements will be generated based on the "4C"s: Customer, Compliance, Commercial, and Corporate requirements and best practices.

Figure 1: 4Cs of Requirements

Event

information regarding a single occurrence within an environment, usually involving an attempted state change. An event usually includes a notion of time, the occurrence, and any details the explicitly pertain to the event or environment that may help explain or understand the event's causes or effects.

Record

a describing of a single event. Generally, a record is an encoded collection of event fields that, together, describe the single event. Terms synonymous to event record include "audit record" and "log entry".

Figure 2: Event Lifecycle

This event lifecycle can be further divided to define a six-step lifecycle process to enable event or audit management:

1. describe: EVENTS are described based on REQUIREMENTS developed based on compliance mandates, policy, and industry best practices

2. encode: The EVENT and relevant data is encoded into an RECORD

3. send: Those RECORDS are sent upstream through the organization for analysis or storage

4. receive: Consuming devices receive the transmitted RECORDS

5. decode: The RECORDS are decoded to retrieve the original EVENT information

6. analyze: The EVENT is analyzed to determine whether they are consistent with identified REQUIREMENTS or indicate issues that require further investigation

Figure 3: Event Management Process

Architecture

The CEE Architecture focuses on the three pieces of the event and audit lifecycle: Requirements, Events, and Records. The event requirements are addressed in the CEE Profile; events are represented as records using the CEE Log Syntax (CLS); and these records are shared via a CEE Log Transport (CLT).

CEE Profile

The CEE Profile defines an extensible structure for a CEE Event. This event structure includes an user-customizable CEE Event Profile definition, a Field Dictionary with definitions of commonly used fields, and an Event Taxonomy, which is a controlled vocabulary of event tags to enable a consistent identification and classification of event types. All of the CEE Profile components are defined using XML Schema.

CEE Log Syntax (CLS)

CLS defines the event language and event encodings for representing CEE events.

CEE Log Transport (CLT)

CLT defines the requirements for secure, reliable recording and transmission of events.

Figure 4: CEE Architecture

BACK TO TOP

Goals

Due to the many uses of event records, CEE is designed to address many diverse log and audit needs. To encourage widespread adoption, the criteria and considerations for the architecture must address current community requirements as well as deficiencies identified with previous standardization attempts. Described below are general design goals for the CEE Architecture. Included with each goal is an explanation why it is important to the success of CEE.

Syntax Neutral

While the CEE Architecture is built upon XML, users of CEE shall be able to exchange additional syntaxes in order to be able to support various event log formats. Attempts to create XML-exclusive log specifications (e.g., SDEE, IDMEF) had limited success, and investigation to date has shown the CEE Community needs more options. The CEE Community supports interchangeability between XML and lower overhead text-based and binary protocols. To maximize usability and promote adoption, the CEE standard shall focus on the event records and the event attributes, while allowing multiple syntax options.

Flexible

CEE Architecture shall provide options in the choice of event fields and syntax encodings to provide flexibility to the end user. Providing some flexible options shall ensure producers and consumers can implement CEE in a manner that makes sense for their intended use or environment.

Extensible

CEE Architecture shall focus on addressing representative event records for a typical organization's environment. Therefore, CEE may not address all events and event fields. Vendors and users shall be provided the ability to define additional events and event fields without compromising CEE device compatibilities.

Agile

The CEE Architecture shall strive to maximize the agility of CEE and its components. CEE shall be designed in such a way to minimize the need for new versions, maximize the compatibility across versions, and not impose any requirements above those that are necessary for interoperability.

Compatible

CEE Architecture shall strive to utilize or provide compatibility with widely used standards, such as Syslog. By dividing CEE into multiple components and abstracting features such as the event terminology, a level of backwards-compatibility is provided. Future changes shall strive not to compromise compatibility with previous versions, yet the compatibility goal shall not prevent future additions and changes to CEE when the CEE Community believes it is necessary. Devices supporting older versions of CEE shall always be able to receive and process event records conforming to recent specification versions.

Comprehensive

All events, event fields, and field values shall be represented within the CEE Architecture or shall be capable of being specified within a compatible profile.

Maintainable

CEE Architecture shall be defined in a manner to ensure that maintenance and updates have minimal impact on CEE and component specifications. While the future of the events and their uses is unpredictable, it is certain that quantity of events and dependency upon them will continue to grow.

Easily Implementable

CEE Architecture and its components shall be defined such that it is easy to implement by both event record producers and consumers.

BACK TO TOP

CEE Profile

The CEE Profile consists of three (3) different components and are defined in XML Schema documents:

1. Event Taxonomy (taxonomy.xsd)
2. Field Dictionary (dictionary.xsd)
3. CEE Event Schema (cee.xsd)
   • Base Event Profile
   • Event Plugin Modules

The Event Taxonomy provides a listing of tags that can be used to classify and identify similar events. The Field Dictionary is a listing of fields that should be used to represent common event data.

The Event defines the structure of an event, including the minimum set of required fields. Event Plugins provide a modular mechanism that allows for the supplementing of additional data or features to a CEE Event.

Users and developers can define their own event structures and customize various plugins by extending the CEE Event (cee.xsd) schema to define their own Event Profiles.

For more information, visit the CEE Profile Specification.

CEE Event

A CEE Event consists of one event and zero or more event plugins. Events are typed using tags defined in the Taxonomy. Plugin types are defined as part of this specification. Both events and plugins contain one or more fields. A Field has an identifying name and one value, and may be defined in the Dictionary.

Figure 5: CEE Event Structure

BACK TO TOP

CEE Log Syntax (CLS)

The CLS specifications define the requirements for encoding and decoding a CEE Event into an event record. The CLS requirements are designed for maximum interoperability with existing event and interchange standards. To ensure compatibility with other encoding standards, CEE provides CEE Log Syntax (CLS) Encodings. Each CLS Encoding declaration defines a mapping from a CEE Event to a specific record syntax.

+---------+             +---------+  encode  +---------+
|         |  describe   |         | =======> |         |
| Profile | ==========> |  Event  |          | Record  |
|         |             |         | <======= |         |
+---------+             +---------+  decode  +---------+

BACK TO TOP

CEE Log Transport (CLT)

The CEE Log Transport (CLT) provides the technical support necessary for a secure and reliable event management infrastructure. A event and audit infrastructure requires more than just standardized event records, support is needed for international string encodings, secure logging services, standardized event interfaces, and secure, verifiable event trails.

The CLT defines a listing of CLT Protocol Requirements that a CEE-compliant event transport protocol must meet. For example, a CLT Protocol must be able to transmit a CLS Encoded CEE Event. More advanced CLT Protocols may provide things like encryption and full acknowledgments. A CLT Protocol may be able to specify or transmit CEE Profile requirements along with additional event-related information, such as packet captures or file data.

CLT also defines transport mappings. A CLT Transport Mapping defines a standardized way for CEE Events to be transmitted over a certain CLT Protocol. One use for a CLT Mapping is to define how to send CEE Events over the RFC5425 TLS Syslog protocol. This Mapping defines that the CEE Event must be encoded using an RFC5424 Syslog-compatible CLS Encoding and placed at a certain point in the Syslog message. The CLT Mapping may need to define additional indicators, such as flags to indicate that the data an encoded CEE Event and the character encoding used (e.g., UTF-8).

The CLT provides the features necessary to support the end-to-end audit process by extending the event record representation to include the essential confidentiality, integrity, and availability audit services.

BACK TO TOP

Page Last Updated: August 10, 2012