[checkpoint] Update setting of event.kind and event.outcome - #20341
Conversation
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.
mjwolf
added
Integration:checkpoint
|
Pinging @elastic/integration-experience (Team:Integration-Experience) |
✅ 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. |
![vera-review-bot[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/3297022?s=60&v=4){kind=small}
🚀 Benchmarks reportTo see the full report comment with |
taylor-swanson
left a comment
taylor-swanson
left a comment
There was a problem hiding this comment.
Changes seem fine to me.
Echoing the bot's comments, should we add the same logic to processors set_event_outcome_e1548f1e and append_event_type_c2ef1ab7 as well?
…processors Apply the same rule_action == null && action fallback to the Accept/Allow event.outcome and event.type processors that was already applied to the Drop/Reject/Block/Prevent path, so allowed events without rule_action are categorized symmetrically with denied events. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
✅ All changelog entries have the correct PR link. |
| <134>1 2025-01-21T09:37:10Z TEST_HOSTNAME CheckPoint 16953 - [action:"Drop"; flags:"409600"; ifdir:"inbound"; logid:"0"; loguid:"{0x5e818e17,0x1,0x6401a8c0,0x108620ab}"; origin:"192.168.1.100"; originsicname:"cn=cp_mgmt,o=gw-da58d3..tmn8s8"; sequencenum:"2"; time:"1737452230"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={880771B0-FD92-2C4F-82FC-B96FC3DE5A07};mgmt=gw-da58d3;date=1585502566;policy_name=Standard\]"; drop_reason:"matched optimized drop"; layer_name:"Network"; layer_uuid:"63b7fe60-76d2-4287-bca5-21af87337b0a"; match_id:"1"; parent_rule:"0"; rule_action:"Drop"; rule_name:"Cleanup rule"; rule_uid:"1fde807b-6300-4b1a-914f-f1c1f3e2e7d2"; packet_amount:"3"; packets:" <81.2.69.142,45000,81.2.69.144,443,6> <81.2.69.142,45001,89.160.20.128,80,17> <81.2.69.142,45002,81.2.69.144,8080,6>"] | ||
| <134>1 2025-11-19T01:36:02Z TEST_HOSTNAME CheckPoint 16953 - [action:"Drop"; flags:"409600"; ifdir:"inbound"; logid:"0"; loguid:"{0x1816caef, 0x1,0x6401a8c0,0x108620ab}"; origin:"192.168.1.100"; originsicname:"CN=fw,O=fmmt.domain.com.tmn8s8"; sequencenum:"3"; time:"1763516162"; version:"5"; packet_amount:"5"; packets:"(sample only) <81.2.69.142,59912,81.2.69.144,1990,6;bond12> <81.2.69.142,40252,81.2.69.144,999,6;bond12> <81.2.69.142,60636,89.160.20.128,999,6;bond12> <81.2.69.142,43010,89.160.20.128,1898,6;bond12> <81.2.69.142,59440,81.2.69.144,1898,6;bond12>";] | ||
| <134>1 2025-03-31T09:45:12Z FW-RANDOM CheckPoint 98765 - [action:"Drop"; flags:"409600"; ifdir:"inbound"; logid:"0"; loguid:"{0xa1b2c3d4,0xe5f67890,0x12345678,0xabcdef12}"; origin:"192.168.45.23"; originsicname:"CN=FWSC-RANDOM,O=TMUK_SDMZ_RANDOM.oam.example.com.abcd12"; sequencenum:"112"; time:"1743414312"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={F1234567-89AB-CDEF-0123-456789ABCDEF};mgmt=TMUK_SDMZ_RANDOM;date=1742477474;policy_name=Standard\\]"; drop_reason:"matched optimized drop"; layer_name:"Network"; layer_uuid:"123e4567-e89b-12d3-a456-426614174000"; match_id:"8"; parent_rule:"0"; rule_action:"Drop"; rule_uid:"abcdef12-3456-7890-abcd-ef1234567890"; packet_amount:"5"; packets:" <203.0.113.45,54321,198.51.100.23,12345,6;bond1.3> <203.0.113.46,23456,198.51.100.24,34567,6;bond1.3> <203.0.113.47,45678,198.51.100.25,56789,6;bond1.3> <203.0.113.48,67890,198.51.100.26,78901,6;bond1.3> <203.0.113.49,89012,198.51.100.27,90123,6;bond1.3>"; product:"VPN-1 & FireWall-1"; proto:"6"] | ||
| <134>1 2026-03-31T06:49:33.170Z TEST_HOSTNAME CheckPoint 31085 - [action:"Drop"; flags:"393216"; ifdir:"inbound"; ifname:"bond1.992"; logid:"1"; loguid:"{0xd82800ab,0xca,0xb384aa9a,0x3331928d}"; origin:"192.168.8.200"; originsicname:"CN=fw,O=example..sdf7da"; sequencenum:"1342"; time:"1743414973170"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={8383ADC5llll0-744C-80D1-6915514EFAD5};mgmt=example;date=1743403451;policy_name=example8\]"; dst:"81.2.69.144"; product:"VPN-1 & FireWall-1"; proto:"6"; s_port:"5223"; service:"49689"; src:"81.2.69.142"; tcp_flags:"ACK"; tcp_packet_out_of_state:"First packet isn't SYN"] |
There was a problem hiding this comment.
Severity: 🔵 Low confidence: high path: packages/checkpoint/data_stream/firewall/_dev/test/pipeline/test-packet-drop.log:5
The added packet-drop sample has a syslog header timestamp (2026-03-31T06:49:33.170Z) that contradicts its own time field (1743414973170 = 2025-03-31T09:56:13.170Z). Align the header with the epoch value.
Details
The RFC 5424 header on this new sample reads 2026-03-31T06:49:33.170Z, while the structured-data time:"1743414973170" decodes to 2025-03-31T09:56:13.170Z — a different year and a different time of day. The pipeline prefers time, which is why the committed test-packet-drop.log-expected.json entry asserts "@timestamp": "2025-03-31T09:56:13.170Z".
The test still passes, but the fixture no longer represents a record a Check Point gateway could emit, which makes it misleading for anyone using it to reason about timestamp handling. The other sample added in the same commit (line 6) is internally consistent: header 2025-11-19T02:10:00Z matches time:"1763518200".
Recommendation:
Make the header agree with the time value the fixture asserts on:
<134>1 2025-03-31T09:56:13.170Z TEST_HOSTNAME CheckPoint 31085 - [action:"Drop"; flags:"393216"; ifdir:"inbound"; ifname:"bond1.992"; logid:"1"; loguid:"{0xd82800ab,0xca,0xb384aa9a,0x3331928d}"; origin:"192.168.8.200"; originsicname:"CN=fw,O=example..sdf7da"; sequencenum:"1342"; time:"1743414973170"; version:"5"; ...]
No change to test-packet-drop.log-expected.json is required — it already expects 2025-03-31T09:56:13.170Z.
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
⚠️ Automated review — verify suggestions before applying.
Review summaryIssues found across the latest commits 7bd7353…1b4b1ae (31 commits) — 1 high, 1 low
Issues found across earlier commits e7a96f3 — 1 medium
🤖 AI-Generated Review | Vera Review Bot | 📚 Knowledge base: integration-skills
|
💚 Build Succeeded
History
cc @mjwolf |
|
Package checkpoint - 1.49.0 containing this change is available at https://epr.elastic.co/package/checkpoint/1.49.0/ |
2 participants
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: Decryptandrule_action: Accept, and unconditionally using checkpoint.action would change the behaviour in existing logs.Checklist
changelog.ymlfile.