Skip to content

Overview ↵

About the Splunk Add-on for Palo Alto Networks
Version 1.0.0
Supported vendor products Cortex XDR, IoT Security, Firewalls, Panorama, Strata Logging Service (Previously Cortex Data Lake)
Add-on has a web UI This add-on contains views for configuration.

Use the Splunk Add-on for Palo Alto Networks to collect data from various Palo Alto Networks products.

This add-on provides modular inputs and CIM-compatible knowledge to use with other Splunk apps.

Download the Splunk Add-on for Palo Alto Networks from Splunkbase. See Deploy the Splunk Add-on for Palo Alto Networks for information about installing and configuring this add-on.

See Release notes for the Splunk Add-on for Palo Alto Networks for a summary of new features, fixed issues, and known issues.

About the Splunk Add-on for Palo Alto Networks
Version 1.0.0
Supported vendor products Cortex XDR, IoT Security, Firewalls, Panorama, Strata Logging Service (Previously Cortex Data Lake)
Add-on has a web UI This add-on contains views for configuration.

Use the Splunk Add-on for Palo Alto Networks to collect data from various Palo Alto Networks products.

This add-on provides modular inputs and CIM-compatible knowledge to use with other Splunk apps.

Download the Splunk Add-on for Palo Alto Networks from Splunkbase. See Deploy the Splunk Add-on for Palo Alto Networks for information about installing and configuring this add-on.

See Release notes for the Splunk Add-on for Palo Alto Networks for a summary of new features, fixed issues, and known issues.

Release history for the Splunk Add-on for Palo Alto Networks

Version 1.0.1 is the latest version of the Splunk Add-on for Palo Alto Networks. See Release Notes for the latest updates.

Version 1.0.0

Version 1.0.0 of the Splunk Add-on for Palo Alto Networks was released on October 2, 2024. It was tested with the following software, CIM versions, and platforms.
Splunk platform versions 9.1, 9.2
CIM 5.x
Platforms Platform independent
Vendor Products Cortex XDR, IoT Security, NGFW, Strata Logging Service, PAN-OS

New features

Version 1.0.0 of the Splunk Add-on for Palo Alto Networks has the following new features: - Modular inputs for IoT Security & Cortex XDR - Monitoring Dashboard - CIM normalisataion for supported vendor products

Third-party software attributions

Third-party software attributions for the Splunk Add-on for Palo Alto Networks for v1.0.0

Hardware and software requirements for the Splunk Add-in for Palo Alto Networks

Splunk platform requirements

Because this add-on runs on the Splunk platform, the system requirements also apply for the Splunk software on which you install the Splunk Add-on for Palo Alto Networks.

  • For Splunk Enterprise system requirements: see System Requirements in the Splunk Enterprise Installation Manual.
  • If you are managing on-premises forwarders to get data into Splunk Cloud, see System Requirements in the Splunk Enterprise Installation Manual, which includes information about forwarders.
  • If you are using Splunk Cloud see Install an add-on in Splunk Cloud

Deploy the Splunk Add-on for Palo Alto Networks

Install and configure the Splunk Add-on for Palo Alto Networks on your supported platform:

  1. Install the Splunk Add-on for Palo Alto Networks.
  2. Create account for Cortex XDR and IoT Security.
  3. Configure inputs for the Splunk Add-on for Palo Alto Networks - Firewalls and Panorama - Cortex XDR - IoT Security - Strata Logging Service

Ended: Overview

Installation ↵

Installation overview for the Splunk Add-on for Palo Alto Networks

  1. Download the Splunk Add-on for Palo Alto Networks from Splunkbase or Splunk Web.
  2. Use the tables in this topic to determine where to install this add-on.
  3. Perform any prerequisite steps specified in the tables before installing.
  4. Use the links in the Installation walkthrough section to perform the installation.

Distributed deployments

Use the following tables to install the Splunk Add-on for Palo Alto Networks in a deployment that uses forwarders to get data in, such as a distributed deployment. You might need to install the add-on in multiple places.

Where to install this add-on

Unless otherwise noted, you can safely install all supported add-ons to all tiers of a distributed Splunk platform deployment. See Where to install Splunk add-ons in Splunk Add-ons for more information.

This table provides a reference for installing this specific add-on to a distributed deployment of the Splunk platform:

Splunk platform component Supported Required
Search heads Yes Yes
Indexers Yes Yes
Heavy forwarders Yes Yes
Universal forwarders No No

Distributed deployment compatibility

This table provides a quick reference for the compatibility of this add-on with Splunk distributed deployment features:

Distributed deployment feature Supported
Search head clusters Yes
Indexer clusters Yes
Deployment server No

Installation walkthroughes

See the following links, or About installing Splunk add-ons in the Splunk Add-Ons manual, for an installation walkthrough specific to your deployment scenario:

Ended: Installation

Configure ↵

Configure Cortex XDR & IoT Security accounts used for inputs for the Splunk Add-on for Palo Alto Networks

Overview

In order to start collecting data, IoT Security and Cortex XDR accounts should be set up prior.

Set up Cortex XDR account

To set up Cortex XDR account, please follow these steps:

  1. Use the instruction in the Cortex XDR Getting Started Guide to gain API access: https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-api/cortex-xdr-api-overview/get-started-with-cortex-xdr-apis Use these values to generate the API key:
Security Level Role
Advanced Viewer

This action will provide you a Key and Key ID. The Key be shown only once, so make sure to record it or you’ll need to re-create the Key. 2. In Splunk, navigate to the Splunk Add-on for Palo Alto Networks. Go to “Configuration” tab, click on “Cortex XDR account” and then click on “Add” 3. Use the following table to complete the fields for the new account in Splunk:

Field Description
Tenant name Value can be found in Cortex XDR URL: https://tenantname.xdr.tenantregion.paloaltonetworks.com/.
Tenant region Value can be found in Cortex XDR URL: https://tenantname.xdr.tenantregion.paloaltonetworks.com/.
API Key ID API Key ID generated in step one. Also could be found in ID column in API Keys dashboard.
API Key API Key generated in step one. Note that API key should have ‘Advanced’ security level with a role of ‘Viewer’.

Set up IoT Security account

To set up IoT Security account, please follow these steps:

  1. Use the instruction in the IoT Security Administrator’s Guide to gain API access: https://docs.paloaltonetworks.com/iot/iot-security-api-reference/iot-security-api-overview/get-started-with-the-iot-security-api.html

This action will provide you a Secret Access Key and Access Key ID. The Secret Access Key be shown only once, so make sure to record it or you’ll need to re-create the Secret Access Key. 2. In Splunk, navigate to the Splunk Add-on for Palo Alto Networks. Go to “Configuration” tab, click on “IoT Security account” and then click on “Add” 3. Use the following table to complete the fields for the new account in Splunk:

Field Description
Customer ID Found in the hostname when accessing IoT Security. (eg. https://customer-id.iot.paloaltonetworks.com).
Access Key ID Secret Access Key ID created in IoT security dashboard.
Secret Access Key Secret Access Key generated in step one.

After adding accounts for Cortex XDR and IoT security check how to collect data from Cortex XDR and IoT Security

Configure Cortex XDR input for the Splunk Add-on for Palo Alto Networks

Overview

Cortex XDR is cloud-hosted so logs are retrieved by Splunk using the Cortex XDR API’s. Logs are pulled down in JSON format with sourcetype=”pan:xdr_incident”.

Create Cortex XDR Input

If you plan to use the Cortex XDR input, you must perform the following steps:

  • In Splunk, navigate to the Splunk Add-on for Palo Alto Networks.
  • Go to “Inputs” page and click on “Create New Input” select “Cortex XDR”.

In the opened window, input these values:

Field Value Description
Name String Name that will be used for input.
Interval Positive integer Frequency in seconds to check for new logs (60 seconds recommended) .
Index Selection The index in which to put the Cortex XDR logs. The default is main.
Incident details Tick box If selected detailed events will be pulled from Cortex XDR API.
Cortex XDR account to use Selection Select Cortex XDR account used to pull data from.

Then click Add to save the modular input.

Verify data ingestion

After waiting the appropriate interval time, check that logs are coming into Splunk by clicking Search at the top and entering this search: 

sourcetype="pan:xdr*"
You should see some JSON formatted logs show up. If nothing shows up, wait a little longer, ensure there is activity in Cortex XDR to generate logs, and try the Troubleshooting Guide.

Configure IoT Security input for the Splunk Add-on for Palo Alto Networks

Overview

IoT Security is cloud-hosted so logs are retrieved by Splunk using the IoT Security logging API. Logs are pulled down in JSON format with sourcetype=”pan:iot_alert”, sourcetype=”pan:iot_device” and eventtype=”pan_iot_device”, eventtype=”pan_iot_alert”.

Create IoT Security Input

If you plan to use the IoT Security input, you must perform the following steps:

  • In Splunk, navigate to the Splunk Add-on for Palo Alto Networks.
  • Go to “Inputs” page and click on “Create New Input” select “IoT Security”.

In pop-up window fill .....

Field Value Description
Name String Name that will be used for input.
Interval Positive integer Frequency in seconds to check for new logs (60 seconds recommended) .
Index Selection The index in which to put the IoT Security logs The default is main.
IoT account to use Selection Select IoT Securty account used to pull data from.

Then click Add to save the modular input.

Verify data ingestion

After waiting the appropriate interval time, check that logs are coming into Splunk by clicking Search at the top and entering this search: 

sourcetype="pan:iot*"
You should see some JSON formatted logs show up. If nothing shows up, wait a little longer, ensure there is activity in IoT Security to generate logs, and try the Troubleshooting Guide.

Firewalls and Panorama

Logging architectures

Log Forwarding App for Logging Service forwards syslog to Splunk from the Palo Alto Logging Service using an SSL Connection.

Firewalls can send logs to Splunk directly, or they can send logs to Panorama or a Log Collector which forwards the logs to Splunk.

Panorama sends its own logs to Splunk and can forward logs from firewalls to Splunk.

Syslog to Splunk using the following protocols:

Product Syslog Protocols
Log Forwarding App for Logging Service SSL
Next-generation Firewall UDP, TCP, or SSL
Panorama UDP, TCP, or SSL

Create a data input

Use the GUI to create a Data Input, or create it in inputs.conf using the CLI.

Firewalls and Panorama can all send logs to the same data input and port. The Add-on will automatically detect the source of each log and parse it correctly.

Select a sourcetype

Log source SourceType
Only Firewall logs pan:firewall

It is preferable to use pan:firewall instead of pan:log because less parsing is required and timestamps will be slightly more accurate.

GUI

  • In the top right corner, click Settings -> Data inputs
  • In the row for UDP or TCP click Add new (SSL Data Inputs can’t be created in the GUI)
  • Enter a port number and click Next
  • Click Select Sourcetype -> Network & Security -> pan:firewall
  • Change the App Context to the Palo Alto Networks Add-on
  • Set any other settings such as Method or Index as appropriate for your environment
  • Click Review, followed by Submit

You can optionally use a more specific sourcetype than pan:log such as pan:firewall.

CLI

Create the inputs.conf in the correct directory: $SPLUNK_HOME/etc/apps/Splunk_TA_paloalto/local/inputs.conf

The local directory is not created during installation, so you may need to create it. Also, the inputs.conf does not have to be in the Add-on directory, but this is Splunk best practice.

Add the following lines to the inputs.conf file. This examples uses the default syslog port UDP 514. Change the port as needed:

[udp://514]
sourcetype = pan:firewall
no_appending_timestamp = true
index = pan_logs

For UDP logs, no_appending_timestamp setting is required. For TCP or SSL syslogs, remove the no_appending_timestamp setting.

You can optionally set an index to store the logs, or remove the index setting to store logs in the default index.

Configure the Firewall

There are two ways to send logs from a Next generation Firewall to Splunk:

  • All firewalls syslog directly to Splunk = All firewalls log to Panorama, then Panorama syslogs to Splunk

The Palo Alto Networks syslog documentation describes each option in detail:

Firewall and Panorama syslog to Splunk: https://www.paloaltonetworks.com/documentation/81/pan-os/pan-os/monitoring/use-syslog-for-monitoring/configure-syslog-monitoring

Firewall and Panorama logs must be sent in the default format. Custom formats, CEF, and LEEF format cannot be parsed by the Splunk Add-on.

Test the configuration

The easiest way to test that everything is working is to configure the firewall to syslog all config events. On the firewall or Panorama, navigate to the Device tab, then Log Settings. Enable config logs and commit the configuration.

Now, make any configuration change and the firewall to produce a config event syslog. You don’t have to commit the change for the syslog to be produced; any uncommitted change to the configuration produces a log.

After waiting the applicable interval time, check that logs are coming into Splunk by clicking Search at the top and entering this search:

eventtype=pan_config

If Splunk is getting the syslogs from the firewall and parsing them correctly, then you’ll see the config event syslogs show up here from the changes you made on the firewall configuration.

If you don’t see the syslog, verify the steps above or try the Troubleshooting Guide.

Strata Logging Service via HTTP Event Collector(HEC)

Send Strata Logging Service logs to Splunk Cloud and Splunk Enterprise with HTTP Event Collector(HEC).

Create Event Collector Token in Splunk for Strata Logging Service Follow the guide for creating an Event Collector Token in Splunk: https://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector

Use these values when creating the token

Field Value
Source type pan:firewall_cloud

Setup HTTP forwarding from Strata Logging Service Use the instruction in the Forward Logs from Strata Logging Service to an HTTPS Server guide:

https://docs.paloaltonetworks.com/strata-logging-service/administration/forward-logs/forward-logs-to-an-https-server

Ended: Configure

Reference ↵

Lookups for the Splunk Add-on for Palo Alto Networks

The Splunk Add-on for Palo Alto Networks contains the following CSV lookup files.

These CSV lookups represent mappings defined in Palo Alto’s documentation that provide information as human readable strings for certain event field values.

The lookup files map certain fields to retrieve more information about threats or applications. The lookup files are located in $SPLUNK_HOME/etc/apps/Splunk_TA_paloalto_networks/lookups.

Filename
app_list.csv
endpoint_actions.csv
ip_classifications.csv
pan_vendor_actions.csv
pan_vendor_info.csv
sanctioned_saas.csv
threat_list.csv
system_actions.csv

Tune or Reduce Firewall Logs

The most common question we get is:

“The firewall/Panorama produces a lot of logs and it’s overwhelming our Splunk license or producing a lot of noise that’s hard to filter through. How can I reduce the log volume without losing security visibility?”

The firewall offers very granular logging controls, so you can tune and reduce logs to Splunk with extreme precision. Even so, this question is difficult to answer because the answer is different for every organization. So this page is an effort to provide general guidance to help you answer this question for yourself.

Log Types

There are many log types, and not all of them are relevant to every organization. The following table shows the characteristics of the most common logs types:

Log Type Splunk Sourcetype Log Size Log Frequency
Traffic pan:traffic Large Very High
Threat pan:threat Large Low
Threat : url pan:threat Large Very High
Threat : file pan:threat Large High
System pan:system Medium Medium
Configuration pan:config Small Low
Correlation pan:correlation Small Low
HIP Match pan:hipmatch Small Medium

Note: URL and File logs are of type Threat, but they are called out separately because they have a different frequency than most threat logs.

You can see from the table that Traffic logs and URL logs are the most frequent and largest, with File logs coming in second. These log types will make up the bulk of what Splunk has to ingest and index.

For more guidance on calculating log sizes and event frequency for your environment, refer to these two articles in the Palo Alto Networks Knowledge base. They include tools and scripts to pull the logging rate from a live device and calculate the storage needed for retension.

Disable Log Types

You can eliminate specific log types that are not of use for your organization. Here are a couple examples:

  1. If you use Splunk in a SOC for security, but are not responsible for the operational health of the firewalls, you could consider disabling System and Config log types
  2. Traffic logs are large and frequent. Cut their volume in half by shutting off ‘Start’ logs in all your firewall rules. ‘Start’ logs often have an incorrect app anyway, becuase they are logged before the app is fully determined. The ‘End’ logs will have the correct App and other data such as the session duration. See Session Log Best Practices.

Reduce Logs for Specific Endpoints or Threats

You can only get so far disabling entire log types. Most organizations need these log types and can’t disable all URL or Traffic logs. You can still make an impact by reducing these log types only when they are redundant or unnecessary. You can turn these logs on or off for specific rules which gives you complete control over every log. Here are examples of where you might consider reducing log volume:

  1. Backup software runs every night generating thousands of connections from endpoints to a backup server. Create a rule for this backup app from internal endponts to the backup server which logs only threats, and doesn’t log traffic sessions, urls, or files.
  2. Use of an internal app regularly triggers a vulnerability or spyware alert, however, its determined that this is the normal operation of the app and no risk exists. Create a rule for this specific app and the server it runs on that disables this signature. See How to disable signatures for a specific host

Source types for the Splunk Add-on for Palo Alto Networks

The Splunk Add-on for Palo Alto Networks has the following sourcetypes.

Sourcetype Description Event type CIM data models
pan:system PAN OS system events pan_system
 pan_system_auth
 pan_system_alert
 pan_system_change		 Authentication
Change
pan:decryption PAN OS decryption events pan_decryption Network Traffic
pan:traffic PAN OS traffic events pan_traffic
 pan_traffic_end
 pan_traffic_start		 Network Traffic
Network Traffic
Network Traffic
pan:threat PAN OS threat events pan_threat
 pan_file pan_url
 pan_email
 pan_data
 pan_virus
 pan_spyware
 Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
pan:config PAN OS config events pan_config Change
pan:hipmatch PAN OS hipmatch events pan_hipmatch
pan:correlation PAN OS correlation events pan_correlation Alerts
pan:userid PAN OS userid events pan_userid
pan:globalprotect GLOBALPROTECT events pan_global_protect Authentication
pan:firewall_cloud Events coming from
Strata Logging Service		 pan_traffic
 pan_threat
 pan_system
 pan_decryption
 pan_spyware
 pan_globalprotect
 pan_wildfire
 pan_correlation
 pan_email
 pan_data
 pan_virus
 pan_file
 pan_url
 pan_wildfire_malicious
 pan_traffic_end
 pan_traffic_start		 Network Traffic
Intrusion Detection
Intrusion Detection
Network Traffic
Intrusion Detection
Authentication
Intrusion Detection
Alerts
Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
Intrusion Detection
Network Traffic
Network Traffic
pan:iot_alert IoT Alerts events pan_iot_alert Alerts
pan:iot_vulnerability IoT Vulnerability events pan_iot_vulnerability Vulnerabilities
pan:pan_iot_device IoT Device Events pan_iot_device Inventory
pan:pan_xdr_incident Incidents from Cortex XDR pan_xdr_incident
 pan_xdr_incident_detailed		 Ticket Management
Ticket Management

Ended: Reference

Migration ↵

Migration to Splunk add-on for Palo Alto Networks

There are 2 possible migration considerations regarding the Splunk add-on for Palo Alto Networks:

  1. If you run both add-ons at the same time:

    • New add-on can be used as a POC, and then safely disabled if it no longer meets your requirements.
    • Could potentially break knowledge objects extractions.
    • Would create duplicate data until you disable the old add-on.

  2. If you disable the Palo Alto supported add-on and only use the Splunk-supported add-on for Palo Alto Networks:

    • Knowledge objects will work as desired.
    • There will be minimal data duplication.
    • You must disable the Palo Alto Networks supported add-on at the same start date and time of data collection in order to migrate modular inputs without any data loss.
    • You might have issues and cause potential data loss if you need to rollback the add-on.

To ingest syslog data without any loss, you must first configure syslog input for the Splunk-supported add-on for Palo Alto Networks and only then disable the Palo Alto-supported add-on.

If you have already installed the Palo Alto Networks Add-on for Splunk in a Splunk instance and want to install Splunk add-on for Palo Alto Networks in the same Splunk instance, you must first:

  • Disable inputs for the Palo Alto Networks Add-on for Splunk
  • Disable the Palo Alto Networks Add-on for Splunk

This prevents clashing of modular inputs, data collection mechanisms, and sourcetypes in both add-ons.

To disable modular inputs for Palo Alto Networks Add-on for Splunk, navigate to the Inputs page and select “Disable”.

To disable the Palo Alto Networks Add-on for Splunk, navigate to Apps > Manage Apps and select “Disable” option for the add-on.

If both add-ons are enabled on the same Splunk instance, data duplication occurs for the sourcetype with the same names: pan:iot_alert, pan:iot_device, pan:iot_vulnerability, pan:xdr_incident

If you created syslog inputs in a local folder for the Palo Alto Networks Add-on, you must migrate them manually to the new add-on.

For changes in CIM mapping please check Add-on comparison page

Changes in CIM may impact custom saved searches or dashboards.

For information about add-on configuration please visit:

For dashboards, use the Splunk-supported app for Palo Alto Networks.

Add-ons comparison

  1. Improved CIM mapping

    • Added support for new OS versions: PanOS 10 & PanOS 11.
    • Review existing mappings. Differences between Add-ons.
    • Map new types of events.

  2. Migration of technical assets from the Security App to the Add-on

    • Moved custom search commands to add-on (will be available in future releases).
    • Moved macro to add-on.

  3. New feature

    • Monitoring dashboard (health check page) and the ability to request detailed events from Cortex XDR.

  4. Changes in macro

    • Basic macros are now designed to look for data in “index=pan*”. If that definition does not match your index configuration, you can make changes to the p_index macro.

  5. Configuration changes for IoT security & Cortex XDR modular inputs

    • Moved Customer ID, Access Key ID, Secret Access Key parameters from IoT Security modular input configuration to the IoT Accounts section on the Configuration page.
    • Moved Tenant name, Tenant region, API Key ID, API Key parameters from Cortex XDR modular input configuration to the Cortex XDR Accounts section on the Configuration page.
    • Collection date time start was added to both inputs, to specify the start of data and time collection.
    • Incident details parameter added to enable detailed event retention from Cortex XDR.

  6. Clean up of deprecated features

    • Removed deprecated modular inputs (Aperture, MineMeld, AutoField) from add-on.
    • Removed unused mappings for deprecated source types (Aperture, MineMeld, and AutoField).
    • Removed deprecated macros and saved searches for Aperture, MineMeld and AutoField.
    • Removed Alert Actions.

Data normalization differences between versions 8.1.3 of the Palo Alto Networks Add-on for Splunk and 1.0.0 of the Splunk Add-on for Palo Alto Networks

CIM model comparison between Addons.

Sourcetype event_type Previous CIM model New CIM model
pan:system pan_system_alert Change
pan:system pan_system_auth Authentication
pan:traffic pan_traffic_start, pan_traffic_end Network Sessions Network Traffic
pan:threat pan_virus, pan_spyware, pan_threat Intrusion Detection Intrusion Detection
pan:threat pan_url Web Intrusion Detection
pan:threat pan_wildfire Malware Intrusion Detection
pan:globalprotect pan_globalprotect Authentication
pan:decryption pan_decryption Network Traffic
pan:correlation pan_correlation Alerts
pan:iot_alert pan_iot_alert Alerts
pan:iot_device pan_iot_device Inventory
pan:iot_vulnerability pan_iot_vulnerability Vulnerabilities
pan:xdr_incident pan_xdr_incident, pan_xdr_incident_detailed Ticket Management
pan:userid pan_userid Not mapped to CIM
pan:hipmatch pan_hipmatch Not mapped to CIM
pan:config pan_config Change Analysis Change

Fields added in Splunk Add-on for Palo Alto Networks v1.0.0

Source type Event name Fields added 1.0.0 extractions
pan:firewall_cloud pan_traffic duration 344
pan:firewall_cloud pan_traffic protocol tcp
pan:firewall_cloud pan_traffic ids_type network
pan:firewall_cloud pan_traffic dest_translated_port 443
pan:firewall_cloud pan_traffic dest_translated_ip 172.168.197.239
pan:firewall_cloud pan_traffic src_translated_port 58983
pan:firewall_cloud pan_traffic src_translated_ip 192.168.1.10
pan:firewall_cloud pan_threat dest_translated_port 80
pan:firewall_cloud pan_threat dest_translated_ip 192.168.185.49
pan:firewall_cloud pan_threat src_translated_port 34479
pan:firewall_cloud pan_threat src_translated_ip 192.168.1.10
pan:firewall_cloud pan_threat protocol tcp
pan:firewall_cloud pan_threat ids_type network
pan:firewall_cloud pan_threat action success
pan:firewall_cloud pan_threat app Palo Alto Networks Firewall
pan:system pan_system_auth change_type FileSystem
pan:system pan_system_auth user admin
pan:system pan_system_auth src_user admin
pan:system pan_system_auth src 192.168.2.2
pan:system pan_system_auth status failure
pan:system pan_system_alert action modified
pan:system pan_system_alert object url_filtering
pan:system pan_system_alert object_attrs 20240513.20182
pan:system pan_system_alert object_category File
pan:system pan_system_alert status success
pan:system pan_system_alert result upgrade-url-database-success
pan:system pan_system_alert src Firewall
pan:xdr_incident pan_xdr_detailed comments NO COMMENTS
pan:xdr_incident pan_xdr_detailed description ‘Ransomware Activity - 244825228’ along with 5 other alerts generated by XDR Agent detected on host c2376524598 involving 2 user
pan:xdr_incident pan_xdr_detailed dest c2376524598:1c482c0623b2445xxxxx13e7707eca
pan:xdr_incident pan_xdr_detailed src_user administrator
pan:config pan_config action modified
pan:config pan_config change_type filesystem
pan:correlation pan_correlation description Host visited known malware URL (100 times).
pan:decryption pan_decryption dest 192.168.160.26
pan:decryption pan_decryption dvc Firewall
pan:decryption pan_decryption src 192.168.4.5
pan:globalprotect pan_globalprotect action success
pan:globalprotect pan_globalprotect app Palo Alto Firewall
pan:globalprotect pan_globalprotect dest GPGW_xxxxx_xxxxxx-xxx_6490686
pan:globalprotect pan_globalprotect dest_ip 192.168.1.222
pan:globalprotect pan_globalprotect src_mac 00:0c:xx:xx:xx:34
pan:iot_alert pan_iot_alert description Detected established connections to malicious ip 192.168.1.94
pan:iot_alert pan_iot_alert src_ip 192.168.1.17
pan:iot_device pan_iot_device name 30:xx:xx:xx:xx:44
pan:iot_device pan_iot_device src_ip 10.3.3.190
pan:iot_vulnerability pan_iot_vulnerability cvss 10
pan:iot_vulnerability pan_iot_vulnerability signature SNMP v1 Usage

Fields removed in Splunk Add-on for Palo Alto Networks v1.0.0

Source type Event name Fields removed Comments
pan:traffic pan_traffic_start, pan_traffic_ends application removed due to being duplicate of field app
pan:firewall_cloud pan_globalprotect status
pan:xdr_incident pan_xdr_incident id
pan:config pan_config before_change_detail
pan:config pan_config after_change_detail
pan:iot_device pan_iot_device enabled

Fields modified in Splunk Add-on for Palo Alto Networks v1.0.0

Source type Event name Fields modified 8.1.3 extractions 1.0.0 extractions Comments
pan:threat pan_spyware category spyware social-networking
pan:traffic pan_spyware dvc host1 Firewall now maps to value of dvc_name instead of host
pan:traffic pan_url dvc host1 Firewall now maps to value of dvc_name instead of host
pan:traffic pan_file category N/A computer-and-internet-info
pan:traffic pan_file dvc host1 Firewall now maps to value of dvc_name instead of host
pan:traffic pan_wildfire category N/A benign
pan:traffic pan_wildfire dvc host1 Firewall now maps to value of dvc_name instead of host
pan:traffic pan_threat dvc host1 Firewall now maps to value of dvc_name instead of host
pan:traffic pan_virus dvc host1 Firewall now maps to value of dvc_name instead of host
pan:firewall_cloud pan_traffic bytes_in 10368 15009 switched mapping for bytes_in and bytes_out as it was incorrectly mappped in past
pan:firewall_cloud pan_traffic bytes_out 15009 10368 switched mapping for bytes_in and bytes_out as it was incorrectly mappped in past
pan:firewall_cloud pan_traffic dvc host1 Firewall now maps to value of dvc_name instead of host
pan:firewall_cloud pan_threat dvc host1 Firewall now maps to value of dvc_name instead of host
pan:firewall_cloud pan_globalprotect dvc host1 GPGW_xxxxx_xxxxxx-xxx_6490686
pan:system pan_system_alert app Palo Alto Networks Firewall PAN-OS
pan:system pan_system_alert dvc host1 Firewall now maps to value of dvc_name instead of host
pan:config pan_config dest host1 xxx.xx.x.xx
pan:correlation pan_correlation signature Host visited known malware URL (100 times). beacon-heuristics
pan:decryption pan_decryption action allow allowed
pan:iot_alert pan_iot_alert action unknown Palo Alto Network IoT Security
pan:iot_alert pan_iot_alert id 5f3e066e5e3caa7b4f540475 alert-mki-mB7uA3
pan:iot_alert pan_iot_alert src 192.168.1.17 Hikivision-Camera
pan:iot_alert pan_iot_alert type policy_alert alert

Ended: Migration

Troubleshooting ↵

Troubleshooting

Common Problems and Solutions

Troubleshooting Cortex XDR

  1. Enable Debug Logging - In Splunk, navigate to the Splunk Add-on for Palo Alto Networks. - Navigate to Configuration and click on the logging. Then change the log level to DEBUG and click on “Save” button.
  2. Use this Splunk search to troubleshoot error messages from Cortex XDR.
index="_internal" sourcetype="splunk_ta_paloalto_networks*"

Time and Timezone Problems

There are a few factors that determine the time and timezone of a log:

  1. The Splunk server’s time and date
  2. The Splunk server timezone, or the Splunk container timezone when using Docker
  3. The date/time and timezone settings on Firewall, Panorama, or Traps ESM
  4. The per-log timezone setting in props.conf

By default, the Add-on do not interpret timezones or have any preconfigured timezone settings.

Firewall/Panorama and Traps always output logs without a timezone, so the timezone setting is honored, but not included with the log. For example, if your Firewall is set to 8:00:00 EST, then the time in the syslog will be 8:00:00 (without the EST timezone).

Splunk always interprets Palo Alto Networks logs as the timezone of the Splunk server (or container).

Therefor, if a Splunk server and Firewall have the same timezone, then the timestamp will be interpreted correctly by Splunk. If they have different timezones, then the interpreted time will be offset by the difference in the timezones. You can overcome this by creating a local/props.conf file that explicitly sets the timezone for the logs. For example, if Splunk is set to UTC and the Firewall is set to EST, then configure a local props.conf file to interpret the Firewall logs as EST, as they will incorrectly be interpreted as UTC by default.

An example timezone setting in props.conf might look like this:

[host::newyork-firewall-*]
TZ = US/Eastern

This example would cause logs from newyork-firewall-1, newyork-firewall-2, etc. to be interpreted as US/Eastern timezone.

Logs have only sourcetype of pan:log

You set the sourcetype to pan:log in your inputs.conf, however, Splunk parses the logs and changes the sourcetype to a more specific one, including pan:traffic, pan:threat, pan:system, pan:config, and others.

If your logs are not getting converted to these other sourcetypes and are instead remaining with the pan:log sourcetype, then there is a parsing issue with the logs. This can happen for several reason, so please check each of these reason until the problem is resolved. Note that sourcetype changes happen at index-time so only newly received logs will get parsed to a sourcetype.

  1. Use the correct log format. For Firewall or Panorama logs, use the default syslog format. For Traps logs use CEF format.
  2. For UDP logs, try adding no_appending_timestamp = true to your inputs.conf.
  3. Ensure the Palo Alto Networks Add-on is installed on all Indexers and Heavy Forwarders, and configure the inputs.conf on the node receiving the logs.

Ended: Troubleshooting

Release Notes ↵

Release notes for the Splunk Add-on for Palo Alto Networks

About this release

Version 1.0.1 of the Splunk Add-on for Palo Alto Networks was released on November 12, 2024. It was tested with the following software, CIM versions, and platforms.
Splunk platform versions 9.1.x, 9.2.x
CIM 5.x
Platforms Platform independent
Vendor Products Cortex XDR, IoT Security, NGFW, Strata Logging Service, PAN-OS

Fixed issues

Version 1.0.1 of the Splunk Add-on for Palo Alto Networks contains the following fixed issues, if any.

Known issues

Version 1.0.1 of the Splunk Add-on for Palo Alto Networks contains the following known issues, if any.

Third-party software attributions

Third-party software attributions for the Splunk Add-on for Palo Alto Networks

Ended: Release Notes