[Tuning] Elastic Defend and Email Alerts Correlation (#5459)

* [Tuning] Elastic Defend and Email Alerts Correlation

this rule uses the logs-* generic index, which causes failures on clusters without an email related integration with `destination.user.name` populated.  for now limiting the rule to checkpoint email security and we can add more or users can customize it by adding more indexes.

* add checkpoint_email manifest and schema

* Update pyproject.toml

* Update multiple_alerts_email_elastic_defend_correlation.toml

(cherry picked from commit 6ac69db)

Author: Samirbous

detection_rules/etc/integration-manifests.json.gz

@@ -1,6 +1,6 @@
 [project]
 name = "detection_rules"
-version = "1.5.22"
+version = "1.5.23"
 description = "Detection Rules is the home for rules used by Elastic Security. This repository is used for the development, maintenance, testing, validation, and release of rules for Elastic Security’s Detection Engine."
 readme = "README.md"
 requires-python = ">=3.12"

detection_rules/etc/integration-schemas.json.gz

@@ -1,7 +1,8 @@
 [metadata]
 creation_date = "2025/11/19"
+integration = ["endpoint", "checkpoint_email"]
 maturity = "production"
-updated_date = "2025/11/19"
+updated_date = "2025/12/15"
 
 [rule]
 author = ["Elastic"]
@@ -22,14 +23,15 @@ tags = [
     "Rule Type: Higher-Order Rule",
     "Resources: Investigation Guide",
     "Data Source: Elastic Defend",
+    "Data Source: Check Point Harmony Email & Collaboration",
     "Domain: Email",
     "Domain: Endpoint"
 ]
 timestamp_override = "event.ingested"
 type = "esql"
 
 query = '''
-from logs-* metadata _id
+from logs-endpoint.alerts-*, logs-checkpoint_email.event-* metadata _id
 // Email or Elastic Defend alerts where user name is populated
 | where
   (event.category == "email" and event.kind == "alert" and destination.user.name is not null) or