event.original field should be preserved by ingest pipelines when mapping errors happen

[adoerrES]

• Version: 8.4
• Operating System: All
• Discuss Forum URL: N/A
• Steps to Reproduce:

SUMMARY
When using the Filebeat Cisco ASA module (possibly other modules) there is inconsistent usage about how the newer event.original field gets used during mapping errors, compared to the legacy log.original field it is meant to replace. The event.original filed should be preserved with the original message so that users can troubleshoot the event causing the issue.
The goal of this filing is to get the product ingest pipelines that have this issue to be changed to better-handle the described fields by default, so that end-users don't have to make the manual changes described below.

DETAILS
For background, there is an RFC proposal to remove log.original in favor of using event.original (here: https://github.com/elastic/ecs/blob/main/rfcs/text/0017-remove-log-original.md). However, when a message that fails to be parsed due to a mapping issue, event.original is not part of the error message at all (log.original is). This is an issue because the original message gets stored in the event.original field but the failing event doesn't contain an event.original field at all. This makes it impossible for a user who really only cares about what is in the original message to display the real message they are searching for.

EXAMPLE

This is what you see when an event is successfully parsed/processed:

event.original: %ASA-6-106015: Deny TCP (no connection) from 12.345.678.910/40813 to 09.876.543.21/80 flags FIN ACK on interface inside

This is what you see when the event fails to properly map:

error.message: Provided Grok expressions do not match field value: [Deny TCP (no connection) from server1.example.com/56634 to 12.345.678.910/1463 flags ACK on interface myinterface]
log.original: %ASA-6-106015: Deny TCP (no connection) from server1.example.com/56634 to 12.345.678.910/1463 flags ACK on interface myinterface
message: Deny TCP (no connection) from server1.example.com/56634 to 12.345.678.910/1463 flags ACK on interface myinterface

CAUSE & WORKAROUNDS

This is caused in the Ingest processor for the module by the rename processor that moves the log.original field to event.original being located farther down the pipeline. When the grok processor fails, the rename processor gets skipped and event.original will not be set. A quick, manual, fix would be to add the rename processor to the Failure Processors at the bottom of the pipeline. This way, as long as log.original has been set, it will always be propagated to event.original, even in the event of failure. The pipeline can be edited from Kibana via Stack Management > Ingest Pipelines. See screenshots below for examples.

Another way to look at handling this would be to add a set processor to the on-failure processors. which copies the value of message to event.original. That way, if the grok processor that sets log.original fails, there will still be a value in event.original. In that case, the the rename processor mentioned above must be changed to a set processor that copies the value from log.original. This is because the rename processor will fail if the target field already exists. In this scenario it may be worth also to add a remove processor to remove the log.original field, since it will still be left around. The order of processors would then be:

• set processor, copies message to event.original
• set processor, copies log.original to event.original
• remove processor, removes log.original

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[botelastic]

Hi!
We just realized that we haven't looked into this issue in a while. We're sorry!

We're labeling this issue as Stale to make it hit our filters and make sure we get back to it as soon as possible. In the meantime, it'd be extremely helpful if you could take a look at it as well and confirm its relevance. A simple comment with a nice emoji will be enough :+1.
Thank you for your contribution!

[elasticmachine]

Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices)