Zone-based firewalls

Zone-based firewalls (ZFWs) such as the Cisco CSR or Juniper SRX use a different underlying security model than the classic firewalls (CFWs) that TrueSight Network Automation supported initially, such as the Cisco ASA. The CFWs used a security model organized around inbound and outbound ACLs applied to interfaces within the firewall. The security model in ZFWs is organized around ACLs applied to source and destination security zone pairs, where each security zone encapsulates one or more interfaces within the firewall. The TrueSight Network Automation security model follows this classic model. To support ZFWs, TrueSight Network Automation must translate from the classic model to the zone-based model when pushing out FW rules to the device.

Consider the following CFW container topology example to see how TrueSight Network Automation performs this translation:

Within the CFW there are six interfaces named Outside 1, Outside 2, Inside A, Inside B, Inside C1, and Inside C2.  Within the TrueSight Network Automation FW model too there are six interfaces with the same names.

Consider that you want to enforce the following security rules within this container:

Note that the security rules for traffic involving NIC Segment C1 are the same as that for traffic involving NIC Segment C2. To enforce these security rules, you would add the following path rules (colors trace back to the originating security rules):

TrueSight Network Automation would translate these into the following FW rule entries in its model:

15 FW rules are spread across 10 different ACLs in the TrueSight Network Automation model, which are pushed out to the CFW without modification.

Consider replacing the CFW with a ZFW in this container. To be able to enforce the same security rules, you would define security zones within the ZFW as follows:

Within the ZFW there are six interfaces named Outside 1, Outside 2, Inside A, Inside B, Inside C1, and Inside C2, similar to the ones in the CFW. Within the TrueSight Network Automation FW model however, there would be five interfaces defined, named after each security zone: Outside 1, Outside 2, Inside A, Inside B, and Inside C. 

With this updated topology, TrueSight Network Automation would translate the original path rules into the following FW rule entries in its model:

TrueSight Network Automation would translate these FW rule entries into the following ZFW rule entries to be pushed out to the device:

The 15 rules spread across 10 different ACLs in the TrueSight Network Automation model have been translated into 9 rules spread across 6 zone pairs to be pushed out to the ZFW device. The rules in a given zone pair will be a combination of applicable rules from the inbound ACL of the interface, which corresponds to the source zone, plus applicable rules from the outbound ACL of the interface which corresponds to the destination zone.  To be applicable, the rule’s source endpoint must be closest to the source zone interface, and its destination endpoint must be closest to the destination zone interface. To determine the closeness of an endpoint to an interface, TrueSight Network Automation first determines which segment encapsulates it most tightly, and then determines which interface connects to that segment most directly.

To translate from the CFW model to a ZBF model, each endpoint of the rule must lie within a network segment (or NAT pool) defined within the container. This is because in order to do the translation, TrueSight Network Automation must be able to determine the ZBF zone pair to apply the rule to.