PAN-OS by Palo Alto Networks

Check coverage given a list of CVEs.

A wrapper script for the panorama-security-policy-match command that receives multiple values for the source, destination, and destination port arguments and performs the policy match for each combination of the inputs.

Classifies incoming PAN-OS Log incidents.

Maps incoming PAN-OS Log incidents.

Version to install on the firewall e.g. 9.0.5 for PAN-OS

List of CVEs to check

Target Firewall - Usually serial number

Manage Palo Alto Networks Firewall and Panorama. Use this pack to manage Prisma Access through Panorama. For more information, see the Panorama documentation.

This playbook blocks URLs using Palo Alto Networks Panorama or Firewall through Custom URL Categories.
The playbook checks whether the input URL category already exists, and if the URLs are a part of this category. Otherwise, it will create the category, block the URLs, and commit the configuration.

Creates or edits a Panorama rule and moves it into the desired position

Creates or edits a Panorama rule and moves it into the desired position

Find if there is signature coverage for a specific CVE.

Commit the PAN-OS Panorama or Firewall configuration. If specified as Panorama, it also pushes the Policies to the specified Device Group in the instance.

This playbook should be run as a job. It is used to periodically remove the specified tag from domain indicators. It should be used in conjunction with the "PAN-OS - Job - Add Malicious Domains To Sinkhole" playbook, to stop domains from being sinkholed after a certain amount of time.
The idea is that traffic to malicious domains will not be redirected to a sinkhole address forever, as malicious domains tend to lose their malicious properties (become inactive, get taken down, or the malware using them is no longer used or maintained).

This playbook add domains EDL to Panorama Anti-Spyware. It assigns External Dynamic List URLs that contain domains to block to Panorama Anti-Spyware. You can create an External Dynamic List (EDL) and add domains to it using the Cortex XSOAR pack called "Generic Export Indicators Service".
We recommend using this playbook as a one-time job. Once EDL is created and assigned to anti-spyware, domains can be blocked by adding them to the EDL.

This playbook blocks IP addresses with 2 optional actions:

• Block IP addresses using Static Address Groups in Palo Alto Networks Panorama or Firewall. The playbook receives malicious IP addresses and an address group name as inputs, verifies that the addresses are not already a part of the address group, adds them and commits the configuration.

• Utilize the Dynamic Address Group (DAG) capability of PAN-OS. DAG enables analysts to create a rule one time, where the group is the source/destination, and adds IP addresses dynamically without the need to commit the configuration every time.
  The playbook checks if the given tag already exists. If the tag exists, then the IP address is added to the tag.
  If the tag does not exist, a new address group is created with the given tag and a matching rule, and the configuration is committed.

This playbook sets up and maintains log forwarding for the Panorama rulebase.
It can be run when setting up a new instance, or as a periodic job to enforce log forwarding policy.
You can either update all rules and override previous profiles, or update only rules that do not have a log forwarding profile configured.

This playbook blocks IP addresses using Static Address Groups in Palo Alto Networks Panorama or Firewall.
The playbook receives malicious IP addresses and an address group name as inputs, verifies that the addresses are not already a part of the address group, adds them and commits the configuration.

***Note - The playbook does not block the address group communication using a policy block rule. This step will be taken once outside of the playbook.

This playbook blocks a destination IP and service (TCP or UDP port) by creating a rule for a specific device group on PAN-OS.

This playbook accepts a PAN-OS static route configuration and creates it in the PAN-OS instance.

This playbook deletes a PAN-OS static route from the PAN-OS instance.

Network operations playbook that updates the version and content of the firewall. You must have Superuser permissions to update the PAN-OS version.

This playbook is designed to enhance the security level in PAN-OS firewalls by safely adding an Anti-Spyware security profile to a security rule.
The playbook provides control over the behavior when a a rule:

• Already has an Anti-Spyware profile
• Uses a security profile group, with or without an Anti-Spyware profile

The output of the playbook is the Anti-Spyware profile configured for the rule upon playbook completion. This can be:

• The initial profile, if untouched
• A newly overwritten profile
• A newly added profile

This playbook blocks IP addresses using Custom Block Rules in Palo Alto Networks Panorama or Firewall.
The playbook receives malicious IP addresses as inputs, creates a custom bi-directional rule to block them, and commits the configuration.

This playbook creates a DNS sinkhole in a PAN-OS firewall. It does the following:

1. Finds a security rule that allows DNS traffic from the internal network to the internet using the "Security Policy Match" feature against traffic from the internal DNS server/s to the public DNS server.
2. Creates or adds an existing anti-spyware security profile to the security rule/s that were found.
3. Sets the DNS Signature Source under the DNS Policies configuration of the security profile with the "sinkhole" action.
4. Creates an address object for the sinkhole address so that it can be referenced later in a deny rule (the sinkhole IP constantly rotates).
5. Creates a new security rule to deny traffic to the sinkhole address object, in order to generate traffic logs for the compromised systems. The IPs of the compromised systems can then be retrieved using the "PAN-OS - Extract IPs From Traffic Logs To Sinkhole" playbook.

Once the configuration is completed, the playbook will create a Tag object and tag the relevant security rules to indicate that sinkholing is configured. That tag will be checked in consecutive playbook runs in order to minimize the actions done on the firewall and time time spent in the playbook execution.

How it works:
A DNS sinkhole can be used to identify infected hosts on a network where there is an internal DNS Server in-route to the firewall that causes the reference of the original source IP address of the host that first originated the query to be lost (the query is received by the internal DNS server, and the internal DNS server sources a new query if the name-to-IP resolution is not locally cached).

This causes the firewall to report observations of malicious DNS queries in the Threat logs where the source IP of the malicious DNS query is the Internal DNS server, which would force the administrator to look into the DNS Server logs to try to trace down what was the infected host that originally sourced the malicious DNS query.

After a security profile with a "sinkhole" action for domains that are listed in the DNS signature source is applied to a rule that allows DNS traffic from the internal server/s to the external one, the threat logs will show that requests from the internal DNS server/s were sinkholed. However, the compromised systems will not appear in those logs.

In order to find the IP addresses of those systems, a new rule denying all requests to our sinkhole address needs to be created. Since the infected systems received a forged DNS response (due to the security profile involved in our previous step), they will now try to connect to the sinkhole address, assuming it is their C&C server. The new rule will deny the subsequent attempts of those systems when they try to access the sinkhole address, and log them.

Assumptions:

• The domains that should be sinkholed are already in a DNS signature source. It can be one of the following sources available in PAN-OS:

1. An existing External Dynamic List (EDL) of type Domain configured in the PAN-OS firewall. Note: XSOAR simplifies the process of creating an EDL, with the Export Generic Indicators Service integration.
2. Palo Alto Networks Content-delivered malicious domains
3. DNS Security Categories available with a DNS Security subscription.

• There is at least one internal DNS server that is sending the DNS requests out through the firewall to a specific public DNS server.

Network operations playbook that upgrades the firewall. You must have Superuser permissions to update the PAN-OS version. Note: This playbook should only be used for minor version upgrades. Major version upgrades will not work due to a change in the API key.

This playbook searches for outgoing traffic to the sinkhole address in PAN-OS. It should be used after a DNS sinkhole was created using the "PAN-OS - Configure DNS Sinkhole" playbook. If a DNS sinkhole was created manually, you should verify in your PAN-OS firewall that there is an address object for the sinkhole FQDN "sinkhole.paloaltonetworks.com", and that there is a rule denying traffic to it from any source. You may specify the name of the deny rule if you know it, or you can let the playbook find the rule automatically.

This TIM playbook should be run as a job. The playbook runs on domain indicators and performs various checks to decide if they should be sinkholed.

If a domain is related to a campaign or a threat actor, or if it resolves to a malicious IP or has malware-related tags, the playbook will add a new tag to it in order to sinkhole that domain.

The playbook assumes that the user is exporting indicators with the sinkhole tag to an EDL (External Dynamic List) using the Export Generic Indicators Service integration in Cortex XSOAR. That EDL should be connected to PAN-OS. It also assumes that a DNS sinkhole is configured in the PAN-OS firewall. However, these are not required for the sole purpose of tagging the domains.

Note: This playbook has inputs from both the "From context data" tab and the "From indicators" tab.

This playbook queries the following PAN-OS log types: traffic, threat, url, data-filtering and wildfire. The playbook accepts inputs such as IP. hash, and url.

Deprecated. Use PAN-OS Commit Configuration v2 instead.

Block a user by tagging them in the Palo Alto Networks NGFW. This requires PAN-OS 9.1 or higher.

This playbook pulls Panorama content update file from shared SMB folder, uploads it to the Panorama server and installs it. It also uploads the content file to SCP folder for future use of the Panorama Device Deployment content updates engine which can be scheduled to pull the files automatically from SCP server.
This playbook should run in "Air Gap internal network" and works together with "Air Gap - Panorama Content Update Sender - External" playbook that runs in "Air Gap external network".

This playbook should be run as part of a Job in the internal network.

Playbook inputs:
panorama_admin_email - email address of the panorama admin for sending the output of the update.
smbshare - the SMB share of the content update folder. Example: Folder
scpwildfire - scp folder for wildfire content update file. Example: /home/demisto/Folder/wildfire
scpcontents - scp folder for contents (antivirus and apps) content update file. Example: /home/demisto/Folder/contents
scpantivirus - scp folder for Anti-Virus content update file. Example: /home/demisto/Folder/antivirus
smbpath - SMB path to the content files files. Example: Content

This playbook blocks IP addresses from External Dynamic List using Custom Block Rules in Palo Alto Networks Panorama or Firewall. The playbook receives EDL name as input, creates a custom "from" directional rule to block, and commits the configuration.

Query Panorama Logs of types: traffic, threat, url, data-filtering and wildfire.

This playbook utilizes the Dynamic Address Group (DAG) capability of PAN-OS.
DAG enables analysts to create a rule one time, where the group is the source/destination, and adds IP addresses dynamically without the need to commit the configuration every time.

The playbook checks if the given tag already exists. If the tag exists, then the IP address is added to the tag.

If the tag does not exist, a new address group is created with the given tag and a matching rule, and the configuration is committed.

Check coverage given a list of CVEs.

A wrapper script for the panorama-security-policy-match command that receives multiple values for the source, destination, and destination port arguments and performs the policy match for each combination of the inputs.

Classifies incoming PAN-OS Log incidents.

Maps incoming PAN-OS Log incidents.

List of CVEs to check

Target Firewall - Usually serial number

Version to install on the firewall e.g. 9.0.5 for PAN-OS

Manage Palo Alto Networks Firewall and Panorama. Use this pack to manage Prisma Access through Panorama. For more information, see the Panorama documentation.

This playbook blocks IP addresses from External Dynamic List using Custom Block Rules in Palo Alto Networks Panorama or Firewall. The playbook receives EDL name as input, creates a custom "from" directional rule to block, and commits the configuration.

This playbook creates a DNS sinkhole in a PAN-OS firewall. It does the following:

1. Finds a security rule that allows DNS traffic from the internal network to the internet using the "Security Policy Match" feature against traffic from the internal DNS server/s to the public DNS server.
2. Creates or adds an existing anti-spyware security profile to the security rule/s that were found.
3. Sets the DNS Signature Source under the DNS Policies configuration of the security profile with the "sinkhole" action.
4. Creates an address object for the sinkhole address so that it can be referenced later in a deny rule (the sinkhole IP constantly rotates).
5. Creates a new security rule to deny traffic to the sinkhole address object, in order to generate traffic logs for the compromised systems. The IPs of the compromised systems can then be retrieved using the "PAN-OS - Extract IPs From Traffic Logs To Sinkhole" playbook.

Once the configuration is completed, the playbook will create a Tag object and tag the relevant security rules to indicate that sinkholing is configured. That tag will be checked in consecutive playbook runs in order to minimize the actions done on the firewall and time time spent in the playbook execution.

How it works:
A DNS sinkhole can be used to identify infected hosts on a network where there is an internal DNS Server in-route to the firewall that causes the reference of the original source IP address of the host that first originated the query to be lost (the query is received by the internal DNS server, and the internal DNS server sources a new query if the name-to-IP resolution is not locally cached).

This causes the firewall to report observations of malicious DNS queries in the Threat logs where the source IP of the malicious DNS query is the Internal DNS server, which would force the administrator to look into the DNS Server logs to try to trace down what was the infected host that originally sourced the malicious DNS query.

After a security profile with a "sinkhole" action for domains that are listed in the DNS signature source is applied to a rule that allows DNS traffic from the internal server/s to the external one, the threat logs will show that requests from the internal DNS server/s were sinkholed. However, the compromised systems will not appear in those logs.

In order to find the IP addresses of those systems, a new rule denying all requests to our sinkhole address needs to be created. Since the infected systems received a forged DNS response (due to the security profile involved in our previous step), they will now try to connect to the sinkhole address, assuming it is their C&C server. The new rule will deny the subsequent attempts of those systems when they try to access the sinkhole address, and log them.

Assumptions:

• The domains that should be sinkholed are already in a DNS signature source. It can be one of the following sources available in PAN-OS:

1. An existing External Dynamic List (EDL) of type Domain configured in the PAN-OS firewall. Note: XSOAR simplifies the process of creating an EDL, with the Export Generic Indicators Service integration.
2. Palo Alto Networks Content-delivered malicious domains
3. DNS Security Categories available with a DNS Security subscription.

• There is at least one internal DNS server that is sending the DNS requests out through the firewall to a specific public DNS server.

Find if there is signature coverage for a specific CVE.

This playbook blocks a destination IP and service (TCP or UDP port) by creating a rule for a specific device group on PAN-OS.

This playbook accepts a PAN-OS static route configuration and creates it in the PAN-OS instance.

This playbook blocks IP addresses with 2 optional actions:

• Block IP addresses using Static Address Groups in Palo Alto Networks Panorama or Firewall. The playbook receives malicious IP addresses and an address group name as inputs, verifies that the addresses are not already a part of the address group, adds them and commits the configuration.

• Utilize the Dynamic Address Group (DAG) capability of PAN-OS. DAG enables analysts to create a rule one time, where the group is the source/destination, and adds IP addresses dynamically without the need to commit the configuration every time.
  The playbook checks if the given tag already exists. If the tag exists, then the IP address is added to the tag.
  If the tag does not exist, a new address group is created with the given tag and a matching rule, and the configuration is committed.

This playbook blocks URLs using Palo Alto Networks Panorama or Firewall through Custom URL Categories.
The playbook checks whether the input URL category already exists, and if the URLs are a part of this category. Otherwise, it will create the category, block the URLs, and commit the configuration.

This playbook blocks IP addresses using Custom Block Rules in Palo Alto Networks Panorama or Firewall.
The playbook receives malicious IP addresses as inputs, creates a custom bi-directional rule to block them, and commits the configuration.

This playbook queries the following PAN-OS log types: traffic, threat, url, data-filtering and wildfire. The playbook accepts inputs such as IP. hash, and url.

This playbook is designed to enhance the security level in PAN-OS firewalls by safely adding an Anti-Spyware security profile to a security rule.
The playbook provides control over the behavior when a a rule:

• Already has an Anti-Spyware profile
• Uses a security profile group, with or without an Anti-Spyware profile

The output of the playbook is the Anti-Spyware profile configured for the rule upon playbook completion. This can be:

• The initial profile, if untouched
• A newly overwritten profile
• A newly added profile

This playbook utilizes the Dynamic Address Group (DAG) capability of PAN-OS.
DAG enables analysts to create a rule one time, where the group is the source/destination, and adds IP addresses dynamically without the need to commit the configuration every time.

The playbook checks if the given tag already exists. If the tag exists, then the IP address is added to the tag.

If the tag does not exist, a new address group is created with the given tag and a matching rule, and the configuration is committed.

Creates or edits a Panorama rule and moves it into the desired position

Commit the PAN-OS Panorama or Firewall configuration. If specified as Panorama, it also pushes the Policies to the specified Device Group in the instance.

This playbook blocks IP addresses using Static Address Groups in Palo Alto Networks Panorama or Firewall.
The playbook receives malicious IP addresses and an address group name as inputs, verifies that the addresses are not already a part of the address group, adds them and commits the configuration.

***Note - The playbook does not block the address group communication using a policy block rule. This step will be taken once outside of the playbook.

This playbook deletes a PAN-OS static route from the PAN-OS instance.

This playbook should be run as a job. It is used to periodically remove the specified tag from domain indicators. It should be used in conjunction with the "PAN-OS - Job - Add Malicious Domains To Sinkhole" playbook, to stop domains from being sinkholed after a certain amount of time.
The idea is that traffic to malicious domains will not be redirected to a sinkhole address forever, as malicious domains tend to lose their malicious properties (become inactive, get taken down, or the malware using them is no longer used or maintained).

Network operations playbook that upgrades the firewall. You must have Superuser permissions to update the PAN-OS version. Note: This playbook should only be used for minor version upgrades. Major version upgrades will not work due to a change in the API key.

Network operations playbook that updates the version and content of the firewall. You must have Superuser permissions to update the PAN-OS version.

This playbook add domains EDL to Panorama Anti-Spyware. It assigns External Dynamic List URLs that contain domains to block to Panorama Anti-Spyware. You can create an External Dynamic List (EDL) and add domains to it using the Cortex XSIAM pack called "Generic Export Indicators Service".
We recommend using this playbook as a one-time job. Once EDL is created and assigned to anti-spyware, domains can be blocked by adding them to the EDL.

This playbook pulls Panorama content update file from shared SMB folder, uploads it to the Panorama server and installs it. It also uploads the content file to SCP folder for future use of the Panorama Device Deployment content updates engine which can be scheduled to pull the files automatically from SCP server.
This playbook should run in "Air Gap internal network" and works together with "Air Gap - Panorama Content Update Sender - External" playbook that runs in "Air Gap external network".

This playbook should be run as part of a Job in the internal network.

Playbook inputs:
panorama_admin_email - email address of the panorama admin for sending the output of the update.
smbshare - the SMB share of the content update folder. Example: Folder
scpwildfire - scp folder for wildfire content update file. Example: /home/demisto/Folder/wildfire
scpcontents - scp folder for contents (antivirus and apps) content update file. Example: /home/demisto/Folder/contents
scpantivirus - scp folder for Anti-Virus content update file. Example: /home/demisto/Folder/antivirus
smbpath - SMB path to the content files files. Example: Content

Block a user by tagging them in the Palo Alto Networks NGFW. This requires PAN-OS 9.1 or higher.

This TIM playbook should be run as a job. The playbook runs on domain indicators and performs various checks to decide if they should be sinkholed.

If a domain is related to a campaign or a threat actor, or if it resolves to a malicious IP or has malware-related tags, the playbook will add a new tag to it in order to sinkhole that domain.

The playbook assumes that the user is exporting indicators with the sinkhole tag to an EDL (External Dynamic List) using the Export Generic Indicators Service integration in Cortex XSIAM. That EDL should be connected to PAN-OS. It also assumes that a DNS sinkhole is configured in the PAN-OS firewall. However, these are not required for the sole purpose of tagging the domains.

Note: This playbook has inputs from both the "From context data" tab and the "From indicators" tab.

Query Panorama Logs of types: traffic, threat, url, data-filtering and wildfire.

This playbook sets up and maintains log forwarding for the Panorama rulebase.
It can be run when setting up a new instance, or as a periodic job to enforce log forwarding policy.
You can either update all rules and override previous profiles, or update only rules that do not have a log forwarding profile configured.

Deprecated. Use PAN-OS Commit Configuration v2 instead.

Creates or edits a Panorama rule and moves it into the desired position

This playbook searches for outgoing traffic to the sinkhole address in PAN-OS. It should be used after a DNS sinkhole was created using the "PAN-OS - Configure DNS Sinkhole" playbook. If a DNS sinkhole was created manually, you should verify in your PAN-OS firewall that there is an address object for the sinkhole FQDN "sinkhole.paloaltonetworks.com", and that there is a rule denying traffic to it from any source. You may specify the name of the deny rule if you know it, or you can let the playbook find the rule automatically.