Looking to upgrade your firewall? In our latest blog, Systal Principal Network Architect Steven McGhie explores what can make a firewall migration successful, what can make it unsuccessful, and what to expect on the journey to ultimately improve your security posture.
Introduction
I think it is fair to say that every one of our customers would like to improve their security posture as part of their next-generation firewall migration strategy. One of the ways to do this in the enterprise and data centers is to migrate their existing L4 firewall to one that has Next Generation capabilities whether staying with their current vendor or changing vendor. This can be a complex process with every detail of why, how, and when needing to be understood not only by the team doing the migration, but also by the customer. In this article we will explore what can make a firewall migration successful, what can make it unsuccessful, and what to expect on the journey to ultimately improve the security posture of our customers.
Steps to a Successful Migration
A high-level strategy first needs to be worked out before the details can be worked on and by a general rule of thumb these are the steps, we have taken in the firewall migration process for our customers:
- Understand the technology
- Understand the differences in technology
- Understand the current setup
- Choosing the tool to convert the existing configuration
- Migrating the configuration and pay attention to the differences
- What are the criteria for success – Testing!!!
- Change Freeze
- Migration Day (Or Night)
- Applying the criteria for success.
- Monitoring
- Giving the customer the maximum return for their investment.
1. Understanding the Technology
From the customers perspective this is understanding what they want from the new technology, understanding the current threat landscape to their business and how the new technology they want to implement in their environment addresses these threats. For example, the customer may see the threat of data exfiltration high on their priority list, so the ability to look inside SSL flows with SSL Forward proxy should be high in their list.
From the migration team to the BAU support team, this means learning the new technology, understanding how to implement it, how to troubleshoot it which in turn gives the customer confidence in your ability, the best experience possible and highest return on investment as possible. This can come in many forms: experience from within the team, self-study, and vendor training.
2.Understand the Differences in Technology
This is probably the key understanding for the team doing the migration. All the vendors of NGFWs do advanced threat detection, use routing protocols like BGP and OSPF and implement NAT and Security policy. However, from experience, different vendors do some of these critical functions in slightly separate ways and understanding the differences can, in the end, determine the amount of work required pre-migration if not understood correctly affect the outcome of the migration. For example, in a recent migration we were migrating from Cisco Fire Power (FPR) to Palo Alto, on the Cisco FPR Firewall there were two OSPF processes working on the same virtual routing instance. This is not possible on the Palo Alto, so we had to physically connect two separate virtual routers (I know this seems odd, but we had to do it this way) and redistribute the routes from the OSPF process on each Virtual Router into RIP via the physical links so each Virtual Router could learn each other’s routes. This is just one example of the kind of technical differences that all Firewall vendors will have with each other, so make sure you understand what they are.
3. Understand the Current Setup
I know this sounds obvious, but it really is important to understand the physical & logical topology the current Firewall is connected to, why do we have some static routing, some dynamic, why do we have to NAT in certain places and not in others, Is there possible other routes the traffic can take during the migration that will minimize outages for the customer and is there any overlapping IP address space? Is or should any of this going to change with the introduction of the new firewall? The Answer to that is it shouldn’t, bringing too many variables into a Firewall migration is only a recipe for failure.
Audit the objects and rules that are already in place, identify unused objects and object groups and get rid of them, identify rules that have no hits on them and get confirmation from the business that these are indeed not required anymore. The less there is to migrate the less to worry about and check during the code migration and the moving of service to the new Firewalls.
4. Choosing the tool to convert the existing configuration
Now that tool, could be you, depending on the size and complexity of the firewall configuration, the best way to tackle this could be manually. However, if you are dealing with a rule base in the hundreds, doing it manually will not only be very time consuming and be prone to errors.
Various vendors give you free tools to convert to their Firewall, like Palo Alto Expedition, Checkpoint Confwiz and some do this as a nominal fee service like Fortinet FortiConverter and then there are third party application like Tufin that can also do the code conversion for you. In nearly all the migrations I have done, it has been done using an automated tool, the vendors you are migrating to, want to make this as painless and seamless a process as possible and put a lot of effort into making sure that is the case. However, this leads me onto….
5. Migrating the configuration and pay attention to the differences
Once the tool is chosen, you have done the import of the current rule base, it is imperative to pay attention to differences in the converted code. Some vendors do not use the concept of zones, some do not provide the functionality for interzone rules, NAT can be handled differently, and some vendors have a difference between ping and traceroute and ICMP, how these are grouped and where they can be used in security policy – is it an application or is it a service? These can all cause problems on the day of the migration to the new firewall, so attention must be paid to the differences in the conversion.
In my experience these tools will get about 90% of the conversion correct so the remaining must be fixed manually.
6. What are the criteria for success – Testing!!!
Again, this might seem an obvious point, but if the testing is carried out after the move to the new firewall, then how can you know if it has been a success? And this is almost entirely the responsibility of the customer, so as the migrating team we must trust and put confidence in the customers knowledge of their environment and applications so that the testing they carry out confirm the success of the migration.
Sure, there is testing the migration team will do; checking routing adjacencies, checking ports for errors, failover testing and path monitoring failure scenarios, but the criterion for success is almost squarely on the shoulders of the customer.
7. Change Freeze
Implementing a change freeze before the migration of services to the new firewall ensures you have enough time to prepare the final migration of configuration from the existing firewall to the new firewall. However, having a period of no change during this period can be unrealistic depending on the environment you are working in. It is the responsibility of the business you are working for to effectively communicate this change freeze period and only changes that are deemed as emergency or urgent should be considered and these must be tracked in detail.
Some vendor migration tools will allow you to merge configurations, and this is the approach that I have taken in some cases, in other cases it has been manual addition on the day of the migration, but this must be kept to a minimum as your time will no doubt be on other pressing matters.
8. Migration Day (or Night)
The migration day or indeed night will be a joint effort between the migration team and customer to work out the best time to do this. For example, online retailers are not going to let you do this on Black Friday and an Energy Company will halt a migration if the next storm is on its way in the next week or so.
The maintenance window and what will be affected must be clearly communicated to all stakeholders, but do all the users need to know? If everyone knows the firewall migration was on Saturday and the users come into work on Monday and they cannot access their email, you can guarantee it will be the fault of the Firewall and any negative press to the work you do, even if it is confirmed successful on the day or night is never welcome.
9. Applying the criteria for success
Ok, the time has come for the big red button to be pressed, but wait, that criteria for success – the testers must do their work first. Having testers test all the required functionality of all their services and applications is necessary before any work is done to reroute traffic via the new firewalls. You never want to be in a situation where you have moved all services from the existing firewall to the new firewall and spend countless hours trying to troubleshoot something that was not working beforehand.
On the day of the move, this will be the time where you find out if what you have done in the preceding months has worked, even if some of it doesn’t work, you have the maintenance window in place to resolve some of these issues. Most will be simple fixes like incorrect source or destination objects, the wrong zone, static route pointing out the wrong interface or an application is using a range of ports that did not get converted correctly.
Every now and then, however, you run into a situation that could never have been predicted. In one case we had two sites connecting using multi-hop OSPF for inter-site failover, in the pre-migration environment the existing Firewall vendor did not decrement the TTL value, and the adjacent router was OK with this, and the adjacency formed. However, on the post migration environment, the new Firewall vendor did decrement the TTL value, the adjacent router was not OK with this and was running a version of code where we couldn’t tell it to ignore the TTL value and the OSPF adjacency did not form. After some network redesign at 6:30am In the morning (not recommended for your sanity) we got it working and ultimately the migration was successful. But after hours of migration and testing to come to the last test of site failover and the failover not to work would have been hard to take.
10. Monitoring
Monitoring should happen from the minute the new firewall starts receiving traffic, but at the end and the migration is considered a success, everyone on the migration team goes home to bed, there will always be a period of what we call Hypercare. Hypercare is a period where increased scrutiny & monitoring is placed on the Firewalls and the applications flowing through them. There are always problems after the migration and these must be taken care of, on priority during the Hypercare phase. These should be prioritized based on their impact and having a team knowledgeable enough who knows if this is related to the migration or is just perceived to be related to the migration is critical.
However, during the planned change or during Hypercare there is a problem serious enough the dreaded “rollback” question will inevitably be asked. This should be the very last resort; I have been involved in one or two and it is not a pleasant scenario.
11. Giving the customer the maximum return for their investment.
So, our customer has the brand-new firewall, everything is working as expected. How do we ensure they get their maximum return on their investment? This is a technical article and that’s what we will focus on here, but there should also be efficiency saving, decreased deployment times, easier to support, but what maximizes their investment from a technical & security perspective?
- Increased ability to intercept threats trying to break into their network.
- Increased ability to understand what users are doing and permitted to do through Zero Trust.
- Integration with Cloud services that can detect zero-day threats via AI & ML.
- Having firewall and IPDS services in one place reduces the complexity of threat intrusion.
- Integration with Cloud Services that publish High Risk, Malicious IP addresses and Tor exit nodes.
- Increased ability to thwart DOS attacks and threat actors carrying out reconnaissance on the customers’ network.
It would be extremely remiss of us to install or migrate a new Firewall into a customer’s network and not let them release all the increased technical and security benefits it brings with it, ensuring we are not doing “like for like”.
Looking to upgrade your firewall? Find Out More
If you are looking to improve your security posture as part of your next-generation firewall migration strategy, speak to one of our experts.
Steven McGhie is a Principal Network Architect within the Architecture & Design Team at Systal Technology Solutions. With over 15 years of experience in the networking field, Steven has worked extensively with large-scale enterprise customers across various sectors, including Information Technology, Banking, Retail, and Manufacturing. His expertise encompasses the design, delivery, and support of security, data centre, and enterprise solutions tailored to meet the unique needs of these industries. Steven collaborates with a team of highly experienced and qualified architects, addressing the full spectrum of networking and security requirements to ensure robust and efficient solutions for our clients.
CONTACT SYSTAL'S EXPERTS
