Deep Dive into Amazon Inspector

What is Amazon Inspector?

Amazon Inspector is a vulnerability management service that automatically discovers workloads and continually scans them for software vulnerabilities and unintended network exposure. Amazon Inspector discovers and scans Amazon EC2 instances, container images in Amazon ECR, and Lambda functions. Some of its keys features are:

Centrally manage multiple Amazon Inspector accounts
Assess vulnerabilities accurately with the Amazon Inspector Risk score
Identify high-impact findings with the Amazon Inspector dashboard
Manage your findings using customizable views
Monitor and process findings with other services and systems

[Source]

Getting Started

If you are new to Inspector and have not used the service before AWS provides a 15 days free trial for you to utilize the service free of cost.

To activate Inspector, go to the service Amazon Inspector from your AWS Console and click on Get Started to activate your free trial.

If you want to create a Delegated Administrator for your organization to centrally manage Inspector across all accounts you can provide the respective Account ID, in our scenario we will activate this for an individual account. Click on Activate Inspector. Once the service is activated AWS will create a service role with the necessary permission to scan our resources in the backend.

Inspector Dashboard

Once the service is activated, it will take some time to populate the resources and scan them against the vulnerability database, once done the findings will be populated on the dashboard.

Key Elements in the dashboard:

The Environment Coverage section helps us understand the overall percentage of compute resources (EC2 Instances, ECR Images, Lambda Functions) that is being monitored by Inspector.
The Critical Findings lists the critical vulnerabilities for each Compute resource. We will be later drilling down into the Findings and shall see them in more details.
Findings with exploit available and fix available is one the most important section if not the most important one, as you can see there are 5 vulnerabilities for which public exploit is available, and should be mitigated on an immediate basis.

Inspector Findings

In the left pane, we have an option called Findings that will display all the vulnerabilities detected by Inspector and has also been grouped based on the type of vulnerability, instance, container image, container repository and Lambda Functions.

There are a total of 4 Finding Status:

Active: The findings which are still active and has not been mitigated will be shown when this option is selected.
Suppressed: All the suppressed findings will be listed here. We will later see how to create a suppression rule.
Closed: The findings that have been mitigated will be shown upon selecting this option.
Show all: Will display all the findings irrespective of their individual status.

We can also set filter criterias based on common fields such as Account ID, Severity, Inspector Score or resource specific filters such as the Image Tag in ECR.

Below is an example where I have filtered the findings with the Image Tag as latest and Public Exploit available as yes.

Now we will explore a finding in detail, for that you can select a particular finding which will open a parallel window with all the necessary details about that finding.

Comprehensive Breakdown of a Finding

Findings Overview: This includes Severity of the vulnerability, If an exploit is available for the vulnerability, If a fix is available or not, etc.
Affected Packages: This helps to locate the package by stating it's file path, the package manager, fixed version of the package etc.
Remediation: If a fix is available for the vulnerability, necessary remediation steps would be provided here.
Related Vulnerabilities: If the current package relates to other CVE's those would be listed here.
Resource Affected: This includes the details of the AWS Resource such as the Repository Name, Image Tags in case of an ECR Image Finding and likewise for other resources.
Tags: Resource Tags

Vulnerability Score

CVSS Score:
CVSS stands for Common Vulnerability Scoring System, this score is obtained from the vendor such as RHEL, Debian, etc. In cases where this score is not provided, Amazon Inspector fetches the score from NVD (National Vulnerability Database) and calculates the score using the CVSS calculator.
Inspector Score:
Amazon Inspector scores each finding after correlating the base score from CVSS and the information collected after scanning the compute environment such as network reachability and exploitable data.

There can be scenarios, where the Inspector Score is less than the CVSS Score, for instance If the vulnerability is exploitable over the network but Amazon Inspector determines that the vulnerable instance is not exposed to the Internet.

Metrics that are used to determine the score are as follows:

Attack Vector: Context by which the vulnerability can be exploited.
Attack Complexity: Difficulty involved in exploiting this vulnerability. Ranges from Low to High.
Privilege Required: Level of privilege required to exploit this vulnerability.
User Interaction: If exploiting this vulnerability requires a human user other than the attacker.
Scope: Unchanged here means the affected resource and the impacted resource are the same. Changed means this vulnerability can be used to impact other resources.
Confidentiality: Impact to Data Confidentiality. Ranges from Low to High.
Integrity: Impact to Data Integrity. Ranges from Low to High.
Availability: Impact to Data Availability. Ranges from Low to High.

[Source]

Suppression Rules

We can suppress or hide findings by creating a rule that operates on the basis of a filter. It can be something that we want to address later such as vulnerabilities with medium and low severity. A Suppression rule in this scenario will help us hide all the vulnerabilities with medium and low severity from the Inspector Findings Dashboard and going forward Inspector will no longer report vulnerabilities of these severities. This however does not mean that the vulnerabilities are marked as closed by Inspector, which will only be done after mitigation by the user. The suppressed vulnerabilities can be once again viewed on the dashboard by disabling the suppression rule.

Creating a Suppression Rule

On the Findings Tab, click on Create Suppression Rule.
Next you enter the suppression rule name, description and the filter on which Inspector would suppress the findings.
Click on Save.

Once the rule is in place the Medium and Low vulnerabilities will not be displayed in the Active Findings section and can be viewed only in the Suppressed Findings section.

SBOM - Configuring and Exporting

A software bill of materials (SBOM) is a nested inventory of all the open-source and third-party software components in your codebase. Amazon Inspector provides SBOMs for individual resources in your environment.

Amazon Inspector supports two major SBOM Formats

CycloneDX 1.4
SPDX 2.3.

While exporting an SBOM we can use filters to create subsets of resources, the following filters are available: AccountID, EC2 instance tag, Function name, Image tag, Lambda function tag, Resource type, Resource ID, Repository name.

To export an SBOM we need to have a few things in place, like:

A private S3 Bucket with a bucket policy that allows Amazon Inspector to upload objects to.
A KMS key that can be used by Amazon Inspector to encrypt the reports.

You can get the S3 Bucket Policy, KMS Key Policy and more details about exporting SBOM here: Amazon Inspector Docs

[Source]

Configuring EventBridge Rule to notify of Critical Findings

We will set up automatic alerts using Amazon SNS (Simple Notification Service) by creating a topic and a subscription with Email as the endpoint.

Go to Amazon SNS Service.
Go to Topics on the left pane and click on create Topic.
Select Type as Standard, Name your Topic, leaving the rest as default create the topic.
Select your Topic, click on Create Subscription, choose your protocol (for this demo we will be going ahead with Email), provide your mail address.
Confirm the subscription in the mail that you will receive from AWS on the mentioned mail id.

Next, we will create an Amazon Eventbridge rule to detect and trigger an alert on the critical findings of Inspector.

Go to Amazon EventBridge.
Click on Rules in the left pane and Create Rule next.
Provide a name to your rule and a description, then select the Rule Type as Rule with an Event Pattern and click next.
In the Creation Method, select Custom pattern (JSON Editor)
Enter the below snippet and click on next.

Choose Amazon SNS as the target and select the topic you created.
Add optional tags if needed and choose next.
Review and click on create rule.

On the next critical finding by Inspector, I received an email alert of the same to my mail id.

Integrating Inspector Scans into Jenkins CI/CD Pipeline

You can achieve the same in two ways.

First one is using a plugin, currently supported CI/CD tools for the same are Jenkins, TeamCity, GitHub Actions.
Second way is to setup a custom integration with your CI/CD solution.

You can check out the Inspector CI/CD Official Documentation for more details on both the methods.

Although a plugin was available for Jenkins, I chose to use the latter method and created a Jenkinsfile that would generate a SBOM and then call the Inspector Scan API to generate a vulnerability report from that SBOM, then I added a threshold limit on the critical vulnerabilities which if breached would fail the job.
You can check out the same, Inspector-Jenkins-Custom-Integration-Jenkinsfile.

Conclusion

Amazon Inspector will help you discover zero day vulnerabilities for your compute workloads and being compliant with the popular cybersecurity frameworks. It facilitates a shift left security approach and prioritizes patch remediation. Furthermore the integration with your CI/CD pipeline and Eventbridge, would allow you to detect vulnerabilities early in the development cycle and respond to it on an immediate basis.

Site Terms, Privacy, and more.

Deep Dive into Amazon Inspector

Comments