Control Compliance Suite

Amazon Web Services (AWS) clouds offer a variety networking security controls for segmenting and isolating EC2 instances running in that cloud. These controls address the following use cases

1. Isolate EC2 instance from the public internet. E.g make those instances unaccessible from the public internet.
2. Isolate EC2 instance belonging to an Enterprise from other EC2 instances belonging to other tenants.
3. Within a tenant, isolate applications and departments from one another. This can be also be used to isolate application tiers from one another.
4. Isolate applications and application tiers from one another within a tenants AWS network..

AWS Network Security Constructs

AWS offers a variety of networking constructs to implement these controls. These include VPC's, Gateways(Internet and VPN), NAT, Subnets, Routes, Security Groups and Elastic IP's.  These objects would be used to implement the above controls as described below in  an example scenario:

A VPC creates a private address space that is not visible to other AWS customers. Instances within a VPC cannot receive traffic from nodes outside the VPC. To allow this traffic (at least for some instances) the following must happen

1. Deploy gateways in the VPC.   
   1. An Internet gateway allows traffic into the public internet.
   2. A VPN Gateway allows traffic back onto the premises via a VPN tunnel.
2. Only instances that have an Elastic IP (EIP) assigned can are visible on the public internet, and can be connected to.
3. A NAT is desirable for ensuring that instances are not directly connected to the public internet. In a secure configuration only the NAT instance should route traffic through the gateway.  In this case the EIP needs to be assigned to the NAT; no other instances need the EIP since  traffic is routed to them through the NAT.
4. Subnets The internal address space is broken up into subnets to allow more additional isolation controls within the VPC.  Different application tiers and different applications may run on different subnet. A subnet is associated with the following
   1.        Routes. This decides how internal and external IP’s are routed to. For example to enable traffic to the internet all external traffic must be routed to the NAT if one exists, or directly to the Internet gateway otherwise.
   2.        Network ACL’s. This is another layer of firewall rules controlling which traffic can enter/exit the subnet. (from/to which CIDR ranges, ports, protocols)

Routes offer additional controls on which instances may make outbound calls to  the public internet. Network ACL’s can be used for controlling access between instances running in different subnets.

5. Security Groups. This sets up hypervisor-based firewall rules for  EC2 instances controlling which ip’s, port, protocols have(not) access to that instance.

Vulnerabilities Arising from Misconfiguration

    Clearly there are a wide variety of AWS objects that need to be configured correctly, and must be monitored for changes that may weaken the network security posture.  These practices are well known to network security architects. However in the cloud often the application admin or server admin takes on networking and storage configuration responsibilities. This conflation of responsibilities may lead to misconfiguration errors. Examples of such vulnerabilities include:

1. Segmentation Management Vulnerabilities. E.g.
   1. Is an EC2 instance running outside a  a VPC?
   2. Is the VPC deployment offer an additional isolation controls using multiple subnets?
   3. Are distinct applications  and tiers isolated in separate security groups?
2. Segregation of responsibilities. E.g. Are their separate AWS admins for separate applications and tiers?
3. Least Privilege. E.g. Are separate applications and tiers locked down to the least required network access permissions via Routes, Network ACL’s and Security Groups?

Compliance Check Automation and Remediation

Configuration checks on infrastructure assets are a common feature of on-premise security programs. Tools for implement these checks discover assets(servers, applications etc), and have pre-built checks against those asset types. The checks may roll up into various internal IT or regulatory compliance standards (e.g. PCI, HIPAA).  Similar capabilities need to be developed against cloud infrastructures. This includes the ability to model rich object relationships such as those defined in the AWS network security objects, and be able to rapidly query those object models for configuration vulnerabilities.   We are working on extending our control compliance products to implement network security checks against AWS configurations.