Policy Migration with App-ID and Encrypted Traffic
A retail company is migrating 3,200 legacy firewall rules from three vendors into PAN-OS. There are 42 business applications, 18 of which use dynamic TCP ports, and 6 use TLS 1.3 with encrypted SNI. The security team wants least privilege enforced with App-ID and dynamic address groups populated by Panorama tags from a CMDB. Legacy rules include broad any-any permits, 140 URL filtering exceptions, and 60 NAT rules with overlapping source NAT pools. The cutover window is 6 hours, and rollback must be possible within 15 minutes. The CIO insists that all rules be migrated with no application downtime, but the architecture team wants unused rules removed before cutover. There is no existing application dependency map.
1. Recommend a migration sequence and rule-ordering approach that meets the 6-hour cutover and 15-minute rollback.
Read the worked answer
I would not migrate the rule text directly. First, build an application dependency map from existing traffic logs and flow data, not from the legacy rule base, because the 3,200 rules include accumulated exceptions that do not reflect actual flows. Group the 42 applications by business criticality and by whether App-ID can identify them without decryption. During the cutover, place narrowly scoped App-ID rules above temporary legacy-style rules, and use PAN-OS policy test and hit-count logging to validate matches before removing the temporary rules. Broad any-any rules should be shadowed by explicit denies only after the dependency map is complete.
For rollback, keep the legacy path available through routing or a parallel interface, export the pre-cutover configuration, and use Panorama configuration versions so the previous policy can be pushed within 15 minutes. A six-hour window is realistic only if application owners sign off on the dependency map before the window; otherwise the no-downtime requirement and the remove-unused-rules requirement cannot both be met.
2. How should you handle applications with dynamic ports and TLS 1.3 encrypted SNI?
Read the worked answer
For dynamic-port applications, do not create wide port ranges. App-ID can identify many applications after the initial handshake, so use application-default service and allow the control channel explicitly, then permit the application by App-ID rather than by port. For applications that App-ID cannot identify, use a temporary service object with a documented expiry and a migration ticket; do not leave it as permanent policy.
TLS 1.3 with encrypted SNI prevents URL-category enforcement because the firewall cannot see the server name. Options are to decrypt the traffic with a forward proxy and a trusted certificate, to enforce by App-ID and destination IP or EDL where the application is identifiable, or to block the application until the business accepts decryption. I would not claim URL filtering enforcement for encrypted SNI without decryption. For the six affected applications, identify which ones can tolerate decryption and which must be exempted, then document the residual risk.
3. What controls would you put in place to prevent an any-any rule from being recreated during cutover?
Read the worked answer
I would use a combination of process and technical controls. Technically, place explicit deny rules with logging for known-bad or unapproved traffic above any temporary broad rules, enable hit counts and expiry dates on temporary rules, and use Panorama to enforce a baseline policy that cannot be overridden by tenant device groups. Any temporary broad rule should have a named owner, a ticket reference, and a review date.
Operationally, require a peer review for any rule with any source, destination, or service, and compare the post-cutover rule base against the approved baseline. Use policy optimizer or hit-count reports weekly to find rules that are unused or overly broad. During the cutover, monitor deny logs and session drops so that a missing dependency is caught and fixed with a narrow rule rather than a blanket permit. The any-any rule should be treated as an incident, not as a shortcut.