# Prepare your scalable vulnerability management program
Preparing to build a scalable vulnerability management program involves educating people, developing processes, and implementing the proper technology according to best practices. People, processes, and technology are equally important for an effective vulnerability management program, and you must tightly integrate them to manage vulnerabilities at scale.
This section of the guide reviews the foundational actions you can take to prepare your scalable vulnerability management program on AWS.
**Topics**
+ [Define a vulnerability management plan](vulnerability-management-plan.md)
+ [Distribute security ownership](distribute-ownership.md)
+ [Develop a vulnerability disclosure program](disclosure-program.md)
+ [Prepare your AWS environment](prepare-environment.md)
+ [Monitor AWS security bulletins](monitor-aws-security-bulletins.md)
+ [Configure AWS security services](configure-aws-security-services.md)
+ [Prepare to assign security findings](prepare-finding-assignments.md)
# Define a vulnerability management plan
The first step when preparing your cloud vulnerability management program is defining your *vulnerability management plan*. This plan includes the policies and processes your organization follows. This plan should be documented and accessible by all stakeholders. A vulnerability management plan is a high-level document that typically includes the following sections:
+ **Goals and scope** – Outline the goals, functions, and scope of vulnerability management.
+ **Roles and responsibilities** – List the vulnerability management stakeholders and detail their responsibilities.
+ **Vulnerability severity and prioritization definitions** – Determine how to classify the severity of a vulnerability and how to prioritize it.
+ **Service level agreements (SLAs)** **for remediation **– For each severity level, define the maximum amount of time a remediation owner has to resolve a security finding. Because SLA compliance is an integral part of having an effective and scalable vulnerability management program, consider how to track whether you're meeting these SLAs.
+ **Exception process **– Detail the process of submitting, approving, and updating exceptions. This process should make sure that exceptions are legitimate, time-bound, and tracked.
+ **Sources of vulnerability information **– List the sources or tools that generate security findings. For more information about AWS services that could be sources for security findings, see [Configure AWS security services](configure-aws-security-services.md) in this guide.
While these sections are common throughout companies of different sizes and industries, each organization's vulnerability management plan is unique. You need to build a vulnerability management plan that works best for your organization. Expect to iterate your plan over time to incorporate lessons learned and evolving technologies.
# Distribute security ownership
The [AWS shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) defines how AWS and its customers share responsibility for cloud security and compliance. In this model, AWS secures the infrastructure that runs all of the services offered in the AWS Cloud, and AWS customers are responsible for securing their data and applications.
You can mirror this model inside your organization and distribute the responsibilities between your cloud and application teams. This helps you scale your cloud security programs more effectively because the application teams take ownership of certain security aspects of their applications. The simplest interpretation of the shared responsibility model is that if you have access to configure the resource, then you are responsible for the security of that resource.
A key part of distributing security responsibilities to application teams is building self-service security tools that help your application teams automate. Initially, this can be a joint effort. The security team can translate security requirements into code-scanning tools, and then application teams can use those tools to build and share solutions with their internal developer community. This contributes to greater efficiencies across other teams that need to meet similar security requirements.
The following table outlines the steps for distributing ownership to application teams and provides examples.
****
| Step | Action | Example |
| --- | --- | --- |
| 1 | Define your security requirements – What are you trying to achieve? This might come from a security standard or compliance requirement. | An example security requirement is least-privilege access for application identities. |
| 2 | Enumerate controls for a security requirement – What does this requirement actually mean from a control perspective? What do I need to do to achieve this? | To achieve least-privilege for application identities, the following are two sample controls:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/vulnerability-management/distribute-ownership.html) |
| 3 | Document guidance for the controls – With these controls, what guidance can you provide to a developer to help them comply with the control? | Initially, you might start by documenting simple example policies, including secure and unsecure IAM policies and Amazon Simple Storage Service (Amazon S3) bucket policies. Next, you can embed policy-scanning solutions within continuous integration and continuous delivery (CI/CD) pipelines, such as using [AWS Config rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html) for proactive evaluation. |
| 4 | Develop reusable artifacts – With the guidance, can you make it even easier and develop reusable artifacts for developers? | You might create infrastructure as code (IaC) to deploy IAM policies that follow the principle of least privilege. You can store these reusable artifacts in a code repository. |
Self-service might not work for all security requirements, but it can work for standard scenarios. By following these steps, organizations can empower their application teams to handle more of their own security responsibilities in a scalable way. Overall, the distributed responsibility model leads to more collaborative security practices within many organizations.
# Develop a vulnerability disclosure program
For a [defense-in-depth](apg-gloss.md#glossary-defense-in-depth) approach to vulnerability management, create a vulnerability disclosure program so that people inside or outside your organization can report security vulnerabilities or risks.
For people inside your organization, establish a process to submit risks or vulnerabilities. This can be done through a ticketing system or email. Regardless of the process you choose, it's essential that your employees are aware of the process and can easily submit any vulnerabilities or risks that they encounter.
For people outside your organization, establish an external webpage for submitting potential security vulnerabilities. As an example, see the [AWS Vulnerability Reporting](https://aws.amazon.com/security/vulnerability-reporting/) webpage. This webpage should also contain disclosure guidelines to help protect your organization's data and assets. A vulnerability disclosure program should not encourage potentially harmful activity, so it's essential that you have a clear policy with guidelines. Building a mature, responsible disclosure program is a goal to strive for as you mature your program. Most don't start with an external disclosure program, and it takes time to get it right.
# Prepare your AWS environment
Before implementing any vulnerability management tooling, make sure that your AWS environment is architected to support a scalable vulnerability management program. The structure of your AWS accounts and your organization's tagging policies can simplify the process of building a scalable vulnerability management program.
## Develop an AWS account structure
[AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) helps centrally manage and govern an AWS environment as your business grows and scales its AWS resources. An *organization* in AWS Organizations consolidates your AWS accounts into logical groups, or *organizational units*, so that you can administer them as a single unit. You manage AWS Organizations from a dedicated account, called the *management account*. For more information, see [AWS Organizations terminology and concepts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html).
We recommend that you manage your AWS multi-account environment in AWS Organizations. This helps create a full inventory of your company's accounts and resources. This complete asset inventory is a critical aspect of vulnerability management. Application teams should not use accounts that are outside of the organization.
[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) helps you set up and govern an AWS multi-account environment, following prescriptive best practices. If you haven't already established a multi-account environment, AWS Control Tower is a good starting point.
We recommend using the [dedicated account structure](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/dedicated-accounts.html) and best practices described in the [AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/). The [Security Tooling account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html) should serve as your delegated administrator for your security services. More information about configuring your vulnerability management tooling in this account is provided later in this guide. Host applications in dedicated accounts in the [Workloads organization unit (OU)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/application.html). This establishes strong workload-level isolation and explicit security boundaries for each application. For information about the design principles and benefits of using a multi-account approach, see [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) (AWS whitepaper).
Having an intentional account structure and centrally managing security services from a dedicated account are critical aspects of a scalable vulnerability management program.
## Define, implement, and enforce tags
*Tags* are key-value pairs that act as metadata for organizing your AWS resources. For more information, see [Tagging your AWS resources](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html). You can use tags to provide business context, such as business unit, application owner, environment, and cost center. The following table shows a set of sample tags.
****
| Key | Value |
| --- | --- |
| BusinessUnit | HumanResources |
| CostCenter | CC101 |
| ApplicationTeam | HumanResourcesTechnology |
| Environment | Production |
Tags can help you prioritize findings. For example, it can help you:
+ Identify the owner of a resource who is responsible for patching a vulnerability
+ Track which applications or business units have a large number of findings
+ Escalate the severity of findings for certain data classifications, such as personally identifiable information (PII) or payment card industry (PCI) data
+ Identify the type of data in the environment, such as test data in a lower-level development environment or production data
To help you achieve effective tagging at scale, follow the instructions in [Building your tagging strategy](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/building-your-tagging-strategy.html) in *Best Practices for Tagging AWS Resources* (AWS whitepaper).
# Monitor AWS security bulletins
We highly recommend monitoring [AWS security bulletins](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinId&card-body.sort-order=desc&awsf.bulletins-flag=*all&awsf.bulletins-year=*all) on a regular and frequent basis. Security bulletins can notify you of any new security-related vulnerabilities, affected services, and applicable updates. You can also subscribe to an [RSS feed](https://aws.amazon.com/security/security-bulletins/rss/feed/) for the security bulletins and build a process to ingest and address these bulletins as part of your vulnerability management program.
# Configure AWS security services
AWS offers a variety of security services that are designed to help protect your AWS environment. For your vulnerability management program, we recommend that you enable the following AWS services in each account:
+ [Amazon GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html) helps detect active threats in your environment. A GuardDuty finding could help you identify an unknown vulnerability that was exploited in your environment. It could also help you understand the effects of an unpatched vulnerability.
+ [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) provides ongoing visibility into your resource performance and the availability of your AWS services and accounts.
+ [AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) analyzes the resource-based policies in your AWS environment to identify resources that are shared with an external entity. This can help you identify vulnerabilities associated with unintended access to your resources and data. For each instance of a resource shared outside of your account, IAM Access Analyzer generates a finding.
+ [Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) is a vulnerability management service that continuously scans your AWS workloads for software vulnerabilities and unintended network exposure.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) helps you check your AWS environment against security industry standards and can identify cloud configuration risks. It also provides a comprehensive view of your AWS security state by aggregating findings from other AWS security services and third-party security tools.
This section discusses how to enable and configure Amazon Inspector and Security Hub CSPM to help you establish a scalable vulnerability management program.
# Using Amazon Inspector in your vulnerability management program
[Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) is a vulnerability management service that continually scans your Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Container Registry (Amazon ECR) container images, and AWS Lambda functions for software vulnerabilities and unintended network exposure. You can use Amazon Inspector to gain visibility and prioritize resolution of software vulnerabilities across your AWS environments.
Amazon Inspector continuously assesses your environment throughout the lifecycle of your resources. It automatically rescans resources in response to changes that could introduce a new vulnerability. For example, it rescans when you install a new package on an EC2 instance, when you install a patch, or when a new common vulnerabilities and exposures (CVE) that affects the resource is published. When Amazon Inspector identifies a vulnerability or an open network path, it produces a finding that you can investigate. The finding provides comprehensive information about the vulnerability, including the following:
+ [Amazon Inspector risk score](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-score.html)
+ [Common Vulnerability Scoring System (CVSS) score](https://www.first.org/cvss/calculator/3.1)
+ Affected resource
+ Vulnerability intelligence data about the CVE from Amazon, [https://www.recordedfuture.com/](https://www.recordedfuture.com/), and [https://www.cisa.gov/](https://www.cisa.gov/)
+ Remediation recommendations
For instructions on setting up Amazon Inspector, see [Getting started with Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/getting_started_tutorial.html). The *Activate Amazon Inspector* step in this tutorial provides two configuration options: a standalone account environment and a multi-account environment. We recommend using the multi-account environment option if you want to monitor multiple AWS accounts that are members of an organization in AWS Organizations.
When you set up Amazon Inspector for a multi-account environment, you designate an account in the organization to be the Amazon Inspector delegated administrator. The delegated administrator can manage findings and some settings for organization members. For example, the delegated administrator can view the details of aggregated findings for all member accounts, enable or disable scans for member accounts, and review scanned resources. The AWS SRA recommends that you create a [Security Tooling account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html) and use it as the Amazon Inspector delegated administrator.
# Using AWS Security Hub CSPM in your vulnerability managment program
Building a scalable vulnerability management program on AWS involves managing traditional software and network vulnerabilities in addition to cloud configuration risks. [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) helps you check your AWS environment against security industry standards and can identify cloud configuration risks. Security Hub CSPM also provides a comprehensive view of your security state in AWS by aggregating security findings from other AWS security services and third-party security tools.
In the following sections, we provide best practices and recommendations for setting up Security Hub CSPM to support your vulnerability management program:
+ [Setting up Security Hub CSPM](#setting-up-security-hub)
+ [Enabling Security Hub CSPM standards](#enabling-security-hub-standards)
+ [Managing Security Hub CSPM findings](#managing-security-hub-findings)
+ [Aggregating findings from other security services and tools](#aggregating-findings-from-other-security-services-and-tools)
## Setting up Security Hub CSPM
For setup instructions, see [Setting up AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-settingup.html). To use Security Hub CSPM, you must enable [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html). For more information, see [Enabling and configuring AWS Config](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-prereq-config.html) in the Security Hub CSPM documentation.
If you are integrated with AWS Organizations, from the organization management account, you designate an account to be the Security Hub CSPM delegated administrator. For instructions, see [Designating the Security Hub CSPM delegated administrator](https://docs.aws.amazon.com/securityhub/latest/userguide/designate-orgs-admin-account.html#designate-admin-overview). The AWS SRA recommends that you create a [Security Tooling account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/security-tooling.html) and use it as the Security Hub CSPM delegated administrator.
The delegated administrator automatically has access to configure Security Hub CSPM for all member accounts in the organization and to view findings associated with those accounts. We recommend that you enable AWS ConfigSecurity Hub CSPM in all AWS Regions and all of your AWS accounts. You can configure Security Hub CSPM to automatically treat new organization accounts as Security Hub CSPM member accounts. For instructions, see [Managing member accounts that belong to an organization](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-accounts-orgs.html).
## Enabling Security Hub CSPM standards
Security Hub CSPM generates findings by running automated and continuous security checks against *security controls*. The controls are associated with one or more *security standards*. The controls help you determine whether the requirements in a standard are being met.
When you enable a standard in Security Hub CSPM, Security Hub CSPM automatically enables the controls that apply to the standard. Security Hub CSPM uses AWS Config [rules](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) to perform most of its security checks for controls. You can enable or disable Security Hub CSPM standards at any time. For more information, see [Security controls and standards in AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards.html). For a complete list of standards, see [Security Hub CSPM standards reference](https://docs.aws.amazon.com/securityhub/latest/userguide/standards-reference.html).
If your organization does not already have a preferred security standard, we recommend using the [AWS Foundational Security Best Practices (FSBP) standard](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html). This standard is designed to detect when AWS accounts and resource deviate from security best practices. AWS curates this standard and updates it regularly to cover new features and services. After triaging the FSBP findings, consider enabling other standards.
## Managing Security Hub CSPM findings
Security Hub CSPM provides several features that help you address large volumes of findings from across your organization and understand the security state of your AWS environment. To help you manage findings, we recommend enabling the following two Security Hub CSPM features:
+ Use [cross-Region aggregation](https://docs.aws.amazon.com/securityhub/latest/userguide/finding-aggregation.html) to aggregate findings, finding updates, insights, control compliance statuses, and security scores from multiple AWS Regions to a single aggregation Region.
+ Use [consolidated control findings](https://docs.aws.amazon.com/securityhub/latest/userguide/controls-findings-create-update.html#consolidated-control-findings) to reduce finding noise by removing duplicate findings. When consolidated control findings is turned on in your account, Security Hub CSPM generates a single new finding or finding update for each security check of a control, even if a control applies to multiple enabled standards.
## Aggregating findings from other security services and tools
In addition to generating security findings, you can use Security Hub CSPM to aggregate finding data from several AWS services and supported third-party security solutions. This section focuses on sending security findings to Security Hub CSPM. The next section, [Prepare to assign security findings](prepare-finding-assignments.md), discusses how you can integrate Security Hub CSPM with products that can receive findings from Security Hub CSPM.
There are many AWS services, third-party products, and open-source solutions available that you can integrate with Security Hub CSPM. If you are just getting started, we recommend doing the following:
1. **Enable integrated AWS services** – Most AWS service integrations that send findings to Security Hub CSPM are automatically activated after you enable both Security Hub CSPM and the integrated service. For your vulnerability management program, we recommend enabling Amazon Inspector, Amazon GuardDuty, AWS Health, and IAM Access Analyzer in each account. These services automatically send their findings to Security Hub CSPM. For a complete list of supported AWS service integrations, see [AWS services that send findings to Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html).
**Note**
AWS Health sends findings to Security Hub CSPM if one of the following conditions are met:
The finding is associated with an AWS security service
The finding **typecode** contains the words `security`, `abuse`, or `certificate`
The finding AWS Health service is `risk` or `abuse`
1. **Set up third-party integrations** – For a list of the currently supported integrations, see [Available third-party partner product integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html). Select any additional tools that can send findings to or receive findings from Security Hub CSPM. You might already have some of these third-party tools. Follow the product instructions to configure integration with Security Hub CSPM.
# Prepare to assign security findings
In this section, you set up the tools that your teams use to manage and assign security findings. This section includes the following options:
+ [Manage findings in existing tools and workflows](existing-tools.md) – This option integrates AWS Security Hub CSPM with existing systems that your teams use to manage their daily tasks, such as a product backlog. This option is recommended for teams that have established tools to manage their workflows.
+ [Manage findings in Security Hub CSPM](manage-findings-in-security-hub.md) – This option configures notifications for Security Hub CSPM events so that the appropriate team receives an alert and can address the finding in Security Hub CSPM.
Decide which workflow would work best for your teams, and make sure that security findings can make it promptly to their respective owners.
# Manage findings in existing tools and workflows
We recommend additional Security Hub CSPM integrations for enterprise organizations that have established tools that teams use to manage or perform their daily tasks. You can import Security Hub CSPM finding data into several technology platforms. Examples include:
+ [Security information and event management (SIEM) systems](apg-gloss.md#glossary-siem) help security teams triage operational security events. SIEM systems provide real-time analysis of security alerts that are generated by applications and network hardware.
+ [Governance, risk, and compliance (GRC)](https://aws.amazon.com/what-is/grc/) systems help compliance and governance teams monitor and report on risk management data. GRC tools are software applications that businesses can use to manage policies, assess risk, control user access, and streamline compliance. You might use GRC tools to integrate business processes, reduce costs, and improve efficiency.
+ Product backlog and ticketing systems help application and cloud teams manage features and prioritize development tasks. [https://www.atlassian.com/software/jira](https://www.atlassian.com/software/jira) and [https://learn.microsoft.com/en-us/azure/devops/user-guide/what-is-azure-devops](https://learn.microsoft.com/en-us/azure/devops/user-guide/what-is-azure-devops) are examples of these systems.
Integrating Security Hub CSPM findings directly with these existing enterprise systems can improve mean time to recovery (MTTR) and security outcomes because the daily operational workflow doesn't have to change. Teams can respond and learn from security findings much faster because they don't have to use separate workflows and tools. Integration makes addressing security findings part of the normal, standard workflow.
Security Hub CSPM integrates with multiple third-party partner products. For a complete list and instructions, see [Available third-party partner product integrations](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html) in the Security Hub CSPM documentation. Common integrations include [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-atlassian-jira-service-management](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-atlassian-jira-service-management), [Bidirectionally integrate AWS Security Hub CSPM with Jira software](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/bidirectionally-integrate-aws-security-hub-with-jira-software.html), and [https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-servicenow-itsm](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-partner-providers.html#integration-servicenow-itsm). The following diagram shows how you can configure Amazon Inspector to send findings to Security Hub CSPM and then configure Security Hub CSPM to send all findings to Jira.
![\[Send Amazon Inspector and AWS Security Hub CSPM findings to Jira\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/vulnerability-management/images/jira-integration-security-hub.png)
# Manage findings in Security Hub CSPM
You can build a cloud-based notification system for Security Hub CSPM findings by using [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) rules and Amazon Simple Notification Service (Amazon SNS) topics. This system notifies the appropriate team about a finding when it is created. For this approach, the multi-account strategy described in [Develop an AWS account structure](prepare-environment.md#account-structure) is critical because applications are separated into dedicated accounts. This helps you notify the correct teams for each finding.
Security or cloud teams might choose to receive events from all AWS accounts. In this case, build an EventBridge rule within the Security Hub CSPM delegated administrator account and subscribe an Amazon SNS topic that notifies these teams. For application teams, configure an EventBridge rule and SNS topic within their respective application accounts. When a Security Hub CSPM finding occurs within an application account, the responsible team is notified about the finding.
Security Hub CSPM already automatically sends all new findings and all updates to existing findings to EventBridge as **Security Hub CSPM Findings - Imported** events. Each **Security Hub CSPM Findings - Imported** event contains a single finding. You can apply filters on EventBridge rules so that a finding initiates the rule only if the finding matches the filters. For instructions, see [Configuring an EventBridge rule for automatically sent findings](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-cwe-all-findings.html). For more information about creating and subscribing Amazon SNS topics, see [Configuring Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-configuring.html).
Consider the following when using this approach:
+ For application teams, create EventBridge rules within each AWS account and AWS Region where the application is hosted.
+ For security and cloud teams, create EventBridge rules in the Security Hub CSPM delegated administrator account. This notifies teams about all findings in the member accounts.
+ Amazon SNS sends a notification each day if the status of the security finding is `NEW`. If you want to turn off the daily notifications, you can create a custom AWS Lambda function that changes the status of the finding from `NEW` to `NOTIFIED` after the Amazon SNS subscriber receives the notification.