Expedition-LogAnalysisGuide v1.0.5
Expedition-LogAnalysisGuide v1.0.5
Expedition-LogAnalysisGuide v1.0.5
1
Palo Alto Networks, Inc.
www.paloaltonetworks.com
© 2020 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. You can find a list of our
trademarks at https://www.paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be
trademarks of their respective companies.
Revision Date: Apr 11, 2022
Contents
APP-ID Adoption 17
Retrieve APP-IDs 17
Split Rules Known/Unknown 19
Clone the existing rule 20
APP-ID Reconciliation 21
Common Steps for Machine Learning (ML) and Rule Enrichment (RE) 23
Machine Learning (ML) Settings 23
Importing Logs to Expedition 24
Exporting from NGFW 24
Manually Export Logs From MONITOR 26
Expedition as Syslog Server 26
Importing from Splunk 27
Configure M. LEARNING on the device 29
Processing Logs From Selected Devices 30
Debugging Log Processing 30
Rule Enrichment(RE) 31
Enable Rule Enrichment 31
Rule Enrichment Discovery 31
Import Discovered Rules back to Project 33
Debug the Rule Enrichment 34
Revision History 47
The Expedition provided below log analysis features that can help you to either migrate your service-port based
security policies to APP-ID based security policies or to refine your existing security policies based on traffic
logs.
● APP-ID Adoption: This feature is used when you have a set of service-port based security policies and
you would like to migrate those legacy security policies to APP-ID based security policies. Expedition will
retrieve APP-ID info from the active log connector, this feature does not require Firewall logs stored in
Expedition.
● Rule Enrichment (RE): This feature is used when you would like to tighten your existing security policies
to remove “any” in security policies. For example, you have a security policy that contains “any” in either
applications, users, zones, or services fields. This feature will auto discover APP-ID and service port info in
the firewall traffic logs to see if it matched the application-default ports and help you to tighten your
security policies to replace “any '' with correct APP-ID and service ports in the security policy. Expedition
will process firewall log in csv format , so this feature does require Firewall logs stored in Expedition.
● Machine Learning (ML): This feature will suggest new sets of security policies based on analysis of the
firewall traffic logs. It is often used in Greenfield deployment or when you have a set of rules that’s more
permissive than required and you don’t know what security policies are required. The ML process will
identify servers, consumers and provide all the security policies including source, destinations, APP-ID,
and service-ports . Expedition will process firewall log in csv format , so this feature does require Firewall
logs stored in Expedition.
Depending on your use case , you will choose different log analysis features. Below are some use cases
and what features you can use.
● Use Case #1
I am clear on what security policies are required in my environment. I want to migrate all my
service-port based ( Layer 4 )security policies to APP-ID (Layer 7) based security policies.
Feature: If you are clear on the security policy requirements, you will choose APP-ID Adoption, with
this feature, you do not need to store firewall logs in Expedition. (if the PAN-OS device is running
PANOS 9.1 or later, it is recommended to directly use Policy Optimizer feature in PAN-OS)
● Use Case #2
I want to migrate all my service-port based ( Layer 4 )security policies to APP-ID (Layer 7) based
security policies and would like to see if Expedition can auto suggest new APP-ID based rules based on
live traffic logs.
● Use Case #3
I am not clear on what security policies are required in my environment , also I want to migrate all my
service-port based ( Layer 4 )security policies to APP-ID (Layer 7) based security policies.
Feature: Machine Learning (ML). This feature will help you by suggesting a new set of security policies
per APP-ID with detailed source and destination info.
● Use Case #4
Most of my security policies are APP-ID based security policies and some of them contain “Any” in the
service field, I would like to see if I can tighten the security policies to only use “application-default” or
the ports that’s needed.
Feature: Rules Enrichment (RE). This feature will help you refine the existing APP-ID based policy.
● Use Case #5
We have security policies that are more permissive than what we really required and I would like to
know what security policies are actually required.
Feature: Machine Learning (ML). This feature will help you by suggesting a new set of security policies
per APP-ID with detailed source and destination info.
● Use Case #6
This is a greenfield firewall deployment and we are not clear on what security policies are required ,
most of the security policies are too permissive.
Feature: Machine Learning (ML). This feature will help you by suggesting a new set of security policies
per APP-ID with detailed source and destination info.
1. Adding a PAN-OS device in the device tab and retrieve latest contents
2. Creating a new Expedition project
3. Adding Panorama or firewall as Log-Connector
4. Importing the latest running configuration from PAN-OS device (Panorama or firewall)
5. Selecting Security Policies
6. Required Steps for ML and RE (For APP-ID Adoption, please jump to step 7)
a. Configure Machine Learning settings
b. Importing traffic logs to Expedition
c. Configure M.Learning on the device
d. Processing the logs from the selected PAN-OS device
7. Please refer below individual sections for the different subsequent steps
a. APP-ID Adoption
b. Rule Enrichment (RE)
c. Machine Learning (ML)
8. Push Modified Security Policies back to PAN-OS Devices
Please follow the steps below to add the PAN-OS device in the device tab and retrieve the latest contents form
the device.
Expedition supports all the PanOS versions since version 7.0 up to 10.x. Let’s follow an example on how to create
a new Device and import the configuration and securely store it on Expedition.
c) A new window will be shown to fill with all the information required.
● Device Name: It’s the name you want to call your firewall
● Model: Palo Alto Networks device model
● Hostname/IP: IP or name used to connect to your firewall, if it’s a name Expedition needs to know how
to resolve it, check the DNS used by Expedition it’s the right one. You can check from the CLI
# sudo cat /etc/resolv.conf
● Port: where the management is running, by default 443
● Serial #: This field is required and will be used as an Index to use the right one.
● Serial # HA: In case this firewall is part of a Cluster you can set the HA serial. This will matter for the
Machine Learning module which will be explained in another chapter of this document.
e) The Edit Device window now is displayed. From the Configuration Tab let’s add our credentials to connect to
the firewall and Expedition will request the firewall to generate a new API key.
notice the generated API Key will be valid as long as the user doesn't change the password from the firewall.
● Auth. Type: How we want to authenticate against he firewalls, we can choose to provide
username and password and let Expedition request the API key to your firewall or in case you
already have the API key choose API KEY and paste your key in the text field
For small environments where you will have only one user and it will be admin there is no need to check
the Apply all Roles and keep that key only attached to the admin Role.
● Click on the Add blue button to generate the Keys.
For debugging purposes there is a file on the devices folder called “debug.txt”. The content of this file comes from
the daemon who controls the access to the firewalls so expect to find the API requests made to retrieve the keys
or dynamic reports in some cases, for security we stripped out the parameter key from the request. So, in case you
want to re-use an API call you will have to add at the end the &key=<and your API key>
You can do the same steps used to create a new Next-gen Firewall, generate the API keys and retrieve the
Contents, now a new tab called PANORAMA DEVICES will be active, so click on that tab.
1. If we need to play with the firewalls connected to that Panorama we need to know them first, so click on
Retrieve Connected Devices. This will request that information to Panorama and create the devices on
Expedition but referencing them under this Panorama device. That means all the requests we will
generate to talk with that Firewall will be done using Panorama as a Proxy.
2. In case we need to download the configuration of one of these devices just select it from the list and click
on Retrieve Contents. This will allow you to import the configuration of that firewall into your project
once we create the project.
If you have one firewall created in Expedition and then you import Panorama and the that firewall it's listed as one
of the connected devices to that panorama (Serial Number is used as index here) the existing firewall in
Expedition will go under the Panorama management meaning from that moment the API requests against it will
pass through Panorama.
From the Devices view we can hide all the connected devices to its Panorama by using the following buttons from
the Panel header
In Expedition each project has its own database. You can create as many projects as you want.
Let’s create a new project and see the workflow we have to follow:
In case we selected a device, this will automatically be added to your project, you can edit these settings to
manage users and devices from within the Project.
Manage Devices
If we want to allow access to import a configuration from an existing device or enable the users to generate API
calls to be sent to the device you must allow the project to have access to that device.
To do it just click on Devices and select the firewalls you want to allow and move them to the right panel
Enter into the Project and Import the configuration from the device who has the configuration (Panorama or a
firewall) and remember that device must be in your Allowed Devices list.
Under the plugins tab, add a log connector. Give it a name, select the device and the device group, the firewall, and
choose the time period for log analysis. This view will show you Device-Groups or Vsys based on the configuration
you were importing as a Base configuration in your project. The time period can be custom as well.
Once you select the correct vsys or device group, you will see the background color of policies turn from gray to
white , that means you can now edit the policies, in below example, I have a firewall configuration and the security
policy is in vsys1 , so I will select vsys1.
❏ Retrieve APP-IDs
❏ Split Known/Unknown Rules
❏ Clone the existing rule
❏ APP-ID Reconciliation
Retrieve APP-IDs
Go to “POLICIES” -> “Security” , select the Port-Based security policies , and right click “Retrieve APPs(Fast)” or
“Retrieve APPs(Slow)” -> “Selection” , alternatively , you could also choose “All Rules” if most of your rules are
port-based.
After the Retrieving APPs process finished , you will see a new column “APP-ID via Log” shown below and it listed
all the APP-IDs found in the firewall traffic logs . Below is the result when you select “Retrieve Apps (Fast)” , the
report will be generated faster without traffic size detailed, for an environment that has a lot of traffic logs, please
select this option for faster processing.
After you performed the step, You will see the original security policy got split into two rules , original rule will
contain known APP-IDs in the “APP-ID via Log” field , Expedition cloned another rule on top of the original rule
and add a prefix “Unk-” to the original rule name , the example below, the original rule name is “AllowAllOut”, the
“Unk-AllowAllOut” contains the “Unknown-TCP” and “Unknown-UDP” as shown in below screenshot:
This action will clone the existing rule and put it under the existing rule like below screenshot with prefix “CL-”, the
example below, the original rule name is “AllowAllOut”, the new cloned rule will be named “CL-AllowAllOut”. This
is identical to the original service-port based rule. The purpose of this step is to keep the original rule in the
bottom of the APP-ID based rule.
1. Application - The application field will be replaced with APP-IDs seen in the “APP-ID via Log” field.
2. Recommended Application- The application field will be replaced with recommended APP-IDs. For
instance if the APP-ID seen in the traffic log is “slack-base”, the recommended APP-ID will be “slack”
which is a parent APP-ID that covers “slack-base” and other APP-IDs under the same parent.
3. Recommended Application & Dependencies - - The application field will be replaced with recommended
APP-ID and it’s dependencies , for example : if “gmail-chat” is seen in the “APP-ID via log” field , and it will
add it’s parent application “gmail” also the dependencies , “google-base” to the rule as well. You can find
APP-ID dependencies by looking up the Application database in the PAN-OS device.
Recommended Application:
After the step is performed , you will see the original service-port based rule become a APP-ID based rule as
shown in below screenshot, and the APP-IDs shown in APP-ID via Log field will be move to “Application” field of
the rule , the “insufficient-data” won’t be move to Application field , this is seen when Firewall does not have
enough packets to determine the APP-ID.
To configure it and specify where the Parquet files will be stored after the log process we have to navigate from
the Dashboard to the SETTINGS tab, then select the M.LEARNING tab.
Step 1: Check the IP address shown in Expedition ML Address is your own IP address if you are running in
standalone mode. If not, put the IP address of the other Expedition VM instance with more hardware resources
than the one you are currently configuring.
Every time you enter here if the ip address is 127.0.0.1 Expedition will replace it by the one shown in the browser’s URL.
Step 2: Type where you want to store the data after the process in parquet files. You could specify a different path
to store your firewall traffic logs. If you don’t have any folder created in Expedition let’s create one, in this case we
will use one named PALogs.
with these commands we are creating and allowing “apache” to have write access to it.
Step 3: click on the Save button located at the bottom bar – right to activate the changes.
If at some point we want to start fresh and remove all the data processed as parquet files we can click on the red
button “DELETE ALL DATA STRUCTURED FILES”. That process cannot be undone.
Depending on your platform and or your log storage strategy, you may want to choose between those four
methods. For instance, you may have a large amount of firewalls deployed on prem and on cloud environments
that you would like to analyze and that are managed by a Panorama device. In such a case, probably the best
strategy would be to use Expedition as a Syslog server and request the firewalls to submit the traffic logs to
Expedition via a Syslog log forwarding profile.
Maybe you already are having a Syslog log forwarding profile on your security rules to store the traffic logs in a
Splunk instance. In that case, maybe the best approach would be to select the fourth option.
Below we describe the four alternatives and discuss the benefits of using each one of them.
Note: The PA-7000 Series and Panorama devices do not offer such log Export functionality or it is limited to the first
1.000.000 entries
https://docs.paloaltonetworks.com/pan-os/10-0/pan-os-web-interface-help/device/device-scheduled-log-export.
html
Actions
We will configure the Scheduled Log Export with the following settings.
● The log type to select is “traffic”;
● we will set the Hostname with our Expedition IP or hostname (if resolved by your DNS server);
● the start time could become something like “00:15” or a time that you consider suitable for initiating a
SFTP transfer that could be between few MBs up to a couple or TBs (depending on your infrastructure
traffic);
● we will set the destination folder in which traffic logs will be stored in Expedition. We recommend using
the folder /PALogs, which may already exist in your Expedition instance, and allows the users “expedition”
and “www-data” to access it;
● we will set the username as “expedition”, which it is an Expedition cli user that we have by default created
in the Expedition VMs and that has privileges to store files in required file system spaces; and
● we will set up the password as “paloalto” or the defined password that you have for the expedition user in
your Expedition VM.
When you create this for the first time you should run the “Test SCP Server connection” twice. The first time in
order to exchange the SSH keys and the second to write a test file and validate that the PanOS Firewall can write
in the folder provided under “path”.
Benefits
On the positive side, this action is performed only once a day and can be programmed to execute during the night
or other low load period of the day.
Additionally, we can be confident that all the traffic logs will be submitted to our Expedition if there is enough
space in our Expedition VM to host the file, as the transfer is performed via a SFTP connection.
You do not need to have the VM running all the time to receive the traffic log files. If you have set up the
scheduled time to be at 10:00am, this gives you the chance to have the Expedition VM off during night hours and
bring it up again before the SCP is going to take place.
Drawbacks
This approach requires firewall configuration changes, in order to set up a periodic log export.
You can always go into any firewall from Palo Alto Networks and from the Monitor tab export the logs in CSV
format and upload that CSV file to Expedition for processing, concretely, into your “PALogs” folder.
The format of those CSV files would be the same as executing a Scheduled Log Export.
Actions
Log into your PANOS device and, under the Monitor tab, enter the filter that you would like to use for collecting
traffic log entries. For instance, specify the rule name and destinations that you would like to study.
Benefits
This option offers us an opportunity to collect specific logs from the firewall, selecting a period of time, specific
sources, destinations, and/or rule names that we would like to bring into Expedition and further study.
Drawbacks
However, this approach would not be suitable for a periodic task, as it requires manual connection to the Firewall,
set the filter logic we want to apply, export the log in a CSV format and manually upload it into the “/PALogs” folder
Expedition can become a Syslog server that can receive the logs generated by platforms like the PA7000 or in any
case you want. And we can submit traffic log entries to our Expedition using a log forwarding profile.
Actions
Become root in your Expedition instance to navigate to the following folder.
sudo su
cd /var/www/html/OS/rsyslog
In that folder you will find 3 examples for the rsyslog.conf you can use:
● rsyslog.default-tcp,
● rsyslog.default-tcpudp and
● rsyslog.default-udp
Each one listen in the specified protocol and port and allow Expedition to accept syslog from some specified
networks (in the examples we define 127.0.0.1, 10.11.29.0/24, 172.16.26.0/24, *.paloaltonetworks.com) and
store them in “/PALogs”.
Restart the VM to make sure that all required syslog modules are activated. Restarting the rsyslog service may
not be enough as dependent modules may not have been initialized with your required settings.
Benefits
Using Expedition as a syslog server may help you determine the security rules that you are interested in studying,
as we can determine the rules that are going to have the log forwarding profile applied.
Drawbacks
This option requires you to activate Expedition as a syslog server and to tune the rsyslog settings to allow
connections via TCP and/or UDP from a specific set of IP addresses.
This option requires your Expedition instance to be available 24x7, as traffic logs are submitted to your
Expedition in real-time. If the syslog entries are defined to be submitted using UDP protocol, there are higher
chances that some traffic logs may be lost if the connection with Expedition is interrupted.
Finally, there is a chance that you have already log forwarding profiles active in your devices to submit the traffic
logs to an Splunk instance. We have prepared Expedition to be able to collect traffic logs information for Splunk,
generating the API queries that would be required to access those entries.
As we do not require the whole amount of information that traffic logs contain, the queries that we generate to
interact with Splunk have already been constructed to request only the needed log fields and to create
aggregations already in Splunk in order to reduce the amount of data that needs to be submitted from Splunk to
Expedition.
Actions
First, make sure that your Splunk instance has the “Palo Alto Networks App for Splunk” and “Palo Alto Networks
Add-On” installed, as this will provide the required schema to query Palo Alto Networks logs. For more details on
the apps, please refer to the link: https://splunk.paloaltonetworks.com/
From Expedition UI, select the device that you would like to retrieve traffic logs from. On the M.Learning tab, click
on the “Query Logs from Splunk®” button to open the Splunk query window.
Fill in the form to generate the individual queries that will be sent to the Splunk instance. In the figure below, we
have provided the IP address of our Splunk instance using the default’s Splunk port 8089 and using the “admin”
account that has API permits. We have defined the period of time we want to collect data from, in the example,
between the first and the third of November 2020 and using the “paloalto” index to increase the performance on
Splunk while loading the log files that refer to Palo Alto Networks devices.
To generate the queries, click on the “Prepare Queries” button. This will create one query per day and those will
be presented in the bottom grid. At this point, we can fire the queries to Splunk by clicking on the “Retrieve Traffic
Logs” button.
At this point, the queries will be submitted to splunk and Expedition will be monitoring the query status to
download the results once Splunk has reported the query as completed. Depending on your Splunk settings and
the number of queries submitted, some of them may be in a queue.
Once the query has been completed in Splunk, and Expedition has downloaded the results, you will be presented
with the message “File successfully downloaded”, and you should be able to display the file in the prior M.Learning
view.
Drawbacks
It requires a user account with API querying permission in order to interact with Splunk.
Currently, this approach offers manual query generation and execution and it needs to be executed for every
firewall that we want to collect traffic logs from.
In the future, we will provide opportunities to retrieve Device Groups traffic logs directly from the Panorama
point of view.
From here we will assign the PATH where our logs have been imported in Expedition, or via SCP or SYSLOG, then
click on Search Files to allow Expedition to search on it and show us all the related logs to the device we are
configuring.
Expedition will filter out and show you only the files from the configured folder (and recursively from there) only if
the serial number configured on the device (or the HA Serial) matches the serial seen in the csv files. So, if you
configure the device and you set the serial “123” but the CSV content talks about the serial number “567” ; those
logs won’t be shown under the view.
By default, the first time Expedition sees a new file is flagged as a NEW file. When clicking on Process files all the
NEW files will be converted to Parquet.
We can select an action for “After Process” like we want to delete the files after transformation to parquet to
reduce the space we need to store the raw data.
If we want to avoid processing some file we have to just select it and click the icon (Ignore File), that will tell
Expedition to skip that file at the Process time.
In case you are using SYSLOG to receive logs in Expedition check the “Log Files come from Syslog” this will
prevent you to transform the logs from Today since it’s a file is still opened and used by the syslog server before
the log rotation that will occur when we change the day at 00:00, so this check will hide the log from Today until
Tomorrow.
While Expedition is processing the logs, we can view the progress and potential issues from the CLI by doing this:
tail -f /tmp/error_logCoCo
As we described before RE it's useful to reduce the surface attack in your current security policies, today with RE
we can remove all the “any” from our Rules. One of the most popular use cases is to help to enrich a policy based
on services with App-ID for instance.
After tag the Rule click on DISCOVERY green bottom located in the bottom bar (center)
A new window will pop up. Click the TAB called RULE ENRICHMENT. Then you have the option to override the
Time Range defined previously in the LOG CONNECTOR, if you define like the last 30 days in the connector you
can select a specific time frame like example and that will take preference from the connector configuration. Also
Once the analysis has finished we will get something like this, this information is based on the logs previously
processed and stored as parquet and filtered by the log connector and the name of the rule tagged as RE (you can
tag as much rules as you want and perform the analysis at the same time for all the rules, each one will create its
own results)
To import the information to our Rule we have to click on the option “IMPORT INTO PROJECT” under the
“Analyze Data” button.
I will select Applications, Service and Source, for the Source I will check IPs that means bring the IP address, I can
choose the regions found instead.
We can override the current (original) rule with the new data to improve that rule or we can let Expedition clone
the existing rule and import the new data on the new cloned rule, that cloned rule will be stored on top of the
original one. This will allow you to run more analysis in the future to ensure you don’t miss anything because the
period of time analyzed was not enough to capture all the data.
Click on “Import”.
How we left “Replace Rule” instead of cloning, Expedition will automatically Clone the Original Rule, bring the
new data on top and disable the current Rule for you to validate that everything looks good after the enrichment,
you can remove the disabled rule at the end of the process.
When we use Rule Enrichment Expedition will group all the data by Rule Name and it will create a rule with all
the traffic seen with Users, another one with the traffic seen without users, another one with the traffic where
the applications where found through their default-port and another one with the traffic where the applications
were found on a port different the default port that means with Rule Enrichment we will get a maximum of 4
rules by each rule we are analyzing.
tail -f /tmp/error_SecRulesEnrich
on the red button “DELETE ALL DATA STRUCTURED FILES”. That process cannot be undone.
Machine Learning is a more sophisticated process than RE. ML was designed to help companies to know what is
going on in the network and translate that to security policies based from the beginning on App-ID and User-ID.
The most common case we cover is a “Greenfield” where you have one rule covering all the traffic and Expedition
suggests all the new rules that cover the traffic seen.
In the ML process Expedition identifies the Servers in the networks based on some analysis since we support
environments with asymmetric traffic this analysis is critical at the time to suggest new rules. Here are the
specific steps for ML:
Example like below , we want to replace below one rule that is too wide open since it allows everything between
two networks.
We want to know what is exactly happening and create the rules based on what we have learned.
First step is to enable the “Machine Learning feature “ by highlighting the rule and right-clicking to select
“Machine Learning” -> “Monitor” -> “Selection” .
After tag the Rule click on DISCOVERY green bottom located in the bottom bar (center) , select “Machine
Learning”
● Cloud: Means Expedition will consider some applications as Cloud, when found in the traffic the
destination ip addresses will be considered as “any” since they can dynamically change and doesn’t make
sense to keep the ones the network resolved in the moment we captured the traffic.
● Common: Are considered common applications that are present in all the networks and generate a huge
volume of logs. Ex: ping, dns, ldap. In some cases you won't want to waste resources to analyze logs
related to those applications to speed up the analysis for other applications. In case Expedition finds
traffic regarding those applications will be considered as source “any '' and destination “any ''. Ex: ping
Rule suggested ANY – ANY – ping – ALLOW
● Peer-to-Peer: All the applications classified as peer to peer by Palo Alto Networks.
● Global: All the other applications. Expedition will analyze sources, destinations, users, service ports to
suggest Rules based on how they are consumed.
Once you select the Application categories, you can then click on “Analyze Data”
Once the analysis has finished:
Discovered Servers
This is the list of the servers we found from the logs after analyzing who is who in the network. This is
important to Expedition to understand the flow of the communications.
This list of servers can be exported for an offline review by clicking on the Export Excel.
We can group the discovered Servers by Applications and see how many Applications each Server has.
● Point your mouse over the column “Server IP Address” and click on the arrow and click on the “Group
by this field” In this example nothing will change but in real life environments will give you the
applications served by each server we used.
It will then switch to the advanced option window like below, you could specify you want to import source or
destination as /24 subnet when you see more than “x” IPs in the same /24 subnet. In the example, we use “2” , if
the suggested rules contains more than 2 different IPs (10.0.0.1 and 10.0.0.2) in the same subnet , the import will
change the source to “10.0.0.0/24” subnet instead of import them as 2 single IPs.
tail -f /tmp/error_SecRulesLearn
After you reviewed the modified security rules and ready to push the changes back to the PAN-OS device, you will
go to “Export” ->”API Output Manager”, click on the “[Step1] Generate API Requests” to generate all the API
calls. By default the mode will be “Atomic” , here are the details of each mode:
● Mega: generates one single API call containing the complete XML configuration.
● Atomic: generate one API call for each section in the configuration, such as address objects section,
service object section, etc. In case of multiple DGs, we may obtain one API call for each section in the DG.
● Subatomic: generate an API call for every element in a configuration. For instance, one API call for each
address object in a configuration. This may be required when only certain objects should be submitted to
the device.
● Clear: generate API calls to delete the content of the desired section
Tag
Address objects
Address-Group objects
Service objects
Service-Group objects
Security Rules
You can filter the section of the configuration by selecting the section on the filter dropdown menu. check on the
API calls you would like to send to the PAN-OS device, click on “[Step 2] Send API Requests”
Select the Device you want to send the API call to , then click on”SEND”
After you send all the required API calls, you can then verify changes in the PAN-OS device and Commit the
changes.