1. Migrating from Juniper to Palo Alto Networks
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level 1 1

2. Agenda Overview Key Differences Key Reasons to Migrate
Migration Best Practices
Q&A

3. Applications Have Changed, Firewalls Haven’t
The fundamental problem that we set out to solve is this: applications have changed, the firewall has not kept pace. And what we sometimes forget is that the firewall was designed to act as the security boundary for your network. It sees all traffic and enables access.
The evolution of the application landscape has not happened over night – although it has accelerated dramatically in recent years.
Antivirus applications began using port 80 as their avenue for updates back in AV is not a web application. The vendors did this to simplify access and better support their customers.
AOL instant messenger (AIM) used to prompt you with “Find an open port?” if it could not establish a connection.
BitTorrent, Skype both port hop and MS sharepoint uses a range of ports.
Finally, MS-Lync – the messaging component for MS live 365 requires port 443, 3478 (stun), 5223 and a range of ports between 20,000-45,000 and 50,000-59,999.
These are just a few examples of how applications have changed to mainly simplify access.
Think about it, if you’re an application developer, you want your application used – so you will do what is necessary to achieve that goal.
The ramifications of these changes result in an increase in business and security risks - applications act as (1) a threat vector ( delivering a video URL but is really malware) and (2) they are threat targets (SQL injection attacks), and (3) they act as the command and control/exfiltration avenue.
So while applications were rapidly evolving, port-based firewalls were stuck in the late 1990s – they did not keep pace. To try and address the problem, the industry’s response has been to sell more stuff!
Goals of this slide.
This slide establishes the problem: Firewalls have always been designed to be the security boundary. They have not kept pace with the application trends.
Use interesting examples that are not Facebook and Twitter to show that applications have changes firewalls have not.
Use examples of applications that may use evasive techniques to simplify use and in so doing, avoid detection.
Use applications that change state as added functions are used – they are hard for UTMS to identify, control and enable.
Network security policy is enforced at the firewall
Sees all traffic
Defines boundary
Enables access
Traditional firewalls don’t work any more

4. The Firewall as a Business Enablement Tool
Applications: Enablement begins with application classification by App-ID.
Users: Tying users and devices, regardless of location, to applications with User-ID and GlobalProtect.
Content: Scanning content and protecting against all threats, both known and unknown, with Content-ID and WildFire.
Lets talk for a moment about how our technology can enable applications, users and content – along with your business.
Safe enablement policies begin with accurate classification of the application using App-ID. App-ID uses a combination of signatures, application and protocol decoders, and heuristics to identify all applications, across all ports, all the time - as soon as traffic hits the firewall. The application identity then becomes the basis for your positive enforcement model firewall policies. This means you can safely allow or block certain applications, or specific functionality within or across multiple applications like file sharing or instant messaging.
Users make up the next piece of a safe enablement policy. We can tie users, regardless of the device platform, to the application with User-ID and GlobalProtect. User-ID integrates with the widest range of directory services on the market, including Active Directory, and Microsoft Exchange (which brings you Linux or MAC-OS users and LDAP to enable you to build policy around users and groups of users by name, not just IP addresses. An API is also available for non-standard directory integration. For remote or traveling employees working on a laptop, an iOS or Android platform from say, a Starbucks or a customer site, we can include them in the safe application enablement policies with our Global Protect end point solution.
Scanning the content within the application is the final enablement policy and that is delivered by Content-ID. IPS, AV, antispyware and URL filtering within Content-ID will allow you to apply very specific threat prevention profiles to your business critical traffic and/or users. The threat prevention engine is stream based and it utilizes a uniform signature format. It looks for a combination of things in a single pass, unlike the silo based AV, IPS and URL filtering. Wildfire provides the ability to identify malicious behaviors typically associated with zero-day attacks found in executable files by running them in a virtual environment and observing their behaviors. When a malicious sample is identified, it is then passed on to the signature generator, which automatically writes a signature for the sample and tests it for accuracy. Signatures are then delivered to all Palo Alto Networks customers as part of the daily malware signature updates.
This slide summarizes one of our Core Value Propositions and Main Differentiators from the other vendors: The ability to SAFELY ENABLE APPLICATIONS, USERS AND CONTENT.
Now, real quick I want to talk about how the device is sold: We sell a purpose built appliance with a purpose built operating system. Included with the base appliance are all the firewall capabilities: App-ID, User-ID, SSL and IPSEC VPN, SSL decryption and re-encryption, QoS, and Data Filtering.
If you are interested in Threat Prevention, URL Filtering – or - Global Protect, these would each require a separate license.
©2013 Palo Alto Networks. Confidential and Proprietary.

5. Controlling Applications, Content and Users
Palo Alto Networks allows you to build enablement policies that are based on business relevant elements – applications, users and content. It makes perfect sense, right? Your business runs on applications, users and content – shouldn’t your security policies?
At the perimeter, you can reduce your organizations threat footprint by blocking a wide range of unwanted applications and then inspecting the allowed applications for threats - both known and unknown.
In the datacenter, application enablement translates to confirming the applications users and content are allowed and protected from threats while simultaneously finding rogue, misconfigured applications - all at multi-Gbps speeds. In virtualized datacenter environments, organizations can apply consistent application enablement policies while addressing security challenges introduced by virtual machine movement and orchestration.
Expanding outwards to enterprise branch offices and remote users, enablement is delivered through policy consistency - the same policy deployed at the corporate location and is extended, seamlessly to other locations.
In short, our technology allows you to enable applications for users and protect the associated content – without hindering your business.
©2013 Palo Alto Networks. Confidential and Proprietary.

6. Broad Range of Hardware Platforms
Firewall
Firewall Throughput
Threat Prevention Throughput
Ports
Session Capacity
PA-7050
System: 120 Gbps
System: 60 Gbps
24 SFP+ (10 Gig)
48 SFP (1 Gig)
72 copper gigabit
24,000,000
PA-7000-NPC
NPC: 20 Gbps
NPC: 10 Gbps
4 SFP+ (10 Gig)
8 SFP (1 Gig)
12 copper gigabit 4,
PA-5060
20 Gbps
10 Gbps
4,000,000
PA-5050
5 Gbps
2,000,000
PA-5020
2 Gbps
8 SFP
1,000,000
PA-3050
4 Gbps
500,000
PA-3020
1 Gbps
250,000
PA-2050
500 Mbps
4 SFP
16 copper gigabit
PA-2020
250 Mbps
8 copper gigabit
125,000
PA-500
100 Mbps
64,000
PA-200
50 Mbps
4 copper gigabit

7. Juniper SRX Overview SRX = Security services gateways.
Successor to the NetScreen/ScreenOS products
Uses JUNOS – a high performance routing OS
Two platform families
Enterprise and datacenter (SRX1400 to SRX5800)
Small, distributed enterprise (SRX100 to SRX650)
AppSecure addresses next-generation firewall features
NGFW feature components added to Stateful inspection
AppTrack (visibility), AppFW (id apps), AppQoS (QoS) and AppDoS (DoS)
Application identification and control are performed after an initial port-based firewall decision is made

8. AppSecure

9. Three Reasons to Migrate

10. Top 3 Reasons to Migrate Context-based policy management
Positive control model?
APT prevention

11. context-based policy management
file-sharing
URL category
pdf
file type
roadmap.pdf
file name
bjacobs
user
prodmgmt
group
canada
destination country
SSL
protocol
HTTP
slideshare
application
slideshare-uploading
application function
unknown
URL category
shipment.exe
file name
china
destination country
344 KB
ANIMATED SLIDE - practice
344 KB. Somewhat meaningless. Sure, its roughly 1/3 of a MB, but so what.
<click> traditional security will give you info on the IP addresses, and the port. So now you have a bit more context, but not much more. Its something going across port 443. may or may not be using SSL. But what else do you know?
<click> But what if you had who the user was, which group they are in?
<click> and wouldn’t the actual protocol be helpful?
<click> and the application, and possibly the function in use?
<click> the file type and file name
The context of the traffic being observed is more meaningful, allowing you to make more intelligent decisions, respond more rapidly to security incidents, generate more complete reports.
Think about what you can do, from a security perspective, with this data.
source IP
destination IP
tcp/443
destination port

12. Shared Context Highlights the Value of Integration
Reporting | Logging | Forensics | Panorama
Apps | Functions | Users | IPS | AV | AS | Malware | QoS | Files | Patterns
Safe Enablement Policies
Applications
Users
Content

13. Operational Efficiency: Unified Policy Control
Users/User Groups
Application
Threat Prevention
Antivirus
Anti-Spyware
Vulnerability Protection
URL Filtering
WildFire
We don't use the default port for identifying applications - it is only used when you set policy and use the service column.  For example, if you created a policy to allow squirrelmail and set service to "application default", then we would only allow squirrelmail to run on port 80.  If we decrypt SSL and see squirrelmail inside (port 443), then we would block it with the policy. 
Single Policy for application, user and content (threat prevention)

14. AppSecure Management Different policy management components
AppSecure Management Challenges
Multiple management components required – Space, CLI, STRM = more work, less visibility & control, slows responsiveness
User information is not natively integrated – requires UAC + Pulse = more work, more devices and components to manage, less effective

15. Application Control in the Firewall
positive control
Application Control in the Firewall
Allow Facebook X
Firewall
App-ID
Policy Decision
Key Difference
Benefit
Single firewall policy
Less work, more secure. Administrative effort is reduced; potential reconciliation holes eliminated.
Positive control model
Allow by policy, all else is denied. It’s a firewall.
Single log database
Less work, more visibility. Policy decisions based on complete information.
Systematically manage unknowns
Less work, more secure. Quickly identify high risk traffic and systematically manage it.
Shared context
Less work, more secure. App, content and user are pervasive - visibility, policy control, logging, reporting
We believe application enablement belongs in the FW, not in a secondary scanning process.
Recall that a firewall uses a positive control security model – meaning, allow what you define, block all else.
Using that as the premise, here is how we might enable facebook. Single policy to allow it, [CLICK} and all else is blocked.
The benefits of the application enablement in the FW are significant
Single rule base means less work – competitive offerings require multiple policies with duplicate data entry. Better security with a single policy – eliminates possible traffic gaps, reconciliation holes left open by the two policies.
Positive security – means new apps that uses may want to try are block implicitly (or explicitly depending on the practices followed).
Single log db means a single view into whats happening on the network.
Most importantly, FW based enablement gives you more control over unknown traffic. Unknown traffic represents 5-8% on every network. We knew from day 1 unknowns would exist – it can be an internal app, a commercial off-the-shelf (COTS) app, or a threat. Any traffic not IDed by our mechanisms falls into unknown udp or unknown tcp. From there, you can quickly analyze it, set policy on it categorically, and systematically manage it.
For unknown Commercial Applications, using visibility tools, you can quickly determine if the traffic is a commercial off-the-shelf (COTS) application or not. If it is a COTS application, then you can use the packet capture feature you can then record the traffic and submit it for App-ID development. The new App-ID is developed, tested, then added to the database for all users in our scheduled updates.
Internal or Custom Applications: Next, you can determine if the application is internal or custom using the visibility tools or the log viewer. If the traffic is an internal application, you can create a custom App-ID using the exposed protocol and application decoders. Once the custom App-ID is developed, your internal application is classified and inspected in the same manner as applications with standard App-IDs. You can enable the internal application via policy, inspect it for threats, shape it using QoS and so on. Custom App-IDs are managed in a separate database on the device, ensuring they are not impacted by the weekly App-ID updates.
Custom traffic as a threat: Once the internal or COTS applications have been addressed, the third possible identity of the unknown traffic is that it is a threat. Here too, you can quickly determine the risk levels using the behavioral botnet report or other forensics tools to isolate the characteristics and apply appropriate policy control.

16. Application Control as an Add-on
Facebook allowed…what about the other 299 apps?
Policy Decision #1
Firewall
Allow port 80
Open ports to
allow the application
Policy Decision #2
App-Control Add-on
Applications
Allow Facebook
tcp service
on port 80
Key Difference
Ramifications
Two separate policies
More Work. Two policies, more admin effort
Possible security holes. No policy reconciliation tools
Two separate policy decisions
Weakens the deny-all-else premise. Applications allowed by FW decision
Two separate log databases
Less visibility with more effort. Informed policy decisions require more effort , slows reaction time
No concept of unknown traffic
Increased risk. Unknown is found on every network = low volume, high risk
More work, less flexible. Significant effort to investigate; limited management
No shared context
More work, less knowledge, slows reaction time. Finding and correlating app, user, content requires significant effort
There are some fundamental differences in competitive offerings that that cannot be overlooked, starting with their foundation. They are all based on stateful inspection – and stateful inspection is making all access control decisions based on port and protocol. This cannot be changed, yet it is easily bypassed by many of today’s applications. Existing firewall vendors try to address application enablement by adding application control features to their Stateful inspection firewall, much like they have done with IPS. There are several significant ramifications to this add-on approach.
Multiple policies with duplicate information increases management effort. A port-based firewall plus application control approach means you will need to build and manage firewall policy with source, destination, user, port, and action, etc. and an application control policy, with the same information adding application and action. If your organization is like most, then you likely have hundreds, even thousands of firewall rules. A multiple policy rulebase approach will not only increase administrative overhead – it may also increase both business and security risks unnecessarily. Palo Alto Networks uses a single, unified policy editor that allows you to use application, user and content as the basis for your secure enablement policies.
Port-based ‘allow’ rule + app ctrl rule weakens the FW ‘deny all else’ premise. The always-on nature of port-based traffic classification, means your incumbent firewall will first need to open? the application default port controlling the application. To control Facebook, you need to allow tcp/80 or tcp/443. Based on the Application Usage and Risk Report, you may be allowing 297 (25% of the average enterprise application mix) other applications that you may or may not want on the network. This means the strength of a default deny all policy is significantly weakened. As soon as traffic hits a Palo Alto Networks firewall, App-ID immediately identifies what the application is, across all ports, all the time. Access control decisions are made based on the application and default deny all can be maintained.
Systematic management of unknown traffic. Unknown traffic epitomizes the 80%-20% rule – it is a small amount of traffic on every network, but it is high risk. Unknown traffic can be a custom application, an unidentified commercial application, or a threat. Incumbent vendors have no way to systematically find and manage that unknown traffic. To be clear, all of the traffic is logged by the firewall, but the applications are logged separately and are a subset, making unknown traffic management nearly impossible. Common competitive responses to unknonw traffic is to block it, which may cripple the business by blocking a critical internal app.
We categorize unknown traffic, which allows you to find internal applications and create a custom App-ID; do a PCAP for unidentified commercial applications and submit them for App-ID development; use the logging and reporting features to see if it is a threat. You are able to systematically manage unknown traffic down to a small, low risk amount – all based on policy.
*Based on Palo Alto Networks Application Usage and Risk Report

17. A Unique Approach to Protecting your Network
APT protection
A Unique Approach to Protecting your Network
Scan ALL applications (including SSL traffic) to secure all avenues in/out of a network, reduce the attack surface area, and provide context for forensics
Prevent attacks across ALL attack vectors (exploit, malware, DNS, command & control, and URL) with content-based signatures
Detect zero day malware & exploits using public/private cloud and automatically creates signatures for global customer base
Our platform is unique in its ability to natively classify and inspect all traffic, inclusive of applications, threats and content. And then we tie that traffic to the user, regardless of location or device type.
Box 1: We scan ALL applications (including SSL traffic) to secure all avenues in/out of a network, applying positive control model security in order to reduce the attack surface area, and provide context for forensics
Box 2: Prevents attacks across ALL attack vectors (exploit, malware, DNS, command & control, and URL) with content-based signatures
Box 3 and feedback loop: Detects zero day malware & exploits using public/private cloud and automatically creates signatures for global customer base
Our approach is applicable across the network. At the gateway, in the datacenter, for segmentation and for carriers.

18. WildFire: Stopping the Unknowns
10Gbps advanced threat visibility and prevention on all traffic, all ports (web, , SMB, etc.)
Malware run in the cloud with open internet access to discover C2 protocols, domains, URLs and staged malware downloads
New malware signatures automatically created by WildFire and delivered to customers globally
Stream-based malware engine performs ongoing in-line enforcement
On-premises WildFire appliance available for additional data privacy
WildFire TM
WildFire Appliance
(optional)
Anti-malware signatures
DNS intelligence
Malware URL database
Anti-C2 signatures
Soak sites, sinkholes,
3rd party sources
WildFire Users
Global intelligence and protection delivered to all users
Command-and-control
Staged malware downloads
Host ID and data exfil

19. Feb 2014: Continued Security Business Uncertainty
security commitment?
Feb 2014: Continued Security Business Uncertainty
The company could cut $200 million in annual operating costs and buy back $2.5 billion in stock immediately and an additional $1 billion in 2015, Elliott said in a presentation of its proposals. Juniper should also review its security and switching businesses to streamline products, and “focus on projects and areas where Juniper has clear competencies and the greatest risk-adjusted return on investment,” Elliott said.

20. Our next-generation enterprise security platform
Next-Generation Firewall
Threat Intelligence Cloud
Inspects all traffic
Blocks known threats
Sends unknown to cloud
Extensible to mobile & virtual networks
Gathers potential threats from network and endpoints
Analyses and correlates threat intelligence
Disseminates threat intelligence to network and endpoints
Our next-generation firewall provides the ability to inspect all traffic going in and out of your organization regardless of which port or protocol is used, or whether that traffic is encrypted. We know attacks have evolved to use new vectors that take advantage of blind spots that exist within traditional security infrastructure such as stateful inspection firewalls. Our next-generation firewall was not only designed to eliminate those blind spots, it was also designed to use that visibility to safely enable those applications that are critical to your business’ success. This is a key distinction in our approach. By utilizing the application identification and control features (App-ID) with user identification (User-ID) you can regain valuable control of your network; applying positive policies to eliminate unnecessary risk; and ultimately reduce down your attack surface and apply application specific threat prevention policies to block known threats.
WildFire, the right had side makes up the basis of our threat intelligence cloud. It was built for the purpose of detecting unique threats that had never been seen before.  Hopefully we agree that detection alone is not sufficient. For that reason we closely integrated WildFire with Threat Prevention which includes IPS, anti-malware, and command-and-control. WildFire also closely integrates with a third cloud-based service, URL Filtering. This ensures that as new forms of malware, vulnerabilities, command-and-control servers, or malicious URLs are discovered, those new signatures created out of WildFire are automatically routed to your prevention tools. We’ve also integrated WildFire into Global Protect allowing you to extend your perimeter defenses out to the mobile worker. Today we have thousands of customers that have subscribed to these services to prevent advanced attacks from breaching their organization.
But what if that attack does get through? More recently we’ve introduced an innovative new approach for protecting the endpoint, also available as a cloud service. This last line of defense protects organizations against advanced zero day exploits that manage to avoid detection and make it to an endpoint system. As it turns out, while there are thousands of vulnerabilities uncovered each year, there are only around 23 techniques that can be used by attackers to actually exploit that vulnerability on a system. These techniques are hard science. In fact they are so hard they don’t change that often. Maybe you’ll see one or two new techniques emerge within an entire year. Our approach once again focused on finding the most minimally invasive, yet effective solution for defeating these advanced threats. We’ve been very effective at doing just that. In fact since this technology was first released we’ve been able to stop virtually every Windows-based zero day. Now, to complete the triangle we’ve integrated our endpoint technology to our threat intelligence cloud. We don’t just prevent the attack and call it a day. Once a new exploit is detected we send it to our cloud for further inspection. In the process we learn a lot! We’re discovering new vulnerabilities, malicious URLs, command-and-control servers, new forms malware, and building signatures against that new intelligence. And much like what we do today with WildFire, those signatures are automatically distributed to our global customer base.
I’ll close here with the point that this platform exists today, this is not a future. Our success as a company supports the acceptance of our vision and ability to execute against that vision. It’s also a testament that what we’ve built can protect some of the most demanding environments out there.
Advanced Endpoint Protection
Inspects all processes and files
Prevents both known & unknown exploits
Integrates with cloud to prevent known & unknown malware

21. Migration Best Practices From Consulting Services

22. Perceived Port/Protocol/IP Migration Challenges
Cost – people and time
Perception of workload and a lot of tedious typing to migrate from your current configuration
Risk
Moving configurations can seem daunting and seem to involve a lot of risk
Legacy policy
Policies were originally created with the mindset of port / protocol / IP and not optimized for applications and users
Lost history
Many companies face “policy bloat” and “cruft” in their firewall configurations

23. Performing the Migration
An effective migration requires a combination of people, process, and technology to efficiently and effectively migrate from legacy firewalls to Palo Alto Networks This approach reduces potential risks and lowers cost.
The engineers performing the task need knowledge of the current platform and Palo Alto Networks
Migration tools can automate the routine conversion tasks reducing effort (cost) and risk.
We’ve spent some time taking a look at the different approaches, so now let’s drill down a little deeper into the process of performing the migration.
Migrating a config takes thought, care, and experience, and it is critical to have experienced engineers perform the migration. They need to understand how the legacy firewall worked as well as the Palo Alto Networks firewall, and how they fit into the surrounding environment. They need to be able to build the new configurations and make modifications where necessary to maintain functionality, and they need to monitor the firewalls after the cutover and make adjustments, if necessary.
A structured process is also key to a successful migration. It is important to follow a process that has been tested again and again in the field and proven successful.
The final piece, and probably least important, is supporting technology. Having migration tools to automate some of the migration steps can drastically reduce the time required to migrate large configurations, and lower risk due to human errors. This is in no way a substitute for experienced engineers and a proven process.
Any migration should follow a proven methodology and process (audit, analyze, migrate, cutover)

24. The Spectrum of Conversion Options
Many options exist when performing the initial conversion from IP/port/protocol to user/application-based policies
There is a spectrum of options each with pros/cons and potential risk
Less risk
Lower effort
Small reward
More risk
Higher effort
Big reward
Initial policy / object conversion options
Phase 1 like for like
Phase 2 moving to app based, etc.
Lessen risk in early stages
Migrate objects and policies “as is”
Policy / object “cleanup”
Policy / object “cleanup” + move to application policies
Migrate to user/application policies

25. Palo Alto Networks Firewall Migration Tool
Web 2.0 application in a VMWare image
Parses configurations into a database backend and web UI frontend
Provides multiple options:
Migrate objects & policies
Migrate used or both used / unused objects
Allows “in-place” editing of PAN-OS objects, services & policies prior to exporting
Doesn’t replace the need for people with expertise in the current technology and PAN-OS
Goal of the tool is 85+% policy migration automation
Later versions NAT translation, Cisco, JNPR, NetScreen
Checkpoint R75 in later versions, objects, NAT rules, etc.
Mention the manual part of review

26. Migration Process - Walk Through
Migrate L4 to L4 (Phase I)
Reduce amount of Rules “Combining” similar ones. By destination address for example.
Clean all the unused objects. Clean disabled rules.
Change services based on other protocols than TCP/UDP to Palo Alto Networks App-IDs. Example: IKE, IPSEC, GRE
Change services with ALG to Palo Alto Networks App-IDs. Example: FTP, SIP
Review & add all NAT rules. Check the security policies to match the destination zones when destination NAT is defined.

27. Example: Reducing Policy Rules
Due to the simplistic nature of the security rules, we can often combine many policies into one, especially if we can utilize App-ID
iOS config, generated GRE & IPSec rules
Later versions of MT Ping & ICMP

28. Migration Process - Walk Through (Cont’d)
Migrate from L4 to L7 (Phase II)
Put the migrated L4 policy in your Palo Alto Networks device. Connect to your network.
In-line ( L3 , L2, VWire ).
Off-line (TAP mode).
From this moment the Palo Alto Networks device will classify all the traffic in your network. That means it will identify all the applications and generate all the log entries for the application traffic.
From the current logs we can extract the applications seen by each rule and we can start to swap from L4 Services to App-ID without to break anything.

29. Additional Migration Considerations
Once we have changed services by App-ID, change the service to “application-default” or leave the previous port. Reduce the surface to detect the application to this port if it always uses the same.
Control the Unknown
From the logs check for unknown traffic (tcp/udp/p2p) and generate custom signatures to identify custom apps. Use Application Override when need.
If you have URL filtering activated check for app we-browsing and the Category is “unknown”. Generate proper App-id to identify this traffic as your custom app instead of web-browsing. This is more efficient.
Block all the unknown.
Threat Prevention
Activate WildFire where the apps can transfer files (PE, PDF, Office, APK, Jar).
Activate IPS/AV/SPY profiles to your rules. Use the migration tool to do it massively.
User-ID
Integrate with your user repository to move from static ip address to users and groups. Improve visibility and win in mobility.

30. Migration Tool – Juniper Caveats
Objects in Address-Books
Check if an object was defined in many address-books (based by zone) If equal, import only once.
Check if the IP address/ port is different based in the zone. If different, use different names to avoid duplicates errors.
Policies and Zones
Reduction of policies only because we can use more than one zone by rule or use the zone ANY. Potential for significant rule reductions here.
Customer with 4,623 rules. Direct reduction by 3 only playing with zones.

31. Best Practices to Make Your Migration Successful
Align people, process and technology
Understand conversion options and optimize policies (ports vs. apps)
Utilize migration tool to automate conversion tasks (Objects, Rule base)
Validation of accuracy and verification of changes
Post migration
Implement custom App-IDs
Rule cleanup - “Highlight Unused Policies” feature to cleanup post-migration
Enable additional security features (User-ID, Content-ID, WildFire, etc…)

32. Get Your Free AVR Report
Find out which applications and threats are on your network with a FREE assessment from Palo Alto Networks
Palo Alto Networks Application Visibility and Risk Report (AVR) :
Request an evaluation
Place Palo Alto Networks inside your network
We’ll tell you what applications and threats we see in your network!
Register today at: