[GCP] set event.module and event.dataset (#1240)

Author: mtojek

packages/gcp/changelog.yml

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "0.2.0"
+  changes:
+    - description: Set "event.module" and "event.dataset"
+      type: enhancement
+      link: https://github.com/elastic/integrations/pull/1240
 - version: "0.1.0"
   changes:
     - description: update to ECS 1.10.0 and adding event.original options

packages/gcp/data_stream/audit/fields/base-fields.yml

@@ -10,3 +10,11 @@
 - name: '@timestamp'
   type: date
   description: Event timestamp.
+- name: event.module
+  type: constant_keyword
+  description: Event module
+  value: gcp
+- name: event.dataset
+  type: constant_keyword
+  description: Event dataset
+  value: gcp.audit

packages/gcp/data_stream/firewall/fields/base-fields.yml

@@ -10,3 +10,11 @@
 - name: '@timestamp'
   type: date
   description: Event timestamp.
+- name: event.module
+  type: constant_keyword
+  description: Event module
+  value: gcp
+- name: event.dataset
+  type: constant_keyword
+  description: Event dataset
+  value: gcp.firewall

packages/gcp/data_stream/vpcflow/fields/base-fields.yml

@@ -10,3 +10,11 @@
 - name: '@timestamp'
   type: date
   description: Event timestamp.
+- name: event.module
+  type: constant_keyword
+  description: Event module
+  value: gcp
+- name: event.dataset
+  type: constant_keyword
+  description: Event dataset
+  value: gcp.vpcflow

packages/gcp/docs/README.md

@@ -134,7 +134,9 @@ An example event for `audit` looks as following:
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version | keyword |
 | event.action | The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer. | keyword |
+| event.dataset | Event dataset | constant_keyword |
 | event.ingested | 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`. | date |
+| event.module | Event module | constant_keyword |
 | event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. `event.outcome` simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of `event.outcome`, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with `event.type:info`, or any events for which an outcome does not make logical sense. | keyword |
 | gcp.audit.authentication_info.authority_selector | The authority selector specified by the requestor, if any. It is not guaranteed  that the principal was allowed to use this authority. | keyword |
 | gcp.audit.authentication_info.principal_email | The email address of the authenticated user making the request. | keyword |
@@ -379,7 +381,9 @@ An example event for `firewall` looks as following:
 | destination.port | Port of the destination. | long |
 | ecs.version | ECS version | keyword |
 | event.action | The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer. | keyword |
+| event.dataset | Event dataset | constant_keyword |
 | event.ingested | 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`. | date |
+| event.module | Event module | constant_keyword |
 | event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. `event.outcome` simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of `event.outcome`, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with `event.type:info`, or any events for which an outcome does not make logical sense. | keyword |
 | gcp.destination.instance.project_id | ID of the project containing the VM. | keyword |
 | gcp.destination.instance.region | Region of the VM. | keyword |
@@ -595,7 +599,9 @@ An example event for `vpcflow` looks as following:
 | destination.port | Port of the destination. | long |
 | ecs.version | ECS version | keyword |
 | event.action | The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer. | keyword |
+| event.dataset | Event dataset | constant_keyword |
 | event.ingested | 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`. | date |
+| event.module | Event module | constant_keyword |
 | event.outcome | This is one of four ECS Categorization Fields, and indicates the lowest level in the ECS category hierarchy. `event.outcome` simply denotes whether the event represents a success or a failure from the perspective of the entity that produced the event. Note that when a single transaction is described in multiple events, each event may populate different values of `event.outcome`, according to their perspective. Also note that in the case of a compound event (a single event that contains multiple logical events), this field should be populated with the value that best captures the overall success or failure from the perspective of the event producer. Further note that not all events will have an associated outcome. For example, this field is generally not populated for metric events, events with `event.type:info`, or any events for which an outcome does not make logical sense. | keyword |
 | gcp.destination.instance.project_id | ID of the project containing the VM. | keyword |
 | gcp.destination.instance.region | Region of the VM. | keyword |

packages/gcp/manifest.yml

@@ -1,6 +1,6 @@
 name: gcp
 title: Google Cloud Platform (GCP)
-version: 0.1.0
+version: 0.2.0
 release: experimental
 description: Google Cloud Platform (GCP) Integration
 type: integration
@@ -17,7 +17,7 @@ categories:
   - network
   - security
 conditions:
-  kibana.version: ^7.12.0
+  kibana.version: ^7.14.0
 screenshots:
   - src: /img/filebeat-gcp-audit.png
     title: filebeat gcp audit