[cisco_ftd] Fix 111008/111009 grok to handle usernames with spaces.

[ie-ops]

Executive summary

The fix changes two grok patterns for message IDs 111008 and 111009 in the Cisco FTD ingest pipeline, replacing %{NOTSPACE:server.user.name} with %{DATA:server.user.name}. The NOTSPACE pattern only matches non-whitespace characters, causing it to fail when usernames contain spaces (e.g., example-service account). Switching to DATA (which matches any character including spaces, stopping at the next literal delimiter) allows the pipeline to correctly capture multi-word usernames enclosed in single quotes.

Proposed commit message

[cisco_ftd] Fix 111008/111009 grok to handle usernames with spaces.

Root cause

The grok patterns for message IDs 111008 and 111009 in grok_message_e6caac62 use %{NOTSPACE:server.user.name} to extract the username from a single-quoted token, but usernames containing whitespace (e.g. example-service account) cause NOTSPACE to fail immediately, making the processor report a grok failure. The fix is to use %{DATA:server.user.name} since the surrounding single quotes already act as the capture boundary.

Approach

In the grok processor tagged grok_message_e6caac62 (pipeline line ~405–411), both patterns use %{NOTSPACE:server.user.name} to capture the username between single quotes, but %{NOTSPACE} refuses to match a username like example-service account that contains a space. Replace %{NOTSPACE:server.user.name} with %{DATA:server.user.name} in both patterns so the match is bounded by the surrounding single-quote literals instead. Add the sanitized event as a new pipeline test fixture and update the expected output.

Implementation

1. Step 1: Edit packages/cisco_ftd/data_stream/log/elasticsearch/ingest_pipeline/default.yml — in the grok processor tagged grok_message_e6caac62 (lines ~404–411), change both occurrences of %{NOTSPACE:server.user.name} to %{DATA:server.user.name}. Pattern 1 becomes: ^%{NOTSPACE} '%{DATA:server.user.name}' executed %{NOTSPACE} %{GREEDYDATA:_temp_.cisco.command_line_arguments}. Pattern 2 becomes: ^%{NOTSPACE} '%{DATA:server.user.name}' executed the '%{DATA}' command.
2. Step 2: Add the sanitized event to packages/cisco_ftd/data_stream/log/_dev/test/pipeline/test-ftd-fix.log as a new line: <181>Jul 7 14:12:01 198.51.100.10 %FTD-5-111008: User 'example-service account' executed the 'show running-config zero-trust' command.
3. Step 3: Add the corresponding expected document to packages/cisco_ftd/data_stream/log/_dev/test/pipeline/test-ftd-fix.log-expected.json — include server.user.name: 'example-service account', event.code: '111008', related.user: ['example-service account'], and the correct syslog fields parsed from the header.
4. Step 4: Bump the patch version in packages/cisco_ftd/manifest.yml from 3.13.4 to 3.13.5.
5. Step 5: Prepend a new changelog entry to packages/cisco_ftd/changelog.yml for version 3.13.5 with type bugfix describing the fix for usernames containing spaces in 111008/111009 messages.
6. Step 6: Run elastic-package test pipeline against the cisco_ftd package to confirm the new fixture passes and no existing fixtures regress.

Pipeline changes

• Modify grok processor grok_message_e6caac62 (message IDs 111008, 111009): change %{NOTSPACE:server.user.name} to %{DATA:server.user.name} in both alternative patterns so that usernames containing spaces are correctly captured within their enclosing single quotes.

Field / mapping changes

—

Sanitized error message

Processor 'grok' with tag 'grok_message_e6caac62' in pipeline 'logs-cisco_ftd.log-default' failed with message '[on_failure_message]'

Sanitized log (event_sanitized excerpt)

<181>Jul  7 14:12:01 198.51.100.10 %FTD-5-111008: User 'example-service account' executed the 'show running-config zero-trust' command.

Reviewer concerns

• The second pattern (executed the '%{DATA}' command) does not capture the command into any field; if capturing that argument is desired, it should be added to both patterns consistently.
• %{DATA} is greedy up to the next literal anchor — the surrounding single-quote delimiters act as the stop, so this should be safe, but reviewers should confirm no pathological inputs exist where the closing quote is missing or escaped.
• The test fixture only covers message ID 111008; a similar test case for 111009 would increase confidence.

Self-review findings

—

Risk and classification

• Plan risk level: low
• Tags: pipeline, processors, test-fixture, ingest
• Impact: medium

Links

• Issue: (no issue number)
• Issue title: cisco_ftd.log: Processor 'grok' with tag 'grok_message_e6caac62' in pipeline 'logs-cisc…
• Pipeline case: 394498904ab18c7a

[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.

[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: 099943c