From b524930a0b0e36dbf50d5093b886481e5f296cd6 Mon Sep 17 00:00:00 2001 From: Roberto Seldner Date: Tue, 14 Jan 2025 11:11:44 -0700 Subject: [PATCH 1/7] Update rules-ui-create.asciidoc - Note fallback behavior in timestamp overrides Explicitly state the fallback behavior on timestamp overrides. --- docs/detections/rules-ui-create.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index 2302d127d9..05c5b95868 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -587,7 +587,7 @@ Suricata, selecting `event.action` lets you see what action (Suricata category) caused the event directly in the Alerts table. + NOTE: For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. -.. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this avoids missing alerts due to ingestion delays. +.. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this avoids missing alerts due to ingestion delays. The query will fallback to `@timestamp` if the selected field is unavailable. However, if you know your data source has an inaccurate `@timestamp` value, it is recommended you select the *Do not use @timestamp as a fallback timestamp field* option to ignore the `@timestamp` field entirely. + TIP: The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and From 4425bcaf4cb8973fb3ba24af8af2e15c27ad4b12 Mon Sep 17 00:00:00 2001 From: "nastasha.solomon" Date: Wed, 15 Jan 2025 14:02:45 -0500 Subject: [PATCH 2/7] Serverless updates --- docs/serverless/rules/rules-ui-create.asciidoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/serverless/rules/rules-ui-create.asciidoc b/docs/serverless/rules/rules-ui-create.asciidoc index 736ea49017..fb0b3660fe 100644 --- a/docs/serverless/rules/rules-ui-create.asciidoc +++ b/docs/serverless/rules/rules-ui-create.asciidoc @@ -620,8 +620,9 @@ caused the event directly in the Alerts table. ==== For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. ==== -.. **Timestamp override** (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this avoids missing alerts due to ingestion delays. -However, if you know your data source has an inaccurate `@timestamp` value, it is recommended you select the **Do not use @timestamp as a fallback timestamp field** option to ignore the `@timestamp` field entirely. +.. **Timestamp override** (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. ++ +If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. + [TIP] ==== From 0fefc4be2b5b8c2537d0ed63e2e70f899eae305c Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Wed, 15 Jan 2025 14:50:48 -0500 Subject: [PATCH 3/7] Update docs/detections/rules-ui-create.asciidoc --- docs/detections/rules-ui-create.asciidoc | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index 05c5b95868..c674a86990 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -587,7 +587,9 @@ Suricata, selecting `event.action` lets you see what action (Suricata category) caused the event directly in the Alerts table. + NOTE: For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. -.. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this avoids missing alerts due to ingestion delays. The query will fallback to `@timestamp` if the selected field is unavailable. +.. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. ++ +If the selected field is unavailable, the rule query will use the `@timestamp` field instead. However, if you know your data source has an inaccurate `@timestamp` value, it is recommended you select the *Do not use @timestamp as a fallback timestamp field* option to ignore the `@timestamp` field entirely. + TIP: The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and From d54d2eb8eeb3d748f46de21a3572df7377691270 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Wed, 15 Jan 2025 15:34:51 -0500 Subject: [PATCH 4/7] Update docs/detections/rules-ui-create.asciidoc --- docs/detections/rules-ui-create.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index c674a86990..d4b0fc5a40 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -590,7 +590,7 @@ NOTE: For threshold rules, not all source event values can be used for overrides .. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. + If the selected field is unavailable, the rule query will use the `@timestamp` field instead. -However, if you know your data source has an inaccurate `@timestamp` value, it is recommended you select the *Do not use @timestamp as a fallback timestamp field* option to ignore the `@timestamp` field entirely. +In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. + TIP: The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and {filebeat-ref}/filebeat-module-google_workspace.html[Google Workspace] {filebeat} modules have an `event.ingested` timestamp field that can be used instead of the default `@timestamp` field. From 6420163944944d41f662bf1c5c7660182649da8f Mon Sep 17 00:00:00 2001 From: "nastasha.solomon" Date: Wed, 15 Jan 2025 15:36:34 -0500 Subject: [PATCH 5/7] formatting fix --- docs/detections/rules-ui-create.asciidoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index d4b0fc5a40..f9d5aebe4f 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -589,8 +589,7 @@ caused the event directly in the Alerts table. NOTE: For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. .. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. + -If the selected field is unavailable, the rule query will use the `@timestamp` field instead. -In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. +If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. + TIP: The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and {filebeat-ref}/filebeat-module-google_workspace.html[Google Workspace] {filebeat} modules have an `event.ingested` timestamp field that can be used instead of the default `@timestamp` field. From 2bbe7c8c9df3086e1a3b9c1bc40928c887337965 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Tue, 21 Jan 2025 13:25:30 -0500 Subject: [PATCH 6/7] Update docs/detections/rules-ui-create.asciidoc Co-authored-by: Yara Tercero --- docs/detections/rules-ui-create.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/detections/rules-ui-create.asciidoc b/docs/detections/rules-ui-create.asciidoc index f9d5aebe4f..fc626627a7 100644 --- a/docs/detections/rules-ui-create.asciidoc +++ b/docs/detections/rules-ui-create.asciidoc @@ -589,7 +589,7 @@ caused the event directly in the Alerts table. NOTE: For threshold rules, not all source event values can be used for overrides; only the fields that were aggregated over (the `Group by` fields) will contain data. .. *Timestamp override* (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. + -If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. +If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `@timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. + TIP: The {filebeat-ref}/filebeat-module-microsoft.html[Microsoft] and {filebeat-ref}/filebeat-module-google_workspace.html[Google Workspace] {filebeat} modules have an `event.ingested` timestamp field that can be used instead of the default `@timestamp` field. From 239f477423298349274caf0cc63959b5de3663ea Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Tue, 21 Jan 2025 13:25:44 -0500 Subject: [PATCH 7/7] Update docs/serverless/rules/rules-ui-create.asciidoc Co-authored-by: Yara Tercero --- docs/serverless/rules/rules-ui-create.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/serverless/rules/rules-ui-create.asciidoc b/docs/serverless/rules/rules-ui-create.asciidoc index fb0b3660fe..f5f0468141 100644 --- a/docs/serverless/rules/rules-ui-create.asciidoc +++ b/docs/serverless/rules/rules-ui-create.asciidoc @@ -622,7 +622,7 @@ For threshold rules, not all source event values can be used for overrides; only ==== .. **Timestamp override** (optional): Select a source event timestamp field. When selected, the rule's query uses the selected field, instead of the default `@timestamp` field, to search for alerts. This can help reduce missing alerts due to network or server outages. Specifically, if your ingest pipeline adds a timestamp when events are sent to {es}, this can prevent missing alerts from ingestion delays. + -If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. +If the selected field is unavailable, the rule query will use the `@timestamp` field instead. In the case that you don't want to use the `@timestamp` field because you know your data source has an inaccurate `@timestamp` value, we recommend selecting the **Do not use @timestamp as a fallback timestamp field** option instead. This will ensure that the rule query ignores the `@timestamp` field entirely. + [TIP] ====