Mapping Palo Syslog to UDM

[kwall00]

I have a tool that receives Palo Alto firewall syslog (formatted in RFC 5424) and then maps the syslog to Chronicle UDM. 

I have made all of the necessary mappings with the exception of the Palo syslog "message" field. I am having trouble determining what UDM field to map it to. I have tried the following without luck:

metadata.rawLog
entries.log_text
entries[].log_text
entries[0].log_text
principal.message
target.message
network.application.raw
udm_event.message
security_result.description
network.application.message

Any suggestions on how to map this field?

[dlove40]

Are you parsing the data before sending it to SecOps, or creating a custom parser for SecOps?

[kwall00]

The data is being parsed, prepared, and mapped to UDM.

[ionutm]

It's tricky to give you the exact mapping without knowing the precise structure of your Palo Alto syslog messages and how they're being parsed. However, based on your attempts and my understanding of UDM, here's a breakdown and suggestions below.

We need first of all to understand what logs you are looking at: System, Threat, Traffic, Global Protect, User-id, Wildfire, etc.

Understanding the Challenge

• Varied Message Content: Palo Alto syslog messages under the "message" field can contain diverse information – traffic details, threat detections, system events, etc. This makes it hard to fit into a single UDM field neatly.
• UDM Structure: UDM aims to normalize security data, so it has specific fields for common security concepts (IP addresses, users, actions, etc.). A generic "message" doesn't always fit this structure.

Troubleshooting and Suggestions

1. metadata.rawLog: This is usually the best catch-all if your parsing tool can't extract specific details from the message. It preserves the original log for later analysis.

2. entries[].log_text: This is closer if your tool breaks down the syslog into multiple "entries" (e.g., one entry per event within the message). However, it's often used for more structured data within the message, not the entire message itself.

3. Contextual Mapping:

   • Traffic Logs: If the message is about network traffic, extract details like source/destination IPs, ports, protocols, and map those to network.source_ip, network.destination_ip, etc. in UDM.
   • Threat Logs: For threat detections, extract threat names, severity, and related file/URL information into security_result.threat_information and other relevant UDM fields.
   • System Events: For system-related messages, consider using udm_event fields or security_result if there's a security implication.

4. Chronicle Documentation:

   • Default Parser: Check if Chronicle's default Palo Alto parser already handles the "message" field in a way you can leverage.
   • Custom Parsing: If the default parser doesn't meet your needs, Chronicle likely allows custom parsing rules to extract specific information from the message and map it to UDM fields.

[kwall00]

Thank you for the responses. I was hoping to map it to metadata.rawLog but nothing seems to work. Whether I delete the message field altogether or map it to a UDM field, it get HTTP 400. 

I am working with Traffic logs at the moment. I have removed a lot of the fields from the original syslog that either map to a UDM array field or has no direct mapping. Just this message field remains a mystery. I'll keep at it.

[dnehoda]

Can you pull that portion out and verify it works without the message?  

I believe you are going to want to use an additional field in this case. 

[kwall00]

It does not work - even when pulling out the message field. What additional fields did you have in mind?

[dnehoda]

Any - whatever makes sense to you.

[dlove40]

You can make a new additional field using a key/value pair. Here's a code example.