[akamai] Add Support for Identity Fields from SIEM Events

[mohitjha-elastic]

Proposed commit message

akamai: add support for identity fields in SIEM events

This change adds support for ingesting identity fields from Akamai SIEM events.
The new fields are parsed and mapped to the appropriate schema to provide additional
identity context for the 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

How to test this PR locally

• Clone integrations repo.
• Install the elastic package locally.
• Start the elastic stack using the elastic package.
• Move to integrations/packages/akamai directory.
• Run the following command to run tests.

elastic-package test -v

Related Issues

• Closes [ Akamai SIEM ] Identity fields are not being parsed. #17728

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[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: 🔵 Low confidence: medium path: packages/akamai/data_stream/siem/fields/fields.yml:114

Blank separator lines in the new identity field block contain trailing whitespace; remove it so elastic-package format/check does not rewrite the file.

Details

The added identity group inserts blank lines that are not empty but contain trailing spaces (after the ja4 and tls_fingerprint_v2 entries). elastic-package format normalizes these away, so committing them as-is can cause a format/lint diff in CI. Purely cosmetic, but it keeps the file from being format-clean.

Recommendation:

Make the separator lines truly empty (no trailing spaces):

    - name: identity
      type: group
      fields:
        - name: ja4
          type: keyword
          description: A JA4 TLS client fingerprint value.

        - name: tls_fingerprint_v2
          type: keyword
          description: A client TLS fingerprint V2 value.

        - name: tls_fingerprint_v3
          type: keyword
          description: A client TLS fingerprint V3 value.

---

🤖 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 e4e119b — 1 low

• 🔵 Blank separator lines in the new identity field block contain trailing whitespace (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: e4e119b

cc @mohitjha-elastic

[efd6]

I'm wondering why we're not putting the json processor's result directly into akamai.siem directly; this would mean that if the API changes the fields that it provides, we just naturally follow. This is fine, but we'd need to do less work in future if we just followed the API.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[mohitjha-elastic]

I'm wondering why we're not putting the json processor's result directly into akamai.siem directly; this would mean that if the API changes the fields that it provides, we just naturally follow. This is fine, but we'd need to do less work in future if we just followed the API.

I agree that populating the JSON processor output directly would reduce the maintenance effort, as any new fields introduced by the API would be ingested automatically without requiring additional mapping changes.

The trade-off is only that we would have less control over the schema and field mappings. However, I think the reduced maintenance and automatic adoption of new fields outweigh those concerns.

[elastic-vault-github-plugin-prod]

Package akamai - 3.2.0 containing this change is available at https://epr.elastic.co/package/akamai/3.2.0/