Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.x] Add network directions ingress and egress (#945) #997

Merged
merged 1 commit into from
Oct 2, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.next.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ Thanks, you're awesome :-) -->
* Added Mime Type fields to HTTP request and response. #944
* Added `threat.technique.subtechnique` to capture MITRE ATT&CK® subtechniques. #951
* Added `configuration` as an allowed `event.category`. #963
* Added network directions ingress and egress. #945

#### Improvements

Expand Down
23 changes: 16 additions & 7 deletions code/go/ecs/network.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

12 changes: 9 additions & 3 deletions docs/field-details.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -3356,6 +3356,10 @@ example: `1:hO+sN4H+MG5MY/8hIrXPqc4ZQz0=`

Recommended values are:

* ingress

* egress

* inbound

* outbound
Expand All @@ -3368,9 +3372,11 @@ Recommended values are:



When mapping events from a host-based monitoring context, populate this field from the host's point of view.
When mapping events from a host-based monitoring context, populate this field from the host's point of view, using the values "ingress" or "egress".

When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of the network perimeter, using the values "inbound", "outbound", "internal" or "external".

When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of your network perimeter.
Note that "internal" is not crossing perimeter boundaries, and is meant to describe communication between two hosts within the perimeter. Note also that "external" is meant to describe traffic between two hosts that are external to the perimeter. This could for example be useful for ISPs or VPN service providers.

type: keyword

Expand Down Expand Up @@ -3409,7 +3415,7 @@ example: `6`
// ===============================================================

| network.inner
| Network.inner fields are added in addition to network.vlan fields to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields include vlan.id and vlan.name. Inner vlan fields are typically used when sending traffic with multiple 802.1q encapsulations to a network sensor (e.g. Zeek, Wireshark.)
| Network.inner fields are added in addition to network.vlan fields to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields include vlan.id and vlan.name. Inner vlan fields are typically used when sending traffic with multiple 802.1q encapsulations to a network sensor (e.g. Zeek, Wireshark.)

type: object

Expand Down
20 changes: 13 additions & 7 deletions generated/beats/fields.ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -2622,11 +2622,17 @@
type: keyword
ignore_above: 1024
description: "Direction of the network traffic.\nRecommended values are:\n \
\ * inbound\n * outbound\n * internal\n * external\n * unknown\n\nWhen\
\ mapping events from a host-based monitoring context, populate this field\
\ from the host's point of view.\nWhen mapping events from a network or perimeter-based\
\ monitoring context, populate this field from the point of view of your network\
\ perimeter."
\ * ingress\n * egress\n * inbound\n * outbound\n * internal\n * external\n\
\ * unknown\n\nWhen mapping events from a host-based monitoring context,\
\ populate this field from the host's point of view, using the values \"ingress\"\
\ or \"egress\".\nWhen mapping events from a network or perimeter-based monitoring\
\ context, populate this field from the point of view of the network perimeter,\
\ using the values \"inbound\", \"outbound\", \"internal\" or \"external\"\
.\nNote that \"internal\" is not crossing perimeter boundaries, and is meant\
\ to describe communication between two hosts within the perimeter. Note also\
\ that \"external\" is meant to describe traffic between two hosts that are\
\ external to the perimeter. This could for example be useful for ISPs or\
\ VPN service providers."
example: inbound
- name: forwarded_ip
level: core
Expand All @@ -2645,8 +2651,8 @@
level: extended
type: object
description: Network.inner fields are added in addition to network.vlan fields
to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed
fields include vlan.id and vlan.name. Inner vlan fields are typically used
to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed
fields include vlan.id and vlan.name. Inner vlan fields are typically used
when sending traffic with multiple 802.1q encapsulations to a network sensor
(e.g. Zeek, Wireshark.)
default_field: false
Expand Down
20 changes: 13 additions & 7 deletions generated/ecs/ecs_flat.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4019,11 +4019,17 @@ network.community_id:
type: keyword
network.direction:
dashed_name: network-direction
description: "Direction of the network traffic.\nRecommended values are:\n * inbound\n\
\ * outbound\n * internal\n * external\n * unknown\n\nWhen mapping events\
\ from a host-based monitoring context, populate this field from the host's point\
\ of view.\nWhen mapping events from a network or perimeter-based monitoring context,\
\ populate this field from the point of view of your network perimeter."
description: "Direction of the network traffic.\nRecommended values are:\n * ingress\n\
\ * egress\n * inbound\n * outbound\n * internal\n * external\n * unknown\n\
\nWhen mapping events from a host-based monitoring context, populate this field\
\ from the host's point of view, using the values \"ingress\" or \"egress\".\n\
When mapping events from a network or perimeter-based monitoring context, populate\
\ this field from the point of view of the network perimeter, using the values\
\ \"inbound\", \"outbound\", \"internal\" or \"external\".\nNote that \"internal\"\
\ is not crossing perimeter boundaries, and is meant to describe communication\
\ between two hosts within the perimeter. Note also that \"external\" is meant\
\ to describe traffic between two hosts that are external to the perimeter. This\
\ could for example be useful for ISPs or VPN service providers."
example: inbound
flat_name: network.direction
ignore_above: 1024
Expand Down Expand Up @@ -4058,8 +4064,8 @@ network.iana_number:
network.inner:
dashed_name: network-inner
description: Network.inner fields are added in addition to network.vlan fields to
describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields
include vlan.id and vlan.name. Inner vlan fields are typically used when sending
describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields
include vlan.id and vlan.name. Inner vlan fields are typically used when sending
traffic with multiple 802.1q encapsulations to a network sensor (e.g. Zeek, Wireshark.)
flat_name: network.inner
level: extended
Expand Down
20 changes: 13 additions & 7 deletions generated/ecs/ecs_nested.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4768,11 +4768,17 @@ network:
network.direction:
dashed_name: network-direction
description: "Direction of the network traffic.\nRecommended values are:\n \
\ * inbound\n * outbound\n * internal\n * external\n * unknown\n\nWhen\
\ mapping events from a host-based monitoring context, populate this field\
\ from the host's point of view.\nWhen mapping events from a network or perimeter-based\
\ monitoring context, populate this field from the point of view of your network\
\ perimeter."
\ * ingress\n * egress\n * inbound\n * outbound\n * internal\n * external\n\
\ * unknown\n\nWhen mapping events from a host-based monitoring context,\
\ populate this field from the host's point of view, using the values \"ingress\"\
\ or \"egress\".\nWhen mapping events from a network or perimeter-based monitoring\
\ context, populate this field from the point of view of the network perimeter,\
\ using the values \"inbound\", \"outbound\", \"internal\" or \"external\"\
.\nNote that \"internal\" is not crossing perimeter boundaries, and is meant\
\ to describe communication between two hosts within the perimeter. Note also\
\ that \"external\" is meant to describe traffic between two hosts that are\
\ external to the perimeter. This could for example be useful for ISPs or\
\ VPN service providers."
example: inbound
flat_name: network.direction
ignore_above: 1024
Expand Down Expand Up @@ -4807,8 +4813,8 @@ network:
network.inner:
dashed_name: network-inner
description: Network.inner fields are added in addition to network.vlan fields
to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed
fields include vlan.id and vlan.name. Inner vlan fields are typically used
to describe the innermost VLAN when q-in-q VLAN tagging is present. Allowed
fields include vlan.id and vlan.name. Inner vlan fields are typically used
when sending traffic with multiple 802.1q encapsulations to a network sensor
(e.g. Zeek, Wireshark.)
flat_name: network.inner
Expand Down
19 changes: 14 additions & 5 deletions schemas/network.yml
Original file line number Diff line number Diff line change
Expand Up @@ -85,17 +85,26 @@
Direction of the network traffic.

Recommended values are:
* ingress
* egress
* inbound
* outbound
* internal
* external
* unknown

When mapping events from a host-based monitoring context, populate this
field from the host's point of view.
field from the host's point of view, using the values "ingress" or "egress".

When mapping events from a network or perimeter-based monitoring context,
populate this field from the point of view of your network perimeter.
populate this field from the point of view of the network perimeter,
using the values "inbound", "outbound", "internal" or "external".

Note that "internal" is not crossing perimeter boundaries, and is meant
to describe communication between two hosts within the perimeter. Note also
that "external" is meant to describe traffic between two hosts that are
external to the perimeter. This could for example be useful for ISPs or
VPN service providers.
example: inbound

- name: forwarded_ip
Expand Down Expand Up @@ -138,14 +147,14 @@

If `source.packets` and `destination.packets` are known, `network.packets` is their sum.
example: 24

# q-in-q vlan fields for identifying 802.1q nested vlans
- name: inner
level: extended
type: object
short: Inner VLAN tag information
description: >
Network.inner fields are added in addition to network.vlan fields to describe
the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields include
Network.inner fields are added in addition to network.vlan fields to describe
the innermost VLAN when q-in-q VLAN tagging is present. Allowed fields include
vlan.id and vlan.name. Inner vlan fields are typically used when sending traffic
with multiple 802.1q encapsulations to a network sensor (e.g. Zeek, Wireshark.)