[checkpoint] Update setting of event.kind and event.outcome

[mjwolf]

Proposed commit message

Update how event.kind and event.action fields are populated. Previously, they were being set solely on the value of checkpoint.rule_action. There are some cases where checkpoint.rule_action does not have a value, but checkpoint.action does. In these cases the value will be taken from checkpoint.action.

This adds one new testcase, and updates the expected results for several others which should have had event.outcome and event.kind set before.

---

The processor changes are conditional on the non-existence of rule_action, because there are several cases where the contents conflict. For example, these pipeline test logs have action: Decrypt and rule_action: Accept, and unconditionally using checkpoint.action would change the behaviour in existing logs.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

[infra-vault-gh-plugin-prod]

Pinging @elastic/integration-experience (Team:Integration-Experience)

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[vera-review-bot]

Severity: 🟡 Medium confidence: low path: packages/checkpoint/data_stream/firewall/elasticsearch/ingest_pipeline/default.yml:466

The rule_action->action fallback was added to the denied/alert/intrusion_detection paths but not to the parallel Accept/Allow processors, so allowed events lacking checkpoint.rule_action still get no event.outcome or event.type. Extend the same fallback to the Accept/Allow outcome and type processors.

Details

This change adds a ctx.checkpoint?.rule_action == null && [...].contains(ctx.checkpoint?.action) fallback to the Drop/Reject/Block/Prevent outcome, the connection/denied type, the alert kind, and the intrusion_detection category. The mirror processors for allowed traffic were left checking rule_action only: set_event_outcome_e1548f1e (event.outcome=success for Accept/Allow, line 444) and append_event_type_c2ef1ab7 (event.type=[allowed, connection], line 447). For the same class of Check Point logs that carry action but no rule_action (which is exactly the case this PR fixes for drops), an Accept/Allow connection event now gets neither event.outcome nor an allowed/connection event.type, while a denied event does. This leaves allowed and denied events categorized asymmetrically.

Recommendation:

Apply the same action fallback to the Accept/Allow outcome and type processors:

  - set:
      tag: set_event_outcome_e1548f1e
      field: event.outcome
      value: success
      if: "['Accept', 'Allow'].contains(ctx.checkpoint?.rule_action) || (ctx.checkpoint?.rule_action == null && ['Accept', 'Allow'].contains(ctx.checkpoint?.action))"
  - append:
      tag: append_event_type_c2ef1ab7
      field: event.type
      value:
        - allowed
        - connection
      if: "(['Accept', 'Allow'].contains(ctx.checkpoint?.rule_action) || (ctx.checkpoint?.rule_action == null && ['Accept', 'Allow'].contains(ctx.checkpoint?.action))) && (ctx.checkpoint?.operation != 'Log In' && ctx.checkpoint?.operation != 'Log Out')"

If allowed events without rule_action are intentionally out of scope for this PR, consider noting that in the changelog so the asymmetry is a documented decision.

---

🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[vera-review-bot]

Review summary

Issues found across the latest commits e7a96f3 — 1 medium

• 🟡 The rule_action->action fallback was added to the denied/alert/intrusion_detection paths but not to the parallel Accept/Allow processors, so allowed events lacking checkpoint.rule_action still get no event.outcome or event.type. Extend the same fallback to the Accept/Allow outcome and type processors. (link) (Unresolved)

A new commit triggers another review — at most once every 15 minutes. I skip the PR while it's approved or has merge conflicts.

🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: e7a96f3

cc @mjwolf