Making AWS Security Simple, Part 4: Perimeter Assessment

Saving time and allowing security teams to both be more efficient and better educated is vital to success in the cloud. Network security is challenging in cloud environments because the architectures are dynamic, which makes fixed security measures cumbersome and expensive. At the same time, hackers are more sophisticated and increasingly engaged in persistent attacks to compromise the network and cloud that can extend over the course of many months. Despite these concerns, however, security and compliance can be strengthened in cloud deployments.
The purpose of this series is to show how to take simple steps toward saving your security team time and headaches. Check out Part 1, Part 2 and Part 3 of the series to see more basic steps you can take covering gap assessment, best practice checks, and CloudTrail. This fourth post of the series will dig deeper into perimeter assessments and auditing security groups. If you haven’t done it before it can be tough to figure out where to begin.
 

Reviewing the Perimeter of your AWS Environment

Moving from a data center to the public cloud requires rethinking how you do assessments of your perimeter security. For this reason CloudCheckr provides the Perimeter Assessment Report. This report will give you information on any publicly accessible resource in each of the available AWS regions. You can find this report under Security/Perimeter Assessment.
Within this report, a + symbol next to a region indicates that there are publicly accessible resources within that region. If you expand a region, it will show you which AWS services have publicly accessible resources and, if you expand the service, it will give you the specific resource and details on the controls around the service and resources.
Resources may be intentionally public. For instance, a web server may well require open access to the Internet. This report helps you to gather the complete list to review and ensure ONLY what is meant to be exposed is. We suggest you review this report and validate any publicly accessible resources are meant to be exposed as such.
Within each region, you will see the list of publicly accessible resources not within a VPC. Verify each and the security groups associated with them to make sure they are appropriately restricted. Ideally you would move resources that can be run from within a VPC into a VPC. These resources types include EC2, RDS, Redshift, Elastic IPs, and ElastiCache. Some resources, such as S3 and DynamoDB, can’t be moved into a VPC.
You will also see the VPCs that are publicly accessible. Underneath the VPC you can review the NACL to see which rules are allowing public access on which ports. One level down, CloudCheckr lists the Subnets within each VPC, and the public resources within each subnet. Additionally, CloudCheckr will show the list of security group rules associated with the instances. This is a lot of information, but it gives you a way to pull all the various controls (VPCs, Security groups, public IP addresses) into a single place to understand if and how access to a resource is restricted (or not).
As we stated earlier, before an application goes into production, you should review the security configuration, starting with Security Best Practice checks. You should also review the privileges and access controls of all the components of the resources. The perimeter assessment report is a good way to start. Get an inventory of the resources from the application team, including the S3 buckets, list of databases, VPCs being used, EC2 instances, auto scaling groups, etc. From this list you use the Perimeter Assessment report to ensure these resources are not publicly accessible unless they are meant to be.
For instance, let’s show an example of an application inventory that includes two S3 buckets, one SQS Queue, one RDS database, and five EC2 instances within a VPC. Start by determining the appropriate access of these resources. For instance, one of the S3 buckets might be marketing materials meant to be publicly available to potential customers. The other bucket contains backups of database files. One of the EC2 instances is a webserver and should be available to potential customers over https on port 443.
Open the Perimeter Assessment, expand the region the S3 buckets are within, and verify that only the one S3 bucket shows up under “Publicly Accessible S3 Buckets”. Verify that the SQS Queue does not show up under “Publicly Accessible SQS Queues”. Next expand the VPC and ensure the RDS database does not show up under “RDS DB instances with a public IP”. Check that only the webserver shows up under “EC2 instances with a public IP” and that the security groups of the instance are limited to port 443.
 

Exporting Publicly Accessible Resources

This report has three output formats to pull the results out of CloudCheckr.

• Export – this format gives you a complete export of all the details in the report.
• Export by Region – this format provides a single line for each region with all the publicly accessible resource within a column in each row.
• Export by Resource – this format list each resource, the resource type, region, and VPC. This format gives you a list of each publicly accessible resource.

You can use these various reports to detect publicly accessible resources. For instance, you may need a complete list of publicly accessible resources to feed into your vulnerability assessment tools to run scans against. In this case, you can click “Export by Resource” to get a complete list of the public resources to feed into your vulnerability assessment tools.
 

Using the API to find Publicly Accessible Resources

You can also use the CloudCheckr API to extract the details from the Perimeter Assessment report. You can see a complete description of how to use the API to extract details from the support site.
Also refer to the sample scripts that you can use to leverage CloudCheckr’s inventory to pull out a list of publicly accessible resources you can then integrate into your vulnerability assessment tools.
 

Auditing Security Groups

Security groups are one of the primary methods used for securing traffic to an EC2 instance, RDS database, Redshift cluster, or ElastiCache cluster. EC2-VPC Security groups can be used to secure any of these resources if they sit in a VPC. If any of these resources are outside of a VPC, you must use security groups that are specific to the resource type. For instance, for RDS you would have to use DB Security Groups.
The two main network security controls in AWS are Security Groups and Network ACLs.
Security groups: Assigned directly to an instance or resource. Rules are stateful, meaning traffic returned from a valid request is allowed irrelevant of the security rules.
Network ACLs: Assigned to an entire subnet in a VPC. Rules are stateless, meaning rules must be defined for return traffic as well.
CloudCheckr provides capabilities to search Security Groups to find ones that are wide open or overly-permissive. An organization may have hundreds of AWS accounts with hundreds of Security Groups. The security team should be reviewing these Security Groups to make sure they are appropriately configured.
The security department can start by reviewing best practice checks. Setup a Multi-Account View to include all AWS accounts, and allow time for the Multi-Account View to collect all results across the accounts. We recommend looking across your entire organization for any issues with the best practice checks below:

• EC2-VPC Security Groups Inbound Rules Set To All IPs And All Ports
• EC2-Classic Security Groups Inbound Rules Allowing Traffic from All IPs and All Ports
• DB Security Groups Inbound Rules Set To Allow Traffic From Any IP Address
• Redshift Security Groups Inbound Rules Allowing Traffic From Any IP Address

These checks are finding Security Groups that have no limitations on access at all.  A no limitations setting is rarely appropriate. It’s highly recommended that you prohibit this as a corporate policy and then monitor for someone inadvertently configuring a group with it. Chances are that many of your AWS accounts will have many of these by default.
The results of these best practice checks look like this:
Group: StandaloneSG | ID: sg-4c82c17f | Port Range: 80,443,0-ALL,8-ALL|
Instances using this security group: 2 | Region: US West (Oregon)
The results contain the number of instances using this Security Group so you can prioritize which ones to track down and shutdown first. Many security groups may be overly-permissive, but might not be assigned to any resources. It is recommended you remove these, but you might prioritize these below fixing security groups that are wide-open and have resources assigned to them. As well, for each result you will see “X Ignore Item”. If you deem that it is appropriate for a specific security group to be wide open, you can choose to ignore this result. You can always resume monitoring the specific security group later if needed by selecting the “Show Ignore” checkbox above.
 

Searching for Specific Security Group Issues

You can also perform ad hoc searches of Security Groups from CloudCheckr. For instance, you should audit your security groups to verify public access to common database ports are shutdown. You can do this within the report Security/Security Groups/Common Searches. Option 2 is labeled “Find Security Groups that allow database access from all IP Addresses”. Click “Search” and you will have a list of Security Groups that match the search filter.
You should also review open access from the Internet to port 22. Within the report Security/Security Groups/Common Searches select Option 3 “Find Security Groups that allow SSH access from all IP Addresses”. The complete list of Security Groups that allow incoming traffic over port 22 from ANY IP address will be generated.

Wrapping up your perimeter and security groups

Knowing what to look for and how to investigate efficiently takes a lot of experience.  Using CloudCheckr to provide automated checks and alerts you will save time and avoid the human error aspect of constant manual checks. Our next post is the last of this series covering Network ACLs.
As always, if you want to try out the features we’ve talked about and experience this all first-hand, get started now. See how much time and effort we can save you. Don’t believe us, ask our customers!