I'm unable to determine if this bug is manifesting in actual Filebeat parses of PAN-OS logs as I'm not utilizing them. I'm using the Filebeat configuration to assist in creating my Logstash pipeline to map PAN-OS fields to Elastic Common Schema.
During my review the first thing I notice is that the Filebeat panw module has the csv parse column 1 to "event.created". Upon reviewing Palo Alto's documentation on the field descriptions, the first column presented is labeled "FUTURE_USE", and the second column is "Receive Time". If the panw module is parsing properly it suggests that the module is somehow skipping the first column, which would be sufficient for the panw stance of dropping many of the fields including those marked for "future use", but I'm hesitant to drop fields that could be used in the future for use cases currently unknown.
This module has been tested with logs generated by devices running PAN-OS versions 7.1 to 9.0 but limited compatibility is expected for earlier versions.
Currently 8.1. The 1st column is highlighted as "FUTURE_USE" in each of the major versions currently supported. Note the section labeled "Format:" with a comma-separated list of fields found in the forwarded log. If it has been tested on these versions, then I'm assuming this first field is being dropped somewhere before the log reaches filebeat so this is probably a non-issue.
Note, I'm using Panorama's Log Forwarding Profile to send directly to Logstash. It comes in as Syslog RFC5424, and after using grok to parse the syslog fields, then passing the remaining message field to the logstash csv filter I do have a value present before the "Receive Time" field on all log types I've parsed including Traffic, Threat, User-ID, and System.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.