Network Security Policy to Enforcement with Aviatrix

Aviatrix provides several mechanisms to enforce network security policy. This is the first in a series of articles about network security policy enforcement mechanisms in the Aviatrix platform. In this article we describe the path from network security policy intent to enforcement. Figure 1 provides an overview of this path.

Figure 1: Steps to move from natural language network security policy to configured enforcement points implementing that policy.

People and organizations like to reason about policy. Government and industry organizations like NIST, SEC, ISO, and PCI provide policy standards to enterprises. In turn teams of auditors are hired to periodically validate that enterprises are following the required policy standards

Policy is written in a human language like English or French, so there is a lack of precision and a gap between what is expressed in the policy and the detail required by devices to enforce the policy. For example, consider the following network security policy:

Figure 2: Overview of network topology. The green arrow connects the two entities addressed in the natural language security policy

The team responsible for network security deployment can configure a number of devices throughout the system to enforce the network security policy mapped to enforceable details. That team can also adjust routing to ensure that all traffic is routed through the appropriate enforcing devices. In a large network topology spread over multiple providers, manually performing this mapping of policy to enforcing devices is tedious and error prone.

In practice, teams will use one or more frameworks to deploy network security policy changes, either frameworks they develop, frameworks from a third party or a combination of third party and self developed logic. Aviatrix as a third party framework provides several mechanisms to simplify deployment of the enforceable network security policy.

Aviatrix Firenet manages routing to ensure that specified traffic passes through virtual third party firewalls also managed by the customer. Figure 3 shows the resulting topology from our example. Aviatrix sets up the routing so traffic to the corporate database is routed through the third party firewall.

Figure 3: The green and yellow areas reflect the routing rules configured by Aviatrix to ensure traffic to the corporate database passes through the third party firewall.

In this case, the customer interacts with two platforms to deploy their network security policy: Aviatrix and another traditional firewall vendor such as Palo Alto Networks or Checkpoint. Through the Aviatrix system, the customer specifies where the traditional firewalls are deployed in the cloud environment and for each firewall which part of the network topology should be routed through that firewall.

The specifics of the network security policy are defined through the management interface provided by the traditional firewall vendor. If the firewalls are deployed in multiple parts of the network topology, the customer will need to configure each deployed firewall with the appropriate subset of the rules.

Aviatrix Distributed Cloud Firewall (DCF) handles both the routing of traffic to enforcement points and the configuration of those enforcement points to accurately implement the network security policy.

With DCF the customer defines one global network security policy. An example is shown in the diagram below.

Figure 4: DCF rule user interface. The first rule encodes our example policy, and refers to smart groups for the source and destinations of the policy.

The policy is built from Smart Groups which represent entities in the customer’s environment. Items in smart groups can be defined in terms of IP addresses and network CIDRs, but they can also be defined in terms of cloud provider resource like tags. Cloud providers like AWS, Azure and GCP allow customers to associate tags with virtual machines, networks and virtual clouds. By specifying a tag such as “prod” in a smart group, any policy referring to that smart group will be enforced against the addresses that correspond to the tagged items at that point in time.

Figure 5: The edit screen for the corporate databases smart group. It is defined by all virtual machines that have the tag deployment set to the value corp-db.

The global policy is deployed at the point in the network where it is needed. If the traffic is moving between VPCs as in our example policy, the policy can be enforced by gateways in the Aviatrix Transit fabric on the path between the production VPC and the database VPC. If the policy applies to traffic between entities in a single VPC, Aviatrix can orchestrate cloud provided network security mechanisms like AWS Security Groups to enforce the policy.

Figure 6: Inter-VPC enforcement points for Aviatrix DCF. For our example policy, the traffic between Production Servers and Corporate Databases should be enforced at the Aviatrix gateways associated with the Prod VPC and the DB VPC. No extra routing hops are required.

Since Aviatrix knows about the customer’s cloud resources, it can automate the work of resolving an enforceable policy to specific, pruned policies for the various enforcement points:

• Resolve tags to current IP addresses

• Update IP addresses based on address translation rules in the fabric.

• Determine where policy traffic will traverse the topology

• Understand how to orchestrate network security policies for specific cloud providers

By distributing the enforcement throughout the network, policies get enforced closer to the source of the traffic, dropping traffic sooner and reducing load on the rest of the network. Also by spreading the enforcement load, no network security enforcement device will take the full processing load.

This overview article skips over a lot of interesting details in how the Aviatrix distributed cloud firewall really works. Stay tuned for future articles in this series to learn more.