The third pillar to well-architected AWS cloud security — NetSec (Network Security)

This is the fourth in a series of seven on the five pillars for well-architected AWS security.  For the entire series, visit the Five pillars – AWS blog page here.

Many organizations make the mistake of beginning their security framework discussions around Infrastructure Protection (aka NetSec), as this was traditionally how they secured on-premises infrastructure.  Companies erroneously assume that because they are leveraging a cloud infrastructure, either they will be less secure than when they “owned” all those resources, or that they can simply mirror their on-premises network security controls in the cloud.

Again, the cloud is different.  The Shared Security model under which AWS operates inherently guarantees security of the network – but can’t guarantee the security of the companies who are accessing it.  Or put another way, organizations using the cloud need to put security measures in place that will ensure they are not the source of threats and compromises.

This is where Firewalls and WAFs in the cloud offer security at a different level.  The controls and nomenclature may be the same as on-premises solutions, but the functions they provide are designed to operate in an infrastructure that is inherently fluid and off-premises.  Because resources are cloud-based, companies often turn to benchmark policies such as CIS Benchmarks that describe cloud-focused policies to detect security policy violations – situations that simply didn’t exist in an on-premises infrastructure. 

In AWS, you can implement both stateful and stateless packet inspection at a very basic protection level – either AWS-native technologies can be leveraged or a number of third-party partner products and services can be acquired through the AWS Marketplace.

The Amazon Virtual Private Cloud (Amazon VPC) provides a private, secured and scalable environment – specifically designed to allow you to define your own specific topology.  With the VPS environment, gateways, routing tables, and both public and private subnets can be defined and protected.   Persistent defenses can be deployed by hardening configurations they develop in either Amazon EC2, ECS, or Elastic Beanstalk instances by containers and then applying these configurations to an Amazon Machine Image AMI – then, all new instances launched via this AMI will receive the same hardened configuration.

To develop a well-architected infrastructure protection pillar, customers must:

• Understand how they will protect their networks
• Understand how they will protect their compute resources

Visit the Well-Architected Labs documentation series to read more about Protecting Networks and Protecting Compute Resources.

Next week we’ll dive deeper into the 4^th Pillar, Data Protection. To follow this series in its entirety, visit the Five Pillars – AWS blog page here.