ECS::LogEntry::Event
Inherits JSON::Serializable < Struct < Value < Object
Constructors
Instance methods
event.action
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.
Level: Core Type: Keyword Example:
user-password-change
event.action
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.
Level: Core Type: Keyword Example:
user-password-change
event.category
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.
Level: Core Type: Keyword Example:
authentication
event.category
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.
Level: Core Type: Keyword Example:
authentication
event.code
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.
Level: Extended Type: Keyword Example:
4648
event.code
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.
Level: Extended Type: Keyword Example:
4648
event.created
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.
Level: Core Type: Date Example:
2016-05-23T08:05:34.857Z
event.created
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.
Level: Core Type: Date Example:
2016-05-23T08:05:34.857Z
event.dataset
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.
Level: Core Type: Keyword Example:
apache.access
event.dataset
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.
Level: Core Type: Keyword Example:
apache.access
event.duration
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.
Level: Core Type: Long
event.duration
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.
Level: Core Type: Long
event.end
event.end contains the date when the event ended or when the activity was last observed.
Level: Extended Type: Date
event.end
event.end contains the date when the event ended or when the activity was last observed.
Level: Extended Type: Date
event.hash
Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate log integrity.
Level: Extended Type: Keyword Example:
123456789012345678901234567890ABCD
event.hash
Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate log integrity.
Level: Extended Type: Keyword Example:
123456789012345678901234567890ABCD
event.id
Unique ID to describe the event.
Level: Core Type: Keyword Example:
8a4f500d
event.ingested
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.
Level: Core Type: Date Example:
2016-05-23T08:05:35.101Z
event.ingested
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.
Level: Core Type: Date Example:
2016-05-23T08:05:35.101Z
event.kind
This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy.
event.kind gives high-level information about what type of information the
event contains, without being specific to the contents of the event. For example,
values of this field distinguish alert events from metric events.
The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not.
Level: Core Type: Keyword Example:
alert
event.kind
This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy.
event.kind gives high-level information about what type of information the
event contains, without being specific to the contents of the event. For example,
values of this field distinguish alert events from metric events.
The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not.
Level: Core Type: Keyword Example:
alert
event.module
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.
Level: Core Type: Keyword Example:
apache
event.module
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.
Level: Core Type: Keyword Example:
apache
event.original
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.
Level: Core Type: Keyword 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
event.original
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.
Level: Core Type: Keyword 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
event.outcome
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.
Level: Core Type: Keyword Example:
success
event.outcome
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.
Level: Core Type: Keyword Example:
success
event.provider
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).
Level: Extended Type: Keyword Example:
kernel
event.provider
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).
Level: Extended Type: Keyword Example:
kernel
event.reference
Reference URL linking to additional information about this event.
This URL links to a static definition of the this event. Alert events, indicated
by event.kind:alert, are a common use case for this field.
Level: Extended Type: Keyword Example:
https://system.vendor.com/event/#0001234
event.reference
Reference URL linking to additional information about this event.
This URL links to a static definition of the this event. Alert events, indicated
by event.kind:alert, are a common use case for this field.
Level: Extended Type: Keyword Example:
https://system.vendor.com/event/#0001234
event.risk_score
Risk score or priority of the event (e.g. security solutions). Use your system's original value here.
Level: Core Type: Float
event.risk_score
Risk score or priority of the event (e.g. security solutions). Use your system's original value here.
Level: Core Type: Float
event.risk_score_norm
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.
Level: Extended Type: Float
event.risk_score_norm
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.
Level: Extended Type: Float
event.sequence
Sequence number of the event.
The sequence number is a value published by some event sources, to make the exact ordering of events unambiguous, regardless of the timestamp precision.
Level: Extended Type: Long
event.sequence
Sequence number of the event.
The sequence number is a value published by some event sources, to make the exact ordering of events unambiguous, regardless of the timestamp precision.
Level: Extended Type: Long
event.severity
The numeric severity of the event according to your event source.
What the different severity values mean can be different between sources and use cases. It's up to the implementer to make sure severities are consistent across events from the same source.
The Syslog severity belongs in log.syslog.severity.code. event.severity is
meant to represent the severity according to the event source (e.g. firewall,
IDS). If the event source does not publish its own severity, you may optionally
copy the log.syslog.severity.code to event.severity.
Level: Core Type: Long Example:
7
event.severity
The numeric severity of the event according to your event source.
What the different severity values mean can be different between sources and use cases. It's up to the implementer to make sure severities are consistent across events from the same source.
The Syslog severity belongs in log.syslog.severity.code. event.severity is
meant to represent the severity according to the event source (e.g. firewall,
IDS). If the event source does not publish its own severity, you may optionally
copy the log.syslog.severity.code to event.severity.
Level: Core Type: Long Example:
7
event.start
event.start contains the date when the event started or when the activity was first observed.
Level: Extended Type: Date
event.start
event.start contains the date when the event started or when the activity was first observed.
Level: Extended Type: Date
event.timezone
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").
Level: Extended Type: Keyword
event.timezone
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").
Level: Extended Type: Keyword
event.type
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.
Level: Core Type: Keyword
event.type
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.
Level: Core Type: Keyword
event.url
URL linking to an external system to continue investigation of this event.
This URL links to another system where in-depth investigation of the specific
occurence of this event can take place. Alert events, indicated by
event.kind:alert, are a common use case for this field.
Level: Extended Type: Keyword Example:
https://mysystem.mydomain.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
event.url
URL linking to an external system to continue investigation of this event.
This URL links to another system where in-depth investigation of the specific
occurence of this event can take place. Alert events, indicated by
event.kind:alert, are a common use case for this field.
Level: Extended Type: Keyword Example:
https://mysystem.mydomain.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe