[Fortinet] Add support for Fortigate 7.6 events and misc improvements

[dot-mike]

Proposed commit message

Adds definitions for 7.6 event fields
Adds 7.6 events test coverage
Adds event.code mapping to event.action
Improve event.outcome & event.type for failure & error events.

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

• [ ]

How to test this PR locally

Related issues

Screenshots

[elastic-vault-github-plugin-prod]

Reviewers

Buildkite won't run for external contributors automatically; you need to add a comment:

• /test : will kick off a build in Buildkite.

NOTE: https://github.com/elastic/integrations/blob/main/.buildkite/pull-requests.json contains all those details.

[elasticmachine]

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

[andrewkroh]

The change also needs a changelog entry and version bump in manifest.yml. You can use elastic-package changelog add to accomplish this.

[dot-mike]

@andrewkroh done. Thanks!

[andrewkroh]

/test

[andrewkroh]

LGTM.

[andrewkroh]

/test

[andrewkroh]

The CI failure is because the readme needs to be regenerated with the newly added field, so you need to run

elastic-package build

to update it.

[dot-mike]

Done, thanks @andrewkroh ! I learned something new

[macroscopeapp]

🟡 Medium pipeline/test-fortinet-7-6.log-expected.json:798

The last test event (starting at line 798) is missing the @timestamp field while all other 12 events in this file include it. This occurs because the input log entry uses RFC5424 syslog format (<13>1 2026-04-07T12:02:23+02:00 ...) but the Fortigate-specific date= and time= fields are malformed as time=12 - - - 02:22 without a date= field. The test passes because the expected output matches the actual malformed parsing result, but this silently tests corrupted-data handling instead of validating proper 7.6 syslog format parsing. Missing @timestamp causes time-based indexing failures in Elasticsearch.

🤖 Copy this AI Prompt to have your agent fix this:

In file packages/fortinet_fortigate/data_stream/log/_dev/test/pipeline/test-fortinet-7-6.log-expected.json around line 798:

The last test event (starting at line 798) is missing the `@timestamp` field while all other 12 events in this file include it. This occurs because the input log entry uses RFC5424 syslog format (`<13>1 2026-04-07T12:02:23+02:00 ...`) but the Fortigate-specific `date=` and `time=` fields are malformed as `time=12 - - - 02:22` without a `date=` field. The test passes because the expected output matches the actual malformed parsing result, but this silently tests corrupted-data handling instead of validating proper 7.6 syslog format parsing. Missing `@timestamp` causes time-based indexing failures in Elasticsearch.

[dot-mike]

I have one request @andrewkroh
Is it acceptable to rewrite the "event.action" fields for login as well? Today it's just mapped to "login" from https://github.com/dot-mike/elastic-integrations/blob/4da8616fdc19c6dcb057cc773966bbfa77e5f418/packages/fortinet_fortigate/data_stream/log/elasticsearch/ingest_pipeline/login.yml#L8-L12

I would like to set event.action from logid.yml mapping so we get proper action, either success or failed:
https://github.com/dot-mike/elastic-integrations/blob/4da8616fdc19c6dcb057cc773966bbfa77e5f418/packages/fortinet_fortigate/data_stream/log/elasticsearch/ingest_pipeline/logid.yml#L330-L331

I know this may break peoples integration when event.action gets a new value. So this is why I'm asking

[andrewkroh]

That would be a breaking change to modify the existing event.action.

I would not do it in this pull request, but if we wanted to make it consistent, then you can probably do that as a separate breaking-change PR and bump the major version. We should do a bit of research to check the impact, like check the elastic/detection-roles to see if there's anything in there that's already depending on the value. Similarly, check if we have any visualizations or dashboards in the package itself that are dependent upon specific event.action values.

[andrewkroh]

/test

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 4da8616

History

• 💔 Build #40959 failed f2c5f84
• 💔 Build #40895 failed 28bccea

[dot-mike]

That would be a breaking change to modify the existing event.action.

I thought so. Thanks for the clarification. Will revise in the future. For now I will apply this to my @custom pipeline.