All posts by Mojgan Toth

Amazon Inspector suppression rules best practices for AWS Organizations

Post Syndicated from Mojgan Toth original https://aws.amazon.com/blogs/security/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

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.

EnvironmentName RiskExposureScore Severity Suppressed
Prod 1 Medium, Low, Informational, Untriaged Yes
Prod 2 Low, Informational, Untriaged Yes
Prod 3 Informational, Untriaged Yes
Dev 1,2 Medium, Low, Informational, Untriaged Yes
Dev 3 Low, Informational, Untriaged Yes
Sandbox 1,2 Critical, High, Medium, Low, Informational, Untriaged Yes
Sandbox 3 High, Medium, Low, Informational, Untriaged Yes

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.

Mojgan Toth

Mojgan Toth

Mojgan is a Senior Technical Account Manager at AWS. She proactively helps public sector customers with strategic technical guidance, solutions, and AWS Cloud best practices. She loves putting together solutions around the Well-Architected Framework. Outside of work, she loves cooking, painting, and spending time with her family, especially her three little boys. They love outdoor activities such as bike rides and hikes.

Simplify management of Network Firewall rule groups with VPC managed prefix lists

Post Syndicated from Mojgan Toth original https://aws.amazon.com/blogs/security/simplify-management-of-network-firewall-rule-groups-with-vpc-managed-prefix-lists/

In this blog post, we will show you how to use managed prefix lists to simplify management of your AWS Network Firewall rules and policies across your Amazon Virtual Private Cloud (Amazon VPC) in the same AWS Region.

AWS Network Firewall is a stateful, managed, network firewall and intrusion detection and prevention service for your Amazon VPC. With Network Firewall, you can filter inbound and outbound traffic to or from internet gateways; AWS Direct Connect gateways; AWS PrivateLink, AWS Site-to-Site VPN, and AWS Client VPN gateways; NAT gateways; and even between other attached VPCs and subnets.

You can use Network Firewall to help prevent your VPC from accessing unauthorized domains, to block IP addresses, and to perform deep packet inspection or protocol filtering. However, it can be time consuming to update your firewall’s rule groups to add, remove, or modify the list of IP addresses across multiple Network Firewall instances that can be deployed in distributed, centralized, or combined deployment models.

With prefix lists, you can group one or more CIDR blocks into a single object. Therefore, you can group IP addresses that you frequently use in a prefix list, and reference this list in Network Firewall rule groups. With this approach, you don’t need to update individual firewall rules when scaling the network to add new IP addresses, and the Network Firewall rule groups that reference the prefix list are automatically updated.

In this post, we will show you how to build an example configuration in your test environment that uses customer-managed prefix lists in a Network Firewall rule group.

Note: This configuration will incur costs as described at AWS Network Firewall pricing.

Prerequisites

For this walkthrough, make sure that you have the following prerequisites in place:

Solution overview

In this post, we will show you how to create a simple architecture in a VPC to create three different VPC prefix lists for private and public subnets and provide protection by restricting traffic flow to the firewall subnet. Then you will create a stateful Network Firewall rule group to include IP set references that are mapped to VPC prefix lists. Figure 1 illustrates the architecture of a protected VPC.

Figure 1: Simple architecture of a protected VPC

Figure 1: Simple architecture of a protected VPC

In this example, the following three subnets are in the protected VPC:

  1. Firewall subnet: 10.1.0.0/28
    This subnet is dedicated for use by Network Firewall. The Network Firewall endpoint is deployed into a dedicated subnet of the VPC.
  2. Public subnet (protected subnet): 10.1.2.0/28
    The resources are designed to be internet-facing, so this subnet needs to communicate with the internet gateway. The NAT gateway and load balancer are also hosted on this subnet.
  3. Private subnet (protected workload subnet): 10.1.3.0/28
    This is the subnet where you host your private workload that doesn’t accept incoming traffic from the internet (in our example, this is the webservers). The private workload can send requests to the internet through the NAT gateway.

Deploy the CloudFormation template

The following AWS CloudFormation template deploys a network firewall and related resources in a distributed architecture across two Availability Zones. In production, AWS recommends that you use multiple Availability Zones to help ensure high availability and improve fault tolerance. To simplify the instructions, we will focus on a single Availability Zone for this blog post.

To deploy the CloudFormation template

  • Choose the following Launch Stack button.

    Launch Stack

    Launch the CloudFormation template in the Region of your choice. Make sure that the Region that you choose supports Network Firewall. Select the Availability Zone or Zones to be used for this deployment, and leave the rest of the options as default.

Create the VPC prefix lists

In this section, we will show you how to define your requirements and implement them within Network Firewall to only enable Secure Shell (SSH) traffic from a trusted IP range (an authorized public subnet on the protected VPC) to the private subnet. We will also show you how to block Internet Control Message Protocol (ICMP) traffic from another IP range (with CIDR 10.0.1.0/24).

You will create the following VPC prefix lists:

  • Public-ip-list — includes the protected subnet: 10.1.2.0/28
  • Private-deny-list — includes a CIDR block from the other VPC: 10.0.1.0/24
  • Private-allow-list — includes the protected workload subnet: 10.1.3.0/28

To create the VPC prefix lists

  1. Open the Amazon VPC console and choose Managed prefix lists.
  2. Choose Create prefix list, and then do the following, as shown in Figure 2:
    • For Prefix list name, enter a name for the prefix list. In our example, the name is Public-ip-list.
    • For Max entries, enter the maximum number of entries for the prefix list. In our example, this number is 10.
    • For Address family, select the prefix list that supports IPv4 entries.

      Note: Network Firewall currently supports only references to IPv4 prefix lists.

    • For Prefix list entries, choose Add new entry, and then enter the CIDR block and a description for the entry. In our example, the CIDR block is 10.1.2.0/28.
    • Choose Create prefix list.
      Figure 2: Example of managed prefix lists

      Figure 2: Example of managed prefix lists

  3. Repeat the preceding steps for the two remaining prefix lists: Private-deny-list and Private-allow-list.

When you’ve finished creating the prefix lists, you can view them under Managed prefix lists, as shown in Figure 3.

Figure 3: Example of VPC prefix lists

Figure 3: Example of VPC prefix lists

Create a Network Firewall rule group

The next step is to create a Network Firewall rule group. A Network Firewall rule group is a reusable set of criteria for inspecting and handling network traffic. As part of this configuration, we will take advantage of customer-managed VPC prefix lists as a variable to simplify the management of the rules.

To create a Network Firewall rule group

  1. In the Amazon VPC console, in the left navigation pane, choose Network Firewall rule groups.
  2. From the Rule groups tab, select Create Network Firewall rule group, and then do the following, as shown in Figure 4:
    • For Rule group type, select Stateful rule group.
    • For Name, enter your network firewall rule group.
    • For Capacity, enter 25 or another appropriate value.
    • For Stateful rule group options, select 5-tuple.
    • Under Stateful rule order, select Default.
    Figure 4: Network Firewall rule group

    Figure 4: Network Firewall rule group

  3. In the IP set references section, do the following, as shown in Figure 5:
    1. For IP set preference variable name, enter new variable names for each of your VPC prefix lists.
    2. From the IP set resource ID dropdown, select an IP set.

    In this example, you are creating three IP set references that are mapped to the VPC prefix lists that you configured in the previous sections, as shown in the following table.

    IP set references variable name Mapped VPC prefix list name to IP set references CIDR block
    IP_list_Allow_ssh_subnets public-ip-list 10.1.2.0/28
    IP_list_Private_Deny private-deny-list 10.0.1.0/24
    IP_list_private_subnets private-allow-list 10.1.3.0/28
    Figure 5: Example of IP set references

    Figure 5: Example of IP set references

  4. In the Add rule section, do the following, as shown in Figure 6:
    1. Select the protocol.
    2. For Source, select Custom and then enter the IP set reference variable name for the source IP address with the following format: <@Your_ip_set_reference_name>. In our example, the name is @IP_list_Allow_ssh_subnets.
    3. For Source port, select Custom and enter the appropriate port number.
    4. For Destination, choose Custom and then enter the IP set reference variable name for the destination IP address with the following format: <@Your_ip_set_reference_name>. In our example, the name is @IP_list_Private_subnets.
    5. For Destination port, choose Custom and enter the appropriate port number.
    6. For Traffic direction, select Any.
    7. For Action, select Pass.
    8. Choose Add rule.
    Figure 6: Example of a Network Firewall rule group with custom IP set references

    Figure 6: Example of a Network Firewall rule group with custom IP set references

  5. For the next set of rules, repeat the preceding steps and choose the appropriate protocol, source, destination, traffic direction, and action, as shown in the following table.

    Protocol Source Destination Source port Destination port Direction Action
    SSH @IP_list_Allow_ssh_subnets @IP_list_private_subnets 22 22 Forward Pass
    SSH Any @IP_list_private_subnets Any 22 Forward Drop
    ICMP @IP_list_Private_Deny Any Any Any Forward Drop

    After completion, you will have a set of stateful rules, as shown in Figure 7.

    Figure 7: Example list of Network Firewall rules

    Figure 7: Example list of Network Firewall rules

Congratulations! You have configured Network Firewall rule groups by using VPC prefix lists for a simplified management to allow SSH traffic only from authorized subnets and to deny ICMP traffic from unauthorized subnets.

For the next steps, you can test your configuration by trying to use protocols such as SSH or ICMP from unauthorized subnets to your private subnets and reviewing the behavior. You can also test your configuration by doing the same from authorized subnets and comparing the results. Furthermore, you can create logging and monitoring solutions in Network Firewall to review the dropped or allowed packets from your Network Firewall log groups in CloudWatch Logs or use contributor insights to analyze Network Firewall logs.

Clean up the resources

To clean up the resources that you created for this walkthrough, do the following:

  1. Remove all subnet associations from the route tables.
  2. Delete Network Firewall policies, rule groups, and IP set preferences.
  3. Delete the network firewall.
  4. Delete VPC prefix lists.
  5. Delete your subnets.
  6. Delete the route tables.
  7. Delete the VPC.
  8. Delete the CloudFormation stack (if you created your environment through CloudFormation).

Conclusion

In this post, you learned how to use Amazon VPC managed prefix lists to simplify management of IP addresses within Network Firewall rule groups. IP set preferences that are mapped to your VPC prefix lists are a great tool to help simplify your firewall rules and reduce operational overhead and administration as you scale your network.

For information about pricing, see AWS Network Firewall pricing. For more information about managed prefix lists, see Work with customer-managed prefix lists. For more examples and use cases, see previous Network Firewall posts on the AWS Security Blog.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Security, Identity, & Compliance re:Post or contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Mojgan Toth

Mojgan Toth

Mojgan is a Sr. Technical Account Manager. She loves putting together solutions around well-architecture and resiliency. When it comes to personal life, she loves cooking, painting and spending time with her family specially her two little sons. They love outdoor activities such as bike rides and hikes.