[Check Point] Process the packets field in SecureXL format

[ilyannn]

Proposed commit message

The specification at https://support.checkpoint.com/results/sk/sk144192 describes the packets field in the Security Gateway - SecureXL Fields section as the tuple of

• Source IP address
• Source Port
• Destination IP address
• Destination Port
• Protocol Number

The current pipeline, however, parses the packets field as an integer, handling only the format described in the Security Gateway - Firewall Fields section. When this field comes as defined in the SecureXL section – a string describing the dropped packets – the current pipeline fails.

In practice the tuple can also contain an additional member denoting the network interface.

This PR adds the parsing to the pipeline. The result is an array of json objects, each structured according to the ECS, that is:

"packets_dropped" => [{
    "source": {
        "ip": ...
        "port": ...
    },
    "destination": {
        "ip": ...
        "port": ...
    },
    "network": {
        "iana_number": ...
    },
    "interface": {
        "name": ...
    }
}, ...]

We handle both the case when the interface name is present (as in practice) and when it's not (as per specification). The added group is defined as nested to preserve the relationships within each tuple.

The parsing is implemented as a Painless script; alternative approaches were tried, but were not ultimately successful.

Screenshot

From the specification:

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

Author's Checklist

• Add test cases for the new functionality
• Use the hashes on the processor's tag

How to test this PR locally

GenAI Note

Cursor with the Claude Opus 4.5 model was used in creating this PR's contents, especially the Painless script.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 0f68a67

cc @ilyannn

[P1llus]

Do we have any sample data (anonymized) we can add to the pipeline test?

[P1llus]

It would be preferred if we could use a common processor to parse this out, as script regex is quite heavy, was this the only way? looking at the data I guess it does seem like that, but its quite troublesome for performance reasons

[P1llus]

Just leaving it as a note rather than something that needs to be resolved, nested types are something we do try to avoid as much as possible, but at this point I am unsure about any other better alternative

[P1llus]

I am a bit unsure but it could be startsWith is better performance wise, though if the only times this is a string is when it is the SecureXL format it might be okay.
If we had sample data we could see if there was an already parsed field that showcases that it's SecureXL type data so we wouldn't need to use either