JR Johnson Cloud, Vulnerability Management AWS, Cloud Vulnerability Scanning, Vulnerability Management

AWS Vulnerability Scanning Best Practices

We get a decent amount of questions regarding the right approach to both penetration testing in the cloud and vulnerability scanning cloud-hosted assets. While we’ve already written several posts on how to approach penetration testing for AWS, Azure, and other cloud providers, today we’ll take a step back and focus on AWS vulnerability scanning best practices. Most of the things we’re going to discuss are not specific to AWS, so they can be applied for vulnerability scanning assets with any cloud provider. But AWS tends to be the most prevalent and does have some unique aspects to consider.

When we talk about vulnerability scanning in this context, it’s helpful to clarify that our focus is on network vulnerability scanning. In general, this type of scanning is most common for organizations that already have a vulnerability management program in place that they are looking to extend to their cloud environment or those organizations that conduct vulnerability scanning for compliance purposes (e.g. PCI DSS). Your cloud assets in AWS may still be points of exposure and, as such, have to be considered along with traditional network assets.

What’s Different about AWS Vulnerability Scanning?

Before we dive into some strategies and considerations, it’s helpful to note what exactly makes cloud assets different and what type of assets we’re concerned with. With network vulnerability scanning, the focus is on infrastructure that has an IP address (either public or on an internal network segment) which the organization configures/controls. Obviously, cloud assets may still fall into this category. One key difference with AWS is that there are many services you may be utilizing that do not fall into this category, such as Lambda, managed databases (Aurora, RDS, DynamoDB), etc. So when you’re inventorying your assets that need to be scanned, you should only be including IP addresses/URLs for machines which you control the host operating system configuration. This could include EC2 instances, load balancers that resolve to EC2 instance, elastic resources (ECS/EKS), etc.

External vs. Internal Vulnerability Scanning in the Cloud

External network vulnerability scanning is performed on systems that are exposed to the Internet. This is understanding and identifying what vulnerabilities can be seen/exploited by anyone on the open Internet. Internal network vulnerability scanning is done from the perspective of an attacker already on the internal network. Your cloud environment most likely has an internal network segment just like your corporate network, and while it may be harder for an attacker to get there, there is attack surface that you should probably be considering.

Here is another key difference between vulnerability scanning for a normal network and performing this kind of testing in AWS. You’ll need a virtual machine running your vulnerability scanning software running in your cloud environment. Getting a system there is pretty easy, as many vulnerability scanning software providers have pre-built AMIs that can be spun up very quickly (like Tenable’s Nessus product line). The tricky part is getting security groups configured for this scanning instance, as you’ll want it to have full, network-level access to all ports/services on all your other hosts, even if you have restricted security groups applied for all your other hosts/segments (which you should!). Basically, your scanning host should be able to access any exposed ports/services for your other assets, but nothing should be able to reach back into the segment containing the scanner.

AWS Scanning Best Practices

While this is not going to be an exhaustive list, this should help get you started with some key points and “gotchas” to avoid when you’re starting AWS vulnerability scanning.

Be careful of assets with dynamic IP addresses (no static IP assigned). Make sure you are using URLs/static IPs where able and scan entire ranges on internal scans.
It’s really easy to add new assets in the cloud, make sure you have a process to check your asset inventory or verify that you’re hitting everything when you scan.
In general, it is a good idea to start with external network vulnerability scanning, as this is going to be your area of highest impact for a successful exploit/compromise. Then expand your scanning activities to include the internal interfaces of resources, too.
Use scanning results to patch and update configurations based on vulnerabilities you discover, but also use the results to tighten Security Groups if you can.
To help augment network scanning, consider using something like AWS Config to help identify architectural/configuration-related vulnerabilities with the services you are using. This service is pretty cool because it will suggest best practice configurations and then notify you of any changes to your configurations via an SNS topic.

These are a few recommendations to help get you started with cloud-based assets. Make sure you also check out our blog on vulnerability management best practices to get some more general recommendations for your program in general. As always, please reach out to us if you’d like to schedule some time to talk through your vulnerability scanning program or get help setting something up for the first time.