event.yml

---
- name: event
  title: Event
  group: 2
  short: Fields breaking down the event details.
  description: >
    The event fields are used for context information about the log or metric event itself.

    A log is defined as an event containing details of something that happened.
    Log events must include the time at which the thing happened.
    Examples of log events include a process starting on a host,
    a network packet being sent from a source to a destination,
    or a network connection between a client and a server being initiated or closed.
    A metric is defined as an event containing one or more numerical or
    categorical measurements and the time at which the measurement was taken.
    Examples of metric events include memory pressure measured on a host,
    or vulnerabilities measured on a scanned host.
  type: group
  fields:

    - name: id
      level: core
      type: keyword
      description: >
        Unique ID to describe the event.
      example: 8a4f500d

    - name: code
      level: extended
      type: keyword
      short: Identification code for this event.
      description: >
        Identification code for this event, if one exists.

        Some event sources use event codes to identify messages unambiguously,
        regardless of message language or wording adjustments over time.
        An example of this is the Windows Event ID.
      example: 4648

    - name: kind
      level: extended
      type: keyword
      short: The kind of the event.
      description: >
        The kind of the event.

        This gives information about what type of information the event
        contains, without being specific to the contents of the event.  Examples
        are `event`, `state`, `alarm`. Warning: In future versions of ECS, we
        plan to provide a list of acceptable values for this field, please use
        with caution.
      example: state

    - name: category
      level: core
      type: keyword
      short: Event category.
      description: >
        Event category.

        This contains high-level information about the contents of the event. It
        is more generic than `event.action`, in the sense that typically a
        category contains multiple actions. Warning: In future versions of ECS,
        we plan to provide a list of acceptable values for this field, please
        use with caution.

      example: user-management

    - name: action
      level: core
      type: keyword
      short: The action captured by the event.
      description: >
        The action captured by the event.

        This describes the information in the event. It is more specific than
        `event.category`. Examples are `group-add`, `process-started`,
        `file-created`. The value is normally defined by the implementer.
      example: user-password-change

    - name: outcome
      level: extended
      type: keyword
      short: The outcome of the event.
      description: >
        The outcome of the event.

        If the event describes an action, this fields contains the outcome of
        that action. Examples outcomes are `success` and `failure`. Warning: In
        future versions of ECS, we plan to provide a list of acceptable values
        for this field, please use with caution.

      example: success

    - name: type
      level: core
      type: keyword
      short: Reserved for future usage.
      description: >
        Reserved for future usage.

        Please avoid using this field for user data.

    - name: module
      level: core
      type: keyword
      short: Name of the module this data is coming from.
      description: >
        Name of the module this data is coming from.

        If your monitoring agent supports the concept of modules or plugins to
        process events of a given source (e.g. Apache logs),
        `event.module` should contain the name of this module.
      example: apache

    - name: dataset
      level: core
      type: keyword
      short: Name of the dataset.
      description: >
        Name of the dataset.

        If an event source publishes more than one type of log or events
        (e.g. access log, error log), the dataset is used to specify which
        one the event comes from.

        It's recommended but not required to start the dataset name with
        the module name, followed by a dot, then the dataset name.
      example: apache.access

    - name: provider
      level: extended
      type: keyword
      short: Source of the event.
      description: >
        Source of the event.

        Event transports such as Syslog or the Windows Event Log typically
        mention the source of an event. It can be the name of the
        software that generated the event (e.g. Sysmon, httpd),
        or of a subsystem of the operating system (kernel, Microsoft-Windows-Security-Auditing).

      example: kernel

    - name: severity
      format: string
      level: core
      type: long
      example: "7"
      short: Original severity of the event.
      description: >
        Severity describes the original severity of the event. What the different
        severity values mean can very different between use cases. It's up to
        the implementer to make sure severities are consistent across events.

    - name: original
      level: core
      type: keyword
      # Unfortunately this example is not shown correctly yet as | do not work
      # in tables well
      # Is | is the representation of | it works except for cases where
      # used ticks.
      example: "Sep 19 08:26:10 host CEF:0|Security|
          threatmanager|1.0|100|
          worm successfully stopped|10|src=10.0.0.1
          dst=2.1.2.2spt=1232"
      short: Raw text message of entire event.
      description: >
          Raw text message of entire event. Used to demonstrate log integrity.

          This field is not indexed and doc_values are disabled. It cannot be
          searched, but it can be retrieved from `_source`.
      index: false
      doc_values: false

    - name: hash
      level: extended
      type: keyword
      example: "123456789012345678901234567890ABCD"
      description: >
          Hash (perhaps logstash fingerprint) of raw field to be able to
          demonstrate log integrity.

    - name: duration
      level: core
      type: long
      format: duration
      input_format: nanoseconds
      output_format: asMilliseconds
      output_precision: 1
      short: Duration of the event in nanoseconds.
      description: >
        Duration of the event in nanoseconds.

        If event.start and event.end are known this value should be the
        difference between the end and start time.

    - name: sequence
      format: string
      level: extended
      type: long
      short: Sequence number of the event.
      description: >
        Sequence number of the event.

        The sequence number is a value published by some event sources, to make the
        exact ordering of events unambiguous, regarless of the timestamp precision.

    - name: timezone
      level: extended
      type: keyword
      short: Event time zone.
      description: >
        This field should be populated when the event's timestamp does not include
        timezone information already (e.g. default Syslog timestamps). It's
        optional otherwise.

        Acceptable timezone formats are: a canonical ID (e.g. "Europe/Amsterdam"),
        abbreviated (e.g. "EST") or an HH:mm differential (e.g. "-05:00").

    - name: created
      level: core
      type: date
      short: Time when the event was first read by an agent or by your pipeline.
      description: >
        event.created contains the date/time when the event was first read by an
        agent, or by your pipeline.

        This field is distinct from @timestamp in that @timestamp typically contain
        the time extracted from the original event.

        In most situations, these two timestamps will be slightly different.
        The difference can be used to calculate the delay between your source
        generating an event, and the time when your agent first processed it.
        This can be used to monitor your agent's or pipeline's ability to
        keep up with your event source.

        In case the two timestamps are identical, @timestamp should be used.

    - name: start
      level: extended
      type: date
      description: >
        event.start contains the date when the event started or when the
        activity was first observed.

    - name: end
      level: extended
      type: date
      description: >
        event.end contains the date when the event ended or when the activity
        was last observed.

    - name: risk_score
      level: core
      type: float
      description: >
        Risk score or priority of the event (e.g. security solutions).
        Use your system's original value here.

    - name: risk_score_norm
      level: extended
      type: float
      short: Normalized risk score or priority of the event (0-100).
      description: >
        Normalized risk score or priority of the event, on a scale of 0 to 100.

        This is mainly useful if you use more than one system that assigns
        risk scores, and you want to see a normalized value across all systems.