From 979c603aaa2b8acb7a3038ccb3b89311be993970 Mon Sep 17 00:00:00 2001 From: Mathieu Martin Date: Thu, 12 Nov 2020 16:32:20 -0500 Subject: [PATCH] Clarify x509 definition guidance for network events with only one cert (#1114) --- CHANGELOG.md | 2 ++ code/go/ecs/x509.go | 13 +++++++------ docs/field-details.asciidoc | 6 +++++- experimental/generated/beats/fields.ecs.yml | 17 ++++++++++------- experimental/generated/ecs/ecs_nested.yml | 16 +++++++++------- generated/beats/fields.ecs.yml | 17 ++++++++++------- generated/ecs/ecs_nested.yml | 16 +++++++++------- schemas/x509.yml | 10 ++++++---- 8 files changed, 58 insertions(+), 39 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index e5e3bd1200..9d6ea9c3a5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -28,6 +28,8 @@ All notable changes to this project will be documented in this file based on the * Provided better guidance for mapping network events. #969 * Added the field `.subdomain` under `client`, `destination`, `server`, `source` and `url`, to match its presence at `dns.question.subdomain`. #981 +* Clarified ambiguity in guidance on how to use x509 fields for connections with + only one certificate. #1114 ### Tooling and Artifact Changes diff --git a/code/go/ecs/x509.go b/code/go/ecs/x509.go index 99d916a641..d3509dda98 100644 --- a/code/go/ecs/x509.go +++ b/code/go/ecs/x509.go @@ -26,12 +26,13 @@ import ( // This implements the common core fields for x509 certificates. This // information is likely logged with TLS sessions, digital signatures found in // executable binaries, S/MIME information in email bodies, or analysis of -// files on disk. When only a single certificate is logged in an event, it -// should be nested under `file`. When hashes of the DER-encoded certificate -// are available, the `hash` data set should be populated as well (e.g. -// `file.hash.sha256`). For events that contain certificate information for -// both sides of the connection, the x509 object could be nested under the -// respective side of the connection information (e.g. `tls.server.x509`). +// files on disk. +// When the certificate relates to a file, use the fields at `file.x509`. When +// hashes of the DER-encoded certificate are available, the `hash` data set +// should be populated as well (e.g. `file.hash.sha256`). +// Events that contain certificate information about network connections, +// should use the x509 fields under the relevant TLS fields: `tls.server.x509` +// and/or `tls.client.x509`. type X509 struct { // Version of x509 format. VersionNumber string `ecs:"version_number"` diff --git a/docs/field-details.asciidoc b/docs/field-details.asciidoc index 6e887c37b4..b78b6ad5d3 100644 --- a/docs/field-details.asciidoc +++ b/docs/field-details.asciidoc @@ -6957,7 +6957,11 @@ example: `Critical` [[ecs-x509]] === x509 Certificate Fields -This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable binaries, S/MIME information in email bodies, or analysis of files on disk. When only a single certificate is logged in an event, it should be nested under `file`. When hashes of the DER-encoded certificate are available, the `hash` data set should be populated as well (e.g. `file.hash.sha256`). For events that contain certificate information for both sides of the connection, the x509 object could be nested under the respective side of the connection information (e.g. `tls.server.x509`). +This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable binaries, S/MIME information in email bodies, or analysis of files on disk. + +When the certificate relates to a file, use the fields at `file.x509`. When hashes of the DER-encoded certificate are available, the `hash` data set should be populated as well (e.g. `file.hash.sha256`). + +Events that contain certificate information about network connections, should use the x509 fields under the relevant TLS fields: `tls.server.x509` and/or `tls.client.x509`. [discrete] ==== x509 Certificate Field Details diff --git a/experimental/generated/beats/fields.ecs.yml b/experimental/generated/beats/fields.ecs.yml index 8a5c8ebccd..8a9bdf3f54 100644 --- a/experimental/generated/beats/fields.ecs.yml +++ b/experimental/generated/beats/fields.ecs.yml @@ -5897,15 +5897,18 @@ - name: x509 title: x509 Certificate group: 2 - description: This implements the common core fields for x509 certificates. This + description: 'This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable binaries, S/MIME information in email bodies, or analysis of files - on disk. When only a single certificate is logged in an event, it should be - nested under `file`. When hashes of the DER-encoded certificate are available, - the `hash` data set should be populated as well (e.g. `file.hash.sha256`). For - events that contain certificate information for both sides of the connection, - the x509 object could be nested under the respective side of the connection - information (e.g. `tls.server.x509`). + on disk. + + When the certificate relates to a file, use the fields at `file.x509`. When + hashes of the DER-encoded certificate are available, the `hash` data set should + be populated as well (e.g. `file.hash.sha256`). + + Events that contain certificate information about network connections, should + use the x509 fields under the relevant TLS fields: `tls.server.x509` and/or + `tls.client.x509`.' type: group fields: - name: alternative_names diff --git a/experimental/generated/ecs/ecs_nested.yml b/experimental/generated/ecs/ecs_nested.yml index 2929f99491..09a3a6d8b7 100644 --- a/experimental/generated/ecs/ecs_nested.yml +++ b/experimental/generated/ecs/ecs_nested.yml @@ -10396,14 +10396,16 @@ vulnerability: title: Vulnerability type: group x509: - description: This implements the common core fields for x509 certificates. This + description: 'This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable - binaries, S/MIME information in email bodies, or analysis of files on disk. When - only a single certificate is logged in an event, it should be nested under `file`. - When hashes of the DER-encoded certificate are available, the `hash` data set - should be populated as well (e.g. `file.hash.sha256`). For events that contain - certificate information for both sides of the connection, the x509 object could - be nested under the respective side of the connection information (e.g. `tls.server.x509`). + binaries, S/MIME information in email bodies, or analysis of files on disk. + + When the certificate relates to a file, use the fields at `file.x509`. When hashes + of the DER-encoded certificate are available, the `hash` data set should be populated + as well (e.g. `file.hash.sha256`). + + Events that contain certificate information about network connections, should + use the x509 fields under the relevant TLS fields: `tls.server.x509` and/or `tls.client.x509`.' fields: x509.alternative_names: dashed_name: x509-alternative-names diff --git a/generated/beats/fields.ecs.yml b/generated/beats/fields.ecs.yml index 3debcda139..0cbde896b8 100644 --- a/generated/beats/fields.ecs.yml +++ b/generated/beats/fields.ecs.yml @@ -5669,15 +5669,18 @@ - name: x509 title: x509 Certificate group: 2 - description: This implements the common core fields for x509 certificates. This + description: 'This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable binaries, S/MIME information in email bodies, or analysis of files - on disk. When only a single certificate is logged in an event, it should be - nested under `file`. When hashes of the DER-encoded certificate are available, - the `hash` data set should be populated as well (e.g. `file.hash.sha256`). For - events that contain certificate information for both sides of the connection, - the x509 object could be nested under the respective side of the connection - information (e.g. `tls.server.x509`). + on disk. + + When the certificate relates to a file, use the fields at `file.x509`. When + hashes of the DER-encoded certificate are available, the `hash` data set should + be populated as well (e.g. `file.hash.sha256`). + + Events that contain certificate information about network connections, should + use the x509 fields under the relevant TLS fields: `tls.server.x509` and/or + `tls.client.x509`.' type: group fields: - name: alternative_names diff --git a/generated/ecs/ecs_nested.yml b/generated/ecs/ecs_nested.yml index f679262400..13be87fce0 100644 --- a/generated/ecs/ecs_nested.yml +++ b/generated/ecs/ecs_nested.yml @@ -9988,14 +9988,16 @@ vulnerability: title: Vulnerability type: group x509: - description: This implements the common core fields for x509 certificates. This + description: 'This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable - binaries, S/MIME information in email bodies, or analysis of files on disk. When - only a single certificate is logged in an event, it should be nested under `file`. - When hashes of the DER-encoded certificate are available, the `hash` data set - should be populated as well (e.g. `file.hash.sha256`). For events that contain - certificate information for both sides of the connection, the x509 object could - be nested under the respective side of the connection information (e.g. `tls.server.x509`). + binaries, S/MIME information in email bodies, or analysis of files on disk. + + When the certificate relates to a file, use the fields at `file.x509`. When hashes + of the DER-encoded certificate are available, the `hash` data set should be populated + as well (e.g. `file.hash.sha256`). + + Events that contain certificate information about network connections, should + use the x509 fields under the relevant TLS fields: `tls.server.x509` and/or `tls.client.x509`.' fields: x509.alternative_names: dashed_name: x509-alternative-names diff --git a/schemas/x509.yml b/schemas/x509.yml index 81a448ee6c..8e07dc0e13 100644 --- a/schemas/x509.yml +++ b/schemas/x509.yml @@ -6,10 +6,12 @@ description: > This implements the common core fields for x509 certificates. This information is likely logged with TLS sessions, digital signatures found in executable binaries, S/MIME information in email bodies, or analysis of files on disk. - When only a single certificate is logged in an event, it should be nested under `file`. When hashes of the DER-encoded - certificate are available, the `hash` data set should be populated as well (e.g. `file.hash.sha256`). For events that - contain certificate information for both sides of the connection, the x509 object could be nested under the respective - side of the connection information (e.g. `tls.server.x509`). + + When the certificate relates to a file, use the fields at `file.x509`. When hashes of the DER-encoded + certificate are available, the `hash` data set should be populated as well (e.g. `file.hash.sha256`). + + Events that contain certificate information about network connections, should use the x509 fields + under the relevant TLS fields: `tls.server.x509` and/or `tls.client.x509`. type: group reusable: top_level: false