Skip to content

Commit

Permalink
Add missing fields
Browse files Browse the repository at this point in the history
  • Loading branch information
andrewkroh committed Jul 30, 2020
1 parent 3734c25 commit 7961d4d
Showing 1 changed file with 251 additions and 0 deletions.
251 changes: 251 additions & 0 deletions packages/suricata/dataset/eve/fields/fields.epr.yml
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&#124;Security&#124; threatmanager&#124;1.0&#124;100&#124;
worm successfully stopped&#124;10&#124;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.

0 comments on commit 7961d4d

Please sign in to comment.