This is part one of a two part series on Amazon Inspector. This article goes over some of the features of Amazon Inspector and covers some of the pros and cons of the service. The second article within this series is a quick start on implementing Amazon Inspector in automated AMI pipelines. 

Introduction to Amazon Inspector

Creating Amazon Machine Images (AMIs) in a pipeline can be a useful way to accelerate the application development process. AMIs are useful because they launch identical systems for applications to run on. Incorporating systems hardening into the AMI creation pipeline pulls security controls into the early stages of the development lifecycle. Systems hardening is an important aspect of DevSecOps because it can help minimize the vulnerabilities an application could be susceptible to. Most people know the importance of hardening, but more often than not, it’s an afterthought. After the AMI is hardened, it should be scanned for security vulnerabilities to verify what components of the system have actually been secured.  Setting up automated security scanning on newly created AMI will benefit in the long run.

Amazon Inspector is a service that can run automated security scanning on EC2 instances. Amazon Inspector offers different rules packages for assessments. Rules packages are based on best practices and updated frequently. At the time of this blog post, Inspector does not support custom rules packages. Inspector rules packages evaluate and report on the configuration of the EC2 instance. They can also check for known vulnerable software versions installed on the instance. Inspector can run against instances in production or development environments. The results of the scan can help develop a patching/configuration strategy for existing instances or the next iteration of AMIs.

Quickstart Setup

Inspector is not supported in every region yet, so be sure to run your instances in a supported region. At the time of writing, Amazon Inspector does not support on premise scanning. Other scanning tools can scan virtual machines in data centers and the cloud. The Amazon Inspector agent needs to be installed on an EC2 instance that’s running a supported Linux or Windows OS before being able to run scans against the instance.

Inspector is only supported for select OSs for the Common Vulnerability and Exposures, CIS Benchmarks, Security Best Practices rules packages. There is also a Network Reachability rules package that can run as an agentless assessment. The predefined list of rules packages is nice for newcomers of security scanning. Enterprises may find the rules are more limited than what they desire. The use of custom rule sets is a common feature in some of the competing security scanning tools.

The price of using these assessment templates with Inspector starts at thirty cents per run for the first 250 assessments run. The price per assessment decreases as the bulk number of assessment runs increases. The benefits of using Inspector over a scanning tool that requires a yearly license include the following:

• Paying for scans based on actual usage
• No up front cost for licensing fee. Pay for usage of the tool only.

Interpreting Scan Results

There are five sections in an Inspector scan report:

1. Executive Summary
2. What is tested
3. Findings Summary
4. Findings Details
5. Passed Rules

Executive Summary

• Displays start time of assessment run
• Shows the name of the assessment template used for the scan
• Shows the EC2 instance tags that defined the resource group
• Total finding count
• Table displaying finding count for each rule package and severity level

What is tested

This section of the report lists rules packages, the instance count, and instance ID’s scanned during the assessment run.

Findings Summary

The findings summary of the report list the findings for each rules package.

Findings Details

The finding details section shows descriptions of all the findings and recommended remedies.

Passed Rules

The passed rules section of the report lists all the passed rules. It also includes a description of each rule from the assessment run.

Addressing Scan Results

The scan results within this article are scans from an Amazon Inspector quickstart showcases in our article Implementing Amazon Inspector in Automated AMI Pipelines.

The default configuration of this quickstart builds the AMI out of a Packer script that does not address any of the findings found in the report. A second Packer script is included in the repository named `hardened_ami.json` that includes some lockdowns in the image creation process. This Packer script can be used instead of the `ami.json` script by replacing the parameter value `PackerFile` in the `aws-inspector-pipeline.yaml` file. Upon making this change, launch the pipeline and inspect the findings results. The findings count should be lower than the scan results of AMIs created with the other Packer script.

Here’s the snippet of the Packer script hardened_ami.json that addresses some of the findings:

Executive summary of new scan against “hardened” image.

Next Steps

If you’ve enjoyed learning about Amazon Inspector in this post and want to get some experience using the service, take a look at our article Implementing Amazon Inspector in Automated AMI Pipelines.

Featured image by Josh Appel on Unsplash

Stelligent Amazon Pollycast