Amazon Inspector suppression rules best practices for AWS Organizations

Vulnerability management is a vital part of network, application, and infrastructure security, and its goal is to protect an organization from inadvertent access and exposure of sensitive data and infrastructure. As part of vulnerability management, organizations typically perform a risk assessment to determine which vulnerabilities pose the greatest risk, evaluate their impact on business goals and overall strategy, and assess the relevant regulatory requirements.

In this post, we explain how to use mechanisms to appropriately prioritize vulnerabilities across your accounts in AWS Organizations. We discuss how to apply tags to resources so that you can use risk-based prioritization of Amazon Inspector findings in your environment, and we talk about some best practices for using suppression rules to suppress less-critical findings in Amazon Inspector, at scale. We also emphasize practices to create a culture of continuous vulnerability management.

Vulnerability management with Amazon Inspector

Amazon Inspector is a vulnerability management service that continuously scans your Amazon Web Services (AWS) workloads for software vulnerabilities and unintended network exposure. Amazon Inspector automatically discovers and scans running Amazon Elastic Compute Cloud (Amazon EC2) instances, container images in Amazon Elastic Container Registry (Amazon ECR), and AWS Lambda functions.

Amazon Inspector creates a finding when it discovers a software vulnerability or an unintended network exposure. A finding describes the vulnerability, identifies the affected resource, rates the severity of the vulnerability, and provides remediation guidance. You can create suppression rules in Amazon Inspector to suppress findings that are less critical, so that you can focus on higher-priority findings.

Best practices for vulnerability management in AWS Organizations

We recommend that you use the best practices discussed in this section to ease the task of resolving thousands of vulnerability findings in your organization in AWS Organizations.

Best practice #1: Set up a delegated admin

You can use Amazon Inspector to manage vulnerability scanning for multiple AWS accounts in an organization. To do this, the AWS Organizations management account needs to designate an account as the delegated administrator account for Amazon Inspector. The delegated administrator account has centralized control over the Amazon Inspector deployment, which allows for more efficient and effective management of security monitoring tasks across the multiple accounts within AWS Organizations. These tasks include activating or deactivating scans for member accounts, aggregating findings by AWS Region, viewing aggregated finding data from the entire organization, and creating and managing suppression rules.

Amazon Inspector is a regional service, meaning you must designate a delegated administrator, add member accounts, and activate scan types in each AWS Region you want to use Amazon Inspector in. When you’re setting up your delegated administrator account, be aware of the following factors:

• Delegated admins can create and manage Center for Internet Security (CIS) scan configurations for the accounts in the organization, except for any scan configurations that are created by member accounts.
• In a multi-account setup, only delegated admins are able to set up scan mode configuration for the complete organization.
• You can use Amazon Inspector to perform on-demand and targeted assessments against OS-level CIS configuration benchmarks for Amazon EC2 instances across your organization.

Best practice #2: Manage findings at scale with suppression rules

There can be thousands of specific common vulnerabilities and exposures (CVEs) or Amazon Resource Names (ARNs) in the findings across your accounts, and therefore managing these findings at scale with proper suppression rules will lead you towards achieving successful vulnerability management.

A suppression rule is a set of criteria consisting of a filter attribute paired with a value, which is used to filter findings by automatically archiving new findings that match the specified criteria. You can create suppression rules to exclude vulnerabilities you don’t intend to act on, so that you can prioritize your most important findings. Suppression rules don’t impact the finding itself and don’t prevent Amazon Inspector from generating a finding. Suppression rules are only used to filter your list of findings and make it easier for you to navigate and prioritize them.

Some helpful filters that you can use in suppression rules are Resource tag, Resource type, Severity, Vulnerability ID, and Amazon Inspector score. For example, you can categorize the findings based on severity levels (Critical, High, Medium, Low, Informational, and Untriaged). To learn more about how Amazon Inspector determines a severity rating for each finding, see Understanding severity levels for your Amazon Inspector findings.

You can navigate through the findings in Amazon Inspector based on different categories such as vulnerability, account, or instance. On the All findings page in Amazon Inspector, if you select a CVE ID, you can view details for the affected resources and the individual AWS account IDs, as shown in Figure 1. This can help you choose filter criteria to use in suppression rules.

Figure 1: Amazon Inspector findings and severity levels

You manage suppression rules at the organization level, and the rules apply to all the member accounts. If Amazon Inspector generates a new finding that matches a suppression rule, the service automatically sets the status of the finding to Suppressed. The findings that match suppression rule criteria don’t appear in the findings list, by default. Therefore, the suppressed findings don’t impact your service quotas. Member accounts inherit the suppression rules from the delegated administrator. The delegated administrator account is limited to 500 rules (per Region), and this is a hard limit.

Keep in mind that member accounts in an organization cannot create or manage suppression rules. Only standalone accounts and Amazon Inspector delegated administrators can create and manage suppression rules. So, if there is a member account within an organization that needs independent management of its own suppression rules, then the account owner needs to activate Amazon Inspector separately in their account.

Best practice #3: Suppress findings based on Amazon Inspector score

Because your time is limited and the volume of security vulnerability findings can be large, especially in bigger organizations, you need to be able to quickly identify and respond to the vulnerabilities that pose the greatest risk to your organization.

One quick approach to suppressing findings is to use the Amazon Inspector score. Amazon Inspector examines the security metrics that compose the National Vulnerability Database (NVD) Common Vulnerability Scoring System (CVSS) base score for a vulnerability, adjusts them according to your compute environment, and then produces a numerical score from 1 to 10 that reflects the vulnerability’s severity.

The NVD/CVSS score is a composition of security metrics, such as threat complexity, exploit code maturity, and privileges required, but it is not a measure of risk.

Be cautious not to over-suppress your findings. Over-suppressing findings can inadvertently expose applications and systems to unmitigated security risks. It’s important to maintain a careful, measured approach when applying suppression rules. Maintaining visibility into the true risk profile for each finding is essential for proactive, comprehensive vulnerability management.

Best practice #4: Use tags to enable risk-based prioritization

For a scalable vulnerability management solution, it’s important to have a strategy for tagging resources appropriately across your accounts.

To prioritize vulnerabilities, first you need to understand and assess each resource’s risk level so that you can tag it properly. Proper tagging enables you to use risk-based prioritization. This means that when you evaluate findings, you look at factors such as the risk level of the resource, the severity of the vulnerability, and the impact of the vulnerability on your organization’s environment so that you can focus on the critical vulnerabilities first. This seems like an obvious recommendation, but its importance cannot be overstated. In the cloud, you have to understand and protect everything you build. Asset mapping must include relationship mapping to understand the implications and risk paths of potential security events.

The priority for remediating cloud resource issues depends on the level of exposure of the resource. Resources in public subnets should generally be prioritized over those in private subnets. Resources running in production environments should be prioritized over those in development and test environments.

The prioritization also depends on factors like firewall rules, AWS Identity and Access Management (IAM) policies, service control policies, and security groups. Resources with more open internet access through various ports and protocols have increased scope for issues like denial of service (DoS), distributed denial of service (DDoS), spoofing, malware, and ransomware, compared to resources with tight access restrictions.

Best practice #5: Base suppression rules on proper resource tags

In complex multi-account environments, it can be challenging to centrally manage suppression rules by using resource IDs, subnet IDs, or VPC IDs, because these values are specific to individual accounts and change over time with new deployments or modifications. This makes it difficult to keep the suppression rules up to date. Here, we review how you can take advantage of risk-based prioritization based on tags (best practice #4) along with the Amazon Inspector score to effectively manage, prioritize, and track your findings.

The following example provides a suggested tagging strategy that you can use across your AWS Cloud resources in your organization for the purpose of vulnerability management:

EnvironmentName, RiskExposureScore

With this tagging strategy, you create prioritization through the suppression of rules across the environment and dismiss the findings that you need to postpone or ignore so that you can focus on the high-value findings. You can also create different rules for different environments with different risk factors. For example, you might want to suppress findings for resources that have low risk exposure levels, are in your non-production environment, and are within these severity levels: Informational, Untriaged, Low, or Medium. You can also take advantage of the Resource Tag field when you create or export a report, to filter out the expected findings.

In the following table, we provide an example for an AWS Cloud environment that has three main divisions of accounts: Prod, Dev, and Sandbox. We’ve suppressed rules for different severity levels based on the possible risks, exposure level, and how critical the workloads are. In our example, we used a RiskExposureScore of 1, 2, and 3 to be equivalent to low, medium, and high. In other words, RiskExposureScore 1 is for the workloads that are less sensitive or have little to no internet exposure, while RiskExposureScore 3 is for sensitive or critical workload that have internet exposure, are less protected, or have higher possible security risks due to their configuration or poor cyber hygiene.

For this specific example, we would like to keep the vulnerability findings that have a severity of High or Critical for the resources in the Prod and Dev accounts, but define different suppression rules across other resources depending on their risk exposure level. We would also like to suppress the majority of the vulnerability findings in the Sandbox accounts, because we don’t have any critical workloads on those accounts. You can use this example as a model for configuring the suppression rules across your environment to prioritize vulnerability findings according to your needs. Also note that you can change, modify, or re-evaluate your suppression rules as you work on remediation, and it’s a best practice to do so as a continuous process.

Best practice #6: Integrate Amazon Inspector with AWS Security Hub

You can integrate Amazon Inspector with AWS Security Hub to send findings from Amazon Inspector to Security Hub, and Security Hub can include these findings in its analysis of your security posture. Amazon Inspector findings that match suppression rules are automatically suppressed and won’t appear in the Security Hub console.

Best practice #7: Re-evaluate your suppression rules on a regular basis

The key to an up-to-date security posture and healthy cloud environment is maintaining and adapting your vulnerability management approach as the threat landscape evolves. Here, we’ve highlighted some practices to focus on:

• Regularly revisit and re-evaluate your suppressed vulnerability detection rules. Vulnerabilities and threats are constantly evolving, so what you suppressed previously might need to be re-enabled.
• View vulnerability management as a continuous, iterative process, not a static procedure. Regularly assess, update, and adapt security controls to address emerging risks in real time.
• Emphasize the importance of continuous monitoring and response, not just initial remediation. Vulnerabilities need to be addressed holistically through the entire lifecycle.
• Foster a culture of security awareness and responsiveness throughout your organization. Everyone should be engaged in identifying and mitigating vulnerabilities on an ongoing basis.
• Make sure that your vulnerability management program aligns with relevant compliance or regulatory requirements (for example, PCI-DSS, HIPAA, or NIST CSF).

Conclusion

In this post, we covered how you can effectively prioritize Amazon Inspector findings at scale across your organization’s AWS infrastructure by using suppression rules and applying risk-based prioritization. We also discussed how to use resource tagging as an effective strategy for prioritizing the remediation of Amazon Inspector findings. For additional blog posts related to Amazon Inspector, see the AWS Security Blog.

If you have feedback about this post, submit comments in the Comments section below.