From 198f6a8c6da1883b3d0869c3ee28b1d75079d053 Mon Sep 17 00:00:00 2001 From: Mathieu Martin Date: Thu, 20 Aug 2020 11:59:39 -0400 Subject: [PATCH 1/4] Add network directions ingress and egress --- code/go/ecs/network.go | 14 ++++++++------ docs/field-details.asciidoc | 10 +++++++--- generated/beats/fields.ecs.yml | 15 ++++++++------- generated/ecs/ecs_flat.yml | 16 +++++++++------- generated/ecs/ecs_nested.yml | 15 ++++++++------- schemas/network.yml | 13 ++++++++----- 6 files changed, 48 insertions(+), 35 deletions(-) diff --git a/code/go/ecs/network.go b/code/go/ecs/network.go index e47d15abd2..7e80a6b11b 100644 --- a/code/go/ecs/network.go +++ b/code/go/ecs/network.go @@ -61,6 +61,8 @@ type Network struct { // Direction of the network traffic. // Recommended values are: + // * ingress + // * egress // * inbound // * outbound // * internal @@ -68,10 +70,10 @@ type Network struct { // * 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. + // perimeter, using the values inbound, outbound, internal or external. Direction string `ecs:"direction"` // Host IP address when the source IP address is the proxy. @@ -94,9 +96,9 @@ type Network struct { Packets int64 `ecs:"packets"` // 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.) + // 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.) Inner map[string]interface{} `ecs:"inner"` } diff --git a/docs/field-details.asciidoc b/docs/field-details.asciidoc index d13a5896c5..65d2223ae3 100644 --- a/docs/field-details.asciidoc +++ b/docs/field-details.asciidoc @@ -3326,6 +3326,10 @@ example: `1:hO+sN4H+MG5MY/8hIrXPqc4ZQz0=` Recommended values are: + * ingress + + * egress + * inbound * outbound @@ -3338,9 +3342,9 @@ 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 your network perimeter. +When mapping events from a network or perimeter-based monitoring context, populate this field from the point of view of your network perimeter, using the values inbound, outbound, internal or external. type: keyword @@ -3379,7 +3383,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 diff --git a/generated/beats/fields.ecs.yml b/generated/beats/fields.ecs.yml index 9a64f03429..6a311095e1 100644 --- a/generated/beats/fields.ecs.yml +++ b/generated/beats/fields.ecs.yml @@ -2594,11 +2594,12 @@ 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 your network perimeter,\ + \ using the values inbound, outbound, internal or external." example: inbound - name: forwarded_ip level: core @@ -2617,8 +2618,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 diff --git a/generated/ecs/ecs_flat.yml b/generated/ecs/ecs_flat.yml index 64540cebfe..35db7dee8a 100644 --- a/generated/ecs/ecs_flat.yml +++ b/generated/ecs/ecs_flat.yml @@ -3983,11 +3983,13 @@ 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.\nWhen mapping\ + \ events from a network or perimeter-based monitoring context, populate this field\ + \ from the point of view of your network perimeter, using the values inbound,\ + \ outbound, internal or external." example: inbound flat_name: network.direction ignore_above: 1024 @@ -4022,8 +4024,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 diff --git a/generated/ecs/ecs_nested.yml b/generated/ecs/ecs_nested.yml index ee213ac0c8..21c5ca9745 100644 --- a/generated/ecs/ecs_nested.yml +++ b/generated/ecs/ecs_nested.yml @@ -4732,11 +4732,12 @@ 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 your network perimeter,\ + \ using the values inbound, outbound, internal or external." example: inbound flat_name: network.direction ignore_above: 1024 @@ -4771,8 +4772,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 diff --git a/schemas/network.yml b/schemas/network.yml index 4b01088e9a..976e4029dd 100644 --- a/schemas/network.yml +++ b/schemas/network.yml @@ -85,6 +85,8 @@ Direction of the network traffic. Recommended values are: + * ingress + * egress * inbound * outbound * internal @@ -92,10 +94,11 @@ * 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 your network perimeter, + using the values inbound, outbound, internal or external. example: inbound - name: forwarded_ip @@ -138,14 +141,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.) From 2b45c5e927780610dc1442840fa2659e59ad9a6d Mon Sep 17 00:00:00 2001 From: Mathieu Martin Date: Thu, 20 Aug 2020 12:15:41 -0400 Subject: [PATCH 2/4] changelog --- CHANGELOG.next.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.next.md b/CHANGELOG.next.md index 4b74d26590..bb81ef28a3 100644 --- a/CHANGELOG.next.md +++ b/CHANGELOG.next.md @@ -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 From 0796cc3437dc50e47bca7677825edbe546881b3e Mon Sep 17 00:00:00 2001 From: Mathieu Martin Date: Fri, 2 Oct 2020 15:11:52 -0400 Subject: [PATCH 3/4] Try to clarify the meaning of the non-directional 'internal' and 'external' values. Also quoting the values, when they're mentioned in the description. --- code/go/ecs/network.go | 11 +++++++++-- docs/field-details.asciidoc | 6 ++++-- generated/beats/fields.ecs.yml | 11 ++++++++--- generated/ecs/ecs_flat.yml | 12 ++++++++---- generated/ecs/ecs_nested.yml | 11 ++++++++--- schemas/network.yml | 10 ++++++++-- 6 files changed, 45 insertions(+), 16 deletions(-) diff --git a/code/go/ecs/network.go b/code/go/ecs/network.go index 7e80a6b11b..21fd5d5b79 100644 --- a/code/go/ecs/network.go +++ b/code/go/ecs/network.go @@ -70,10 +70,17 @@ type Network struct { // * unknown // // 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. + // 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, using the values inbound, outbound, internal or external. + // 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 their perimeter. This could for example be useful for + // ISPs or VPN service providers. Direction string `ecs:"direction"` // Host IP address when the source IP address is the proxy. diff --git a/docs/field-details.asciidoc b/docs/field-details.asciidoc index 65d2223ae3..2ccf97afe8 100644 --- a/docs/field-details.asciidoc +++ b/docs/field-details.asciidoc @@ -3342,9 +3342,11 @@ Recommended values are: -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 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 your 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, 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 their perimeter. This could for example be useful for ISPs or VPN service providers. type: keyword diff --git a/generated/beats/fields.ecs.yml b/generated/beats/fields.ecs.yml index 6a311095e1..fd51cab037 100644 --- a/generated/beats/fields.ecs.yml +++ b/generated/beats/fields.ecs.yml @@ -2596,10 +2596,15 @@ 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.\nWhen mapping events from a network or perimeter-based monitoring\ + \ 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 your network perimeter,\ - \ using the values inbound, outbound, internal or external." + \ 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 their perimeter. This could for example be useful for ISPs or\ + \ VPN service providers." example: inbound - name: forwarded_ip level: core diff --git a/generated/ecs/ecs_flat.yml b/generated/ecs/ecs_flat.yml index 35db7dee8a..929eeecf14 100644 --- a/generated/ecs/ecs_flat.yml +++ b/generated/ecs/ecs_flat.yml @@ -3986,10 +3986,14 @@ network.direction: 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.\nWhen mapping\ - \ events from a network or perimeter-based monitoring context, populate this field\ - \ from the point of view of your network perimeter, using the values inbound,\ - \ outbound, internal or external." + \ 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 your 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 their perimeter.\ + \ This could for example be useful for ISPs or VPN service providers." example: inbound flat_name: network.direction ignore_above: 1024 diff --git a/generated/ecs/ecs_nested.yml b/generated/ecs/ecs_nested.yml index 21c5ca9745..5c4e50dc2b 100644 --- a/generated/ecs/ecs_nested.yml +++ b/generated/ecs/ecs_nested.yml @@ -4734,10 +4734,15 @@ network: 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.\nWhen mapping events from a network or perimeter-based monitoring\ + \ 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 your network perimeter,\ - \ using the values inbound, outbound, internal or external." + \ 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 their perimeter. This could for example be useful for ISPs or\ + \ VPN service providers." example: inbound flat_name: network.direction ignore_above: 1024 diff --git a/schemas/network.yml b/schemas/network.yml index 976e4029dd..d70051ee89 100644 --- a/schemas/network.yml +++ b/schemas/network.yml @@ -94,11 +94,17 @@ * unknown 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. + 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, - using the values inbound, outbound, internal or external. + 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 their perimeter. This could for example be useful for ISPs or + VPN service providers. example: inbound - name: forwarded_ip From f41def58f7517029388c41dab0e8c8e28f243f09 Mon Sep 17 00:00:00 2001 From: Mathieu Martin Date: Fri, 2 Oct 2020 16:25:54 -0400 Subject: [PATCH 4/4] Minor adjustments to the wording: 'the perimeter' not your, nor their --- code/go/ecs/network.go | 6 +++--- docs/field-details.asciidoc | 4 ++-- generated/beats/fields.ecs.yml | 4 ++-- generated/ecs/ecs_flat.yml | 6 +++--- generated/ecs/ecs_nested.yml | 4 ++-- schemas/network.yml | 4 ++-- 6 files changed, 14 insertions(+), 14 deletions(-) diff --git a/code/go/ecs/network.go b/code/go/ecs/network.go index 21fd5d5b79..a696a4e419 100644 --- a/code/go/ecs/network.go +++ b/code/go/ecs/network.go @@ -73,14 +73,14 @@ type Network struct { // 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 + // context, 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 their perimeter. This could for example be useful for - // ISPs or VPN service providers. + // are external to the perimeter. This could for example be useful for ISPs + // or VPN service providers. Direction string `ecs:"direction"` // Host IP address when the source IP address is the proxy. diff --git a/docs/field-details.asciidoc b/docs/field-details.asciidoc index 2ccf97afe8..e1fd345bf7 100644 --- a/docs/field-details.asciidoc +++ b/docs/field-details.asciidoc @@ -3344,9 +3344,9 @@ Recommended values are: 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 your 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 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 their perimeter. This could for example be useful for ISPs or VPN service providers. +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 diff --git a/generated/beats/fields.ecs.yml b/generated/beats/fields.ecs.yml index fd51cab037..91728fa88e 100644 --- a/generated/beats/fields.ecs.yml +++ b/generated/beats/fields.ecs.yml @@ -2598,12 +2598,12 @@ \ * 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 your network perimeter,\ + \ 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 their perimeter. This could for example be useful for ISPs or\ + \ external to the perimeter. This could for example be useful for ISPs or\ \ VPN service providers." example: inbound - name: forwarded_ip diff --git a/generated/ecs/ecs_flat.yml b/generated/ecs/ecs_flat.yml index 929eeecf14..6d1f55b7ca 100644 --- a/generated/ecs/ecs_flat.yml +++ b/generated/ecs/ecs_flat.yml @@ -3988,12 +3988,12 @@ network.direction: \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 your network perimeter, using the values\ + \ 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 their perimeter.\ - \ This could for example be useful for ISPs or VPN service providers." + \ 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 diff --git a/generated/ecs/ecs_nested.yml b/generated/ecs/ecs_nested.yml index 5c4e50dc2b..02c42e9bbe 100644 --- a/generated/ecs/ecs_nested.yml +++ b/generated/ecs/ecs_nested.yml @@ -4736,12 +4736,12 @@ network: \ * 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 your network perimeter,\ + \ 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 their perimeter. This could for example be useful for ISPs or\ + \ external to the perimeter. This could for example be useful for ISPs or\ \ VPN service providers." example: inbound flat_name: network.direction diff --git a/schemas/network.yml b/schemas/network.yml index d70051ee89..c6fed904b7 100644 --- a/schemas/network.yml +++ b/schemas/network.yml @@ -97,13 +97,13 @@ 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 their perimeter. This could for example be useful for ISPs or + external to the perimeter. This could for example be useful for ISPs or VPN service providers. example: inbound