Continuous verification of network compliance using Amazon VPC Network Access Analyzer and AWS Security Hub

Introduction

As your distributed application teams operate network infrastructure, it can be challenging for central security, networking, or cloud operations teams to determine whether the correct network controls are in place. Network controls, such as firewall rules, NAT Gateways, network access control lists (ACL’s), security groups, and network segmentation, serve as a critical first line of defense in securing your infrastructure. They help block illegitimate network access and prevent your critical resources from external access.

Today, many customers address governance of their network by manually checking network designs and configurations. This approach is difficult and does not always identify every network access issue, especially on a large scale. It is operationally tedious, error prone, and therefore an ineffective way to validate your overall network control objectives. In addition, cloud environments are dynamic, with evolving security mandates and constant network design changes. Finally, operations and network teams often find it challenging to show that network controls are compliant.

The previous blog post introduced the Network Access Analyzer feature of Amazon Virtual Private Clouds (VPC). Jeff’s post walks through how Network Access Analyzer helps you identify network configurations that lead to unintended network access. It shows ways you can use this feature to identify improvements to your security posture while still letting you and your organization be agile and flexible.

In this post, we describe an architecture for continuously monitoring the compliance of your network configuration using AWS Security Hub and Amazon VPC Network Access Analyzer. Security Hub consumes, analyzes, and aggregates security events produced by Network Access Analyzer by consuming its security findings. Aggregating security events from across your AWS environment into Security Hub allows your security teams to integrate those events into their existing tools and workflows. This helps you to more easily verify network compliance at scale in your AWS environments.

To assist simplify your deployment, we also provide you with the code to provision the infrastructure required to set up continuous monitoring and export of Network Access Analyzer findings into Security Hub.

Network Access Analyzer – How it works

Network Access Analyzer uses automated reasoning to verify and statistically prove whether your network controls meet your requirements. You define your requirements in a Network Access Scope. Analyzing a scope produces findings that show where there are non-compliant network configurations, the affected resources, and their traffic flows.

For example, you can specify validation policies such as, “Finance must be isolated from Development” and “Web-apps can access the Internet only through a Firewall”. Once you declare these governance requirements, use Network Access Analyzer in an on-demand basis to validate that the network conforms to these requirements. This simplifies network and security operations by allowing you to express and validate your high-level requirements in a simple and comprehensive manner, rather than creating and managing disparate configuration rule checks.

Solution overview

In this section, we will cover how our solution of Network Access Analyzer and Security Hub works. The solution uses an Amazon EventBridge for scheduling an event that triggers a state machine that runs the network scope analysis and exports the findings as security events to Security Hub. Figure 1 shows a high-level architecture of Network Access Analyzer and AWS Security Hub.

Figure 1: A high level architecture of Network Access Analyzer and AWS Security Hub

The step function runs at a set interval (configurable value with default set at every 12 hours). During the execution, they carry out the following steps:

Step 1: Initiates network scope analysis for all the network scopes defined within Network Access Analyzer in the target AWS Region.

Step 2: Checks if all the analyses are complete (with a default 30 second wait between network scope analyses).

Step 3: Sends findings to Security Hub for the analysis that are complete.

Step 4: If the analyses are not complete, the execution returns to Step 2, otherwise the analysis result is formatted as an output of the step function.

All the code that is required to deploy our solution can be found in the GitHub repository.

Solution walkthrough

To show how this solution works, we walk through an example use case of a business application running on an EC2 instance in a VPC that is accessible over internet. Another EC2 instance with a directory service or database is used as an example running in another VPC. The two VPCs are connected via VPC peering. The directory service or database instance pulls the updates from internet using a NAT gateway. This is shown in figure 2.

Figure 2: An use case scenario of a private EC2 instance running a database or any directory service and a business application hosted on an EC2 from different VPC connected via VPC Peering

With this architecture, Network Access Analyzer identifies any non-compliant network access configurations. We review the findings to identify what we must change to ensure that network access is complaint. We focus on three network requirements, and intentionally tweak the network configuration to generate findings. We use the following network security guidelines:

1. Inbound traffic from the internet can only access port 80 and 443 across all EC2 instances.
2. Outbound traffic from the VPC hosting the business application to the VPC with an EC2 instance running (directory service or databases as examples) only allowed on port 53 (the port directory service is running on).
3. Outbound traffic to the internet is only allowed to download directory service software updates from a public IP address range 55.3.0.0/16 (the IP address range of the servers hosting the updates).

The following steps begin network analysis and send findings to AWS Security Hub.

1. Deploy the sample infrastructure with the compliant configuration.
2. Create network access scopes to define the compliance requirements.
3. Deploy the solution to run analysis.
4. Update the sample infrastructure with a non-compliant configuration.
5. Verify that findings were sent to AWS Security Hub.

Prerequisites

• An AWS Account or set of accounts in which you want to continuously monitor compliance.
• AWS CloudShell in your AWS Account (recommended as it already comes with Serverless Application Model (SAM CLI pre-installed) or you can use a command line tool within your local computer or an EC2 instance in which case you will need to install SAM CLI following the instructions.
• Identity and Access Management (IAM) permission to create the provided CloudFormation stack and the corresponding resources.
• An understanding of Security Hub and the instructions to set it up.

Step 1 – Deploy the sample infrastructure with the compliant configuration

In this step, we deploy the sample infrastructure in the preceding diagram (Figure 2) by using a CloudFormation template. The template created two VPCs as part of the deployment to ensure you have not exhausted your Regional VPC quota.

To deploy the stack, run the following in the CLI

git clone https://github.com/aws-samples/aws-vpc-network-access-analyzer-automation/tree/main/sample_resources

aws cloudformation create-stack --stack-name networkaa-autorun-sample-stack --template-body file:///$PWD/compliant-sample-stack.yml --capabilities CAPABILITY_NAMED_IAM

Next, run the following command to retrieve the stack output. Note the VPC identifiers in the output. You will use these values while creating network scopes in step 2 and compliance requirement 2.

aws cloudformation describe-stacks —stack-name networkaa-autorun-sample-stack

Figure 3: Output from CloudFormation template deployment

Step 2 – Create network scopes to define the network security guidelines

We will now create the network access scopes that will identify if the network configuration is compliant. We base the network access scopes on the three compliance requirements as examples.

Compliance Requirement 1 – Inbound traffic from the internet can only access port 80 and 443 across all EC2 instances

We configure the match path for this network scope to have a source resource type of “AWS::EC2::InternetGateway“ and a destination resource type of ”AWS::EC2::Instance”. The exclude path sets the expected destination ports to be either 80 or 443. The network scope applies to all inbound traffic from all InternetGateway resources to all EC2 instances in the Region. This is enabled by running the following commands

cd aws-vpc-network-access-analyzer automation/network_access_scopes

aws ec2 createnetwork-insights-access-scope --cli-input-json file://all_ingress_port_80_443.json

Compliance Requirement 2 – Outbound traffic from the VPC hosting a business application to the VPC hosting a directory or database service is only allowed on port 53

The match paths (that contain source and destination elements) for this network scope have a source resource with the business application VPC identifier and a destination resource with the directory service VPC identifier. The exclude paths (that can contain resource types, specific resources, and so forth) set the expected destination port to 53 (the port the directory service is running on). The network scope applies to all outbound traffic from the business application VPC to the directory service VPC. If the traffic accesses any port other than port 53, it generates a finding. To perform this step, modify the file with VPC IDs shown in figure 3 as per your account setup and run the following command:

aws ec2 createnetwork-insights-access-scope --cli-input-json file://all_vpc_egress_to_port.json

Compliance Requirement 3 – Outbound traffic to the internet is only allowed to download directory service software updates from a public IP address range 55.3.0.0/16

The match path for this network scope has a source resource type of  ”AWS::EC2::Instance” and a destination resource type of “AWS::EC2::InternetGateway“. The exclude path sets the expected destination IP address range to be 55.3.0.0/16 (the IP address range of the servers hosting the updates). The network scope applies to all outbound traffic to the internet (via the InternetGateway) from all EC2 instances in the Region. If any traffic can reach a destination IP address that is not in the CIDR 55.3.0.0/16, it generates a finding. To adhere to compliance requirement 3, run the following command:

aws ec2 createnetwork-insights-access-scope --cli-input-json file://all_egress_to_cidr.json

To guide you on how to create network scopes to meet your network security needs refer to the documentation.

Step 3 – Deploy the solution and run network scope analysis

In this step, you deploy the solution to schedule the execution of the network scope analysis and send the findings to AWS Security Hub following the instructions below. The “sam deploy —guided —capabilities CAPABILITY_NAMED_IAM“ command asks you to specify a few parameters. You can select the defaults by pressing “Enter” at each prompt.

cd /home/cloudshell-user/networkaa-autorun

sam build

sam deploy --guided --capabilities CAPABILITY_NAMED_IAM

Once we have deployed the SAM application, a schedule rule is created in Amazon EventBridge that triggers the step function at the set interval. The step function consists of three tasks:

• RunNetworkScopeAnalysis – a lambda function that identifies all the network scopes created in the corresponding Region and initiates a network scope analysis for each.
• CheckNetworkScopeAnalysis – a lambda function that checks the status of the network scope analysis to identify if the analysis is still in a “running” state.
• SendFindingToSecurityHub – a lambda function that aggregates the findings across the network scope analysis and sends the findings to AWS Security Hub.

Because we deployed the compliant infrastructure, the step function executes but does not send any finding to AWS Security Hub. The Figure 4 is the output of the step function (“findings_count”) that shows that no findings were generated.

Figure 4: Execution of the Step Function on the compliant infrastructure

Step 4 – Update the sample infrastructure with a non-compliant configuration

In this step, we update the sample infrastructure with a non-compliant configuration. We changed the CloudFormation template to make our configurations non-compliant.

• Updated the Directory Service security group to allow ingress on all ports (and not just port 53) and allow egress to all public IP addresses 0.0.0.0/0 (and not just the update server IP address range 55.3.0.0/16).
• Updated the Business Server security group to allow ingress on all ports (and not just port 80 and 443) and allow egress on all ports (and not just port 53).

The sample_resources folder contains the non-compliant CloudFormation template. You update the stack using the commands below:

cd sample_resource

aws cloudformation update-stack --stack-name networkaa-autorun-sample-stack --template-body file:///$PWD/non-compliant-sample-stack.yml --capabilities CAPABILITY_NAMED_IAM

Step 5 – Verify that findings are sent to AWS Security Hub

The next run of the step function identifies findings during the network scope analysis and sends them to Security Hub. It identifies each finding in Security Hub with the network access Scope Id and the severity level set to “MEDIUM” by default (you can build a logic to set the right severity level for your needs based on the network scope). This is shown in Figure 5.

Figure 5: Security Hub Findings generated by the solution

Clicking on the link “Finding ID” (shown in the top right of the screenshot that follows, Figure 6 shows the full Security Hub finding (in JSON). The finding includes the network scope analysis id and the total number of findings generated by the solution.

Figure 6: Output from Security Hub finding generated by the solution providing details on NetworkScopeAnalysisId and NetworkScopeAnalysisFindingsCount

Once your incident response process resolves the finding, update the corresponding finding in security hub using the Security Hub BatchUpdateFindings API.

Clean up

Follow the instructions that follow to clean up the provisioned resources. Leaving resources that you no longer need in your AWS account may incur charges. Performing these steps will delete the Lambda functions, Event Bridge, EC2 instances, Step Functions, Peering Connections, and CloudWatch Logs that were created as part of deploying the solution discussed in this blog post.

aws cloudformation delete-stack --stack-name networkaa-autorun

aws cloudformation delete-stack --stack-name networkaa-autorun-sample-stack

Conclusion

Network Access Analyzer uses the same automated reasoning technology that powers AWS IAM Access Analyzer, Amazon VPC Reachability Analyzer, Amazon Inspector Network Reachability, and other provable security tools from AWS. These features use Network Access Scopes to specify the desired connectivity between your AWS resources. In a previous post by Jeff on Network Access Analyzer, we showed how you can get started with a set of existing scopes, and then either copy and customize them, or create your own from scratch. The scopes are high-level and independent of any network architecture or configuration. You can think of them as a language for specifying the proper level of access and connectivity for your network.

In this post, we’ve shown how to deploy a SAM based solution for collecting the Network Access Analyzer findings in AWS Security Hub leveraging AWS Step Functions workflow. We also provided you with the necessary CloudFormation templates.

To learn more about Network Access Analyzer, check out documentation.

We hope that you’ve found this post informative and we look forward to hearing how you use this new feature!

About the Authors