diff --git a/packages/cisco_duo/changelog.yml b/packages/cisco_duo/changelog.yml index 9a2c19a3353..982927f4e03 100644 --- a/packages/cisco_duo/changelog.yml +++ b/packages/cisco_duo/changelog.yml @@ -1,4 +1,9 @@ # newer versions go on top +- version: "1.1.3" + changes: + - description: Add mapping for event.created. + type: bugfix + link: https://github.com/elastic/integrations/pull/3021 - version: "1.1.2" changes: - description: Make fields agree with ECS diff --git a/packages/cisco_duo/data_stream/admin/fields/ecs.yml b/packages/cisco_duo/data_stream/admin/fields/ecs.yml index 24292905a8c..63f54f60c26 100644 --- a/packages/cisco_duo/data_stream/admin/fields/ecs.yml +++ b/packages/cisco_duo/data_stream/admin/fields/ecs.yml @@ -6,6 +6,8 @@ name: event.action - external: ecs name: event.category +- external: ecs + name: event.created - external: ecs name: event.kind - external: ecs diff --git a/packages/cisco_duo/data_stream/auth/fields/ecs.yml b/packages/cisco_duo/data_stream/auth/fields/ecs.yml index 4535de0d2b2..0472838691a 100644 --- a/packages/cisco_duo/data_stream/auth/fields/ecs.yml +++ b/packages/cisco_duo/data_stream/auth/fields/ecs.yml @@ -4,6 +4,8 @@ name: event.agent_id_status - external: ecs name: event.category +- external: ecs + name: event.created - external: ecs name: event.kind - external: ecs diff --git a/packages/cisco_duo/data_stream/offline_enrollment/fields/ecs.yml b/packages/cisco_duo/data_stream/offline_enrollment/fields/ecs.yml index 43ef3e68731..1ea7f82f877 100644 --- a/packages/cisco_duo/data_stream/offline_enrollment/fields/ecs.yml +++ b/packages/cisco_duo/data_stream/offline_enrollment/fields/ecs.yml @@ -1,5 +1,7 @@ - external: ecs name: ecs.version +- external: ecs + name: event.created - external: ecs name: event.original - external: ecs diff --git a/packages/cisco_duo/data_stream/summary/fields/ecs.yml b/packages/cisco_duo/data_stream/summary/fields/ecs.yml index 398eb94ea09..b334910e040 100644 --- a/packages/cisco_duo/data_stream/summary/fields/ecs.yml +++ b/packages/cisco_duo/data_stream/summary/fields/ecs.yml @@ -1,5 +1,7 @@ - external: ecs name: ecs.version +- external: ecs + name: event.created - external: ecs name: event.original - external: ecs diff --git a/packages/cisco_duo/data_stream/telephony/fields/ecs.yml b/packages/cisco_duo/data_stream/telephony/fields/ecs.yml index f669654daee..a24c00497b5 100644 --- a/packages/cisco_duo/data_stream/telephony/fields/ecs.yml +++ b/packages/cisco_duo/data_stream/telephony/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/cisco_duo/docs/README.md b/packages/cisco_duo/docs/README.md index 9b06cef419a..b057d707233 100644 --- a/packages/cisco_duo/docs/README.md +++ b/packages/cisco_duo/docs/README.md @@ -116,6 +116,7 @@ An example event for `admin` looks as following: | 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.agent_id_status | Agents are normally responsible for populating the `agent.id` field value. If the system receiving events is capable of validating the value based on authentication information for the client then this field can be used to reflect the outcome of that validation. For example if the agent's connection is authenticated with mTLS and the client cert contains the ID of the agent to which the cert was issued then the `agent.id` value in events can be checked against the certificate. If the values match then `event.agent_id_status: verified` is added to the event, otherwise one of the other allowed values should be used. If no validation is performed then the field should be omitted. The allowed values are: `verified` - The `agent.id` field value matches expected value obtained from auth metadata. `mismatch` - The `agent.id` field value does not match the expected value obtained from auth metadata. `missing` - There was no `agent.id` field in the event to validate. `auth_metadata_missing` - There was no auth metadata or it was missing information about the agent ID. | 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 | @@ -358,6 +359,7 @@ An example event for `auth` looks as following: | 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.agent_id_status | Agents are normally responsible for populating the `agent.id` field value. If the system receiving events is capable of validating the value based on authentication information for the client then this field can be used to reflect the outcome of that validation. For example if the agent's connection is authenticated with mTLS and the client cert contains the ID of the agent to which the cert was issued then the `agent.id` value in events can be checked against the certificate. If the values match then `event.agent_id_status: verified` is added to the event, otherwise one of the other allowed values should be used. If no validation is performed then the field should be omitted. The allowed values are: `verified` - The `agent.id` field value matches expected value obtained from auth metadata. `mismatch` - The `agent.id` field value does not match the expected value obtained from auth metadata. `missing` - There was no `agent.id` field in the event to validate. `auth_metadata_missing` - There was no auth metadata or it was missing information about the agent ID. | 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 | @@ -506,6 +508,7 @@ An example event for `offline_enrollment` 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.module | Event module | constant_keyword | | event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from `_source`. If users wish to override this and index this field, please see `Field data types` in the `Elasticsearch Reference`. | keyword | @@ -614,6 +617,7 @@ An example event for `summary` 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.module | Event module | constant_keyword | | event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from `_source`. If users wish to override this and index this field, please see `Field data types` in the `Elasticsearch Reference`. | keyword | @@ -721,6 +725,7 @@ An example event for `telephony` 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 | diff --git a/packages/cisco_duo/manifest.yml b/packages/cisco_duo/manifest.yml index 2287682fcfe..cef105ff204 100644 --- a/packages/cisco_duo/manifest.yml +++ b/packages/cisco_duo/manifest.yml @@ -1,7 +1,7 @@ format_version: 1.0.0 name: cisco_duo title: Cisco Duo -version: 1.1.2 +version: 1.1.3 license: basic description: Collect logs from Cisco Duo with Elastic Agent. type: integration