diff --git a/packages/tenable_sc/changelog.yml b/packages/tenable_sc/changelog.yml index 16fca591289..4120c917ee0 100644 --- a/packages/tenable_sc/changelog.yml +++ b/packages/tenable_sc/changelog.yml @@ -1,4 +1,9 @@ # newer versions go on top +- version: "1.2.1" + changes: + - description: Add mapping for `event.created` + type: bugfix + link: https://github.com/elastic/integrations/pull/3568 - version: "1.2.0" changes: - description: Update to ECS 8.2 diff --git a/packages/tenable_sc/data_stream/asset/fields/ecs.yml b/packages/tenable_sc/data_stream/asset/fields/ecs.yml index 2ab085a53d2..94317a5fa34 100644 --- a/packages/tenable_sc/data_stream/asset/fields/ecs.yml +++ b/packages/tenable_sc/data_stream/asset/fields/ecs.yml @@ -2,6 +2,8 @@ name: ecs.version - external: ecs name: event.category +- external: ecs + name: event.created - external: ecs name: event.kind - external: ecs diff --git a/packages/tenable_sc/data_stream/plugin/fields/ecs.yml b/packages/tenable_sc/data_stream/plugin/fields/ecs.yml index 2a59524e0fa..7a3785b3f8e 100644 --- a/packages/tenable_sc/data_stream/plugin/fields/ecs.yml +++ b/packages/tenable_sc/data_stream/plugin/fields/ecs.yml @@ -1,5 +1,7 @@ - external: ecs name: ecs.version +- external: ecs + name: event.created - external: ecs name: event.kind - external: ecs diff --git a/packages/tenable_sc/data_stream/vulnerability/fields/ecs.yml b/packages/tenable_sc/data_stream/vulnerability/fields/ecs.yml index 4634b2e8bd8..b5f451523da 100644 --- a/packages/tenable_sc/data_stream/vulnerability/fields/ecs.yml +++ b/packages/tenable_sc/data_stream/vulnerability/fields/ecs.yml @@ -2,6 +2,8 @@ name: ecs.version - external: ecs name: event.category +- external: ecs + name: event.created - external: ecs name: event.kind - external: ecs diff --git a/packages/tenable_sc/docs/README.md b/packages/tenable_sc/docs/README.md index 23a16d1700d..da917569f26 100644 --- a/packages/tenable_sc/docs/README.md +++ b/packages/tenable_sc/docs/README.md @@ -160,6 +160,7 @@ An example event for `asset` looks as following: | data_stream.type | Data stream type. | constant_keyword | | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword | | event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword | +| event.created | 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. | date | | event.dataset | Event dataset | constant_keyword | | event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | event.module | Event module | constant_keyword | @@ -395,6 +396,7 @@ An example event for `plugin` looks as following: | data_stream.namespace | Data stream namespace. | constant_keyword | | data_stream.type | Data stream type. | constant_keyword | | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword | +| event.created | 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. | date | | event.dataset | Event dataset | constant_keyword | | event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | event.module | Event module | constant_keyword | @@ -710,6 +712,7 @@ An example event for `vulnerability` looks as following: | data_stream.type | Data stream type. | constant_keyword | | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword | | event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword | +| event.created | 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. | date | | event.dataset | Event dataset | constant_keyword | | event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword | | event.module | Event module | constant_keyword | diff --git a/packages/tenable_sc/manifest.yml b/packages/tenable_sc/manifest.yml index d480adc168b..6da0016d368 100644 --- a/packages/tenable_sc/manifest.yml +++ b/packages/tenable_sc/manifest.yml @@ -2,7 +2,7 @@ format_version: 1.0.0 name: tenable_sc title: Tenable.sc # The version must be updated in the pipeline as well. Until elastic/kibana#121310 is implemented we will have to manually sync these. -version: 1.2.0 +version: 1.2.1 license: basic description: | Collect logs from Tenable.sc with Elastic Agent.