Challenges in converting from one firewall vendor to another
Most of the major firewall vendors provide similar features for controlling network access and providing service availability; network and service objects, filtering, network address translation, VPN and routing rules. However, they still differ in significant ways. For example, firewall configuration syntax, how the firewall is managed, and how changes are deployed to the firewall are all different. But the most significant difference is the way policies are grouped or partitioned and applied on packets entering and exiting the firewall.
For example, Check Point has a flat security rule base that is evaluated for every packet entering the firewall while Cisco firewalls define security levels and specific access lists on an interface basis, including default behavior when traffic has to traverse the interfaces of different security levels. Juniper NetScreen allows interfaces to be grouped into zones and specify policies based on packets entering and exiting specific zones. As a result, what is allowed by a filtering rule with any source address or any destination address is quite different on a Check Point, Cisco and NetScreen box. Then there is the issue of NAT specification: Check Point supports NAT objects as well as twice NAT to specify translation of Source, Destination and Service; Cisco has a fairly complex specification for NAT rules including nat control feature that serves as an additional access control function (note: the specification has been simplified to a great extent in ASA 8.3 with the support of NAT objects and twice NAT); while NetScreen combines the specification of Filtering and NAT rules, providing support for NAT objects in the form of MIP, VIP and DIP objects. Besides all of this, each of these firewalls have different settings and default behaviors that affect what traffic is allowed through the firewall.
Fortunately, there are some tools available from the vendors to handle the syntactic translation; however these still do not address the semantic differences, leaving a lot of policy gaps still to be addressed in the conversion. These gaps could result in security holes or disruptions to service availability. Projects that try to convert from one vendor to another vendor are pretty challenging. For a successful conversion effort, understanding the policy gaps that result in these conversions, the impact of gaps, and how to plug them is very important and not supported by available firewall vendor conversion tools.
Athena FirePAC has a policy comparison solution that verifies the policy equivalence between the original and converted configurations. It identifies the policies added or removed as a result of the conversion, and the specific rules that were responsible on both the sides for the differences. This solution can check the policy equivalence between Cisco, Check Point and NetScreen configurations. For advanced conversion support, Athena also has a more specific migration solution for Cisco to Check Point conversions where FirePAC identifies the source of the policy gaps and provides recommendations for closing the gaps.
Tags: Athena FirePAC, Check Point, Cisco ASA, firewall migration, Juniper Netscreen, policy comparison