I have done several migrations from multiple legacy devices to PAN-OS, and it’s clear that APP-ID migration is the essence of our existence as Palo Alto Networks architects, engineers, consultants, and partners or customers.
The core value of having a NGFW is to use its Layer 7 capabilities. Several vendors claim to have the same capability, or some way to achieve Layer 7 protection, however I found Palo Alto Networks devices to be the single one capable of doing it efficiently, and very elegantly.
Usually migrations are done in a “like for like” manner, and that is how it should be, however, when using a Palo Alto Networks device all migrations should happen in at least 2 phases.
Phase 1: Convert all port based rules in a “ like for like” manner and make sure that any mistakes made on the legacy device can be corrected before it’s replicated into a new candidate configuration to be sent into a PAN-OS device. Make sure to learn the basics of PAN-OS such as NAT rules and how Destination NAT rules are combined with Security policies. Observe the legacy environment and understand that these configs will not always bring zone information; the zone concept is new, or never existed in some vendors. For that reason a good migration should account for proper zoning discussions and proper design. As part of a good security project, segmentation should be always suggested and evaluated.
Once these elements are in place, security and NAT policies have been checked and corrected or validated along with proper zoning planning the migration will interpret and bring the legacy configuration file into PAN-OS. At this point the new candidate config should be ready to be sent to the PAN-OS device via API, XML file, or a SET command sequence.
Phase 2: The legacy config has successfully been migrated into PAN-OS, and the next step is what will make the device a NGFW. So far there are still just Layer 3, and 4 rules (port base firewalling).
Making sure that the traffic is flowing using the Migration Tool 3.0 again. Create a Connector, and point it to the newly migrated Palo Alto Networks device, capture logs for up 30 days straight.
It’s a good recommendation to analyze traffic every 2 weeks.
With the information gathered use the App-ID for all rules, or to a specific one if the project requires. The first step migrating to APP-ID is to separate known from unknown traffic. The first block to be analyzed should be the unknown traffic since we must establish what applications are traversing the PAN-OS device that are not in compliance with the environment and need to be blocked, or to have new APP-IDs created to proper identify these unknown as known and approved traffic.
As a best practice, separate these rules and do not delete them until each unknown hit is properly identified. If unable to identify the unknown traffic place them in a “deny” rule. The next step is to work on the known traffic, which are the Apps already identified by PAN-OS while watching the live traffic logs, even though they are identified correctly it doesn’t mean that they are valid, for instance some traffic may be passing through any rule as port 80 but actually connecting to a terminal service to access RDP via 3389. This is easily achieved by changing the ports on the application itself. Now that a list of applications are available, more analyzes is necessary for several reasons. Some APP-IDs have dependencies and within a single rule you may have the same dependency for more than one application, for instance https, web-browsing, and facebook will share the same dependency, SSL and HTTP, therefore less rules may be created with less dependencies if they are properly placed in the same set of rules. This is offered by the Migration Tool 3.0 when choosing the selected applications to be placed on a new rule or included in an existing rule, the Migration Tool itself displays choices for Application, Recommended, Dependencies, and Recommended with Dependencies. Once one of these options is selected these applications and dependencies are applied to the rule and this policy is now a NGFW policy, and no longer port based only.
There are other methods within the Migration Tool 3.0 that is called “App-ID Reconciliation” that brings all the APP-IDs for all rules with its dependencies “automatically or at once.” However, that process should be used with parsimony because a good migration needs to have an extensive analysis of each application and dependency to avoid unnecessary “pin-holes” in a security policy.
After all applications have been identified, as good practice clone the port based rules (the legacy rules) and place the new APP-ID rules ABOVE these legacy rules leaving that for an extra 2 weeks for future comparison and demonstration that the proper traffic is traversing the firewall and the legacy rule has NO hits. These rules should be removed and leave only the APP-ID capable rules.
Again, after these 2 weeks, there should still be some new unknown traffic that needs attention, and the process repeats until no more unknown traffic needs to be identified and all rules still containing any unknown traffic can be deleted.
At this point (4 weeks since phase 1 started), at least 85% of the rule base should be completely migrated to APP-ID based policies, and the remaining traffic can be analyzed further until the maximum use of APP-ID policies is adopted.
Another good practice during each step of each phase, is to take a snapshot of the configuration, and save it with name and date in case a roll back is necessary to validate an unknown traffic or even an APP-ID signature that needs further analysis.
APP-ID adoption assures the layer 7 inspection, and brings the legacy configuration file to a whole new world—
a more secure one.
