Automated Vulnerability Management on AWS with Amazon Inspector
A few days ago, AWS announced a new and completely revamped version of Amazon Inspector. The previous version, now called Amazon Inspector Classic, will still be available for a while to help those still migrating to the new version. In this post, we will focus on the new version and we will dig deep into how to get it working with our vulnerable servers and container images.
I. Introduction
Whether we are aware or not, the network infrastructure, servers, and applications we have in our staging and production environments may have vulnerabilities that attackers can take advantage of. For example, let’s say that we are using a misconfigured Redis server in our staging environment and we mistakenly left the port open for anything outside of the VPC to access it. Depending on how fast this server gets compromised (minutes to hours), we may find this cache server doing something else — attacking other servers. At this point, the best assumption to make is that this server can no longer be trusted and other systems connected to it might have been compromised as well. This is something we all wish to avoid and this is one of the reasons why we should audit and ensure the overall security of our systems. One of the ways to prevent these issues from happening is to use vulnerability scanning tools which look for relevant vulnerabilities in our systems. Of course, there’s also penetration testing but that’s another story.
If we already have container images in ECR along with running EC2 instances in our AWS account, one of the more convenient ways to incorporate automated security assessments is through the use of Amazon Inspector. In addition to the other major upgrades, the new version of Amazon Inspector has replaced the periodic and manual scanning approach with continual automated scans. The cool thing here is that Amazon Inspector automatically detects the EC2 instances and container images in our account and then performs the assessment scan when a “change” is performed. Of course, all newly detected instances and container images get scanned as well upon detection. This new way of using Amazon Inspector makes things much more scalable and practical long term.
II. Detecting and Scanning Container Images for Vulnerabilities
To test Amazon Inspector’s capability to detect and automatically scan container images, we simply create a new ECR repository and push a sample vulnerable container image such as a container image that contains DVWA (D*** Vulnerable Web Application). If this is your first time hearing about DVWA, it is simply a sample application that helps security professionals learn basic penetration testing.
After a few minutes, we are able to see that there are 50 Critical issues found by Amazon Inspector. That’s probably where the web application got its name 😅
By clicking the title link, we are able to see a few more details regarding one of the reported issues.
If we scroll down a bit, we should be able to see a link that opens a reference with more information about this vulnerability.
Clicking the Vulnerability ID link, the following page should open:
Verifying if this is a false positive or not and remediating this security issue is another story 😉 . For now, let’s proceed with how Amazon Inspector is used to detect and scan EC2 instances.
III. Detecting and Scanning EC2 Instances for Vulnerabilities
To test Amazon Inspector’s capability to detect and automatically scan EC2 instances, we simply launch any instance in an existing VPC. For this example, we launched a new Cloud9 instance using the Amazon Linux 2 image. After a few minutes after instance launch, the new instance should be seen in the Account management page (and in other relevant pages as well) inside the Amazon Inspector console.
If the target instance can not be detected by Amazon Inspector (e.g., Status = “Unmanaged EC2 instance”), click “Unmanaged EC2 instance” and then click “these instructions”
This should open the Execute automation document page within Systems Manager which we will use to troubleshoot what’s wrong with the setup and configuration.
We simply input the instance ID and then click “Execute”. After a few minutes, the executed automation should give us the debugging information we need to fix the setup.
The first thing we need to ensure is that the IAM role used by the instance has the AmazonSSMManagedInstanceCore policy attached.
We do this by creating a new IAM role (or using an existing one) and attaching the AmazonSSMManagedInstanceCore policy
The VPC where the target instance resides needs to be configured with the relevant VPC endpoints as well.
Run the Systems Manager troubleshooting steps again, verify what has been fixed already, and then fix the rest of the reported configuration issues. Once everything has been configured properly, then we should see Amazon Inspector scanning the instance.
After a few minutes, we should see the reported vulnerabilities by the scan.
Following the same set of steps as with Part II where we scanned a vulnerable container image, we should see a page similar to what is shown in the image below.
Again, verifying if this is a false positive or not and remediating this security issue is another story.
As we can see, getting Amazon Inspector to work in our accounts is simple and straightforward. It might take a few minutes to set it up to get it to work with EC2 instances but this effort is easily rewarded with the continuous assessment and scan of the resources involved. If something changes in the EC2 instance, Amazon Inspector will detect things and run the additional scans automatically without us having to trigger these scans manually (similar to how it is done in Amazon Inspector Classic).
IV. Next Steps
Once you are done, feel free to turn off, terminate / delete, and disable the resources created while you are following the steps in this tutorial. This will help prevent any unexpected charges while using the different services.
There are a lot more features, capabilities, and integrations of Amazon Inspector which we will not discuss here. These include:
- Amazon EventBridge integration
- AWS Security Hub integration
- Better risk scoring system
- and more…
If you would like to learn more about this service, feel free to check this link.
V. WHAT’S NEXT?
If you are interested in machine learning and machine learning engineering, you may check the 762-page book I’ve written here: https://amzn.to/3CCMf0S. Working on the hands-on solutions in this book will make you an advanced ML practitioner using SageMaker in no time.
You should find all the other features and capabilities of SageMaker such as SageMaker Clarify, SageMaker Model Monitor, and SageMaker Debugger here as well.
If you want to take things to the next level, feel free to check my 2nd book as well: https://www.amazon.com/Machine-Learning-Engineering-AWS-Production-dp-1803247592/dp/1803247592/
This should give you the experience and confidence needed to architect custom solutions using a variety of AWS services for ML engineering requirements.
That’s it for now and until next time!
