Introduction

A1. What is CEE?

CEE™ is the Common Event Expression initiative being developed by a community representing the vendors, researchers, and end users, and coordinated by MITRE. The primary goal of the effort is to standardize the representation and exchange of logs from electronic systems.

A2. What are logs?

Logs are the recordings of one or more events occurring on information systems. Logs can be organized based on the program, day, severity, host, or a number of other categories. For example, in Microsoft Windows XP, log entries are recorded into the Application, Security, or System log, and can be viewed via the Event Viewer. In Linux, events are logged per application or service, into a text file in the /var/log directory.

Logs may be referred to as log files, audit logs, or audit trails, and, in some cases, also cover alerts, alarms, event records, event logs, event messages, log records, audit records, and sometimes even SNMP traps.

A3. What are the basic components of CEE?

The CEE architecture focuses on the three pieces of the Event Lifecycle: Requirements, which are addressed in the CEE Profile; Events, which are represented as records using the CEE Log Syntax (CLS); and Records, which are shared via a CEE Log Transport (CLT).

The CEE Language includes the following:

• CEE Profiles — defines the structure of a CEE Event, which includes a 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
• CEE Log Syntax (CLS) — defines the event structure and representation
• CEE Log Transport (CLT) — allows for the sharing of event information

Please see About CEE and CEE Language for more detailed information.

A4. What distinguishes CEE? Why should we attempt yet another log standard?

Other efforts involving event and log standardization have either too closely coupled the syntax and transport components, thus limiting usability, or have developed their standard to support a single, narrowly-defined use-case. CEE attempts to standardize the heterogeneous vocabulary so that events can be expressed in a uniform, device-independent manner. Furthermore, we realize that a single syntax is not suitable for every environment. CEE offers the vendor and operators the flexibility to choose the best option by providing several, flexible syntax and transport options, including the very important option of currently utilized transport and format options, which will be adopted by the CEE standard effort.

A5. Why should we support CEE? How will it benefit me or my organization?

CEE will provide a variety of benefits software vendors, IT users, and log management vendors as detailed below:

Software Vendors — Overall CEE will simplify and standardize logging procedures and reduce costs of audit trail support. In particular, CEE’s standardized transport will allow products to be compatible with existing network topologies, CEE’s syntax will simplify logging across all products and reduce costs of audit trail support, the CEE taxonomy will simplify logging across all products, and CEE’s log recommendations will allow you to provide the data your customers want and expect in logs.

IT Users — Overall CEE will reduce costs for log management and compliance overhead and improve monitoring abilities. In particular, CEE’s standardized transport will help you identify and manage log-related traffic, CEE’s syntax will simplify log analysis across all deployed products and improve system interoperability, the CEE taxonomy will help you to understand what is in the logs better and easier and to support higher-level compliance requirements, and CEE’s log recommendations will help you to know what audit, compliance, operational best practices are and will also help you save on research.

Log Management Vendors — Overall CEE will result in reduced cost for log support and allow for improved product capabilities. In particular, CEE’s standardized transport will simplify log collection, CEE’s syntax will simplify log analysis from all deployed products and simplify searching, the CEE taxonomy will enable better cross-log-source analysis, and CEE’s log recommendations will help you know what to tell users that they need to do.

Also see Benefits of CEE on the About CEE page.

A6. What is MITRE’s role?

The MITRE Corporation manages and maintains the creation of CEE with assistance from the CEE Board, conducts community outreach activities, maintains the CEE Web site, and provides neutral guidance throughout the process to ensure that CEE serves the public interest.

In partnership with government clients, The MITRE Corporation is a not-for-profit corporation working in the public interest. It addresses issues of critical national importance, combining systems engineering and information technology to develop innovative solutions that make a difference.

MITRE’s work is focused within four Federally Funded Research and Development Centers (FFRDCs). One FFRDC performs systems engineering and integration work for Department of Defense C3I. A second performs systems research and development work for the Federal Aviation Administration and other civil aviation authorities. A third FFRDC provides strategic, technical and program management advice to the Internal Revenue Service and the Treasury Department. The fourth FFRDC provide systems engineering expertise and acquisition strategy advice to the Department of Homeland Security.

BACK TO TOP

CEE Language

B1. What is the difference between the Event Taxonomy and the Syntax (or "fields")?

Distinguishing the difference between the CEE Taxonomy and Syntax is the most common area for confusion. Instead of trying to describe the differences, it may be easier to understand an example. For instance, let us use the following event record:

On January 1, 2008 at 10:00 a.m., Joe drove to the supermarket.

Here, the general event, or taxonomy, is "a person went to a store." The other details, such as the date, time, the person’s name, the type of store, and even the method of transportation, are unique to that specific instance and are provided by the syntax. In CEE, this allows for a user to easily identify all of the "going to the store" events, without having to understand all of the details. With a taxonomy, this concept can be abstracted further to find the events involving people or events where things move from one location to another.

Similarly, in event logs from electronic systems, the data can be divided into two abstraction levels: the generic event type and the instance-specific facts. The taxonomy provides a general statement regarding what happened, while the syntax describes the event details.

As the primary goal of CEE is to dramatically simplify and unify heterogeneous event logs — when two or more devices log the same event, the event logs should contain similar detail and use the same terminology (the only variation should come in specificity, as some devices are more specialized in certain areas). The Event Taxonomy defines the event type and the Syntax provides the event instance-specific details. In newspaper terminology, the taxonomy would be the headline: "User Logs In," "Configuration Settings Changed," "Network Packet Blocked." If the headline is of interest and you want more details, you could read into the story, or syntax, to get the specifics: when, where, what user, what settings, what packet, why?

The Event Taxonomy only deals with the type of event, all instance-specific details are ignored. All events of the same type should be recorded identically, and events of similar types should be similar in representation in the logs. The taxonomy provides a way for each event to be classified in the same way, but does not provide enough information to distinguish unique events of the same event type from one another. For example, a taxonomy may express that a "local user login" and "remote user login" are similar, but distinct event types; while "user login", "user logon", and "user authentication" are all "user login" events.

The Event Taxonomy could be thought of as one of many event details defined by the Syntax. To represent unique instances of events, CEE produces a log based on the Syntax. The data dictionary used by that Syntax specifies the data elements such as timestamps, hostnames, protocol, and other specific details. If not coupled with the Event Taxonomy, the event logs will be all specifics with no contextual information. The time, source, destination, and size details does not help in telling what the event was: an upload? Download? An attempted attack?

B2. Please explain the CEE Taxonomy terms. How can a log message be translated into the CEE Taxonomy?

In CEE, the taxonomy consists of terms such as an ACTION, OBJECT, and STATUS to indicate what happened, to whom did it occur, and what was the result. Each log entry should be expressed in active voice, where the ACTION on the OBJECT. For example, a correct CEE taxonomy would indicate that a "user changed a configuration setting," and not "a configuration setting was changed by the user."

B3. If the CEE Taxonomy and Syntax are distinct, why are the CEE Taxonomy terms included in the Data Dictionary?

The categories used in the CEE Taxonomy are present as fields in the Data Dictionary and Syntaxes. The inclusion of the taxonomy as fields in the data dictionary is only used to indicate how the event type is specified within a CEE log. While it would be possible to define the taxonomy portion in-line with the dictionary, we believe that it is best that the CEE Taxonomy and its terms are defined in their own specification. By doing this, it is the hope that the specification becomes more streamlined and implementable. Additionally, CEE can reference the taxonomy document independently, or in combination with the Logging Recommendation, to provide guidance and answers to some the more frequent event logging questions, including:

• "Which events should I be logging?"
• "Which events are important to my customers?"
• "Which events correspond to my higher level logging requirements, such as those outlined in regulatory standards or organizational policy?"

B4. Why do we need a Data Dictionary in addition to the Log Syntax?

Simply put, the Data Dictionary is the data elements and their meaning, and the Log Syntax is how those data elements are represented in logs. The dictionary abstracts the event details from being syntax-specific. The data elements will have the same name, meaning, and format regardless of the Log Syntax used.

While CEE-Compatible devices should support all relevant Data Dictionary elements, they may choose to only support a subset of possible Log Syntaxes. The Log Syntax is the actual representation of the logs, including the message structure and syntax-specific encodings, and allows a device to parse the log. For example, a Log Syntax can be in XML as defined by an XML schema or in a byte-delimited binary encoding. Since the dictionary and syntax are separate, it becomes trivial to translate logs from one Log Syntax to another.

B5. What is the difference between the Log Syntax and Log Transport?

Log Transport is the CEE component that is used to facilitate the exchange of logs, as represented by the Log Syntax. Log Syntax is the representation of the event data (including the taxonomy and syntax) in logs.

The Log Transport specifies whether the logs are exchanged as files or via other protocols. The Log Syntax and Log Transport are two distinct components, but are dependent upon one another in certain instances. Some syntax options, such as XML-based syntaxes are limited to certain transport options like file-based or via SOAP. Due the XML verbosity, the transport cannot be Syslog. The Log Transport can be modified independent of the syntax to adjust to various network or transaction restrictions, such as low bandwidth or a firewall policy that only allows web and e-mail traffic. Additionally, the transport is where administrators can control encryption, reliability, or other transport-level options.

B6. Why does CEE separate the data from the syntax, does not this introduce further complexity? How does CEE differ from current log standards?

CEE believes that the biggest hurdle with the adoption of current log standardization efforts, such as IDMEF and XDAS, is that they integrate the log data into their XML syntaxes. In doing so, they force all adopters to use XML. While many believe that XML is the best way to express log data, CEE takes the position that this limitation is unnecessary and prevents the log community from using such standards as a base for their log architectures. Additionally, system and network administrators may not want the overhead of such logs consuming bandwidth.

By viewing each of these components separately, CEE maximizes the flexibility while making the standard more easily adoptable. It is easier to manage discussion, encourage community feedback, and come to a consensus on the event taxonomy, data dictionary elements, and transport syntax as individual topics instead of presenting them with a 100+ page document to review and implement.

B7. Is CEE extensible? Can I add fields or develop a new CEE Syntax to fulfill my needs? How will CEE-compatible devices handle such CEE extensions?

We are trying to balance CEE to be as extensible and flexible as possible while maximizing the compatibility. Custom versions of CEE should be avoided.

It will be possible to utilize custom fields or create your own syntax, however you would be limiting your compatibility. CEE is being designed to handle the normal event log traffic for a typical organization networking environment. The data dictionary should contain all fields necessary for the average user. If you feel that there are items that should be on the supported CEE Data Dictionary, then we request that you email us at cee@mitre.org or post a proposal to the CEE discussion list. If your data is environment specific or the CEE community feels that the field is not suitable for addition to the dictionary, you can still utilize custom fields by extending the syntax. It is requested that you name your fields uniquely enough that there is a minimal chance of overlap with other custom fields and possible future CEE dictionary extension. The only limitation of defining and utilizing custom fields is that all CEE-compatible devices should ignore all field names that are not in the official CEE Data Dictionary and they do not recognize.

While it is also possible to create your own syntax based on the CEE Data Dictionary, it is not recommended. By utilizing a custom syntax, you risk confliction with all CEE-compatible devices. If a custom syntax is absolutely necessary, please email cee@mitre.org or submit a proposal for a new syntax to the CEE Discussion list detailing why you feel that CEE should support another syntax. Otherwise, custom syntaxes should be used only by systems under your control and translated to a supported CEE Syntax before being sent outside of a controlled environment.

BACK TO TOP

CEE Community

C1. How can I or my organization participate in the CEE effort?

CEE is not currently seeking community participation.

C2. What is the CEE Board?

See the CEE Board page.

C3. How can I or my organization join the CEE Board?

The CEE Board is not currently accepting new members.