schemas/v1/action_responses/action_responses.yaml

'@timestamp':
  dashed_name: timestamp
  description: 'Date/time when the event originated.

    This is the date/time extracted from the event, typically representing when the
    event was generated by the source.

    If the event source has no original timestamp, this value is typically populated
    by the first time the event was received by the pipeline.

    Required field for all events.'
  example: '2016-05-23T08:05:34.853Z'
  flat_name: '@timestamp'
  level: core
  name: '@timestamp'
  normalize: []
  required: true
  short: Date/time when the event originated.
  type: date
EndpointActions.action_id:
  dashed_name: EndpointActions-action-id
  description: The action id
  flat_name: EndpointActions.action_id
  ignore_above: 1024
  level: custom
  name: action_id
  normalize: []
  short: action id
  type: keyword
EndpointActions.completed_at:
  dashed_name: EndpointActions-completed-at
  description: Request completion timestamp when the response is done executing. Usually
    matches with @timestamp.
  flat_name: EndpointActions.completed_at
  level: custom
  name: completed_at
  normalize: []
  short: completed at
  type: date
EndpointActions.data:
  dashed_name: EndpointActions-data
  description: The action request information
  flat_name: EndpointActions.data
  level: custom
  name: data
  normalize: []
  short: data
  type: object
EndpointActions.data.alert_id:
  dashed_name: EndpointActions-data-alert-id
  description: List of alert ids that triggered the action
  flat_name: EndpointActions.data.alert_id
  ignore_above: 1024
  level: custom
  name: data.alert_id
  normalize: []
  short: alert id
  type: keyword
EndpointActions.data.command:
  dashed_name: EndpointActions-data-command
  description: The action that is requested
  example: isolate
  flat_name: EndpointActions.data.command
  ignore_above: 1024
  level: custom
  name: data.command
  normalize: []
  short: command
  type: keyword
EndpointActions.data.comment:
  dashed_name: EndpointActions-data-comment
  description: A comment that describes the action that is requested
  flat_name: EndpointActions.data.comment
  level: custom
  name: data.comment
  normalize: []
  norms: false
  short: comment text
  type: text
EndpointActions.started_at:
  dashed_name: EndpointActions-started-at
  description: Timestamp of start of request
  flat_name: EndpointActions.started_at
  level: custom
  name: started_at
  normalize: []
  short: started at
  type: date
EndpointActions.status:
  dashed_name: EndpointActions-status
  description: The status of the request that distinguishes if the request is queued,
    running or completed.
  flat_name: EndpointActions.status
  ignore_above: 1024
  level: custom
  name: status
  normalize: []
  short: status
  type: keyword
action_id:
  dashed_name: action-id
  description: The action id
  flat_name: action_id
  level: custom
  name: action_id
  normalize: []
  path: EndpointActions.action_id
  short: action id
  type: alias
agent.id:
  dashed_name: agent-id
  description: 'Unique identifier of this agent (if one exists).

    Example: For Beats this would be beat.id.'
  example: 8a4f500d
  flat_name: agent.id
  ignore_above: 1024
  level: core
  name: id
  normalize: []
  short: Unique identifier of this agent.
  type: keyword
agent_id:
  dashed_name: agent-id
  description: 'Alias field that maps to {agent: {id}}'
  flat_name: agent_id
  level: custom
  name: agent_id
  normalize: []
  path: agent.id
  short: alias field for agent.id
  type: alias
completed_at:
  dashed_name: completed-at
  description: Request completion timestamp when the response is done executing. Usually
    matches with @timestamp.
  flat_name: completed_at
  level: custom
  name: completed_at
  normalize: []
  path: EndpointActions.completed_at
  short: completed at
  type: alias
data.alert_id:
  dashed_name: data-alert-id
  description: List of alert ids that triggered the action
  flat_name: data.alert_id
  level: custom
  name: data.alert_id
  normalize: []
  path: EndpointActions.data.alert_id
  short: EndpointActions.data.alert_id
  type: alias
data.command:
  dashed_name: data-command
  description: The action that is requested
  flat_name: data.command
  level: custom
  name: data.command
  normalize: []
  path: EndpointActions.data.command
  short: EndpointActions.data.command
  type: alias
data.comment:
  dashed_name: data-comment
  description: A comment that describes the action that is requested
  flat_name: data.comment
  level: custom
  name: data.comment
  normalize: []
  path: EndpointActions.data.comment
  short: EndpointActions.data.comment
  type: alias
data_stream.dataset:
  dashed_name: data-stream-dataset
  description: Data stream dataset name.
  example: nginx.access
  flat_name: data_stream.dataset
  level: custom
  name: dataset
  normalize: []
  short: The field can contain anything that makes sense to signify the source of
    the data.
  type: constant_keyword
data_stream.namespace:
  dashed_name: data-stream-namespace
  description: Data stream namespace.
  example: production
  flat_name: data_stream.namespace
  level: custom
  name: namespace
  normalize: []
  short: A user defined namespace. Namespaces are useful to allow grouping of data.
  type: constant_keyword
data_stream.type:
  dashed_name: data-stream-type
  description: Data stream type.
  example: logs
  flat_name: data_stream.type
  level: custom
  name: type
  normalize: []
  short: An overarching type for the data stream.
  type: constant_keyword
ecs.version:
  dashed_name: ecs-version
  description: 'ECS version this event conforms to. `ecs.version` is a required field
    and must exist in all events.

    When querying across multiple indices -- which may conform to slightly different
    ECS versions -- this field lets integrations adjust to the schema version of the
    events.'
  example: 1.0.0
  flat_name: ecs.version
  ignore_above: 1024
  level: core
  name: version
  normalize: []
  required: true
  short: ECS version this event conforms to.
  type: keyword
error.code:
  dashed_name: error-code
  description: Error code describing the error.
  flat_name: error.code
  ignore_above: 1024
  level: core
  name: code
  normalize: []
  short: Error code describing the error.
  type: keyword
error.id:
  dashed_name: error-id
  description: Unique identifier for the error.
  flat_name: error.id
  ignore_above: 1024
  level: core
  name: id
  normalize: []
  short: Unique identifier for the error.
  type: keyword
error.message:
  dashed_name: error-message
  description: Error message.
  flat_name: error.message
  level: core
  name: message
  normalize: []
  short: Error message.
  type: match_only_text
error.stack_trace:
  dashed_name: error-stack-trace
  description: The stack trace of this error in plain text.
  flat_name: error.stack_trace
  level: extended
  multi_fields:
  - flat_name: error.stack_trace.text
    name: text
    type: match_only_text
  name: stack_trace
  normalize: []
  short: The stack trace of this error in plain text.
  type: wildcard
error.type:
  dashed_name: error-type
  description: The type of the error, for example the class name of the exception.
  example: java.lang.NullPointerException
  flat_name: error.type
  ignore_above: 1024
  level: extended
  name: type
  normalize: []
  short: The type of the error, for example the class name of the exception.
  type: keyword
event.action:
  dashed_name: event-action
  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
  flat_name: event.action
  ignore_above: 1024
  level: core
  name: action
  normalize: []
  short: The action captured by the event.
  type: keyword
event.category:
  allowed_values:
  - description: Events in this category annotate API calls that occured on a system.
      Typical sources for those events could be from the Operating System level through
      the native libraries (for example Windows Win32, Linux libc, etc.), or managed
      sources of events (such as ETW, syslog), but can also include network protocols
      (such as SOAP, RPC, Websocket, REST, etc.)
    expected_event_types:
    - access
    - admin
    - allowed
    - change
    - creation
    - deletion
    - denied
    - end
    - info
    - start
    - user
    name: api
  - description: Events in this category are related to the challenge and response
      process in which credentials are supplied and verified to allow the creation
      of a session. Common sources for these logs are Windows event logs and ssh logs.
      Visualize and analyze events in this category to look for failed logins, and
      other authentication-related activity.
    expected_event_types:
    - start
    - end
    - info
    name: authentication
  - description: 'Events in the configuration category have to deal with creating,
      modifying, or deleting the settings or parameters of an application, process,
      or system.

      Example sources include security policy change logs, configuration auditing
      logging, and system integrity monitoring.'
    expected_event_types:
    - access
    - change
    - creation
    - deletion
    - info
    name: configuration
  - description: The database category denotes events and metrics relating to a data
      storage and retrieval system. Note that use of this category is not limited
      to relational database systems. Examples include event logs from MS SQL, MySQL,
      Elasticsearch, MongoDB, etc. Use this category to visualize and analyze database
      activity such as accesses and changes.
    expected_event_types:
    - access
    - change
    - info
    - error
    name: database
  - description: 'Events in the driver category have to do with operating system device
      drivers and similar software entities such as Windows drivers, kernel extensions,
      kernel modules, etc.

      Use events and metrics in this category to visualize and analyze driver-related
      activity and status on hosts.'
    expected_event_types:
    - change
    - end
    - info
    - start
    name: driver
  - description: 'This category is used for events relating to email messages, email
      attachments, and email network or protocol activity.

      Emails events can be produced by email security gateways, mail transfer agents,
      email cloud service providers, or mail server monitoring applications.'
    expected_event_types:
    - info
    name: email
  - description: Relating to a set of information that has been created on, or has
      existed on a filesystem. Use this category of events to visualize and analyze
      the creation, access, and deletions of files. Events in this category can come
      from both host-based and network-based sources. An example source of a network-based
      detection of a file transfer would be the Zeek file.log.
    expected_event_types:
    - access
    - change
    - creation
    - deletion
    - info
    name: file
  - description: 'Use this category to visualize and analyze information such as host
      inventory or host lifecycle events.

      Most of the events in this category can usually be observed from the outside,
      such as from a hypervisor or a control plane''s point of view. Some can also
      be seen from within, such as "start" or "end".

      Note that this category is for information about hosts themselves; it is not
      meant to capture activity "happening on a host".'
    expected_event_types:
    - access
    - change
    - end
    - info
    - start
    name: host
  - description: Identity and access management (IAM) events relating to users, groups,
      and administration. Use this category to visualize and analyze IAM-related logs
      and data from active directory, LDAP, Okta, Duo, and other IAM systems.
    expected_event_types:
    - admin
    - change
    - creation
    - deletion
    - group
    - info
    - user
    name: iam
  - description: Relating to intrusion detections from IDS/IPS systems and functions,
      both network and host-based. Use this category to visualize and analyze intrusion
      detection alerts from systems such as Snort, Suricata, and Palo Alto threat
      detections.
    expected_event_types:
    - allowed
    - denied
    - info
    name: intrusion_detection
  - description: Events in this category refer to the loading of a library, such as
      (dll / so / dynlib), into a process. Use this category to visualize and analyze
      library loading related activity on hosts.  Keep in mind that driver related
      activity will be captured under the "driver" category above.
    expected_event_types:
    - start
    name: library
  - description: Malware detection events and alerts. Use this category to visualize
      and analyze malware detections from EDR/EPP systems such as Elastic Endpoint
      Security, Symantec Endpoint Protection, Crowdstrike, and network IDS/IPS systems
      such as Suricata, or other sources of malware-related events such as Palo Alto
      Networks threat logs and Wildfire logs.
    expected_event_types:
    - info
    name: malware
  - description: Relating to all network activity, including network connection lifecycle,
      network traffic, and essentially any event that includes an IP address. Many
      events containing decoded network protocol transactions fit into this category.
      Use events in this category to visualize or analyze counts of network ports,
      protocols, addresses, geolocation information, etc.
    expected_event_types:
    - access
    - allowed
    - connection
    - denied
    - end
    - info
    - protocol
    - start
    name: network
  - description: Relating to software packages installed on hosts. Use this category
      to visualize and analyze inventory of software installed on various hosts, or
      to determine host vulnerability in the absence of vulnerability scan data.
    expected_event_types:
    - access
    - change
    - deletion
    - info
    - installation
    - start
    name: package
  - description: Use this category of events to visualize and analyze process-specific
      information such as lifecycle events or process ancestry.
    expected_event_types:
    - access
    - change
    - end
    - info
    - start
    name: process
  - description: Having to do with settings and assets stored in the Windows registry.
      Use this category to visualize and analyze activity such as registry access
      and modifications.
    expected_event_types:
    - access
    - change
    - creation
    - deletion
    name: registry
  - description: The session category is applied to events and metrics regarding logical
      persistent connections to hosts and services. Use this category to visualize
      and analyze interactive or automated persistent connections between assets.
      Data for this category may come from Windows Event logs, SSH logs, or stateless
      sessions such as HTTP cookie-based sessions, etc.
    expected_event_types:
    - start
    - end
    - info
    name: session
  - description: Use this category to visualize and analyze events describing threat
      actors' targets, motives, or behaviors.
    expected_event_types:
    - indicator
    name: threat
  - description: Relating to vulnerability scan results. Use this category to analyze
      vulnerabilities detected by Tenable, Qualys, internal scanners, and other vulnerability
      management sources.
    expected_event_types:
    - info
    name: vulnerability
  - description: 'Relating to web server access. Use this category to create a dashboard
      of web server/proxy activity from apache, IIS, nginx web servers, etc. Note:
      events from network observers such as Zeek http log may also be included in
      this category.'
    expected_event_types:
    - access
    - error
    - info
    name: web
  dashed_name: event-category
  description: 'This is one of four ECS Categorization Fields, and indicates the second
    level in the ECS category hierarchy.

    `event.category` represents the "big buckets" of ECS categories. For example,
    filtering on `event.category:process` yields all events relating to process activity.
    This field is closely related to `event.type`, which is used as a subcategory.

    This field is an array. This will allow proper categorization of some events that
    fall in multiple categories.'
  example: authentication
  flat_name: event.category
  ignore_above: 1024
  level: core
  name: category
  normalize:
  - array
  short: Event category. The second categorization field in the hierarchy.
  type: keyword
event.created:
  dashed_name: event-created
  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.'
  example: '2016-05-23T08:05:34.857Z'
  flat_name: event.created
  level: core
  name: created
  normalize: []
  short: Time when the event was first read by an agent or by your pipeline.
  type: date
event.end:
  dashed_name: event-end
  description: '`event.end` contains the date when the event ended or when the activity
    was last observed.'
  flat_name: event.end
  level: extended
  name: end
  normalize: []
  short: '`event.end` contains the date when the event ended or when the activity
    was last observed.'
  type: date
event.hash:
  dashed_name: event-hash
  description: Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate
    log integrity.
  example: 123456789012345678901234567890ABCD
  flat_name: event.hash
  ignore_above: 1024
  level: extended
  name: hash
  normalize: []
  short: Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate
    log integrity.
  type: keyword
event.id:
  dashed_name: event-id
  description: Unique ID to describe the event.
  example: 8a4f500d
  flat_name: event.id
  ignore_above: 1024
  level: core
  name: id
  normalize: []
  short: Unique ID to describe the event.
  type: keyword
event.ingested:
  dashed_name: event-ingested
  description: 'Timestamp when an event arrived in the central data store.

    This is different from `@timestamp`, which is when the event originally occurred.  It''s
    also different from `event.created`, which is meant to capture the first time
    an agent saw the event.

    In normal conditions, assuming no tampering, the timestamps should chronologically
    look like this: `@timestamp` < `event.created` < `event.ingested`.'
  example: '2016-05-23T08:05:35.101Z'
  flat_name: event.ingested
  level: core
  name: ingested
  normalize: []
  short: Timestamp when an event arrived in the central data store.
  type: date
event.outcome:
  allowed_values:
  - description: Indicates that this event describes a failed result. A common example
      is `event.category:file AND event.type:access AND event.outcome:failure` to
      indicate that a file access was attempted, but was not successful.
    name: failure
  - description: Indicates that this event describes a successful result. A common
      example is `event.category:file AND event.type:create AND event.outcome:success`
      to indicate that a file was successfully created.
    name: success
  - description: Indicates that this event describes only an attempt for which the
      result is unknown from the perspective of the event producer. For example, if
      the event contains information only about the request side of a transaction
      that results in a response, populating `event.outcome:unknown` in the request
      event is appropriate. The unknown value should not be used when an outcome doesn't
      make logical sense for the event. In such cases `event.outcome` should not be
      populated.
    name: unknown
  dashed_name: event-outcome
  description: 'This is one of four ECS Categorization Fields, and indicates the lowest
    level in the ECS category hierarchy.

    `event.outcome` simply denotes whether the event represents a success or a failure
    from the perspective of the entity that produced the event.

    Note that when a single transaction is described in multiple events, each event
    may populate different values of `event.outcome`, according to their perspective.

    Also note that in the case of a compound event (a single event that contains multiple
    logical events), this field should be populated with the value that best captures
    the overall success or failure from the perspective of the event producer.

    Further note that not all events will have an associated outcome. For example,
    this field is generally not populated for metric events, events with `event.type:info`,
    or any events for which an outcome does not make logical sense.'
  example: success
  flat_name: event.outcome
  ignore_above: 1024
  level: core
  name: outcome
  normalize: []
  short: The outcome of the event. The lowest level categorization field in the hierarchy.
  type: keyword
event.start:
  dashed_name: event-start
  description: '`event.start` contains the date when the event started or when the
    activity was first observed.'
  flat_name: event.start
  level: extended
  name: start
  normalize: []
  short: '`event.start` contains the date when the event started or when the activity
    was first observed.'
  type: date
event.type:
  allowed_values:
  - description: The access event type is used for the subset of events within a category
      that indicate that something was accessed. Common examples include `event.category:database
      AND event.type:access`, or `event.category:file AND event.type:access`. Note
      for file access, both directory listings and file opens should be included in
      this subcategory. You can further distinguish access operations using the ECS
      `event.action` field.
    name: access
  - description: 'The admin event type is used for the subset of events within a category
      that are related to admin objects. For example, administrative changes within
      an IAM framework that do not specifically affect a user or group (e.g., adding
      new applications to a federation solution or connecting discrete forests in
      Active Directory) would fall into this subcategory. Common example: `event.category:iam
      AND event.type:change AND event.type:admin`. You can further distinguish admin
      operations using the ECS `event.action` field.'
    name: admin
  - description: The allowed event type is used for the subset of events within a
      category that indicate that something was allowed. Common examples include `event.category:network
      AND event.type:connection AND event.type:allowed` (to indicate a network firewall
      event for which the firewall disposition was to allow the connection to complete)
      and `event.category:intrusion_detection AND event.type:allowed` (to indicate
      a network intrusion prevention system event for which the IPS disposition was
      to allow the connection to complete). You can further distinguish allowed operations
      using the ECS `event.action` field, populating with values of your choosing,
      such as "allow", "detect", or "pass".
    name: allowed
  - description: The change event type is used for the subset of events within a category
      that indicate that something has changed. If semantics best describe an event
      as modified, then include them in this subcategory. Common examples include
      `event.category:process AND event.type:change`, and `event.category:file AND
      event.type:change`. You can further distinguish change operations using the
      ECS `event.action` field.
    name: change
  - description: Used primarily with `event.category:network` this value is used for
      the subset of network traffic that includes sufficient information for the event
      to be included in flow or connection analysis. Events in this subcategory will
      contain at least source and destination IP addresses, source and destination
      TCP/UDP ports, and will usually contain counts of bytes and/or packets transferred.
      Events in this subcategory may contain unidirectional or bidirectional information,
      including summary information. Use this subcategory to visualize and analyze
      network connections. Flow analysis, including Netflow, IPFIX, and other flow-related
      events fit in this subcategory. Note that firewall events from many Next-Generation
      Firewall (NGFW) devices will also fit into this subcategory.  A common filter
      for flow/connection information would be `event.category:network AND event.type:connection
      AND event.type:end` (to view or analyze all completed network connections, ignoring
      mid-flow reports). You can further distinguish connection events using the ECS
      `event.action` field, populating with values of your choosing, such as "timeout",
      or "reset".
    name: connection
  - description: The "creation" event type is used for the subset of events within
      a category that indicate that something was created. A common example is `event.category:file
      AND event.type:creation`.
    name: creation
  - description: The deletion event type is used for the subset of events within a
      category that indicate that something was deleted. A common example is `event.category:file
      AND event.type:deletion` to indicate that a file has been deleted.
    name: deletion
  - description: The denied event type is used for the subset of events within a category
      that indicate that something was denied. Common examples include `event.category:network
      AND event.type:denied` (to indicate a network firewall event for which the firewall
      disposition was to deny the connection) and `event.category:intrusion_detection
      AND event.type:denied` (to indicate a network intrusion prevention system event
      for which the IPS disposition was to deny the connection to complete). You can
      further distinguish denied operations using the ECS `event.action` field, populating
      with values of your choosing, such as "blocked", "dropped", or "quarantined".
    name: denied
  - description: The end event type is used for the subset of events within a category
      that indicate something has ended. A common example is `event.category:process
      AND event.type:end`.
    name: end
  - description: The error event type is used for the subset of events within a category
      that indicate or describe an error. A common example is `event.category:database
      AND event.type:error`. Note that pipeline errors that occur during the event
      ingestion process should not use this `event.type` value. Instead, they should
      use `event.kind:pipeline_error`.
    name: error
  - description: 'The group event type is used for the subset of events within a category
      that are related to group objects. Common example: `event.category:iam AND event.type:creation
      AND event.type:group`. You can further distinguish group operations using the
      ECS `event.action` field.'
    name: group
  - description: 'The indicator event type is used for the subset of events within
      a category that contain details about indicators of compromise (IOCs).

      A common example is `event.category:threat AND event.type:indicator`.'
    name: indicator
  - description: The info event type is used for the subset of events within a category
      that indicate that they are purely informational, and don't report a state change,
      or any type of action. For example, an initial run of a file integrity monitoring
      system (FIM), where an agent reports all files under management, would fall
      into the "info" subcategory. Similarly, an event containing a dump of all currently
      running processes (as opposed to reporting that a process started/ended) would
      fall into the "info" subcategory. An additional common examples is `event.category:intrusion_detection
      AND event.type:info`.
    name: info
  - description: The installation event type is used for the subset of events within
      a category that indicate that something was installed. A common example is `event.category:package`
      AND `event.type:installation`.
    name: installation
  - description: The protocol event type is used for the subset of events within a
      category that indicate that they contain protocol details or analysis, beyond
      simply identifying the protocol. Generally, network events that contain specific
      protocol details will fall into this subcategory. A common example is `event.category:network
      AND event.type:protocol AND event.type:connection AND event.type:end` (to indicate
      that the event is a network connection event sent at the end of a connection
      that also includes a protocol detail breakdown). Note that events that only
      indicate the name or id of the protocol should not use the protocol value. Further
      note that when the protocol subcategory is used, the identified protocol is
      populated in the ECS `network.protocol` field.
    name: protocol
  - description: The start event type is used for the subset of events within a category
      that indicate something has started. A common example is `event.category:process
      AND event.type:start`.
    name: start
  - description: 'The user event type is used for the subset of events within a category
      that are related to user objects. Common example: `event.category:iam AND event.type:deletion
      AND event.type:user`. You can further distinguish user operations using the
      ECS `event.action` field.'
    name: user
  dashed_name: event-type
  description: 'This is one of four ECS Categorization Fields, and indicates the third
    level in the ECS category hierarchy.

    `event.type` represents a categorization "sub-bucket" that, when used along with
    the `event.category` field values, enables filtering events down to a level appropriate
    for single visualization.

    This field is an array. This will allow proper categorization of some events that
    fall in multiple event types.'
  flat_name: event.type
  ignore_above: 1024
  level: core
  name: type
  normalize:
  - array
  short: Event type. The third categorization field in the hierarchy.
  type: keyword
started_at:
  dashed_name: started-at
  description: Timestamp of start of request
  flat_name: started_at
  level: custom
  name: started_at
  normalize: []
  path: EndpointActions.started_at
  short: started at
  type: alias
status:
  dashed_name: status
  description: The status of the request that distinguishes if the request is queued,
    running or completed.
  flat_name: status
  level: custom
  name: status
  normalize: []
  path: EndpointActions.status
  short: status
  type: alias