Cloud Network Security with AWS Network Firewall

James Bromberger, 20 August 2021

Country: Australia

Executive Summary

Akkodis implemented a fully managed cloud firewall to either restrict or inspect and permit data egressing from a customer’s Cloud network as a central point of control. This was delivered in a DevOps approach and brought a significant uplift in customer security profile.

About the Client

The client is a large public sector organisation in the energy industry. They are undertaking a major cloud migration of their systems, starting with a few analytics workloads. These systems are from their IT portfolio and are key to their revenue stream.

As a public sector organisation, budgets are tight; the TCO and cloud costs need to be optimised from a cost and effort perspective.

The Challenges

There are multiple providers working in segregated AWS workloads and VPCs, connected into one co-ordinated network topology. While teams are given guidance on best practice for network security, the customer wishes to have a centralised control.

The individual engineers from the disparate providers have differing levels of experience and competency with configuring AWS. Akkodis’ deep experience means that accepting default values in certain environments and with certain managed services is sometimes not adequate. Despite offering these recommendations, the individual providers did not follow these recommendations, so centralised control appears desirable.

With more workloads starting to migrate, the desire to have egress filtering in place rapidly was growing.

The Objectives

After deep discussions with the customer’s security and governance teams, we resolved the following split of traffic:

Ingress web traffic would enter into production workloads from the Internet; a public-facing Application Load Balancer with Web Application Firewall and an Amazon Certificate Manager (ACM) certificate would be the external presentation layer, with a strict cipher configuration.

These ALBs would be in Public subnets in the same VPC (and same AWS account) as the required Target Group and EC2 instances, permitting the entire configuration to be in one (set of) CloudFormation templates, and not breaking the CI/CD boundary across accounts.

The Strategy The initial strategy was to permit only the desired outbound network traffic based upon the previous requirements spreadsheet.

All egress traffic from instances residing in private subnets would be routed via Transit gateway to a centralised Packet Inspection VPC, and a Network Load Balancer would funnel traffic to a managed 3rd party firewall appliance running on a fleet of Ec2 instances.

Akkodis dug in and challenged the desire to filter traffic, with a few limited exceptions. With an initial requirement for permitting outbound HTTP and HTTPS traffic, we pushed the customer to answer the question: why do you want to do unencrypted HTTP from your production environment to external services across the untrusted Internet? We resolved to raise the bar and drop support for unencrypted HTTP egress traffic. We also sought to ensure that HTTPS traffic (currently TCP port 443) would be validated to contain TLS traffic (no break in inspection was required).

The Solution With this simple requirement for inspection, we proposed to replace the third-party firewall service with a cheaper, more scalable and managed AWS Network Firewall.

We created a CloudFormation template to create the network inspection VPC, deployed into the Sydney AWS Region (ap-southeast-2). The Inspection VPC would span three Availability Zones (with accommodation for a fourth Availability Zone) to ensure that it could match the egress path for all traffic and provide maximum availability.

A second template defined the Network Firewall, its configuration and rule set, and the routing changes required to filter the outbound traffic and the return path flow via the network firewall. This template also defined the retention period for flow and alert logs from the managed firewall.

Centralised Inspection VPC (egress) Diagram

The rules in place ended up being relatively straight forward, requiring the TCP handshake to complete and the initial TLS packet to traverse the network before making a decision on rejecting the traffic. All other ports were directly dropped.

The Result The end service is a scalable managed service ensuring that service issues and maintenance updates are consumed as-a-service. The cost is around one-third of the previously estimated third-party firewalling (and without the customer managed software upgrade process).

With this solution in place, private subnets across the enterprise can request resources, appear in a central log, and be reviewed and monitored.

Rules can be added to the Network Firewall by way of CloudFormation updates and any changes can be detected via CloudFormation drift and stack update times.