Although the change process will vary from organization to organization, there are several common roles and process steps.  The change process will typically involve many stakeholders who require different levels of access to information about the change and the network itself.  The request will be initiated by an end-user who desires access to particular services or specific devices.  A security auditor may review the security implications of the request.  A change manager may review the request for correctness and completeness.  A network engineer will design configuration changes based on the requirements in the request.  A change manager may review the proposed changes for impact on network behavior and compliance to network standards.  Once approved, a network engineer will deploy the changes to the network.  Finally, the actual change deployed to the network may be validated to ensure it was made correctly and corresponds to an actual change request.

In networks of any reasonable size, it is quite likely that a packet specified by a change request will traverse multiple network devices along its path from source to destination.  Identifying the path and knowing which devices will need to be touched along the path requires significant knowledge of and experience with the network in question.  Not all of the stakeholders will have access to this information, either for security reasons or simply that it’s irrelevant to their jobs.

The application developers and other end-users who request access to particular services or specific devices are frequently unclear on the nuts and bolts of the network architecture.  They are not likely to be familiar with the intricate details of IP subnetting or network address translations.  They may not even be sure of the exact port numbers used by their favorite services.  This all leads to change requests that may be ill-formed and even strewn with erroneous IP addresses or port values.

Another issue is that even if a change request contains the correct host and service parameters, the request may be spurious because the service is already available and accessible.  Even so, just determining that a request is spurious requires identifying the correct path through the network from source to destination and finding the network devices that could potentially block the packet.  In this case, the network engineer’s valuable time is wasted even just responding to the request because there’s nothing to be done.

Assuming the change request is accurate and non-spurious, the network engineer still has to identify the correct path through the network from source to destination and determine which, if any, devices must be touched in order to complete the request.

Using traditional tools like ping or traceroute, the network engineer can only identify the first device along the path that is blocking the packet.  He would then have to identify the change required in that device, deploy the change to the network, and then continue pinging or tracerouting to the next blocking device and so on.  Since the changes to each device are made individually, they can only be tested and validated individually as well.  This can be a very time-consuming and potentially error-prone process.

Finally, once the correct devices have been identified, the network engineer must determine which ruleset in each device has to be modified and where in the ruleset to make the change.  In many cases, even if the engineers understand the network well enough to know which devices need to be touched, the devices themselves are so complex that designing the correct change is a challenge all by itself.

With so many stakeholders having various and differing interests in changes to the network, a single change request can spend a lot of time going back and forth between different people.  Each additional step in the process introduces the possibility of error and represents more time taken before the change can actually be deployed into production.

Athena Security’s Change Advisor addresses these issues by automating the change process.  It takes advantage of Athena’s core technology of deep dataflow understanding of firewall and network device behavior to determine how packets would traverse the network, based on connectivity, routing and the firewall devices involved in the change request.  It moves analysis of the change to the front of the process and makes the results of that analysis available to the different stakeholders when and how they need it.  This can dramatically reduce the change cycle time and the incidence of errors while ensuring that sensitive information about the network configurations is made available only to those who need it.

Application developers and other end-users use a web form to submit change requests.  They can select the source and destination parameters from a list of known hosts, cutting down on potential errors at the point of entry.

Once a complete request has been entered, Change Advisor issues a packet tracer query based on the request’s source, destination and service parameters to determine the path the requested packet would take through the network and identifying the firewalls and routers involved.  The result is an answer to the application engineer that shows whether or not the change is needed.  Since no data is injected into the network, and the application engineer does not view or access the configurations directly, this is a secure process.

If the packet tracer query shows that the change is required, the request is then forwarded to a network engineer for fulfillment.  The packet tracer query issued from the change request parameters identifies the routable path through the network from the specified source to the specified destination.  This process determines whether or not the packet can be routed to its proper destination.  If NAT’ing is involved, the packet tracer will calculate the proper translated address ranges.  Then if there are any devices along the path that can apply security rules, the packet tracer determines whether or not the packet will be filtered from reaching its destination.

When presented to the network engineer, this analysis result shows precisely where in the network the packet will travel, which devices along the path will need to be modified to allow the requested service, and even which rules in those devices need to be changed.

The network engineer then has all of FirePAC’s extensive capabilities for exploring firewall configurations, understanding firewall behavior, and modeling the effects of change on firewalls and routers and can design and verify the change prior to deployment out to the network.  Following deployment to the network, FirePAC’s Change Impact Monitor can validate that the correct change has actually been deployed.

Validation

Once the source firewall configuration has been migrated to the target, you will want to validate that the conversion has been done correctly.  There are two aspects to this process.  The first is to ensure that all elements in the source configuration have been accurately and completely transferred to the target.  This is typically done by a object-by-object and rule-by-rule comparison of the two configurations.  Each object definition and rule in the source is traced to the corresponding object definition and rule in the target.  In many cases, this is not actually a one-to-one correspondence because architectural differences between platforms may force one source object or rule to be decomposed into multiple objects or rules in the target.  This is particularly a challenge when tracing the conversion of NAT rules.

The second aspect of validation is to verify that the policies in the target firewall are functionally equivalent to those of in the source.  This means analyzing the traffic flows across each pair of ingress and egress interfaces in the source firewall and comparing it to the traffic flows across the corresponding interface pair in the target.  Calculating the traffic flows involves determining what traffic is allowed/denied for all possible sources, destinations, and services and must take into account the combined effects of the reachable networks for each interface, filtering from security rules, address translations, and routing table entries.  Performing this kind of analysis manually is feasible only for some small number of critical connections; performing a full traffic comparison analysis for the entire configuration is only possible using automated tools.

Athena FirePAC provides a Firewall Migration module that can perform automated traffic flow comparison between configurations from different firewall vendors.  This can be used to validate migrated configurations and to find all packets that are being dropped or added in the new target configuration. The comparison report also provides a list of all added and deleted traffic flows along with the rules that allow and deny the traffic on both the sides.  Not only is it very useful for validating policy equivalence between migrated configurations, but it will also identify the specific rules responsible for deviations in the target firewall.

FirePAC now also provides a fully automated process for migrating Cisco configurations to Check Point firewalls.  This capability addresses many of the limitations in the Confwiz migration tool provided by Check Point.  Specifically:

1. Identifies global rules in the Cisco firewall configuration (generated from CSM) and ignores them when generating rules on the Check Point side.
2. Uses the routing rules to perform network reachability and generates the interface reachable network objects correctly and fixes zone spanning objects when generating acl rules.
3. Generates flat basic objects instead of group objects with one member for basic objects defined in CSM and converted as an object group in the Cisco configuration.
4. Fixes the limitations in ConfWiz ACL generation like protocol object groups, tcp-udp service object groups, acl rules with source ports, non classic subnet masks such as 255.255.255.192,  port operators like ne, neq etc.,
5. Reuses all predefined and user defined service objects on the Check Point management server when generating objects.
6. Flexibility to specify the customer desired object naming conventions for naming the generated network and service object groups and renaming existing objects. ConfWiz uses fixed naming conventions with a mandatory prefix that the users need to fix manually later on.
7. Aggregates the expanded ACEs back to the aggregated form as specified in CSM when converting configuration of a Cisco firewall that is managed by CSM.
8. Generates the NAT rules accurately and in the correct order as evaluated by Cisco firewall irrespective of the order of NAT statements in the configuration. Generates all possible Twice NAT rules from Static Source and Static Destination NAT, Dynamic NAT and Static Destination NAT, Policy NAT and Static Destination NAT, NAT 0 and Static destination NAT etc., Identity NAT statements will not be generated only if other NAT rules that follow them do not overlap with them.
9. Optimizes the generated NAT rules by removing redundant NAT rules and NAT rules whose effective rule portion is covered by any of the ACL rules and hence would never be triggered. This optimization removes a significant number of Twice NAT rules and irrelevant nat rules formed from bidirectional static nat statements.
10. Uses Excel format to display the generated rules and objects and uses this excel document to deploy the rules and objects to the Check Point management server using CPMI interface. Users can very easily review this Excel and modify this excel to make desired changes before pushing the configuration to the Check Point management server.
11. Performs an offline gap analysis on the original and the converted configurations using nat, acl and routing rules on adds rules to fix the gaps.
12. Generates a validation report to identify all traffic flows (IP packets) that were added or dropped along with the responsible acl, nat and route rules in both the source and target configurations.
13. When the converted configuration is ready for deployment to production, it compares the objects on the production and the staging management server and flags all conflicts in an excel document with the conflicts merged. These conflicts are then pushed to the production server if desired or the users can manually resolve them using the excel report. This feature addresses major work flow issues with merging the changes that keep happening in production systems while the engineers work on the migration.

If you are engaged in or planning a Cisco to Check Point migration project and would like to evaluate this new capability in FirePAC, please contact sales@athenasecurity.net.

Converting Network Address Translation Rules

The basic semantics of an address translation rule involve specifying the original source, destination, and service and the corresponding translated source, translated destination, and translated service.  When an IP packet is found that matches the original elements, the firewall modifies the packet with the translated values.  In Static NAT, you specify a fixed one-to-one mapping on source, destination, and/or service.  In Dynamic NAT, you specify a mapping between multiple (typically) private or internal addresses and one or more public or external IP addresses drawn from an address pool.  A specify form of this is dynamic port address translation, where internal IP addresses are mapped to a single external IP address and a dynamically assigned port value.  Sometimes an Identity NAT (where the addresses are _not_ translated) is used to exclude certain connections from translation when their sources and/or destinations fall within the address ranges specified in more general NAT rules.

All firewall platforms support the above features; how they are implemented differ significantly from platform to platform. In most of the firewall platforms, the address translation rules are implemented separately from filtering rules. The Juniper Netscreen platform combines filtering and address translation rules, which poses it’s own set of challenges.

In Cisco firewalls until ASA 8.3, it was not possible to specify both source and destination translation in a single NAT rule. You had to specify different NAT statements, some of them bidirectional (Static NAT statements performing Source NAT from real IP to virtual IPin one direction and Destination NAT from virtual IP to real IP in the other direction) and have the device combine them into a Twice NAT rule. Moreover, the address translation syntax is quite complex with 6 to 7 variants for specifying NAT rules. Also because of the Twice NAT rule limitation, multiple NAT statements have to be combined to specify a single translation. You might combine Dynamic NAT with Static Source NAT, Static Source NAT with Static Destination NAT, NAT Exemption/Identity NAT with Static Destination NAT, etc., etc. Determining all of the possible combinations becomes very difficult as the number of NAT rules increases. In addition, it is possible that not all of the possible combinations created from the bidirectional rules are relevant and in actual use. It is necessary to examine the security rules to determine which combinations of NAT rules are actually used instead of converting all possible combinations.

With Check Point, it is possible to specify address translation on network objects on a global basis from which NAT rules are generated automatically. Rules are generated in both directions for Static NAT; doing Source NAT in one direction and Destination NAT in another direction. Check Point also combines these bidirectional rules to perform twice NAT, although these twice NAT combinations are not shown in the management console. However, Automatic NAT cannot be used to specify a Twice NAT rule to perform desired source and destination translation in a single rule. To override the Automatic NAT, Manual NAT can be used to specify Twice NAT or other rules and placed in front of Automatic NAT rules. When converting address translation to a Check Point target, it is far simpler to use Manual NAT.

In Juniper Netscreen firewalls, the address translations are specified as part of the security rules.  Address translation is specified for all rules that allow the traffic. This has the advantage of seeing the NAT information with rules that allow the traffic but if different address translation is required for different addresses, filtering rules have to be split to accommodate the different NAT specification. This also presents a significant problem when converting to the Juniper Netscreen platform from other platforms where the rules are kept separate. You have to find the overlaps between the filtering and address translation rules and then generate a combined rule. This might result in more rules on the target Netscreen firewall than are present in the source firewall in order to properly cover all of the combinations.

In the next blog post, we will examine the issue of validating the migrated policy in the target firewall.

Converting Security Rules

The basic elements of a security rule (sometimes called ACLs or filtering rules) are defined similarly in all firewall platforms.  Each rule specifies a set of source addresses, a set of destination addresses, and a set of services that are matched against an incoming network data packet, and an action to take: typically to allow or deny the matching packets.

The syntax of these rules is quite different across different firewall platforms as are the mechanisms for grouping rules to provide higher-level abstractions and partitioning rules for better management of rule bases.

Some firewall platforms, such as Cisco security appliances, allow only a single network or service object value for source, destination, and service elements.  The Cisco Security Manager (CSM) management console allows you to specify multiple values per element in a rule, but when the configuration is installed on a target firewall, the rules are expanded to have only one value per element.  Other firewalls, like Check Point and Juniper Netscreen, allow multiple values per element to allow for an aggregated and smaller rule base.

In Check Point firewalls, all rules are grouped into a single, flat rule base.  This entire rule base is evaluated for each packet entering the firewall, regardless of entering or exiting interface.  Thus it is not possible to organize the rules to take advantage of the network structure based on the set of network address ranges reachable from each interface.  In Cisco firewalls, security rules are organized into access groups that are assigned to one or more interfaces to be evaluated for packets either entering or exiting through that interface.  In Juniper Netscreen firewalls, interfaces that have networks behind them with similar security posture can be grouped into security zones.  Rules are defined by packets entering and exiting through the source and destination zone.

These different ways of organizing and grouping rules pose the biggest challenge in converting the security rules from one platform to another.  It is necessary to understand which networks are reachable from each interface or security zone and then partition the rules accordingly.  This can get interesting when converting rules using zone-spanning objects on a firewall with a flat architecture to an architecture that requires the rules to be partitioned by interface or zone.

Because of these different approaches to grouping of rules, the impact of using “Any” values in source and destination elements is varies across different firewall platforms.  When “Any” is used as Source or destination in a Check Point configuration, it means any address that is reachable from any interface.  However when “Any” is used as a source in a filtering rule on a Cisco firewall, it means only the networks that are reachable from the interface(s) that the rules are applied to.  Similarly in a Netscreen firewall, when “Any” is used as a source or destination value in a filtering rule, it really means only the networks that are reachable from the interfaces belonging to the source or destination security zones.

Zone-spanning objects pose a similar issue.  In a Cisco or Juniper firewall, only the addresses reachable from the relevant interface or security zone are allowed or denied by the filtering rules, even if a zone spanning object is used.  When converting such rules to a flat rule base, as in Check Point, the zone spanning object will have to be divided so as to specify only the reachable networks for the correct interface.

In general, when converting rules from a firewall platform where rules have higher level of grouping to a platform with lesser level of grouping or no grouping, “Any” values or zone spanning objects need to be resolved with networks that are actually reachable from interface(s) in the target firewall.  When converting rules from a firewall platform with flat or lower level of grouping to a higher level of grouping, source networks and destination addresses in each rule have to be analyzed to find the proper interface or security zone through which the networks are actually reachable and place them in the proper ruleset.

In the next blog post, we will examine some of the issues involved in migrating network address translation (NAT) rules.

All firewall vendors provide essentially the same basic firewall capabilities that are required to control the traffic entering and exiting their corporate network. The following elements make up the bulk of a firewall configuration:

• Interfaces through which the traffic which enter and exit the firewall and optionally security zones to group interfaces with common network availability and security posture.
• Routing rules to route packets through specific interface(s) based on destination and source addresses.
• Network and service objects and groups to define address and service elements and use them in the filtering and address translation rules for better maintenance of the firewall rule base,
• Filtering rules to control traffic entering the device based on Source, Destination and Service of an IP packet.
• Address translation rules to translate virtual ip addresses to real ip addresses and vice-versa,

To get a working baseline configuration for the target firewall platform, all of the above essential configuration elements have to be translated from the original firewall configuration to the target firewall platform.  This simple-sounding task is made very difficult by the myriad of architectural differences and incompatibilities between different vendors’ products.  Some firewall platforms group all security rules into a single flat rule base and evaluate those rules for all packets entering the firewall, regardless of entering interface.  Others provide capabilities to group rules into one or more rule sets and apply them either by specific ingress and egress interfaces or security zones. Similarly, even though the semantics of the address translation rules are the same, the syntax used for creating these rules is quite different in across the various platforms.  These differences pose significant challenges when converting these rules, whether manually or automatically.  Many vendors provide tools for performing these conversions, but all of them have major shortcomings because of these architectural differences.

Network Interfaces and Routing Rules

In this discussion of migration, we will assume that a drop-in replacement of one firewall for another is being done.  This means that there are no changes being made to the structure of the network itself.  This assumption implies that there is a one-to-one mapping of network interfaces from the original firewall to the target and that the target will be connected to the same networks as the original.  This also implies that the routing table will carry over directly from the original to the target.  The routing table is used to identify the networks that are reachable from each network interface.  It is sometimes useful to create network object groups that identify these reachable networks for each interface in the target.  For example, when migrating from a Cisco device to a Check Point firewall, it is necessary to replace “Any” used in filtering rules with network objects that specify the reachable networks for the interface that the filtering rule was applied to.

The syntax and semantics of the routing rules are similar across different firewall platforms, so converting routing tables is essentially a syntax conversion.  The most common type of routes on firewalls are static routes and converting these is very straight-forward.  If dynamic routing is used, it will be necessary to verify that the routes are learned properly on the target firewall.  If the network should change during the migration process, then it will be necessary to update the network object groups created to specify the reachable networks to match any changes in routes.

For appliance firewalls such as Cisco or Juniper devices, the routing rules are part of the firewall configuration.  For Check Point firewalls, the routing rules have to be configured using the native operating system syntax provided for configuring the routing instead of via the management server.

Converting Networks and Service Objects

Network and service objects and object groups provide an abstraction for better management of the firewall rule base. Using objects, you can reuse address and service values in multiple rules.  When making changes, you need modify the values only once in the object definition and it will apply to all rules that refer to the object. By using object groups, you can group network and service objects that serve a common purpose and reuse them in multiple rules and rule bases. When a management server is used, global object definitions can be shared across multiple firewall configurations.

Converting object definitions from one firewall platform to another is fairly easy.  This is largely a matter of converting the source syntax to the target syntax.  The challenge is in reusing existing object groups and detecting conflicts when the target firewalls are managed using a management server that shares global objects between multiple firewalls.

In such environments, it is not sufficient to simply convert the object definitions.  Objects with same content but different names and objects with the same name but different content might already exist in the target management server.  In addition to identifying potential conflicts with existing objects, we might also want to reuse  existing objects where the content is the same.  This requires that we identify the congruent object definitions in the target management server and replace the corresponding object references from the source configuration with references to objects in the management server.

This becomes a significant process issue when migrated configurations are developed in a staging environment and then have to be pushed to production systems.  It is typically not realistic to freeze the production systems for the duration of the entire migration process.  Even if a snapshots are taken at the start of the migration process, the production system is likely to change while the migrations are being worked on.  When the migration is complete, there may still be conflicts between the migrated and production object definitions that must be identified and resolved.

In the next blog post, we will examine some of the issues involved in migrating ACL or filtering rules.

The Change Impact Monitor takes advantage of another new feature, which is the capability to schedule tasks.  You can schedule firewall configurations for update on a regular basis and never have to worry about synchronizing your inventory before running a query again.  You can schedule analysis jobs to run on a regular basis and let FirePAC generate the reports for you automatically.

Speaking of updating configurations, FirePAC can now connect to your devices directly to retrieve configurations and routing tables during the Import and Update operations.  This means that three different mechanisms are available for getting configurations into FirePAC: import from the local filesystem, import from an NCM repository such as Solarwinds Orion NCM, and now import directly from the device.

And last, but certainly not least, FirePAC now supports a distributed architecture with mulitple clients sharing access to a common database.  Now everyone in the team can see the same configurations with only one import.  Combined with scheduled updates, you need never worry about getting out of sync with your teammates.

That’s a lot of powerful new features from Athena Security.  Check it out!

Athena Security’s new PathFinder network path analysis product offers such visibility into security infrastructure. Network engineers can upload configuration data of firewalls, switches and routers into the tool, which generates an offline, virtual model of a network. They can then simulate packet transmission through this network model, and PathFinder predicts how device configurations and firewall rules will affect packet flows.

There’s an interesting case study of using PathFinder to troubleshoot service availability after changes to the DMZ structure in a network.

“Since we got [PathFinder] we’ve been using it to troubleshoot… how the path runs through our ASA [Cisco Adaptive Security Appliance],” he said. “For PCI we’ve recently split our DMZ into four different DMZs. When we first set it up, we didn’t have the routing exactly right through it, and our VMware guy was having some issues with some of the servers that we had in the DMZ.”

With PathFinder’s offline network path analysis features, Serauskas used his device configurations to create a model of his network and sent simulated packets through the DMZ. He saw that the ASA was intercepting certain packets as they passed through it. He examined the rules on the ASA and discovered that some entries were sending the packets through an older path that had gone unused before segmentation.

“We just had to change the path on the DMZ ­— make the proper changes on the firewall for it — and once we made the changes to the config, we ran a new test [in PathFinder],” he said. “Once we knew the IP that [the VMware admin] was trying to get through had traveled correctly, we made the change [in production].

Read the whole article.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

Rich Mogull over at Securosis has additional commentary.

What’s interesting is that this is no random drive-by attack, but rather a targeted assault on a major security vendor.  This is a big deal, of course, because so many organizations rely on RSA’s SecurID systems for authentication.  We currently don’t know the vector of the attaack, what information was lost, or exactly how this will affect SecurID users.  One thing is for sure, if you have a SecurID token from a bank or some other provider, you will want to contact them for guidance.

This is one evolving situation we’ll be watching over the next several days and weeks.

1. Extending Athena’s range of analytics that go deep into individual devices.  With even more limited time and resources, firewall engineers are in need of easier ways to make the analytics more actionable and supportive of certain operational realities.

With the releases of Rule Tracker, Object Standardization, Configuration Debugger and major advancements to our Change Impact functionality, FirePAC meets the requirements for interactive intelligence that is especially useful to security operations groups.

2. Extending Athena’s policy awareness from a device-specific to a network-specific perspective.  Macro level issues involving service availability across multiple devices, reachability based on routing, and what devices to touch to implement a change request are all extremely well-suited for Athena’s offline analysis.

With the release of Athena PathFinder, we stuck to our product development philosophy of offering tools that are focused and easy to use, yet powerful enough to save man years of manual effort.  This is our solution for firewall engineers who are seeking a handy way to test network behavior for troubleshooting and simplifying rule changes, and we made sure they can get started immediately with a free 2-week evaluation offer.