-
Notifications
You must be signed in to change notification settings - Fork 429
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
3734c25
commit 7961d4d
Showing
1 changed file
with
251 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,251 @@ | ||
- name: event | ||
title: Event | ||
group: 2 | ||
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 measurements and the time at which the measurement was taken. | ||
Examples of metric events include memory pressure measured on a host and device | ||
temperature. See the `event.kind` definition in this section for additional | ||
details about metric and state events.' | ||
type: group | ||
fields: | ||
- name: created | ||
level: core | ||
type: date | ||
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' | ||
- name: ingested | ||
level: core | ||
type: date | ||
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' | ||
- name: original | ||
level: core | ||
type: keyword | ||
ignore_above: 1024 | ||
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`.' | ||
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 | ||
|
||
- name: dns | ||
title: DNS | ||
group: 2 | ||
description: 'Fields describing DNS queries and answers. | ||
DNS events should either represent a single DNS query prior to getting answers | ||
(`dns.type:query`) or they should represent a full exchange and contain the | ||
query details as well as all of the answers that were provided for this query | ||
(`dns.type:answer`).' | ||
type: group | ||
fields: | ||
- name: answers | ||
level: extended | ||
type: object | ||
object_type: keyword | ||
description: 'An array containing an object for each answer section returned | ||
by the server. | ||
The main keys that should be present in these objects are defined by ECS. | ||
Records that have more information may contain more keys than what ECS defines. | ||
Not all DNS data sources give all details about DNS answers. At minimum, answer | ||
objects must contain the `data` key. If more information is available, map | ||
as much of it to ECS as possible, and add any additional fields to the answer | ||
objects as custom fields.' | ||
- name: answers.class | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The class of DNS data contained in this resource record. | ||
example: IN | ||
- name: answers.data | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The data describing the resource. | ||
The meaning of this data depends on the type and class of the resource record.' | ||
example: 10.10.10.10 | ||
- name: answers.name | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The domain name to which this resource record pertains. | ||
If a chain of CNAME is being resolved, each answer''s `name` should be the | ||
one that corresponds with the answer''s `data`. It should not simply be the | ||
original `question.name` repeated.' | ||
example: www.google.com | ||
- name: answers.ttl | ||
level: extended | ||
type: long | ||
description: The time interval in seconds that this resource record may be cached | ||
before it should be discarded. Zero values mean that the data should not be | ||
cached. | ||
example: 180 | ||
- name: answers.type | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The type of data contained in this resource record. | ||
example: CNAME | ||
- name: header_flags | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'Array of 2 letter DNS header flags. | ||
Expected values are: AA, TC, RD, RA, AD, CD, DO.' | ||
example: | ||
- RD | ||
- RA | ||
- name: id | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The DNS packet identifier assigned by the program that generated | ||
the query. The identifier is copied to the response. | ||
example: 62111 | ||
- name: op_code | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The DNS operation code that specifies the kind of query in the | ||
message. This value is set by the originator of a query and copied into the | ||
response. | ||
example: QUERY | ||
- name: question.class | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The class of records being queried. | ||
example: IN | ||
- name: question.name | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The name being queried. | ||
If the name field contains non-printable characters (below 32 or above 126), | ||
those characters should be represented as escaped base 10 integers (\DDD). | ||
Back slashes and quotes should be escaped. Tabs, carriage returns, and line | ||
feeds should be converted to \t, \r, and \n respectively.' | ||
example: www.google.com | ||
- name: question.registered_domain | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The highest registered domain, stripped of the subdomain. | ||
For example, the registered domain for "foo.google.com" is "google.com". | ||
This value can be determined precisely with a list like the public suffix | ||
list (http://publicsuffix.org). Trying to approximate this by simply taking | ||
the last two labels will not work well for TLDs such as "co.uk".' | ||
example: google.com | ||
- name: question.subdomain | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The subdomain is all of the labels under the registered_domain. | ||
If the domain has multiple levels of subdomain, such as "sub2.sub1.example.com", | ||
the subdomain field should contain "sub2.sub1", with no trailing period.' | ||
example: www | ||
- name: question.top_level_domain | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The effective top level domain (eTLD), also known as the domain | ||
suffix, is the last part of the domain name. For example, the top level domain | ||
for google.com is "com". | ||
This value can be determined precisely with a list like the public suffix | ||
list (http://publicsuffix.org). Trying to approximate this by simply taking | ||
the last label will not work well for effective TLDs such as "co.uk".' | ||
example: co.uk | ||
- name: question.type | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The type of record being queried. | ||
example: AAAA | ||
- name: resolved_ip | ||
level: extended | ||
type: ip | ||
description: 'Array containing all IPs seen in `answers.data`. | ||
The `answers` array can be difficult to use, because of the variety of data | ||
formats it can contain. Extracting all IP addresses seen in there to `dns.resolved_ip` | ||
makes it possible to index them as IP addresses, and makes them easier to | ||
visualize and query for.' | ||
example: | ||
- 10.10.10.10 | ||
- 10.10.10.11 | ||
- name: response_code | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: The DNS response code. | ||
example: NOERROR | ||
- name: type | ||
level: extended | ||
type: keyword | ||
ignore_above: 1024 | ||
description: 'The type of DNS event captured, query or answer. | ||
If your source of DNS events only gives you DNS queries, you should only create | ||
dns events of type `dns.type:query`. | ||
If your source of DNS events gives you answers as well, you should create | ||
one event per query (optionally as soon as the query is seen). And a second | ||
event containing all query details as well as an array of answers.' | ||
example: answer | ||
|
||
- name: related | ||
title: Related | ||
group: 2 | ||
description: 'This field set is meant to facilitate pivoting around a piece of | ||
data. | ||
Some pieces of information can be seen in many places in an ECS event. To facilitate | ||
searching for them, store an array of all seen values to their corresponding | ||
field in `related.`. | ||
A concrete example is IP addresses, which can be under host, observer, source, | ||
destination, client, server, and network.forwarded_ip. If you append all IPs | ||
to `related.ip`, you can then search for a given IP trivially, no matter where | ||
it appeared, by querying `related.ip:192.0.2.15`.' | ||
type: group | ||
fields: | ||
- name: ip | ||
level: extended | ||
type: ip | ||
description: All of the IPs seen on your event. |