AWS re:Inforce 2019 is a two-day conference for security, identity, and compliance learning and community building. This year’s keynote, presented by AWS Vice President and CIO, Stephen Schmidt, announced the general availability of AWS Control Tower and the new VPC Traffic Mirroring feature. These two announcements resonated with me, and I wanted to expand upon them to help you gain valuable insights into how Amazon Web Services (AWS) manages security at scale.
In this article, we’ll take a closer look at each of these topics. To dive deeper and train on the leading security tools and best practices in the cloud, test your skills, and keep your cloud environment secure and compliant, check out Cloud Academy’s Security Training Library.
AWS Control Tower
Migrating to AWS can be a big challenge for organizations. Any help with infrastructure, account design, security, and implementing operational controls would be welcomed by many. This is where AWS Control Tower can help. It has been designed to help create and outline a multi-account AWS environment that conforms to best practices defined within the AWS Well-Architected Framework, including security and key operational services as a landing zone.
AWS Control Tower helps ensure that your AWS accounts meet standards required and stipulated by specific compliance controls. It includes the option to adopt and implement AWS Config Rules as a part of the deployment, ensuring specific controls are being met. AWS Config Rules provide a great method to help you enforce specific compliance controls and checks across your resources and allows for you to adopt an ‘ideal’ deployment specification for each of your resource types. Each rule is simply a Lambda function. When called upon, it evaluates the resource and carries out some simple logic to determine the compliance result with the rule. AWS Control Tower will also provide a summary of each AWS account to show its compliance with your policies to show if there is a violation against any AWS Config Rules.
Guardrails
Control Tower also uses a feature known as guardrails within your AWS Organizations organizational unit (OU). These guardrails can be both mandatory and optional to help enforce security compliance and governance across your accounts. Examples of mandatory guardrails include controls such as:
- Disallowing changes to IAM roles set up for AWS Control Tower
- Disallowing public read access to log archive
- Disallowing policy changes to log archive
In addition to these mandatory guardrails, there are also numerous recommended guardrails that you can enable or disable, such as disallowing public write access to Amazon S3 buckets. As well as being either mandatory or optional, these guardrails fall into two categories: preventive and detective. Preventive guardrails stop actions that fail to comply with your policies, and detective guardrails identify non-compliance within your accounts.
AWS Control Tower automatically and efficiently implements new accounts. This can be configured to use other management tools, such as AWS Organizations and AWS Service Catalog, to help you maintain greater control over your AWS environment.
Blueprints
Much of this configuration is simplified in an automated setup through the use of Control Tower blueprints. These best-practice blueprints provide a template configuration centered around AWS security and management services. This helps to deploy your infrastructure using key features, such as federation, logging, audit control, enhanced network design, and workflows to help provision accounts.
Here are a number of examples of what the different blueprints can assist you with:
- Configure AWS Organizations to create a multi-account environment
- Provide identity management using AWS SSO Users and Groups
- Federate access using AWS single sign-on
- Centralize logging using AWS CloudTrail and AWS Config
- Enable cross-account security audits using AWS IAM
- Implement network design using Amazon VPC
- Define workflows for provisioning accounts using AWS Service Catalog
As a part of the overall management of your multi-account environment, AWS Control Tower allows you to view your infrastructure from a top-level summary via a dashboard which provides information such as:
- Number of accounts provisioned
- Number of policies enabled across all of your accounts
- Compliance status of your accounts
Summary
In short, AWS Control Tower is a powerful new addition to the ever-expanding security, identity & compliance category of AWS services to govern and secure multiple AWS accounts. For more information on AWS Config and AWS Organizations, check out the following links:
VPC Traffic Mirroring
Within any organization, security analysts strive to understand what traffic is being generated by resources across the network to discover potential security threats and weaknesses and to troubleshoot incidents. By using AWS virtual private clouds (VPCs), one method of capturing this traffic is to deploy agents across your resources to track and capture network traffic from your EC2 instances. As your environments grow and you deploy more and more VPCs, this approach of agent-based deployments can become very cumbersome and difficult to maintain and manage.
I am pleased to report that AWS has now developed and designed a new solution to resolve this problem. VPC Traffic Mirroring is a new feature within the VPC service, allowing you to duplicate network traffic generated from your resources within your VPC. This traffic can then be sent to another instance or appliance for further analysis and inspection without the use of any third party agents installed on your resources, simplifying management and control of traffic capturing. VPC Traffic Mirroring is only available on sources running Nitro-based instances.
Bandwidth
As this process duplicates traffic, this additional load counts towards your bandwidth associated with the source instance. If your bandwidth limit reaches capacity, causing congestion, then AWS will first drop your mirrored traffic used by VPC Traffic Mirroring to help alleviate the congestion.
Design
Per design best practices, it’s recommended that you forward your duplicated network traffic to a Network Load Balancer (NLB), which then forwards the traffic to a fleet of appliances sitting behind it via a UDP listener. If required, you can simply forward the traffic to a single instance or appliance, but you should design with high availability in mind.
The great thing about VPC Traffic Mirroring is that the instances or appliance that performs the traffic analysis can be in a different VPC than that of the source generating the traffic. This allows you to achieve a hub and spoke design, drawing in traffic collated from multiple different VPCs all being directed from a single VPC dedicated for security analysis and detecting network anomalies. Again, this design helps with management and control of your resources.
Mirror filter
With added configurational parameters, its possible to implement mirror filtering to allow you to specify which network packets you are interested in capturing. For example if you want to analyze all traffic using a specific port and protocol, such as SSH, then this could be configured via a mirror filter.
Any traffic that matches the mirror filter criteria would be captured, and any that didn’t would be dropped at the source. This prevents your appliances and instances from having to analyze ALL traffic generated by a resource when you may only be interested in a specific subset of the traffic.
Components
The components used within VPC Traffic Mirroring are easy to define. Firstly, we need a source. This can be any resource within your VPC which uses an Elastic Network Interface (ENI), such as an EC2 instance.
You must also have a mirror target as well, which is where the traffic will be sent. As I explained earlier, this would generally be a network load balancer, but you can specify an ENI of another instance or appliance as required. This target can even be in a different VPC as the source.
To restrict which traffic is captured at your source, you can set and configure your mirror filters which are created as rules, based on protocols, ranges, and CIDR blocks. These rules are then read in order and the appropriate action is taken as soon as a match is found, much like a network access control list (NACL).
The final component is a mirror session. This essentially defines the logical connection between a source and a target and it’s associated mirror filters. You can create more than one mirror session for a source. For example, as shown in the diagram below, you can create a mirror session (Mirror session 1) that captures all TCP traffic from Source A to Target A. Then another mirror session (Mirror session 2) captures all UDP traffic from Source A (again) but to a different Target: Target B.
This might be helpful if you have different tools on each target that you will use to analyze different types of traffic. However, be aware there is a limit of three mirror sessions per ENI.
Summary
Being able to monitor network traffic across multiple VPCs without having to implement agents on monitored resources simplifies network analysis for incident identification and resolution, security anomalies, and compliance. The ability to couple this configuration with existing security tools obtained from the AWS Marketplace makes this a very powerful tool in the security of VPCs.
