FUEL EDUCATION SERIES -PALO ALTO NETWORKS

101

TABLE OF CONTENTS

Fuel Education Series Palo Alto Networks 101 ............................................................................................. 1

Your Migration Checklist ............................................................................................................................... 3

Planning Details............................................................................................................................................. 4

Documentation.......................................................................................................................................... 4

Project Timeline ........................................................................................................................................ 4

Business Buy-In.......................................................................................................................................... 5

Migration Steps for Your Current Firewall .................................................................................................... 5

Audit Your Current Systems ...................................................................................................................... 5

Notify Your Partners .................................................................................................................................. 6

The Deep Freeze ........................................................................................................................................ 6

Setting Up Your Device ................................................................................................................................. 6

Location, Location, Location...................................................................................................................... 6

Standardization ......................................................................................................................................... 6

Basic Configuration.................................................................................................................................... 7

Policy Migration ............................................................................................................................................ 7

a New Approach to Policies....................................................................................................................... 7

Migration Choices...................................................................................................................................... 8

Using the Migration Tool ........................................................................................................................... 8

Developing a Communication Plan ............................................................................................................... 9

Final Preparations ......................................................................................................................................... 9

Designing a Test Plan................................................................................................................................. 9

Designing a Rollback plan .......................................................................................................................... 9

Cutover .................................................................................................................................................... 10

Post-Launch Check-ups ............................................................................................................................... 10

 Troubleshooting Issues............................................................................................................................ 10

Post-launch activities............................................................................................................................... 11

What’s Next?............................................................................................................................................... 11
You’ve done your homework, built the business case, and now it’s time to make it happen and get your firewall
migration underway. Whether you’re starting a completely new Palo Alto Networks implementation, or
consolidating a mish-mosh of devices and providers into a single, unified cybersecurity approach, the right
migration plan will make the difference between a smooth rollout and a network of broken links and interrupted
access.

A word of caution at the start: Migration takes time. A lot of time. Policy migration on its own can take weeks of
editing, review and testing, so make sure you give yourself enough time to prepare and execute. In the long run, a
well-planned, thoughtful and careful migration will save you countless hours of correction and ensure maximum
protection for your organization.

NOTE: This guide is focused on the configuration of the operating system of the Next-Generation Firewall. For
hardware specifics, please refer to the Palo Alto Networks Hardware Guides.

YOUR MIGRATION CHECKLIST

Before you launch into setting up your new firewall, take some time to make a checklist of all the tasks you need to
accomplish in order to have a successful migration. Every plan will be different, so make sure you get input from
your Migration Team into your list, and that you cover all of the steps below.

Not surprisingly, the first place to start in developing your checklist is the technical documentation for your Next-
Generation Firewall. For each version of PAN-OS, you’ll find a section in the administrator guide on preparing your
device for deployment.

Additional Resources:
 Here is an example of a firewall checklist you can use to build your own!
1

 SANS also has a great whitepaper on migration that includes recommendations for many of the major
migration steps.
 It’s not “apples to apples”, but the Palo Alto Networks Panorama Migration notes from 7.0 are a nice
reference to have as well.

1
UNC CAUSE Conference 2016: https://unccause.org/
PLANNING DETAILS

DOCUMENTATION

By now you should know the full scope of your project – the systems to be migrated – but it’s important to
carefully document the current state of these systems, their owners, and any business processes that may be
affected by the migration.

Some items to include in your project documentation are listed below. Some of these may seem obvious, but it can
be surprising to hear how different team members interpret some of these items, and how it may differ from your
intention.

Important Project Documentation Items:

 Project Goals
 Key Stakeholders
 Project Scope
 Time & Resource Limitations
 Major Deliverables
 Potential Risk Events
 Dependencies
 Roles and Responsibilities
o During Migration
o Post-Migration
 Technical Information
o Topology Maps
o Current Configuration Details
o IP Address Table
o Third Party Systems

PROJECT TIMELINE

You should also define a timeline for the migration that includes:

 Current system auditing

 Defining your future state
 Basic setup steps for your new Next Generation Firewall
 Policy migration
 Testing and troubleshooting
 Defining rollback and troubleshooting strategies
 Go-live
 Post-launch testing
 Continued maintenance and evaluation

This timeline will help you make sure all team members and affected parties understand how this will impact
normal business operations, and also give you a way to evaluate your progress. If you are consistently missing
target dates, ask yourself why. Are there factors you did not originally incorporate into your planning? Are you
running into resistance to change? A little time spent to identify the root cause of these delays will help you re-
evaluate your timeline and adjust to incorporate this new information.
BUSINESS BUY-IN

By now you should have a Migration Team in place to help ensure communication with all of the major teams
affected by the migration, but your corporate communicate shouldn’t stop there.

Despite your best efforts to communicate up, down and across your organization, you may (and probably will)
encounter a division or area owner who does not support the migration and insists that their systems not be
affected; maybe they’re refusing to allow any change. This is another place where your Migration Team and
documented project goals will be helpful. Communicate the “why” of the migration, not just the “what”; it can also
be helpful to highlight the projected impact of an attack or breach to help add some context to the situation. Don’t
be afraid to involve your executive-level project sponsor to help drive home this importance of this project!

 Support your case with statistics.

o The Identity Theft Resource Center has some great statistics on the number of breaches.
o IBM released a study in 2016 of the impact of breach costs worldwide.
o PWC’s study on the state of information security is worth reviewing, but the Appendix is the best
part.

Also, if you’re getting pushback from executive leadership, bring some serious credibility to your plan through this
Gartner report.

MIGRATION STEPS FOR YOUR CURRENT FIREWALL

Okay, on to the technical details!

Your exact migration plan will be heavily dependent on how many disparate systems you’re migrating, what your
new planned configuration looks like, what resources are available, third party product integration, etc. However,
there are some best practices you should put into effect while still operating on your existing systems.

AUDIT YOUR CURRENT S YSTEMS

You want to migrate, and you want to clean up your policies, but you shouldn’t necessarily do both at the same
time. Take advantage of this pre-migration timing to conduct a thorough audit.

 Remove all the unused address objects, services, and networks

 Perform a rulebase analysis to remove outdated or inactive policies
 Monitor your traffic. Give yourself a sizable window of time for this. While some rules might be hit every
day, others might only be used monthly, but that doesn’t mean they’re less important.
 Does anyone in your organization know the history of some of all of your rules? Ask senior team members
for insight into why certain policies were implemented, and gather any documentation you can find on
the old rules.
 Make sure you understand how your current firewall forwards packets, and how this may be different
than your Next-Generation Firewall. This will be important when you are migrating your information.
NOTIFY YOUR PARTNERS

Communicate your timeline and information on packet transfer changes to all partners before you begin setting up
your new firewall. You don’t want to be in the middle of your launch countdown and find out that a major vendor
has a compatibility issue.

Speaking of partners, have you spoken with your Palo Alto Networks team? Whether it’s an official consultation
with the Migration Services team or just a discussion with your migration contact, remember that you are working
with a team that has experience helping lots of customers in making the jump to the Next-Generation Firewall.
Don’t be afraid to leverage brainpower from outside of your organization!

THE DEEP FREEZE

Once you’ve completed your audit and are comfortable with the remaining policies and rules, you need to
implement a “freeze” on your configuration so that no policies rules or objects are changed. You’ll take a copy at
the beginning of this freeze for use in your migration.

Of course, saying “no changes” is not always realistic. If there are serious security issues or mission-critical
processes that are being delayed or denied based on your current configuration, you’ll have to make edits, but
track them carefully so you can make sure they are carried over.

It is possible that a freeze is simply not realistic for your organization. If this is the case, make sure you have a plan
for documenting changes and transferring them to your new device. Since you won’t have the option of a test run
with these new policies and rules, make sure you test them thoroughly after your cutover.

SETTING UP YOUR DEVICE

One you’ve made reasonable progress on your audit, you can start the initial preparation phases for your new
Next-Generation firewall. The basic setup for any firewall can be prepared at this stage without any policy
migration.

LOCATION, LOCATION, LOC ATION

The first step if you’re using a physical firewall is to install the equipment in its permanent location. If you are
planning to use the space currently occupied by your current equipment, you may want to reconsider this option,
as it will force you to maneuver equipment that’s in use; additionally, if you need to perform any kind of rollback,
it’s easier to still have your old equipment in place.

STANDARDIZATION

One of the most useful steps you can take at this point is to define a standard naming convention for devices,
zones, policies, etc. Having a clear standard will make it easier for new team members to understand your
topology, improve troubleshooting response times, and should reduce the amount of per device/zone/etc.
documentation you have to write. After all, if you have a standard naming convention where you’ve documented
what the different components are, all you really need is a glossary of terms!

If you are using more than one device, even if the usage and setup is slightly different, make sure you’re naming
conventions are the same. This might mean you have to adapt your preferred structure to match some existing
setups.
BASIC CONFIGURATION

Things You Can Start Configuring:

 Interface Settings (physical, logical and IPs)
 Routing (dynamic routing protocols or static routes)
 High Availability Setup (clustering)
 Management Settings (users, remote access, AAA, SNMP, and Syslog)

Since PAN-OS devices have a dedicated management interface, you can also start acquainting yourself with this
option and thinking about how this will impact your processes for management. Any third-party networking and
monitoring tools can also be enabled for this device to check connectivity. Lastly, this is a great time to set up your
logging and reporting so that it’s ready to go immediately upon cutover, and you can start monitoring the
effectiveness of your new Next-Generation Firewall immediately.

Once these pieces are in place, you can perform an acceptance test to make sure everything is running smoothly.
You don’t want to finish migrating your policies and then have something simple slow down the process or impact
user testing.

POLICY MIGRATION

A NEW APPROACH TO POLICIES

The biggest issue for customer who migrate to Next-Generation Firewalls is not seeing an improvement in
performance or blocked threats. This has nothing to do with the firewall, and everything to do with the way it was
configured.

If you have a port-based configuration, you should migrate onto your new device in this same configuration.
However, if you do not then translate your policies to take advantage of features like App-ID and User-ID on your
new system, and aren’t receiving the full benefit of a Next-Generation Firewall. Migrate your existing
configuration, and then translate it to an application-based policy structure.

 If you’ve had a very granular level of control, you’re not using the zone approach that makes managing a
Next-Generation Firewall easier and more effective.
 Did you consider changes in packet flow? Not all firewalls perform their checks in the same order!
 Here’s a great blog post from Router Freak that also points out that it’s important to look at NAT, service
timeouts and application extensions when you plan your migration.
 There’s also deep packet inspection, event logging, and much more to consider. A good way to get a
handle on what you should check is to look at your current reporting state, and if you are looking for any
additional or different information going forward.
MIGRATION CHOICES

Here it is, the biggest and most complicated step in your migration: migrating your policies, objects, services, NAT,
and VPNs. This is the “make or break” moment of your migration, but if you’ve done your homework and
preparation, this can actually be a very smooth transition.

Before beginning this stage, it’s important to know if you will perform the migration manually or automatically
using the Migration Tool. There are pros and cons to each option:

 Automatically (Migration Tool)

o Pros:
 Great for large rule sets
 Most basic policies will move without issue
 Lowered risk of human error (missing rules, incorrect information entered, etc.)
 Allows for a test run of your migration!
o Cons
 Errors are still possible due to things like syntactical differences, or difficulty in
accurately translating complex rules
 Adds an extra level of effort to move into Panorama managed environments
 Manual Migration
o Pros:
 Good for migrations where there are major changes in how information is passed
through
 If you have been “creative” in your rule development, you will need to spend the time
manually to translate your needs into more workable rules
o Cons
 Time-consuming
 Room for human error
 Or maybe a little of both…
o Leverage the migration tool to identify unused objects and services and to draft what your policy
will look like.
o When you are ready to create your real policy, you will already have a draft of what it should
look like to keep you on track.

Regardless of which option you choose, remember that this will be a time-consuming process, and rushing or
automating your migration and not performing adequate quality assurance is a recipe for disaster. If you cannot be
confident that you can reserve enough time for this project, consider involving the Palo Alto Networks Migration
Services team. There are several different levels of support available based on your specific needs, and this is a
great way to add additional temporary, experienced resources to your team.

USING THE MIGRATION TOOL

The Palo Alto Networks Migration Tool is a great resource for organizations to help expedite their migrations, and
to help with the translation needed from other major vendors. The current Migration Tool supports migrations
from Cisco, Check Point, Fortinet, McAfee and Juniper; it also supports migration between Palo Alto Networks
firewalls. For more information on what’s supported, to download the user guide, or to get the Migration Tool,
visit the Palo Alto Networks website. Also, don’t forget to look at the Migration Tool Best Practices.

NOTE: Once you’re finished with your migration, don’t ignore the Migration Tool. It can help you with rules
optimization, security control validation, and implementing features like User-ID and App-ID!
DEVELOPING A COMMUNICATION PLAN

There’s an old adage that says “The best defense is a good offense”, which is applicable to all facets of
th
cybersecurity planning, including communication. If you don’t want to get 11 hour emails or face a barrage of
troubleshooting phone calls, emails and meetings, take the time to communicate about this change across your
organization. While not everyone needs to know why you’re making the change or the technical details, everyone
can be impacted by outages, and suddenly discovering you can’t access services you need and having no idea why
is a recipe for disaster.

Notify the Front Line: Once your timeline is solid, send a communication to your IT support teams and the
lead of any division who could be impacted. Include a brief synopsis of the project, key dates where
service may be affected, major IP changes, and who to contact if there is an issue. As you complete each
step of this process, make sure you’re sending this group an update, especially any timeline changes.

Notify the Reserves: Your entire organization should know that a migration is taking place, but they don’t
need nearly the same level of detail as IT support. Work with your corporate communications team to
send at least 2 messages to all employees notifying them of key dates of interrupted or potentially
impacted service, and who to contact if they experience an issue. This allows teams to plan around these
outages, and provides a helpful reminder in case they forget!

Different organizations will want to adapt their communications to limit the amount of information distributed
about the changeover, but having a reference page with information about the change can be a huge time-saver.
Look at what CSU San Bernardino shared with their campus members in terms of timing, impact and support.

FINAL PREPARATIONS

DESIGNING A TEST PLAN

Once you’ve got your Next-Generation Firewall fully loaded, it’s test time. While you won’t be able to check every
possible usage scenario, you should have a good idea of where most of your traffic was coming from on your old
systems, and what business needs are going to be the most critical to avoid an interruption of service.

 How do you know where your traffic was? Because you monitored it back during the audit!
 Ask your Migration Team and key stakeholders what they think is important to test, or where they have
the most anxiety.
 Form a set of use cases and questions, including failure response. Even if all of your test cases are
successful on the first attempt, you will inevitably find an issue in production. Now is the time to get ready
for it.
 Check out this TechTarget list of basic checks for network and application connectivity to include in your
planning.
 Ask your Palo Alto Networks SE to review your plan and offer suggestions.
 Ask the Fuel community! Many community members are happy to offer advice and suggestions.

DESIGNING A ROLLBACK PLAN

Make sure you have a plan in place for rollback to your previous configuration. Even a well-planned migration can
experience issues, and you don’t want to have your entire network down for an extended period, or worse,
unsecured. Your rollback plan should include a cutover scenario that requires immediate rollback, a plan for the
monitoring phase, and, depending on the complexity of your deployment, the option for partial rollback vs. a full
revert.
CUTOVER

It’s officially cutover day, and you’re ready to get started, so let’s review the key steps:

 Plan your migration during a service window with the lowest possible amount of network traffic (or the
least traffic on critical systems.)
 Save a local copy of the current firewall configurations.
 Communicate the start of the process to your Migration Team.
 Once all polices, rules and other settings have been transferred, and you have disabled your previous
firewall, run through your major testing scenarios again to ensure success.
 Communicate completion the Migration Team!

POST-LAUNCH CHECK-UPS

TROUBLESHOOTING ISSUES

You did it! You’ve successfully migrated to your new Next-Generation Firewall, everything (or most everything) is
running smoothly. So why are you getting phone calls? Make sure you have a plan for the 2 weeks following the
migration so that you and your Migration Team know what the roles are and how much time needs to be set aside
to provide support. Here are a few helpful tips:

 Triage Your Support – Cybersecurity is not a “first come, first serve” environment; the inability to access
Facebook pales in comparison to not being able to process transactions. Make sure your submission
process for issues includes a severity level, and make sure that “level 1” alerts – a total loss of critical
service” are automatically sent to a team member on-call, not waiting in your ticketing system.
 Have FAQs Ready – Most users, despite your earlier communications, probably didn’t understand what
this migration might change about their day. An FAQ page will probably answer the vast majority of non-
IT issues. It will be important to include a special focus on mobile traffic and SaaS software.
 Share Your Process – Publish your response windows. Telling users up-front that lower level requests may
take longer might seem like it will backfire, but if you provide examples of what a “level 1” issue looks like,
most users will understand why these issues take priority. This should help to address reminder phone
calls and emails about the status of requests.
 Track Your Results – Enter all issues into a tracking system. If you’re not using a ticketed support program,
set up a shared resource for anyone who will help to address these issues. Having this information may
help you identify a pattern or trend for root cause analysis. Don’t settle for bandages – find the problem
and fix it.
 Timestamp Your Rules – This may seem a bit out of place here, but by adding a timestamp to all rules,
and updating it whenever you make a change, you can go back and look at how much revision you had to
do, and if there were significant patterns to the adaptations. This will be important information as you
look forward and implement more features of the firewall.
 Ask for Help – Don’t forget to utilize your Migration Team and the Fuel Community! Your co-workers can
help to continue to communicate with teams on the process and impact of the migration.
POST-LAUNCH ACTIVITIES

Your migration journey might be at its end, but there are a few more closing items you should consider before you
mark this project “Complete”:

 Communicate, One More Time: Notify everyone in your organization of the successful migration and
remind them where to go for help with questions.
 De-Brief: Bring together your Migration Team to celebrate, and also to talk about what you learned as
part of this process. What would you do differently? What did you not think of at the start? This
information can help with future deployments, upgrades and other changes.
 Report Out: You should already be planning to run reports early and often on your new setup, and to
compare these reports to your previous system’s tracking to see if there are any major differences. It’s
also good to provide a 90- or 120-day report that highlights the impact of the migration. Sharing
information with executive leadership and IT teams about improvements you’re seeing helps to
demonstrate the ROI of the project, and will hopefully lead other members of your organization to
abandon risky or insecure processes.

WHAT’S NEXT?

In the upcoming editions of Palo Alto Networks 101, we’ll review more of the advanced features of the Next-
Generation Firewall, including Panorama, App-ID, User-ID and Traps.