Javascript is required for MOREAL Online Documentation to function properly. Please enable Javascript by adjusting your browser settings.

Common Event Format structure

Common Event Format (CEF) is a log output structure standard that was introduced by HP Arcsight and was proposed in order to promote and facilitate the communication between devices and applications that generate, consume or manipulate logs, and is currently supported by a variety of vendors and software platforms.

CEF Message structure

A CEF Message consists of what could be interpreted as a CEF Header (The Message header) delimited by a “|” character and a CEF Extension (the Message body) that consist of key­value pairs. The Message is broken down in the following logical fields.

CEF:<Version>|<Device Vendor>|<Device Product>|<Device Version>|<Signature ID>|<Name>|<Severity>|<Extensions>

** Note: Common Event Format is a syntax standard, so interpretation of the fields in place is not strictly enforced, so in between implementations and vendors, header field usage and type may vary, like Signature ID which can be seen as Subtype and Name which can be seen as Type.

  • Version: The CEF version used to construct the message. Is currently 0. Future version may enforce different parsing.
  • Device vendor: Vendor of the device that produces the message as a text string, e.g. “Palo Alto Networks”. In some implementations it may contains the module or system component that produced the event log, e.g. “Security”.
  • Device product: Generic name of the device that produces the message as a text string, e.g. “PAN­OS”. When the
  • vendor field contains a module or component, the product usually contains the subsystem, e.g. “threatmanager”.
  • Device version: Version of the device that produces the message, usually numerical, e.g. “5.0.0”
  • Signature ID / Subtype: Unique identifier per event type which can be a string or an integer.
  • Name / Type: Description of the event in human­readable form. Special characters need to be escaped and may span over multiple lines using \n or \r.
  • Severity: Usually an integer that denotes the importance of the event. Scale is 0­10, where 10 is the most important event.
    Systems and devices adhering to CEF should adapt to that scale, by matching the highest values first and omitting lower ones as necessary.
  • Extensions: Extension field is essentially the actual CEF Message body (containing the event information) and may consist of an arbitrary number of key­value pairs separated by space by default. Value fields of said pairs can contain non­escaped spaces.

    Those fields are listed and described in the reference links below, though their name, content and meaning may vary depending on the event type and/or vendor implementation.
    There is also the option of custom pairs of vendor/customer­applied fields, with one of them holding the name of the attribute the field describes and the other holding the value of said attribute.
    There are maximum 6 custom string fields, 3 custom numerical, and 2 custom flexstring/flexnumber ones.
    They should be appropriately converted to standard key­value pairs, before being further processed (renaming, altering, etc).



    should become:


    There is also the possibility of encountering user/vendor­defined Custom Extensions in the proposed form of VendorNameProductNameExplanatoryKeyName (i.e. PanOSPacketsSent for PAN­OS 5.0). Those Custom Extensions should adhere to the following rules:

    1. must be made up of a single word, with no spaces.
    2. must be alphanumeric.
    3. names should be as clear and concise as possible.
    4. names should not clash with any existing names in ArcSight Extension Dictionary


Vendor­specific Mappings: