Making East-West Security More Robust on AWS with More Specific Routing (MSR)

Sometimes the smallest of features makes a world of a difference. This post details the recent Amazon VPC routing enhancements that allow customers to inspect traffic between subnets in an AWS VPC. On the surface, this feature from AWS looks small but the outcome to AWS customers is huge.

This AWS feature along with cloud-native integration from providers like Valtix significantly improves public cloud security for AWS customers. Specifically, this solution allows customers to shrink the zero trust boundary of inspection from a VPC to a subnet-level construct for east-west protection against lateral attacks. We will use the term more specific routing (MSR) to refer to this feature since it lacks a glamorous name.

AWS More Specific Routing

From a network security perspective, before the MSR feature was released control of routing was restricted to the VPC’s CIDR, i.e. you could not specify a route more specific than the VPC IP range (aka CIDR) unless the destination was outside the VPC. This meant that one could not force traffic from subnet 1 going to subnet 2 (within the same VPC) to go to a firewall or any specific destination for inspection.

You could only control traffic going to a destination outside the VPC, for example to other VPC’s or to the Internet. This meant that the entire VPC was effectively a giant trust boundary. An attacker or malicious insider inside the VPC can effectively attack and compromise any other cloud resource within the VPC (including VPC endpoints and Private Links for services like RDS, S3, DynamoDB, etc or third-party services accessed privately). 

More specific routing means that you are now allowed to define a route more specific than the VPC CIDR, but only up to subnet level, i.e. traffic that leaves a subnet to any destination can now be redirected to any chosen destination. This is a major advancement in implementing proper network security to ensure:

• that lateral attacks can be stopped at the subnet boundary
• segmentation can be implemented at a subnet-level and does not force the creation of separate VPCs to achieve this

At this point, traffic between instances inside a subnet cannot be controlled or inspected, i.e. your micro-segmentation boundary is restricted to subnet boundaries for east-west traffic within a VPC. For traffic with destinations outside the VPC, you can create instance-level microsegmentation policies (details below).

Valtix supports the MSR feature and improves it by enabling true dynamic security policies that are not dependent on static IPs or subnet IP ranges:

• Define security and inspection policies based on continuous cloud asset discovery:
  • Use tags assigned to your instances 
  • Use VPC endpoints
  • Use PaaS definitions to allow/block from the 100s of AWS services
• Apply the same security policy across subnets, VPCs and across multiple AWS accounts and across clouds

For example, your policies in Valtix would look exactly the same across all deployments, including across AWS, Azure, and Google Cloud. 

Tag-based security policies in Valtix powered by the continuous cloud-asset discovery

MSR together with the new PaaS visibility and control features of Valtix 2.9 allows customers to enforce stricter controls on a per-subnet basis.

Summary

AWS more specific routing (MSR) allows east-west inspection at a subnet-level instead of the VPC-level previously. But it is impractical to write every security policy at a subnet-level across the 10s and 100s of subnets in your environment. Valtix fixes this problem by performing continuous cloud-asset discovery. This has several significant benefits in terms of security and operations:

• Easily define east-west policies whether it’s at a VPC-level, subnet-level, or instance level. By just setting your routing once during VPC design, you are free from constantly adjusting security policies to match the networking and application changes. Valtix discovers the workload context for you and enforces relevant security policies. 
• Security teams can consistently define policies that work regardless of whether workloads/instances exist now or in the future, in any VPC, account, or cloud. As soon as a new instance (traditional VM or a container) spins up or tags are updated, Valtix notices it within seconds and enforces policy.
• Application teams know the approved security policies and simply have to tag their workloads correctly to make an application go live – you don’t need to open a ticket for every firewall change!
• Bake security into your DevOps process: as the app moves through the dev to release cycle (dev, test, staging, prod), you can automatically enforce policies with no additional work. 

The more specific routing (MSR) feature is a significant improvement for organizations that already use contextual tags for billing and cost allocation to build a more robust security architecture. It also aligns with a common security best practice of attribute-based access control that Valtix enables with continuous, and near real-time, discovery of cloud assets. 

To experience Valtix in a 10-minute interactive demo, please take our product tour.