[stormshield] Add outcome, identity and HTTP mappings and extend the metadata allow-list by arenard · Pull Request #20085 · elastic/integrations

arenard · 2026-07-10T13:05:43Z

Proposed commit message

Derive event.outcome on the auth, server and xvpn families from the vendor error return code (0 maps to success, other codes to failure). The official field documentation lists exactly these three families for error; on vpn logs the same key is a severity level and is left untouched. The vendor documentation pairs 0-first numeric examples with Success-first display labels without stating the convention outright, so the mapping follows the strong implication of the field tables.

Map domain to user.domain and usergroup to user.group.name, splitting the comma-separated multi-valued form that SNS 5.x emits. On web logs, map op to http.request.method and result to http.response.status_code; on other families these keys carry protocol-specific codes (FTP, Modbus) and are not promoted. Map the module name in service to process.name on the system, sandboxing and routing families only — on pvm logs the same key names the vulnerable product detected on a scanned host. Set observer.product. All mappings are copies; the vendor keys remain available under stormshield.metadata.

Extend the stormshield.metadata allow-list with the documented vendor keys that previously leaked as undeclared stormshield.* fields: host and IP reputation (srchostrep, dsthostrep, srciprep, dstiprep), alarm packet captures (pktlen, pktdump, pktdumplen), Ethernet protocol (etherproto), SSO agent (agentid), IKE peer name (peername), and the industrial-protocol plugin fields (unitid/unit_id, cipservicecode, cipclassid, requestmode, responsemode, UI, error_class, error_code, format).

The NAT reading of the pipeline was verified against the official field tables while preparing this change: origdst/origdstport are documented as the destination before translation and map to destination.ip/destination.port; dst is the translated destination and maps to destination.nat.ip when it differs. A connection sample with the documented example values now locks this in the pipeline tests, alongside new samples for the alarm reputation and packet-capture fields, a Modbus plugin line (whose result stays under metadata and does not produce http.*), a server line, a system line, and multi- and single-valued usergroup forms.

Design notes

Field semantics all come from the official "Description of Audit logs" guides (v3, v4 and v5 field tables were cross-checked; the v4/v5 Affected logs lists drive the family guards). The alarm class sub-categorization was deliberately left out: the documentation gives example values without an exhaustive list or definitions.
event.outcome is only set where the log reports a return code, never inferred from message text.
Like the 1.6.0 changes, everything is additive: no stormshield.* field changes location or type, so existing dashboards and saved queries are unaffected.

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.

Author's Checklist

elastic-package check, test pipeline, test static and test system pass against stack 9.4.3
New pipeline test samples are synthesized from the field example values published in the official audit-log documentation, with addresses in RFC 1918/5737 ranges
The promotions are guarded by log family wherever the vendor documents family-dependent semantics (result, service, error)

How to test this PR locally

cd packages/stormshield
elastic-package check
elastic-package test pipeline
elastic-package stack up -d
elastic-package test system

Related issues

Relates [stormshield] Follow-up tasks for new integration #10114
Requires [stormshield] Fix pipeline descriptions and correct documentation claims #20030 and [stormshield] Add ECS event categorization and network mappings #20031 (the branch is stacked on them; will be rebased as they merge)

Fix the copy-pasted descriptions of the default and count ingest pipelines, remove field definitions that never appear in events (the pipeline consumes tz into event.timezone, converts duration into event.duration, renames msg to message, and drops origdst/origdstport after converting them to destination fields), and correct the documentation: the agent syslog processor is configured for RFC5424, so the README no longer presents the Legacy format as supported, and the compatibility section now covers SNS 4.x and 5.x, which share the same WELF key-value audit log format. Also document how to collect SNS IPFIX flow records with the NetFlow integration, update vendor links to the SNS v5 documentation, and use arrows for menu paths per the documentation style guide.

github-actions · 2026-07-10T13:08:01Z

✅ 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 · 2026-07-10T13:29:41Z

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

infra-vault-gh-plugin-prod · 2026-07-10T20:00:46Z

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

vera-review-bot · 2026-07-10T20:24:05Z

+| connection | event | network, session | connection, end |
+| count, filterstat, ipsecstat, routerstat | metric | network | info |
+| date | event | host | change |
+| dmrouting, routing | event | network | change |


Severity: 🔵 Low confidence: high path: packages/stormshield/_dev/build/docs/README.md:222

The categorization table lists event.category network for dmrouting/routing, but the pipeline sets network, host; update the table row to match.

Details

The ECS categorization table documents the dmrouting, routing families as event.category: network. The pipeline's categorization script (data_stream/log/elasticsearch/ingest_pipeline/default.yml) maps both dmrouting and routing to category: [network, host] (kind event, type change). Every other row in the table matches the pipeline; this row is the only discrepancy, so a reader relying on the docs to build queries/filters on event.category for routing events would get an incomplete picture. The generated docs/README.md (line 285) carries the same error; fixing the template here regenerates it.

Recommendation:

Update the table row so the documented category matches the pipeline (category: [network, host]):

| dmrouting, routing | event | network, host | change |

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

⚠️ Automated review — verify suggestions before applying.

Right — the pipeline was changed to network, host for these two families during an ECS expected-combination review, and the table row was missed. Fixed at the source: the row now reads network, host (amended in #20031, which owns this content; this branch has been rebased on it).

vera-review-bot · 2026-07-10T20:24:05Z

+  changes:
+    - description: Set ECS event categorization fields (`event.kind`, `event.category`, `event.type`) for every log family, including `event.kind` `metric` for the periodic statistics families.
+      type: enhancement
+      link: https://github.com/elastic/integrations/pull/20031


Severity: 🟡 Medium confidence: high path: packages/stormshield/changelog.yml:14

Changelog links a different PR number

Details

This changelog entry's link: points at pull/20031, but it was added in PR #20085. It is likely a leftover template placeholder or a copy from another PR.

Recommendation:

Point the changelog link at this PR:

link: https://github.com/elastic/integrations/pull/20085

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

⚠️ Automated review — verify suggestions before applying.