# Managing Amazon GuardDuty findings
GuardDuty offers several important features to help you sort, store, and manage your findings. These features will help you tailor findings to your specific environment, reduce noise from low value findings, and help you focus on threats to your unique AWS environment. Review the topics on this page to understand how you can use these features to increase the value of security findings in your environment.
**Topics:**
[Summary dashboard in Amazon GuardDuty](guardduty-summary.md)
Learn about the components of the summary dashboard available in the GuardDuty console.
[Filtering findings in GuardDuty](guardduty_filter-findings.md)
Learn how to filter GuardDuty findings based on the criteria you specify.
[Suppression rules in GuardDuty](findings_suppression-rule.md)
Learn how to automatically filter the findings GuardDuty alerts you to through suppression rules. Suppression rules automatically archive findings based on filters.
[Customizing threat detection with entity lists and IP address lists](guardduty_upload-lists.md)
Customize the GuardDuty monitoring scope using IP Lists and Threat Lists based on publicly-routable IP addresses. Trusted IP lists prevent non-DNS findings from being generated from IP's you consider trusted, while Threat Intel Lists will cause GuardDuty to alert you of activity from user-defined IPs.
[Exporting generated findings to Amazon S3](guardduty_exportfindings.md)
Export the generated findings to an Amazon S3 bucket so that you can maintain records past the 90-day findings retention period in GuardDuty. Use this historical data to track potential suspicious activities in your account and evaluate whether the recommended remediation steps were successful.
[Processing GuardDuty findings with Amazon EventBridge](guardduty_findings_eventbridge.md)
Set up automatic notifications for GuardDuty findings through Amazon EventBridge events. You can also automate other tasks through EventBridge to help you respond to findings.
[Understanding CloudWatch Logs and reasons for skipping resources during Malware Protection for EC2 scan](malware-protection-auditing-scan-logs.md)
Learn how you can audit the CloudWatch Logs for GuardDuty Malware Protection for EC2 and what are the reasons because of which your impacted Amazon EC2 instance or Amazon EBS volumes may have been skipped during the scanning process.
[Reporting false positives in Malware Protection for EC2](malware-protection-false-positives.md)
Learn how you can report potential false positive threat detections in Malware Protection for EC2.
[Reporting S3 object scan result as false positive in Malware Protection for S3Reporting false positive S3 object scan result](report-malware-protection-s3-false-positives.md)
Learn how you can report potential false positive threat detections in Malware Protection for S3.
[Reporting false positives in Malware Protection for Backup](malware-protection-backup-false-positives.md)
Learn how you can report potential false positive threat detections in Malware Protection for Backup.
# Summary dashboard in Amazon GuardDuty
The GuardDuty **Summary** dashboard provides an aggregated view of the GuardDuty findings generated in your AWS account in the current AWS Region.
If you're using a GuardDuty administrator account, the dashboard provides aggregated statistics and data for your account and member accounts in your organization.
**Viewing Summary dashboard**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
GuardDuty displays the **Summary** dashboard by default when you open the console.
1. On the **Summary** page, choose the desired AWS Region from the Region selector in the top-right corner of the console.
1. From the date range selector menu, choose the date range for which you want to view the summary. By default, the dashboard displays the data for the present day, **Today**.
**Note**
If no findings were generated during the selected date range, the dashboard will not have any data to display. You can refresh the dashboard, or adjust the date range.
**Topics**
+ [Overview](#understanding-guardduty-summary-overview)
+ [Findings](#understanding-guardduty-summary-findings-widget)
+ [Most common finding types](#understanding-guardduty-summary-most-common-finding-types)
+ [Findings by severity](#understanding-guardduty-summary-findings-by-sev)
+ [Accounts with most findings](#understanding-guardduty-summary-account-with-findings)
+ [Resources with findings](#understanding-guardduty-summary-resources-with-findings)
+ [Least occurring findings](#understanding-guardduty-summary-least-occurring-findings)
+ [Protection plans coverage](#understanding-guardduty-summary-protection-plans-coverage)
## Overview
This section provides the following data:
+ **Attack sequences**: Indicates the number of attack sequence findings that GuardDuty generated in your account in the current Region.
GuardDuty detects potential multi-stage attacks in your account. You can select the *number* under **Attack sequences** to view its details on the **Findings** page.
+ **Total findings**: Indicates the total number of findings generated in your account in the current Region. This includes both individual findings and attack sequence findings.
+ **Resources with findings**: Indicates the number of resources that are associated to a finding, and have been potentially compromised.
+ **Accounts with findings**: Indicates the number of accounts in which at least one finding was generated. If you're a standalone account, the value in this field is **1**.
For the time ranges **Last 7 days** and **Last 30 days**, the **Overview** pane may show the percentage difference in the findings generated week over week (WoW) or month over month (MoM), respectively. If no findings were generated in the week or the month before, then with no data to compare, the percentage difference may not be available.
![\[Overview section in the GuardDuty Summary dashboard.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/attack-sequence-summary-overview-console.png)
If you're a GuardDuty administrator account, all of these fields provide the summarized data across all the member accounts in your organization.
## Findings
The **Findings** widget displays up to eight top findings. These findings are listed on the basis of their severity level, with *Critical* findings displayed first.
By default, you can view all the findings. To view only attack sequence findings data, turn on **Top attack sequences only**.
In this list, you can select any finding to view its details.
![\[Findings widget in the GuardDuty Summary dashboard.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/attack-sequence-summary-finding-widget-console.png)
## Most common finding types
This section provides a pie chart illustrating the top five most common finding types generated in the current Region. When hovering over each sector of the pie chart, you can observe the following:
+ **Findings count**: Indicates the number of times this finding has been generated in the chosen date range.
+ **Severity**: Indicates the severity level of the finding.
+ **Percentage**: Indicates proportion of this finding type relative to the total.
+ **Last generated**: Indicates how much time has passed since this finding type was last detected.
## Findings by severity
This section displays a bar chart showing the total number of findings over the selected date range. The chart breaks down findings by severity (*Critical*, *High*, *Medium*, and *Low*), and helps you view the number of findings for specific dates within the range.
To view the counts for each severity level on a specific date, hover over the corresponding bar in the chart.
## Accounts with most findings
This section provides the following data:
+ **Account**: Indicates the AWS account ID where the finding was generated.
+ **Finding count**: Indicates the number of times a finding was generated for this account ID.
+ **Last generated**: Indicates how much time has passed since a finding type was last generated for this account ID.
+ **Severity filter**: By default, the data is shown for the high severity finding types. Possible options for this field are **All severity**, **Critical severity**, **High severity**, and **Medium severity**.
## Resources with findings
This section provides the following data:
+ **Resource**: Shows the potentially impacted resource type and if this resource belongs to your account, you can access the quick link to view the resource details. If you're a GuardDuty administrator account, you can view the details of the potentially impacted resource by accessing the GuardDuty console with the credentials of the owner member account.
+ **Account**: Indicates the AWS account ID to which this resource belongs.
+ **Finding count**: Indicates the number of times that this resource was associated to a finding.
+ **Last generated**: Indicates how much time has passed since a finding type associated to this resource was last generated.
+ **Resource type filter**: By default, the data is shown for all the resource types. By using this filter, you can choose to view the data for a specific resource type, such as **Instance**, **AccessKey**, **Lambda**, and others.
+ **Severity filter**: By default, the data is shown for **All severity**. By using this filter, you can choose to view the data for other severity levels. Possible options are **Critical severity**, **High severity**, **Medium severity**, and **All severity**.
## Least occurring findings
This section highlights finding types that occur infrequently in your AWS environment. This widget is designed to help you identify and investigate potential emergent threat patterns.
This widget displays the following data:
+ **Finding type**: Shows the finding type name.
+ **Finding count**: Indicates the number of times that this finding type was generated in the chosen time range.
+ **Last generated**: Indicates how much time has passed since this finding type was last generated.
+ **Severity filter**: By default, the data is shown for the high severity finding types. Possible options for this field are **Critical severity**, **High severity**, **Medium severity**, and **All severity**.
## Protection plans coverage
This section displays statistics for the member accounts in your organization. It shows the number of member accounts that have enabled GuardDuty (foundational threat detection) in the current Region. Only a delegated GuardDuty administrator can view the statistics for the member accounts within their organization. When you create a new AWS organization, it might take up to 24 hours to generate the statistics for the entire organization.
**How to use this widget**
+ **Configuration**: If a protection plan is not configured, choose **Configure** under the **Actions** column.
+ **Viewing enabled accounts**: Hover over the bar in the **Enabled accounts** column to view how many accounts have enabled each protection plan. To further view account details, select the green bar, and choose **View accounts**.
![\[View status of protection plans enablement for member accounts, in GuardDuty Summary dashboard.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/guardduty-summary-protection-plans-console.png)
# Filtering findings in GuardDuty
A finding filter allows you to view findings that match the criteria you specify and filter out any unmatched findings. You can easily create finding filters using the Amazon GuardDuty console, or you can create them with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API using JSON. Review the following sections to understand how to create a filter in the console. To use these filters to automatically archive incoming findings, see [Suppression rules in GuardDuty](findings_suppression-rule.md).
When you create filters, take the following list into consideration:
+ You can specify a minimum of one attribute and up to a maximum of 50 attributes as the criteria for a particular filter.
+ When you use the **Equals** or **Does not equals** operator to filter on an attribute value, such as Account ID, you can specify a maximum of 50 values.
+ Each filter criteria attribute is evaluated as an `AND` operator. Multiple values for the same attribute are evaluated as `AND/OR`.
+ For information about the maximum number of saved filters that you can create in an AWS account in each AWS Region, see [GuardDuty quotas](guardduty_limits.md).
The following sections provide instructions on how to create and save filters using GuardDuty console, and API and CLI commands. Choose your preferred access method to proceed.
## Creating and saving filter set in the GuardDuty console
Finding filters can be created and tested through the GuardDuty console. You can save filters created through the console for use in suppression rules or future filter operations. A filter is made up of at least one filter criteria, which consists of one filter attribute paired with at least one value.
**To create and save filter criteria (console)**
1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the left navigation pane, choose **Findings**.
1. On the **Findings** page, select the *Filter findings* bar next to **Saved rules** menu. This will display an expanded list of **Property filters**.
![\[Selecting property filters to filter findings in the GuardDuty console.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/guardduty-findings-page-console.png)
1. From the expanded list of filters, select an attribute based on which you want to filter the findings table.
For example, to view findings for which the potentially impacted resource is an **S3Bucket**, choose **Resource type**.
1. For **Operators**, choose one that will help you filter the findings to get the desired result. To continue the example from the previous step, choose **Resource type =**. This will display a list of resource types in GuardDuty.
![\[Selecting the equals or does not equals operator to filter findings in GuardDuty console.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/guardduty-findings-page-filters-operator-console.png)
If your use case requires excluding specific findings, you can choose **Does not equal** or **\$1=** operator.
1. Specify the value for the selected property filter. If needed, choose **Apply**. To continue the example from the previous step, you can choose **S3Bucket**.
This will display the findings that match with the applied filters.
1. To add more than one filter criteria, repeat steps 3-6.
For a complete list of attributes, see [Property filters in GuardDuty](#filter_criteria).
1.
**(Optional) save the specified attributes and values as filters**
To apply this filter combination again in the future, you can save the specified attributes and their values as a filter set.
1. After you have created a filter criteria with one or more property filters, select the *arrow* in the **Clear filters** menu.
![\[Saving a filter set in GuardDuty console to be able to filter the findings again.\]](http://docs.aws.amazon.com/guardduty/latest/ug/images/guardduty-findings-page-filters-console.png)
1. Enter the filter set **Name**. The name must be 3-64 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (\$1).
1. The **Description** is optional. If you enter a description, it can have up to 512 characters.
1. Choose **Create**.
## Creating and saving filter set by using GuardDuty API and CLI
You can create and test the finding filters by using either API or CLI commands. A filter is made up of at least one filter criteria, which consists of one filter attribute paired with at least one value. You can save filters to create [Suppression rules](findings_suppression-rule.md) or to perform other filter operations later.
**To create finding filters using API/CLI**
+ Run [CreateFilter](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API by using the regional detector ID of the AWS account where you want to create a filter.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
+ Alternatively, you can use the [create-filter](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/create-filter.html) CLI to create and save the filter. You can use one or more filter criteria from [Property filters in GuardDuty](#filter_criteria).
Use the following examples by replacing the placeholder values shown in red.
**Example 1**: Create a new filter to view all the findings that match a specific finding type
The following example creates a filter that matches all `PortScan` findings for an instance created from a specific image. The placeholder values are shown in red. Replace these values with suitable values for your account. For example, replace *12abc34d567e8fa901bc2d34EXAMPLE* with your regional detector ID.
```
aws guardduty create-filter \
--detector-id 12abc34d567e8fa901bc2d34EXAMPLE \
--name FilterExampleName \
--finding-criteria '{"Criterion": {"type": {"Equals": ["Recon:EC2/Portscan"]}, "resource.instanceDetails.imageId": {"Equals":["ami-0a7a207083example"]}} }'
```
**Example 2**: Create a new filter to view all the findings that match severity levels
The following example creates a filter that matches all findings associated with the `HIGH` severity levels. The placeholder values are shown in red. Replace these values with suitable values for your account. For example, replace *12abc34d567e8fa901bc2d34EXAMPLE* with your regional detector ID.
```
aws guardduty create-filter \
--detector-id 12abc34d567e8fa901bc2d34EXAMPLE \
--name FilterExampleName \
--finding-criteria '{"Criterion": {"severity": {"Equals": ["7", "8"]}} }'
```
+ For API/CLI, the [Findings severity levels](guardduty_findings-severity.md) are represented as numerals. To filter the findings based on the severity levels, use the following values:
+ For `LOW` severity levels, use `{ "severity": { "Equals": ["1", "2", "3"] } }`
+ For `MEDIUM` severity levels, use `{ "severity": { "Equals": ["4", "5", "6"] } }`
+ For `HIGH` severity levels, use `{ "severity": { "Equals": ["7", "8"] } }`
+ For `CRITICAL` severity levels, use `{ "severity": { "Equals": ["9", "10"] } }`
+ For findings with multiple severity levels, use placeholder values similar to the following example: `{ "severity": { "Equals": ["7", "8", "9", "10"] } }`
This example will show the findings that have either `HIGH` or `CRITICAL` severity levels.
**Note**
If you specify an example with only one numeric value instead of all the numeric values associated with a severity level, the API and CLI might show the filtered findings. When you use this saved filter set in the GuardDuty console, it will not work as expected. This is because the GuardDuty console considers the filter values as `CRITICAL`, `HIGH`, `MEDIUM`, and `LOW`. For example, a filter created with a CLI command that includes `{ "severity": { "Equals": ["9"] } }` is expected to show an appropriate output in API/CLI. However, this saved filter includes partial severity level when used in the GuardDuty console and will not show an expected output. This makes it necessary for the API and CLI to specify all the values associated with each severity level.
## Property filters in GuardDuty
When you create filters or sort findings using the API operations, you must specify filter criteria in JSON. These filter criteria correlate to a finding's details JSON. The following table contains a list of the console display names for filter attributes and their equivalent JSON field names.
| Console field name | JSON field name |
| --- | --- |
| Account ID | accountId |
| Finding ID | id |
| Region | region |
| Severity | severity You can filter the finding types based on the severity level of the finding types. For more information about severity values, see [Severity levels of GuardDuty findings](guardduty_findings-severity.md). If you use `severity` with API, AWS CLI, or CloudFormation, it is assigned a numeric value. For more information, see [findingCriteria](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html#guardduty-CreateFilter-request-findingCriteria) in the *Amazon GuardDuty API Reference*. |
| Finding type | type |
| Updated at | updatedAt |
| Access Key ID | resource.accessKeyDetails.accessKeyId |
| Principal ID | resource.accessKeyDetails.principalId |
| Username | resource.accessKeyDetails.userName |
| User type | resource.accessKeyDetails.userType |
| IAM instance profile ID | resource.instanceDetails.iamInstanceProfile.id |
| Instance ID | resource.instanceDetails.instanceId |
| Instance image ID | resource.instanceDetails.imageId |
| Instance tag key | resource.instanceDetails.tags.key |
| Instance tag value | resource.instanceDetails.tags.value |
| IPv6 address | resource.instanceDetails.networkInterfaces.ipv6Addresses |
| Private IPv4 address | resource.instanceDetails.networkInterfaces.privateIpAddresses.privateIpAddress |
| Public DNS name | resource.instanceDetails.networkInterfaces.publicDnsName |
| Public IP | resource.instanceDetails.networkInterfaces.publicIp |
| Security group ID | resource.instanceDetails.networkInterfaces.securityGroups.groupId |
| Security group name | resource.instanceDetails.networkInterfaces.securityGroups.groupName |
| Subnet ID | resource.instanceDetails.networkInterfaces.subnetId |
| VPC ID | resource.instanceDetails.networkInterfaces.vpcId |
| Outpost ARN | resource.instanceDetails.outpostARN |
| Resource type | resource.resourceType |
| Bucket permissions | resource.s3BucketDetails.publicAccess.effectivePermission |
| Bucket name | resource.s3BucketDetails.name |
| Bucket tag key | resource.s3BucketDetails.tags.key |
| Bucket tag value | resource.s3BucketDetails.tags.value |
| Bucket type | resource.s3BucketDetails.type |
| Action type | service.action.actionType |
| API called | service.action.awsApiCallAction.api |
| API caller type | service.action.awsApiCallAction.callerType |
| API Error Code | service.action.awsApiCallAction.errorCode |
| API caller city | service.action.awsApiCallAction.remoteIpDetails.city.cityName |
| API caller country | service.action.awsApiCallAction.remoteIpDetails.country.countryName |
| API caller IPv4 address | service.action.awsApiCallAction.remoteIpDetails.ipAddressV4 |
| API caller IPv6 address | service.action.awsApiCallAction.remoteIpDetails.ipAddressV6 |
| API caller ASN ID | service.action.awsApiCallAction.remoteIpDetails.organization.asn |
| API caller ASN name | service.action.awsApiCallAction.remoteIpDetails.organization.asnOrg |
| API caller service name | service.action.awsApiCallAction.serviceName |
| DNS request domain | service.action.dnsRequestAction.domain |
| DNS request domain suffix | service.action.dnsRequestAction.domainWithSuffix |
| Network connection blocked | service.action.networkConnectionAction.blocked |
| Network connection direction | service.action.networkConnectionAction.connectionDirection |
| Network connection local port | service.action.networkConnectionAction.localPortDetails.port |
| Network connection protocol | service.action.networkConnectionAction.protocol |
| Network connection city | service.action.networkConnectionAction.remoteIpDetails.city.cityName |
| Network connection country | service.action.networkConnectionAction.remoteIpDetails.country.countryName |
| Network connection remote IPv4 address | service.action.networkConnectionAction.remoteIpDetails.ipAddressV4 |
| Network connection remote IPv6 address | service.action.networkConnectionAction.remoteIpDetails.ipAddressV6 |
| Network connection remote IP ASN ID | service.action.networkConnectionAction.remoteIpDetails.organization.asn |
| Network connection remote IP ASN name | service.action.networkConnectionAction.remoteIpDetails.organization.asnOrg |
| Network connection remote port | service.action.networkConnectionAction.remotePortDetails.port |
| Remote account affiliated | service.action.awsApiCallAction.remoteAccountDetails.affiliated |
| Kubernetes API caller IPv4 address | service.action.kubernetesApiCallAction.remoteIpDetails.ipAddressV4 |
| Kubernetes API caller IPv6 address | service.action.kubernetesApiCallAction.remoteIpDetails.ipAddressV6 |
| Kubernetes namespace | service.action.kubernetesApiCallAction.namespace |
| Kubernetes API caller ASN ID | service.action.kubernetesApiCallAction.remoteIpDetails.organization.asn |
| Kubernetes API call request URI | service.action.kubernetesApiCallAction.requestUri |
| Kubernetes API status code | service.action.kubernetesApiCallAction.statusCode |
| Network connection local IPv4 address | service.action.networkConnectionAction.localIpDetails.ipAddressV4 |
| Network connection local IPv6 address | service.action.networkConnectionAction.localIpDetails.ipAddressV6 |
| Protocol | service.action.networkConnectionAction.protocol |
| API call service name | service.action.awsApiCallAction.serviceName |
| API caller account ID | service.action.awsApiCallAction.remoteAccountDetails.accountId |
| Threat list name | service.additionalInfo.threatListName |
| Resource role | service.resourceRole |
| EKS cluster name | resource.eksClusterDetails.name |
| Kubernetes workload name | resource.kubernetesDetails.kubernetesWorkloadDetails.name |
| Kubernetes workload namespace | resource.kubernetesDetails.kubernetesWorkloadDetails.namespace |
| Kubernetes user name | resource.kubernetesDetails.kubernetesUserDetails.username |
| Kubernetes container image | resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image |
| Kubernetes container image prefix | resource.kubernetesDetails.kubernetesWorkloadDetails.containers.imagePrefix |
| Scan ID | service.ebsVolumeScanDetails.scanId |
| EBS volume scan threat name | service.ebsVolumeScanDetails.scanDetections.threatDetectedByName.threatNames.name |
| S3 object scan threat name | service.malwareScanDetails.threats.name |
| Threat severity | service.ebsVolumeScanDetails.scanDetections.threatDetectedByName.threatNames.severity |
| File SHA | service.ebsVolumeScanDetails.scanDetections.threatDetectedByName.threatNames.filePaths.hash |
| ECS cluster name | resource.ecsClusterDetails.name |
| ECS container image | resource.ecsClusterDetails.taskDetails.containers.image |
| ECS task definition ARN | resource.ecsClusterDetails.taskDetails.definitionArn |
| Standalone container image | resource.containerDetails.image |
| Database Instance Id | resource.rdsDbInstanceDetails.dbInstanceIdentifier |
| Database Cluster Id | resource.rdsDbInstanceDetails.dbClusterIdentifier |
| Database Engine | resource.rdsDbInstanceDetails.engine |
| Database user | resource.rdsDbUserDetails.user |
| Database instance tag key | resource.rdsDbInstanceDetails.tags.key |
| Database instance tag value | resource.rdsDbInstanceDetails.tags.value |
| Executable SHA-256 | service.runtimeDetails.process.executableSha256 |
| Process name | service.runtimeDetails.process.name |
| Executable path | service.runtimeDetails.process.executablePath |
| Lambda function name | resource.lambdaDetails.functionName |
| Lambda function ARN | resource.lambdaDetails.functionArn |
| Lambda function tag key | resource.lambdaDetails.tags.key |
| Lambda function tag value | resource.lambdaDetails.tags.value |
| DNS request domain | service.action.dnsRequestAction.domainWithSuffix |
# Suppression rules in GuardDuty
A suppression rule is a set of criteria, consisting of a filter attribute paired with a value, used to filter findings by automatically archiving new findings that match the specified criteria. Suppression rules can be used to filter low-value findings, false positive findings, or threats you do not intend to act on, to make it easier to recognize the security threats with the most impact to your environment.
After you create a suppression rule, new findings that match the criteria defined in the rule are automatically archived as long as the suppression rule is in place. You can use an existing filter to create a suppression rule or create a suppression rule from a new filter you define. You can configure suppression rules to suppress entire finding types, or define more granular filter criteria to suppress only specific instances of a particular finding type. You can edit the suppression rules at any time.
Suppressed findings are not sent to AWS Security Hub CSPM, Amazon Simple Storage Service, Amazon Detective, or Amazon EventBridge, reducing finding noise level if you consume GuardDuty findings via Security Hub CSPM, a third-party SIEM, or other alerting and ticketing applications. If you've enabled [Malware Protection for EC2](malware-protection.md), the suppressed GuardDuty findings won't initiate a malware scan.
GuardDuty continues to generate findings even when they match your suppression rules, however, those findings are automatically marked as **archived**. The archived finding is stored in GuardDuty for 90-days and can be viewed at any time during that period. You can view suppressed findings in the GuardDuty console by selecting **Archived** from the findings table, or through the GuardDuty API using the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API with a `findingCriteria` criterion of `service.archived` equal to true.
**Note**
In a multi-account environment only the GuardDuty administrator can create suppression rules.
## Using suppression rules with Extended Threat Detection
GuardDuty Extended Threat Detection automatically detects multi-stage attacks that span data sources, multiple types of AWS resources, and time, within an AWS account. It correlates events across different data sources to identify scenarios that present themselves as a potential threat to your AWS environment, and then generates an attack sequence finding. For more information, see [How Extended Threat Detection works](guardduty-extended-threat-detection.md#extended-threat-detection-how-it-works).
When you create suppression rules that archive findings, Extended Threat Detection can't use these archived findings when correlating events for attack sequences. Broad suppression rules might impact the ability of GuardDuty to detect behaviors aligned with detecting multi-stage attacks. Findings that are archived because of suppression rules are not considered as signals for attack sequences. For example, if you create a suppression rule that archives all EKS cluster-related findings instead of targeting specific known activities, GuardDuty won't be able to use those findings to detect an attack sequence where a threat actor exploits a container, obtains privileged tokens, and accesses sensitive resources.
Consider the following recommendations from GuardDuty:
+ Continue using suppression rules to reduce alerts from known trusted activities.
+ Keep the suppression rules focused on specific behaviors for which you don't want GuardDuty to generate a finding.
## Common use cases for suppression rules and examples
The following finding types have common use cases for applying suppression rules. Select the finding name to learn more about that finding. Review the use case description to decide if you want to build a suppression rule for that finding type.
**Important**
GuardDuty recommends that you build suppression rules reactively and only for findings for which you have repeatedly identified false positives in your environment.
+ [UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS](guardduty_finding-types-iam.md#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws) – Use a suppression rule to automatically archive findings generated when VPC networking is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway.
This finding is generated when networking is configured to route internet traffic such that it egresses from an on-premises gateway rather than from a VPC Internet Gateway (IGW). Common configurations, such as using [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/), or VPC VPN connections, can result in traffic routed this way. If this is expected behavior, it is recommended that you use suppression rules and create a rule that consists of two filter criteria. The first criteria is **finding type**, which should be `UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`. The second filter criteria is **API caller IPv4 address** with the IP address or CIDR range of your on-premises internet gateway. The example below represents the filter you would use to suppress this finding type based on API caller IP address.
```
Finding type: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS API caller IPv4 address: 198.51.100.6
```
**Note**
To include multiple API caller IPs you can add a new API Caller IPv4 address filter for each.
+ [Recon:EC2/Portscan](guardduty_finding-types-ec2.md#recon-ec2-portscan) – Use a suppression rule to automatically archive findings when using a vulnerability assessment application.
The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `Recon:EC2/Portscan`. The second filter criteria should match the instance or instances that host these vulnerability assessment tools. You can use either the **Instance image ID** attribute or the **Tag** value attribute depending on which criteria are identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain AMI.
```
Finding type: Recon:EC2/Portscan Instance image ID: ami-999999999
```
+ [UnauthorizedAccess:EC2/SSHBruteForce](guardduty_finding-types-ec2.md#unauthorizedaccess-ec2-sshbruteforce) – Use a suppression rule to automatically archive findings when it is targeted to bastion instances.
If the target of the brute force attempt is a bastion host, this may represent expected behavior for your AWS environment. If this is the case, we recommend that you set up a suppression rule for this finding. The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `UnauthorizedAccess:EC2/SSHBruteForce`. The second filter criteria should match the instance or instances that serve as a bastion host. You can use either the **Instance image ID** attribute or the **Tag** value attribute depending on which criteria is identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain instance tag value.
```
Finding type: UnauthorizedAccess:EC2/SSHBruteForce Instance tag value: devops
```
+ [Recon:EC2/PortProbeUnprotectedPort](guardduty_finding-types-ec2.md#recon-ec2-portprobeunprotectedport) – Use a suppression rule to automatically archive findings when it is targeted to intentionally exposed instances.
There may be cases in which instances are intentionally exposed, for example if they are hosting web servers. If this is the case in your AWS environment, we recommend that you set up a suppression rule for this finding. The suppression rule should consist of two filter criteria. The first criteria should use the **Finding type** attribute with a value of `Recon:EC2/PortProbeUnprotectedPort`. The second filter criteria should match the instance or instances that serve as a bastion host. You can use either the **Instance image ID** attribute or the **Tag** value attribute, depending on which criteria is identifiable with the instances that host these tools. The example below represents the filter you would use to suppress this finding type based on instances with a certain instance tag key in the console.
```
Finding type: Recon:EC2/PortProbeUnprotectedPort Instance tag key: prod
```
### Recommended suppression rules for Runtime Monitoring findings
+ [PrivilegeEscalation:Runtime/DockerSocketAccessed](findings-runtime-monitoring.md#privilegeesc-runtime-dockersocketaccessed) gets generated when a process inside a container communicates with the Docker socket. There may be containers in your environment that may need to access the Docker socket for legitimate reasons. Access from such containers will generate PrivilegeEscalation:Runtime/DockerSocketAccessed finding. If this is a case in your AWS environment, we recommend that you set up a suppression rule for this finding type. The first criteria should use the **Finding type** field with value equal to `PrivilegeEscalation:Runtime/DockerSocketAccessed`. The second filter criteria is **Executable path** field with value equal to the process's `executablePath` in the generated finding. Alternatively, the second filter criteria can use **Executable SHA-256** field with value equal to the process's `executableSha256` in the generated finding.
+ Kubernetes clusters run their own DNS servers as pods, such as `coredns`. Therefore, for each DNS lookup from a pod, GuardDuty captures two DNS events – one from the pod and the other from the server pod. This may generate duplicates for the following DNS findings:
+ [Backdoor:Runtime/C&CActivity.B\$1DNS](findings-runtime-monitoring.md#backdoor-runtime-ccactivitybdns)
+ [CryptoCurrency:Runtime/BitcoinTool.B\$1DNS](findings-runtime-monitoring.md#cryptocurrency-runtime-bitcointoolbdns)
+ [Impact:Runtime/AbusedDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-abuseddomainrequestreputation)
+ [Impact:Runtime/BitcoinDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-bitcoindomainrequestreputation)
+ [Impact:Runtime/MaliciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-maliciousdomainrequestreputation)
+ [Impact:Runtime/SuspiciousDomainRequest.Reputation](findings-runtime-monitoring.md#impact-runtime-suspiciousdomainrequestreputation)
+ [Trojan:Runtime/BlackholeTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-blackholetrafficdns)
+ [Trojan:Runtime/DGADomainRequest.C\$1DNS](findings-runtime-monitoring.md#trojan-runtime-dgadomainrequestcdns)
+ [Trojan:Runtime/DriveBySourceTraffic\$1DNS](findings-runtime-monitoring.md#trojan-runtime-drivebysourcetrafficdns)
+ [Trojan:Runtime/DropPoint\$1DNS](findings-runtime-monitoring.md#trojan-runtime-droppointdns)
+ [Trojan:Runtime/PhishingDomainRequest\$1DNS](findings-runtime-monitoring.md#trojan-runtime-phishingdomainrequestdns)
The duplicate findings will include pod, container, and process details that correspond to your DNS server pod. You may set up a suppression rule to suppress these duplicate findings using these fields. The first filter criteria should use the **Finding type** field with value equal to a DNS finding type from the list of findings provided earlier in this section. The second filter criteria could be either **Executable path** with value equal to your DNS server's `executablePath` or **Executable SHA-256** with value equal to your DNS server's `executableSHA256` in the generated finding. As an optional third filter criteria, you can use **Kubernetes container image** field with value equal to the container image of your DNS server pod in the generated finding.
# Creating suppression rules in GuardDuty
A suppression rule is a set of criteria that includes using filter attributes and providing values for which you don't want GuardDuty to generate a finding type. The finding types that match this criteria are automatically archived. To reduce noise, the suppressed findings are not sent to any of the AWS services with which you may integrate. For more information about common use cases for creating suppression rules, see [Suppression rules](findings_suppression-rule.md).
You can visualize, create, and manage suppression rules by using the **Suppression rules** page in the GuardDuty console. Suppression rules can also be generated from your existing saved filters. For more information about creating filters, see [Filtering findings in GuardDuty](guardduty_filter-findings.md).
The filter criteria can include an exact match using **Equals** and **NotEquals** operators, a **wildcard match** using the **Matches** and **NotMatches** operators or **comparison match** using **GreaterThan**, **GreaterThanEquals**, **LessThan** and **LessThanEquals** operators. More information on the available operators can be found in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Condition.html) page.
Choose your preferred access method to create a suppression rule for GuardDuty finding types.
------
#### [ Console ]
**To create a suppression rule using the console:**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. On the **Suppression rules** page, click on the **Create suppression rule** to open the **Create suppression rule** form.
1. Enter a **Name** for the suppression rule. The name must be 3-64 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (\$1).
1. The **Description** is optional. If you enter a description, it can have up to 512 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), colon (:), brackets(\$1\$1()[]), forward slash (/), and space.
1. The **Rank** is optional. It can be a numerical value from 1 up to the total count of filters and suppression rules, plus 1.
1. Under the **Attributes** section, select a **Key** and an **Operator** from the drop-down.
1. Enter the value either “string” or “date” from the datepicker based on the selected key. If it is a string value, type the text and press enter. Multiple values can be added in case of string values.
1. Additional criteria can be added by selecting **Add Criteria** to add another set of **Key**, **Operator** and **Value(s)**.
1. Select **Create suppression rule** to create and save the suppression rule.
You can also create a suppression rule from an existing saved filter. For more information about creating filters, see [Filtering findings in GuardDuty](guardduty_filter-findings.md).
**To create a suppression rule from a saved filter:**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. On the **Findings** page, from the **Saved rules** menu, select a saved filter set rule. This will automatically display the filter set and findings that match the criteria.
1. You can also add more filter criteria to this saved rule. If you don't need additional filter criteria, skip this step. To add one or more filter criteria, follow steps 3 through 7 in [Adding filters on Findings page](guardduty_filter-findings.md#guardduty-add-filters-findings-page), and then continue with the following steps.
1. After you have added the filter criteria and confirmed that the filtered findings meet your requirements, choose **Create suppression rule**.
1. Enter a **Name** for the suppression rule.The name must be 3-64 characters. Valid characters are a-z, A-Z, 0-9, period (.), hyphen (-), and underscore (\$1).
1. The **Description** is optional. If you enter a description, it can have up to 512 characters.
1. Choose **Create**.
1. If you don't need to add additional filter criteria to the saved rule, follow steps 4 through 7 to create the filter.
------
#### [ API/CLI ]
**To create a suppression rule using API:**
1. You can create suppression rules through the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API. To do so, specify the filter criteria in a JSON file following the format of the example detailed below. The below example will suppress any unarchived low-severity findings that has a DNS request to the `test.example.com` domain. For medium severity findings, the input list will be `["4", "5", "7"]`. For high severity findings, the input list will be `["6", "7", "8"]`. For critical severity findings, the input list will be `["9", "10"]`. You can also filter on the basis of any one value in the list.
The following example adds a filter for low severity findings for lambda functions with function name prefix "MyFunc" and function tag with prefix not as "TestTag"
```
{
"Criterion": {
"service.action.dnsRequestAction.domain": {
"Equals": [
"test.example.com"
]
},
"severity": {
"Equals": [
"1",
"2",
"3"
]
}
}
}
```
You can create suppression rules using wildcard characters \$1 and ? . Wildcards in filters are supported using **Matches** and **NotMatches** operators only. To match any number of characters, you can use \$1 in the attribute value and to match a single character, you can use ? in the attribute value. Filters support a maximum of 5 attributes under a single wildcard condition and a maximum of 5 wildcard character within a single attribute. The following example adds a filter for Lambda name matching the prefix “MyFunc" but not Lambda functions with tags with "TestTag" as prefix followed by 0-2 characters.
```
{
"Criterion": {
"resource.lambdaDetails.functionName": {
"Matches": [
"MyFunc*"
]
},
"resource.lambdaDetails.tags.key": {
"NotMatches": [
"TestTag??"
]
}
}
}
```
For a list of JSON field names and their console equivalent see [Property filters in GuardDuty](guardduty_filter-findings.md#filter_criteria).
To test your filter criteria, use the same JSON criterion in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API, and confirm that the correct findings have been selected. To test your filter criteria using AWS CLI follow the example using your own detectorId and .json file.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
```
aws guardduty list-detector
```
```
aws guardduty list-findings \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--region us-east-1 \
--finding-criteria file://criteria.json
```
**Note**
Wildcards matching are not available for ListFindings and GetFindingsStatistics. Criteria containing wildcards cannot be validated using ListFindings and GetFindingsStatistics.
1. Upload your filter to be used as suppression rule with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateFilter.html) API or by using the AWS CLI following the example below with your own detector ID, a name for the suppression rule, and .json file.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
```
aws guardduty create-filter \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--region us-east-1 \
--action ARCHIVE \
--name yourfiltername \
--finding-criteria file://criteria.json
```
You can view a list of your filters programmatically with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFilter.html) API. You can view the details of an individual filter by supplying the filter name to the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetFilter.html) API. Update filters using [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateFilter.html) or delete them with the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html) API.
------
# Updating suppression rules in GuardDuty
This section provides the steps to update a suppression rule in your AWS account in a specific AWS Region.
You can update existing suppression rules from the **Suppression rules** page in the GuardDuty console. GuardDuty supports updating the suppression filter description, rank and filter criteria from the GuardDuty console or by using the GuardDuty CLI/API. Updating suppression rule follows the same restrictions on the field values for description, rank and criteria as [Creating suppression rules](create-suppression-rules-guardduty.md).
If you're a member account, your administrator account can take this action on your behalf. For more information, see [Administrator account and member account relationships](administrator_member_relationships.md).
Choose your preferred access method to delete a suppression rule for GuardDuty findingtypes.
------
#### [ Console ]
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. On the **Suppression rules** page, select the suppression rule to update.
1. From the **Actions** dropdown, select **Update suppression rule**.
1. This opens the existing the suppression rule form.
1. Make changes to the **Description**, **Rank** and **Attributes** section as required.
1. Select **Update suppression rule** to update the Suppression rule.
------
#### [ API/CLI ]
**To update a suppression rule using API:**
1. You can update suppression rules through the UpdateFilter API. Only **description**, **rank** and **criteria** can be updated using the UpdateFilter API. All these three fields are optional.
1. To update an existing filter, you will need the name of the filter that you are planning to update.
1. If you want to update the existing criteria, create a JSON file with the updated criteria similar to how you first created the filter. An example criteria to suppress any unarchived low-severity findings that has a DNS request to the test.example.com domain. For medium severity findings, the input list will be ["4", "5", "7"]. For high severity findings, the input list will be ["6", "7", "8"]. For critical severity findings, the input list will be ["9", "10"]. You can also filter on the basis of any one value in the list. The following example adds a filter for low severity findings.
```
{
"Criterion": {
"service.action.dnsRequestAction.domain": {
"Equals": [
"test.example.com"
]
},
"severity": {
"Equals": [
"1",
"2",
"3"
]
}
}
}
```
For a list of JSON field names and their console equivalent see [Property filters in GuardDuty](guardduty_filter-findings.md#filter_criteria).
To test your filter criteria, use the same JSON criterion in the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListFindings.html) API, and confirm that the correct findings have been selected. To test your filter criteria using AWS CLI follow the example using your own detectorId and .json file.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
```
aws guardduty list-detectors --region us-east-1
```
1. If you want to update the description, you can include the description parameter in the CLI call.
1. If you want to update the rank, you can include the rank parameter in the CLI call.
1. If you want to update from a suppression filter to a regular filter, using the action parameter and value as **ARCHIVE** in the CLI call.
1. Update your existing filter API or by using the AWS CLI following the example below with your own detector ID, a name for the suppression rule, and .json file.
1. The following is an example CLI that updates all the parameters described above. You can select the specific parameters to be updated for your use case from the command -
```
aws guardduty update-filter \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--region us-east-1 \
--action ARCHIVE \
--rank 1 \
--description "Updated description" \
--finding-criteria file://criteria.json
```
------
# Deleting suppression rules in GuardDuty
This section provides the steps to delete a suppression rule in your AWS account in a specific AWS Region.
You may want to delete a suppression rule that no longer depicts an expected behavior in your environment. You no longer want to suppress the associated finding type so that GuardDuty can generate a finding type.
If you're a member account, your administrator account can take this action on your behalf. For more information, see [Administrator account and member account relationships](administrator_member_relationships.md).
Choose your preferred access method to delete a suppression rule for GuardDuty finding types.
------
#### [ Console ]
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. On the **Suppression rules** page, select the suppression rule to delete.
1. From the **Actions** dropdown, select **Delete suppression rule**.
1. It prompts a confirmation pop-up. Select **Delete** to proceed with the deletion. Or select **Cancel** to cancel the operation.
------
#### [ API/CLI ]
Run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteFilter.html) API. Specify the filter name and the associated detector ID for the particular Region.
Alternatively, you can use the following AWS CLI example by replacing the values formatted in *red*:
```
aws guardduty delete-filter \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--filter-name filterName \
--region us-east-1
```
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
------
# Customizing threat detection with entity lists and IP address lists
Amazon GuardDuty monitors the security of your AWS environment by analyzing and processing VPC Flow Logs, AWS CloudTrail event logs, and DNS logs. By enabling one or more [Use-case focused GuardDuty protection plans](https://docs.aws.amazon.com/guardduty/latest/ug/what-is-guardduty.html#features-of-guardduty) (except [Runtime Monitoring](runtime-monitoring.md), you can expand the monitoring capabilities within GuardDuty.
With lists, GuardDuty helps you customize the scope of threat detection in your environment. You can configure GuardDuty to stop generating findings from your trusted sources and generate findings for known malicious sources from your threat lists. GuardDuty continues to support legacy IP address lists and extends support to entity lists (recommended) that can contain IP addresses, domains, or both.
**Topics**
+ [Understanding entity lists and IP address lists](#guardduty-threat-intel-list-entity-sets)
+ [Important considerations for GuardDuty lists](#guardduty-lists-entity-sets-considerations)
+ [List formats](#prepare_list)
+ [Understanding list statuses](#guardduty-entity-list-statuses)
+ [Setting up prerequisites for entity lists and IP address lists](guardduty-lists-prerequisites.md)
+ [Adding and activating an entity list or IP list](guardduty-lists-create-activate.md)
+ [Updating an entity list or IP address list](guardduty-lists-update-procedure.md)
+ [De-activating entity list or IP address list](guardduty-lists-deactivate-procedure.md)
+ [Deleting entity list or IP address list](guardduty-lists-delete-procedure.md)
## Understanding entity lists and IP address lists
GuardDuty offers two implementation approaches: entity lists (recommended) and IP lists. Both approaches help you specify trusted sources, which stop GuardDuty from generate findings and known threats, which GuardDuty uses to generate findings.
**Entity lists** support both IP addresses and domain names. They use direct Amazon Simple Storage Service (Amazon S3) access with a single IAM permission that doesn't impact IAM policy size limits across multiple Regions.
**IP lists** support only IP addresses and use [GuardDuty service-linked role (SLR)](slr-permissions.md) (SLR), requiring IAM policy updates per Region, which may impact IAM policy size limits.
Trusted lists (both entity lists and IP address lists) include entries that you trust for secure communication with your AWS infrastructure. GuardDuty does not generate findings for entries listed in trusted sources. At any given time, you can add only one trusted entity list and one trusted IP address list per AWS account per Region.
Threat lists (both entity lists and IP address lists) include entries that you have identified as known malicious sources. When GuardDuty detects an activity involving these sources, it generates findings to alert you of potential security issues. You can create your own threat lists or incorporate third-party threat intelligence feeds. This list can be supplied by third-party threat intelligence or created specifically for your organization. In addition to generating findings because of a potentially suspicious activity, GuardDuty also generates findings based on an activity that involves entries from your threat lists. At any given time, you can upload up to six threat entity lists and threat IP address lists per AWS account per Region.
**Note**
To migrate from IP address lists to entity lists, follow [Prerequisites for entity lists](guardduty-lists-prerequisites.md#guardduty-entity-list-prerequisites), then add and activate the required entity list. After this, you can choose to deactivate or delete the corresponding IP address list.
## Important considerations for GuardDuty lists
Before you begin working with lists, read the following considerations:
+ IP address lists and entity lists apply only to traffic destined for publicly routable IP addresses and domains.
+ In an entity list, the entries apply to CloudTrail, VPC Flow Logs in Amazon VPC, and Route53 Resolver DNS query logs findings.
In an IP address list, the entries apply to CloudTrail and VPC Flow Logs in Amazon VPC findings, but not to Route53 Resolver DNS query logs findings.
+ If you include the same IP address or domain in both trusted and threat lists, then this entry in the trusted list will take precedence. GuardDuty will not generate a finding if there is an activity associated with this entry.
+ In a multi-account environment, only the GuardDuty administrator account can manage lists. This setting automatically applies to the member accounts. GuardDuty generates findings based on an activity that involves known malicious IP addresses (and domains) from the administrator account's threat sources, and doesn't generate findings based on activity that involves IP addresses (and domains) from the administrator account's trusted sources. For more information, see [Multiple accounts in Amazon GuardDuty](guardduty_accounts.md).
+ Only IPv4 addresses are accepted. IPv6 addresses are not supported.
+ After you activate, deactivate, or delete an entity list or IP address list, the process is estimated to complete within 15 minutes. In certain scenarios, it may take up to 40 minutes for this process to complete.
+ GuardDuty uses a list for threat detection only when the status of the list becomes **Active**.
+ Whenever you add or update an entry in the list's S3 bucket location, you must activate the list again. For more information, see [Updating an entity list or IP address list](guardduty-lists-update-procedure.md).
+ Entity lists and IP addresses have different quotas. For more information, see [GuardDuty quotas](guardduty_limits.md).
## List formats
GuardDuty accepts multiple file formats for your lists and entity lists, with a maximum of 35 MB per file. Each format has specific requirements and capabilities.
### Plaintext (TXT)
This format supports IP addresses, CIDR ranges, and domain names. Each entry must appear on a separate line.
****Example for entity list****
```
192.0.2.1
192.0.2.0/24
example.com
example.org
*.example.org
```
****Example for IP address list****
```
192.0.2.0/24
198.51.100.1
203.0.113.1
```
### Structured Threat Information Expression (STIX)
This format supports IP addresses, CIDR block, and domain names. STIX allows you to include additional context with your threat intelligence. GuardDuty processes IP addresses, CIDR ranges, and domain names from the STIX indicators.
****Example for an entity list****
```
Malicious domain observed Example
Domain Watchlist
bad.example.com
```
****Example for an IP address list****
```
192.0.2.0##comma##192.0.2.255
198.51.100.1
203.0.113.1
```
### Open Threat Exchange (OTX)TM CSV
This format supports CIDR block, individual IP addresses, and domains. This file format has comma-separated values.
****Example for entity list****
```
Indicator type, Indicator, Description
CIDR, 192.0.2.0/24, example
IPv4, 198.51.100.1, example
IPv4, 203.0.113.1, example
Domain name, example.net, example
```
****Example for IP address list****
```
Indicator type, Indicator, Description
CIDR, 192.0.2.0/24, example
IPv4, 198.51.100.1, example
IPv4, 203.0.113.1, example
```
### FireEyeTM iSIGHT Threat Intelligence CSV
This format supports CIDR block, individual IP addresses, and domains. The following sample lists uses a `FireEyeTM` CSV format.
****Example for entity list****
```
reportId, title, threatScape, audience, intelligenceType, publishDate, reportLink, webLink, emailIdentifier, senderAddress, senderName, sourceDomain, sourceIp, subject, recipient, emailLanguage, fileName, fileSize, fuzzyHash, fileIdentifier, md5, sha1, sha256, description, fileType, packer, userAgent, registry, fileCompilationDateTime, filePath, asn, cidr, domain, domainTimeOfLookup, networkIdentifier, ip, port, protocol, registrantEmail, registrantName, networkType, url, malwareFamily, malwareFamilyId, actor, actorId, observationTime
01-00000001, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000001, https://www.example.com/report/01-00000001, , , , , , , , , , , , , , , , , , , , , , , , 192.0.2.0/24, , , Related, , , , , , network, , Ursnif, 21a14673-0d94-46d3-89ab-8281a0466099, , , 1494944400
01-00000002, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000002, https://www.example.com/report/01-00000002, , , , , , , , , , , , , , , , , , , , , , , , , , , Related, 198.51.100.1, , , , , network, , Ursnif, 12ab7bc4-62ed-49fa-99e3-14b92afc41bf, , ,1494944400
01-00000003, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000003, https://www.example.com/report/01-00000003, , , , , , , , , , , , , , , , , , , , , , , , , , , Related, 203.0.113.1, , , , , network, , Ursnif, 8a78c3db-7bcb-40bc-a080-75bd35a2572d, , , 1494944400
01-00000002, Malicious domain observed in test, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000002,https://www.example.com/report/01-00000002,,,,,,,,,,,,,,,,,,,,,,,, 203.0.113.0/24, example.com,, Related, 203.0.113.0, 8080, UDP,,, network,, Ursnif, fc13984c-c767-40c9-8329-f4c59557f73b,,, 1494944400
```
****Example for IP address list****
```
reportId, title, threatScape, audience, intelligenceType, publishDate, reportLink, webLink, emailIdentifier, senderAddress, senderName, sourceDomain, sourceIp, subject, recipient, emailLanguage, fileName, fileSize, fuzzyHash, fileIdentifier, md5, sha1, sha256, description, fileType, packer, userAgent, registry, fileCompilationDateTime, filePath, asn, cidr, domain, domainTimeOfLookup, networkIdentifier, ip, port, protocol, registrantEmail, registrantName, networkType, url, malwareFamily, malwareFamilyId, actor, actorId, observationTime
01-00000001, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000001, https://www.example.com/report/01-00000001, , , , , , , , , , , , , , , , , , , , , , , , 192.0.2.0/24, , , Related, , , , , , network, , Ursnif, 21a14673-0d94-46d3-89ab-8281a0466099, , , 1494944400
01-00000002, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000002, https://www.example.com/report/01-00000002, , , , , , , , , , , , , , , , , , , , , , , , , , , Related, 198.51.100.1, , , , , network, , Ursnif, 12ab7bc4-62ed-49fa-99e3-14b92afc41bf, , ,1494944400
01-00000003, Example, Test, Operational, threat, 1494944400, https://www.example.com/report/01-00000003, https://www.example.com/report/01-00000003, , , , , , , , , , , , , , , , , , , , , , , , , , , Related, 203.0.113.1, , , , , network, , Ursnif, 8a78c3db-7bcb-40bc-a080-75bd35a2572d, , , 1494944400
```
### ProofpointTM ET Intelligence Feed CSV
In ProofPoint CSV format, you can add IP either addresses or domain names in a one list. The following sample list uses the `Proofpoint` CSV format. Providing value for the `ports` parameter is optional. When you don't provide it, leave a trailing comma (,) at the end.
****Example for entity list****
```
domain, category, score, first_seen, last_seen, ports (|)
198.51.100.1, 1, 100, 2000-01-01, 2000-01-01,
203.0.113.1, 1, 100, 2000-01-01, 2000-01-01, 80
```
****Example for IP address list****
```
ip, category, score, first_seen, last_seen, ports (|)
198.51.100.1, 1, 100, 2000-01-01, 2000-01-01,
203.0.113.1, 1, 100, 2000-01-01, 2000-01-01, 80
```
### AlienVaultTM Reputation Feed
The following sample list uses the `AlienVault` format.
****Example for entity list****
```
192.0.2.1#4#2#Malicious Host#KR##37.5111999512,126.974098206#3
192.0.2.2#4#2#Scanning Host#IN#Gurgaon#28.4666996002,77.0333023071#3
192.0.2.3#4#2##CN#Guangzhou#23.1166992188,113.25#3
www.test.org#4#2#Malicious Host#CA#Brossard#45.4673995972,-73.4832000732#3
www.example.com#4#2#Malicious Host#PL##52.2393989563,21.0361995697#3
```
****Example for IP address list****
```
198.51.100.1#4#2#Malicious Host#US##0.0,0.0#3
203.0.113.1#4#2#Malicious Host#US##0.0,0.0#3
```
## Understanding list statuses
When you add an entity list or an IP address list, GuardDuty shows the status of that list. The **Status** column indicates whether the list is effective and if any action is required. The following list describes valid status values:
+ **Active** – Indicates the list is currently in use for custom threat detection.
+ **Inactive** – Indicates that the list is currently not in use. For GuardDuty to use this list for threat detection in your environment, see Step 3: Activating an entity list or IP address list in [Adding and activating an entity list or IP list](guardduty-lists-create-activate.md).
+ **Error** – Indicates that there is an issue with the list. Hover over the status to view the error details.
+ **Activating** – Indicates that GuardDuty has initiated the process of activating the list. You can continue monitoring the status for this list. If there is no error, the status should update to **Active**. While the status remains **Activating**, you can't perform any action on this list. It might take a few minutes for the list status to change to **Active**.
+ **Deactivating** – Indicates that GuardDuty has initiated the process of deactivating the list. You can continue monitoring the status for this list. If there is no error, the status should update to **Inactive**. While the status remains **Deactivating**, you can't perform any action on this list.
+ **Delete Pending** – Indicates that the list is in the process of being deleted. While the status remains **Delete Pending**, you can't perform any action on this list.
# Setting up prerequisites for entity lists and IP address lists
GuardDuty uses entity lists and IP address lists to customize threat detection in your AWS environment. Entity lists (recommended) support both IP addresses and domain names, while IP address lists support only IP addresses. Before you begin creating these lists, you must add the required permissions for the type of list that you want to use.
## Prerequisites for entity lists
When you add entity lists, GuardDuty reads your trusted and threat intelligence lists from S3 buckets. The role you use to create entity lists must have the `s3:GetObject` permission for the S3 buckets contains these lists.
**Note**
In a multi-account environment, only the GuardDuty administrator account can manage lists, which automatically apply to member accounts.
If you don't already have the `s3:GetObject` permission for the S3 bucket location, then use the following example policy and replace *amzn-s3-demo-bucket* with your S3 bucket location.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/[object-key]"
}
]
}
```
------
## Prerequisites for IP address lists
Various IAM identities require special permissions to work with trusted IP lists and threat lists in GuardDuty. An identity with the attached [AmazonGuardDutyFullAccess\$1v2 (recommended)](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonGuardDutyFullAccess-v2) managed policy can only rename and deactivate uploaded trusted IP lists and threat lists.
To grant various identities full access to working with trusted IP lists and threat lists (in addition to renaming and deactivating, this includes adding, activating, deleting, and updating the location or name of the lists), make sure that the following actions are present in the permissions policy attached to a user, group, or role:
```
{
"Effect": "Allow",
"Action": [
"iam:PutRolePolicy",
"iam:DeleteRolePolicy"
],
"Resource": "arn:aws:iam::555555555555:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"
}
```
**Important**
These actions are not included in the `AmazonGuardDutyFullAccess` managed policy.
### Using SSE-KMS encryption with entity lists and IP lists
GuardDuty supports SSE-AES256 and SSE-KMS encryption for your lists. SSE-C is not supported. For more information about encryption types for S3, see [Protecting data using server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/serv-side-encryption.html).
Regardless of whether you use entity lists or IP lists, if you use SSE-KMS, then add the following statement to your AWS KMS key policy. Replace *123456789012* with your own account ID.
```
{
"Sid": "AllowGuardDutyServiceRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/aws-service-role/guardduty.amazonaws.com/AWSServiceRoleForAmazonGuardDuty"
},
"Action": "kms:Decrypt*",
"Resource": "*"
}
```
# Adding and activating an entity list or IP list
Entity lists and IP address lists help you customize the threat detection capabilities in GuardDuty. For more information about these lists, see [Understanding entity lists and IP address lists](guardduty_upload-lists.md#guardduty-threat-intel-list-entity-sets). To manage the trusted and threat intelligence data for your AWS environment, GuardDuty recommends using entity lists. Before you begin, see [Setting up prerequisites for entity lists and IP address lists](guardduty-lists-prerequisites.md).
Choose one of the following access methods to add and activate a trusted entity list, threat entity list, trusted IP list, or a threat IP list.
------
#### [ Console ]
**(Optional) step 1: Fetching location URL of your list**
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the navigation pane, choose **Buckets**.
1. Choose the Amazon S3 bucket name that contains the specific list that you want to add.
1. Choose the object (list) name to view its details.
1. Under the **Properties** tab, copy the **S3 URI** for this object.
**Step 2: Adding trusted or threat intelligence data**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Lists**.
1. On the **Lists** page, choose **Entity lists** or **IP address lists** tab.
1. Based on your selected tab, choose to add a trusted list or a threat list.
1. In the dialog box to add either trusted or threat list, do the following steps:
1. For **List name**, enter a name for your list.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
For an IP address list, the name of your list must be unique within an AWS account and Region.
1. For **Location**, provide the location where you have uploaded your list. If you don't already have it, see [Step 1: Fetching location URL of your list](#fetch-location-URL-list-manage).
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
**Format of location URL:**
+ https://s3.amazonaws.com/bucket.name/file.txt
+ https://s3-aws-region.amazonaws.com/bucket.name/file.txt
+ http://bucket.s3.amazonaws.com/file.txt
+ http://bucket.s3-aws-region.amazonaws.com/file.txt
+ s3://bucket.name/file.txt
1. (Optional) For **Expected bucket owner**, you can enter the AWS account ID that owns the Amazon S3 bucket specified in the **Location** field.
When you don't specify an AWS account ID owner, then GuardDuty behaves differently for entity lists and IP address lists. For entity lists, GuardDuty will validate that the current member account owns the S3 bucket specified in the **Location** field. For IP address lists, if you don't specify an AWS account ID owner, GuardDuty doesn't perform any validation.
If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating the list.
1. Select the **I agree** check box.
1. Choose **Add list**. By default, the **Status** of the added list is **Inactive**. For the list to be effective, you must activate the list.
**Step 3: Activating an entity list or IP address list**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Lists**.
1. On the **Lists** page, select the tab in which you want to activate the list - **Entity lists** or **IP address lists**.
1. Select one list that you want to activate. This will enable the **Action** and **Edit** menu.
1. Choose **Action**, and then choose **Activate**.
------
#### [ API/CLI ]
**To add and activate a trusted entity list**
1. Run [CreateTrustedEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateTrustedEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to create this trusted entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty create-trusted-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--format TXT \
--location "https://s3.amazonaws.com/amzn-s3-demo-bucket/DOC-EXAMPLE-SOURCE-FILE.format" \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the trusted entity list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. Whether or not you specify the value for this parameter, GuardDuty validates that the AWS account ID associated with this `--detector-id` value owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
**To add and activate threat entity lists**
1. Run [CreateThreatEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateThreatEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to create this threat entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty create-threat-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--format TXT \
--location "https://s3.amazonaws.com/amzn-s3-demo-bucket/DOC-EXAMPLE-SOURCE-FILE.format" \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the trusted entity list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. Whether or not you specify the value for this parameter, GuardDuty validates that the AWS account ID associated with this `--detector-id` value owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
**To add and activate a trusted IP address list**
1. Run [CreateIPSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateIPSet.html). Make sure to provide the `detectorId` of the member account for which you want to create this trusted IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
For an IP address list, the name of your list must be unique within an AWS account and Region.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will update the trusted IP address list.
```
aws guardduty create-ip-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--format TXT \
--location "https://s3.amazonaws.com/amzn-s3-demo-bucket/DOC-EXAMPLE-SOURCE-FILE.format" \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the trusted IP list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. When you don't specify the account ID that owns the S3 bucket, GuardDuty doesn't perform any validation. When you specify the account ID for the `expected-bucket-owner` parameter, GuardDuty validates that this AWS account ID owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
**To add and activate threat IP lists**
1. Run [CreateThreatIntelSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateThreatIntelSet.html). Make sure to provide the `detectorId` of the member account for which you want to create this threat IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
For an IP address list, the name of your list must be unique within an AWS account and Region.
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will update the threat IP list.
```
aws guardduty create-threat-intel-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--format TXT \
--location "https://s3.amazonaws.com/amzn-s3-demo-bucket/DOC-EXAMPLE-SOURCE-FILE.format" \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the threat IP list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. When you don't specify the account ID that owns the S3 bucket, GuardDuty doesn't perform any validation. When you specify the account ID for the `expected-bucket-owner` parameter, GuardDuty validates that this AWS account ID owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
------
After you activate an entity list or IP address list, it might take a few minutes for this list to be effective. For more information, see [Important considerations for GuardDuty lists](guardduty_upload-lists.md#guardduty-lists-entity-sets-considerations).
# Updating an entity list or IP address list
Entity lists and IP address lists help you customize the threat detection capabilities in GuardDuty. For more information about these lists, see [Understanding entity lists and IP address lists](guardduty_upload-lists.md#guardduty-threat-intel-list-entity-sets).
You can update the name of a list, S3 bucket location, expected bucket owner account ID, and the entries in an existing list. If you update the entries in a list, you must follow the steps to activate the list again for GuardDuty to use the latest version of the list. After you update or activate an entity list or IP address list, it might take a few minutes for this list to be effective. For more information, see [Important considerations for GuardDuty lists](guardduty_upload-lists.md#guardduty-lists-entity-sets-considerations).
**Note**
If the status of a list is **Activating**, **Deactivating**, or **Delete Pending**, you must wait for a few minutes before performing any action. For information about these statuses, see [Understanding list statuses](guardduty_upload-lists.md#guardduty-entity-list-statuses).
Choose one of the access methods to update an entity list or IP address list.
------
#### [ Console ]
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Lists**.
1. On the **Lists** page, select the appropriate tab - **Entity lists** or **IP address lists**.
1. Select one list (trusted or threat) that you want to update. This will enable the **Action** and **Edit** menu.
1. Choose **Edit**.
1. In the dialog box to update the list, specify the details that you want to update.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
For an IP address list, the name of your list must be unique within an AWS account and Region.
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
1. (Optional) For **Expected bucket owner**, you can enter the AWS account ID that owns the Amazon S3 bucket specified in the **Location** field.
When you don't specify an AWS account ID owner, then GuardDuty behaves differently for entity lists and IP address lists. For entity lists, GuardDuty will validate that the current member account owns the S3 bucket specified in the **Location** field. For IP address lists, if you don't specify an AWS account ID owner, GuardDuty doesn't perform any validation.
If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating the list.
1. Select the **I agree** check box, and then choose **Update list**.
------
#### [ API/CLI ]
To begin with the following procedures, you need the ID, such as `trustedEntitySetId`, `threatEntitySetId`, `trustedIpSet`, or `threatIpSet`, that is associated with the list resource you want to update.
**To update and activate a trusted entity list**
1. Run [UpdateTrustedEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateTrustedEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to update this trusted entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
1. Alternatively, you can do this by running the following AWS Command Line Interface command that updates the `name` of the list and also activates this list:
```
aws guardduty update-trusted-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--trusted-entity-set-id d4b94fc952d6912b8f3060768example \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the trusted entity list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. Whether or not you specify the value for this parameter, GuardDuty validates that the AWS account ID associated with this `--detector-id` value owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
**To update and activate a threat entity list**
1. Run [UpdateThreatEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateThreatEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to create this threat entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
1. Alternatively, you can do this by running the following AWS Command Line Interface command that updates the `name` of the list and also activates this list:
```
aws guardduty update-threat-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--threat-entity-set-id d4b94fc952d6912b8f3060768example \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the threat entity list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. Whether or not you specify the value for this parameter, GuardDuty validates that the AWS account ID associated with this `--detector-id` value owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
Applies only to custom threat and custom trusted entity sets – If you provide a location URL that doesn't match the following supported formats, then you will receive an error message during list addition and activation.
**To update and activate a trusted IP address list**
1. Run [CreateIPSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateIPSet.html). Make sure to provide the `detectorId` of the member account for which you want to update this trusted IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
For an IP address list, the name of your list must be unique within an AWS account and Region.
1. Alternatively, you can do this by running the following AWS Command Line Interface command that also activates the list:
```
aws guardduty update-ip-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--ip-set-id d4b94fc952d6912b8f3060768example \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will update the trusted IP list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. When you don't specify the account ID that owns the S3 bucket, GuardDuty doesn't perform any validation. When you specify the account ID for the `expected-bucket-owner` parameter, GuardDuty validates that this AWS account ID owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
**To add and activate threat IP lists**
1. Run [CreateThreatIntelSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CreateThreatIntelSet.html). Make sure to provide the `detectorId` of the member account for which you want to create this threat IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**List naming constraints** – The name of your list can include lowercase letters, uppercase letters, numbers, dash (-), and underscore (\$1).
For an IP address list, the name of your list must be unique within an AWS account and Region.
1. Alternatively, you can do this by running the following AWS Command Line Interface command that also activates the list:
```
aws guardduty update-threat-intel-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--name "AnyOrganization ListEXAMPLE" \
--threat-intel-set-id d4b94fc952d6912b8f3060768example \
--activate
```
Replace `detector-id` with the detector ID of the member account for which you will update the threat IP list, and other placeholder values that are *shown in red*.
If you don't want to activate this newly created list, then replace the parameter `--activate` with `--no-activate`.
The `expected-bucket-owner` parameter is optional. When you don't specify the account ID that owns the S3 bucket, GuardDuty doesn't perform any validation. When you specify the account ID for the `expected-bucket-owner` parameter, GuardDuty validates that this AWS account ID owns the S3 bucket specified in the `--location` parameter. If GuardDuty finds that this S3 bucket doesn't belong to the specified account ID, you will get an error at the time of activating this list.
------
# De-activating entity list or IP address list
When you no longer want GuardDuty to use a list, you can deactivate it. It might take a few minutes for the process to complete. For more information, see [Important considerations for GuardDuty lists](guardduty_upload-lists.md#guardduty-lists-entity-sets-considerations). After the list gets deactivated, the entries in the entity list or IP address list will not impact threat detection in GuardDuty.
Choose one of the access methods to deactivate the list.
------
#### [ Console ]
**To deactivate entity list or IP address list**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Lists**.
1. On the **List** page, select the tab in which you want to deactivate the list - **Entity lists** or **IP address list**.
1. In the selected tab, select the list that you want to deactivate.
1. Choose **Actions**, and then choose **Deactivate**.
1. Confirm the action and choose **Deactivate**.
------
#### [ API/CLI ]
To begin with the following procedures, you need the ID, such as `trustedEntitySetId`, `threatEntitySetId`, `trustedIpSet`, or `threatIpSet`, that is associated with the list resource you want to deactivate.
**To deactivate a trusted entity list**
1. Run [UpdateTrustedEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateTrustedEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to deactivate this trusted entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty update-trusted-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--trusted-entity-set-id d4b94fc952d6912b8f3060768example \
--no-activate
```
Replace `detector-id` with the detector ID of the member account for which you will deactivate the trusted entity list, and other placeholder values that are *shown in red*.
**To deactivate threat entity lists**
1. Run [UpdateThreatEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateThreatEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to deactivate this threat entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty update-threat-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--threat-entity-set-id d4b94fc952d6912b8f3060768example \
--no-activate
```
Replace `detector-id` with the detector ID of the member account for which you will create the threat entity list, and other placeholder values that are *shown in red*.
**To deactivate a trusted IP address list**
1. Run [UpdateIPSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateIPSet.html). Make sure to provide the `detectorId` of the member account for which you want to deactivate this trusted IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will deactivate the trusted IP address list.
```
aws guardduty update-ip-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--ip-set-id d4b94fc952d6912b8f3060768example \
--no-activate
```
**To deactivate threat IP list**
1. Run [UpdateThreatIntelSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateThreatIntelSet.html). Make sure to provide the `detectorId` of the member account for which you want to deactivate this threat IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will deactivate the threat IP list.
```
aws guardduty update-threat-intel-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--threat-intel-set-id d4b94fc952d6912b8f3060768example \
--no-activate
```
------
# Deleting entity list or IP address list
When you no longer want to keep a list entry in your entity set or IP address set, you can delete it. It might take a few minutes for the process to complete. For more information, see [Important considerations for GuardDuty lists](guardduty_upload-lists.md#guardduty-lists-entity-sets-considerations).
If the status of the list is **Activating** or **Deactivating**, you must wait for a few minutes before performing any action. For more information, see [Understanding list statuses](guardduty_upload-lists.md#guardduty-entity-list-statuses).
Choose one of the access methods to delete the list.
------
#### [ Console ]
**To delete entity list or IP address list**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Lists**.
1. On the **List** page, select the tab in which you want to delete the list - **Entity lists** or **IP address list**.
1. In the selected tab, select the list that you want to delete.
1. Choose **Actions**, and then choose **Delete**.
The list status will change to **Delete Pending**. It might take a few minutes for the list to get deleted.
------
#### [ API/CLI ]
To begin with the following procedures, you need the ID, such as `trustedEntitySetId`, `threatEntitySetId`, `trustedIpSet`, or `threatIpSet`, that is associated with the list resource you want to delete.
**To delete a trusted entity list**
1. Run [DeleteTrustedEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteTrustedEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to delete this trusted entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty delete-trusted-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--trusted-entity-set-id d4b94fc952d6912b8f3060768example
```
Replace `detector-id` with the detector ID of the member account for which you will delete the trusted entity list, and other placeholder values that are *shown in red*.
**To deactivate threat entity lists**
1. Run [DeleteThreatEntitySet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteThreatEntitySet.html). Make sure to provide the `detectorId` of the member account for which you want to delete this threat entity list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command:
```
aws guardduty delete-threat-entity-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--threat-entity-set-id d4b94fc952d6912b8f3060768example
```
Replace `detector-id` with the detector ID of the member account for which you will delete the threat entity list, and other placeholder values that are *shown in red*.
**To delete a trusted IP address list**
1. Run [DeleteIPSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteIPSet.html). Make sure to provide the `detectorId` of the member account for which you want to delete this trusted IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will delete the trusted IP address list.
```
aws guardduty delete-ip-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--ip-set-id d4b94fc952d6912b8f3060768example
```
Replace `detector-id` with the detector ID of the member account for which you will delete the threat entity list, and other placeholder values that are *shown in red*.
**To delete threat IP list**
1. Run [DeleteThreatIntelSet](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteThreatIntelSet.html). Make sure to provide the `detectorId` of the member account for which you want to delete this threat IP address list. To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Alternatively, you can do this by running the following AWS Command Line Interface command and make sure to replace the `detector-id` with the detector ID of the member account for which you will delete the threat IP list.
```
aws guardduty delete-threat-intel-set \
--detector-id 12abc34d567e8fa901bc2d34e56789f0 \
--threat-intel-set-id d4b94fc952d6912b8f3060768example
```
Replace `detector-id` with the detector ID of the member account for which you will delete the threat entity list, and other placeholder values that are *shown in red*.
------
# Exporting generated GuardDuty findings to Amazon S3 buckets
GuardDuty retains the generated findings for a period of 90 days. GuardDuty exports the active findings to Amazon EventBridge (EventBridge). You can optionally export the generated findings to an Amazon Simple Storage Service (Amazon S3) bucket. This will help you to track the historical data of potentially suspicious activities in your account and evaluate whether the recommended remediation steps were successful.
Any new active findings that GuardDuty generates are automatically exported within about 5 minutes after the finding is generated. You can set the frequency for how often updates to the active findings are exported to EventBridge. The frequency that you select applies to the exporting of new occurrences of existing findings to EventBridge, your S3 bucket (when configured), and Detective (when integrated). For information about how GuardDuty aggregates multiple occurrences of existing findings, see [GuardDuty finding aggregation](finding-aggregation.md).
When you configure settings to export findings to an Amazon S3 bucket, GuardDuty uses AWS Key Management Service (AWS KMS) to encrypt the findings data in your S3 bucket. This requires you to add permissions to your S3 bucket and the AWS KMS key so that GuardDuty can use them to export findings in your account.
**Topics**
+ [Considerations](#guardduty-export-findings-considerations)
+ [Step 1 – Permissions required to export findings](#guardduty_exportfindings-permissions)
+ [Step 2 – Attaching policy to your KMS key](#guardduty-exporting-findings-kms-policy)
+ [Step 3 – Attaching policy to Amazon S3 bucket](#guardduty_exportfindings-s3-policies)
+ [Step 4 - Exporting findings to an S3 bucket (Console)](#guardduty_exportfindings-new-bucket)
+ [Step 5 – Setting frequency to export updated active findings](#guardduty_exportfindings-frequency)
## Considerations
Before proceeding with the prerequisites and steps to export findings, consider the following key concepts:
+ **Export settings are regional** – You need to configure export options in each Region where you use GuardDuty.
+ **Exporting findings to Amazon S3 buckets in different AWS Regions (cross-Region)** – GuardDuty supports the following export settings:
+ Your Amazon S3 bucket or object, and AWS KMS key must belong to the same AWS Region.
+ For the findings generated in a commercial Region, you can choose to export these findings to an S3 bucket in any commercial Region. However, you can't export these findings to an S3 bucket in an opt-in Region.
+ For the findings generated in an opt-in Region, you can choose to export these findings to the same opt-in Region where they're generated or any commercial Region. However, you can't export findings from one opt-in Region to another opt-in Region.
+ **Permissions to export findings** – To configure settings for exporting active findings, your S3 bucket must have permissions that allows GuardDuty to upload objects. You must also have an AWS KMS key that GuardDuty can use to encrypt findings.
+ **Archived findings are not exported** – The default behavior is that the archived findings, including new instances of suppressed findings, are not exported.
When a GuardDuty finding gets generated as *Archived*, you will need to *Unarchive* it. This changes the **Filter finding status** to **Active**. GuardDuty exports the updates to the existing unarchived findings based on how you configure [Step 5 – Frequency for exporting findings](#guardduty_exportfindings-frequency).
+ **GuardDuty administrator account can export findings generated in associated member accounts** – When you configure export findings in an administrator account, all the findings from the associated member accounts that are generated in the same Region are also exported to the same location that you configured for the administrator account. For more information, see [Understanding the relationship between GuardDuty administrator account and member accounts](administrator_member_relationships.md).
## Step 1 – Permissions required to export findings
When you configure settings for exporting findings, you select an Amazon S3 bucket where you can store the findings and an AWS KMS key to use for data encryption. In addition to permissions for GuardDuty actions, you must also have permissions to the following actions to successfully configure settings to export findings:
+ `s3:GetBucketLocation`
+ `s3:PutObject`
If you need to export the findings to a specific prefix in your Amazon S3 bucket, you must also add the following permissions to the IAM role:
+ `s3:GetObject`
+ `s3:ListBucket`
## Step 2 – Attaching policy to your KMS key
GuardDuty encrypts the findings data in your bucket by using AWS Key Management Service. To successfully configure the settings, you must first give GuardDuty permission to use a KMS key. You can grant the permissions by [attaching the policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html) to your KMS key.
When you use a KMS key from another account, you need to apply the key policy by logging in to the AWS account that owns the key. When you configure the settings to export findings, you'll also need the key ARN from the account that owns the key.
**To modify the KMS key policy for GuardDuty to encrypt your exported findings**
1. Open the AWS KMS console at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms).
1. To change the AWS Region, use the Region selector in the upper-right corner of the page.
1. Select an existing KMS key or perform the steps to [Create a new key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*, that you will use to encrypt the exported findings.
**Note**
The AWS Region of your KMS key and the Amazon S3 bucket must be the same.
You can use the same S3 bucket and KMS key pair to export the findings from any applicable Region. For more information, see [Considerations](#guardduty-export-findings-considerations) for exporting findings across Regions.
1. In the **Key policy** section, choose **Edit**.
If **Switch to policy view** is displayed, choose it to display the **Key policy**, and then choose **Edit**.
1. Copy the following policy block to your KMS key policy, to grant GuardDuty permission to use your key.
```
{
"Sid": "AllowGuardDutyKey",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "kms:GenerateDataKey",
"Resource": "KMS key ARN",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012",
"aws:SourceArn": "arn:aws:guardduty:Region2:123456789012:detector/SourceDetectorID"
}
}
}
```
1. Edit the policy by replacing the following values that are formatted in **red** in the policy example:
1. Replace *KMS key ARN* with the Amazon Resource Name (ARN) of the KMS key. To locate the key ARN, see [Finding the key ID and ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html) in the *AWS Key Management Service Developer Guide*.
1. Replace *123456789012* with the AWS account ID that owns the GuardDuty account exporting the findings.
1. Replace *Region2* with the AWS Region where the GuardDuty findings are generated.
1. Replace *SourceDetectorID* with the `detectorID` of the GuardDuty account in the specific Region where the findings generated.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
**Note**
If you're using GuardDuty in an opt-in Region, replace the value for the "Service" with the Regional endpoint for that Region. For example, if you're using GuardDuty in the Middle East (Bahrain) (me-south-1) Region, replace `"Service": "guardduty.amazonaws.com"` with `"Service": "guardduty.me-south-1.amazonaws.com"`. For information about endpoints for each opt-in Region, see [GuardDuty endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/guardduty.html).
1. If you added the policy statement before the final statement, add a comma before adding this statement. Make sure that the JSON syntax of your KMS key policy is valid.
Choose **Save**.
1. (Optional) copy the key ARN to a notepad for use in the later steps.
## Step 3 – Attaching policy to Amazon S3 bucket
Add permissions to the Amazon S3 bucket to which you will export findings so that GuardDuty can upload objects to this S3 bucket. Independent of using an Amazon S3 bucket that belongs to either your account or in a different AWS account, you must add these permissions.
If at any point in time, you decide to export findings to a different S3 bucket, then to continue exporting findings, you must add permissions to that S3 bucket and configure the export findings settings again.
If you do not already have an Amazon S3 bucket where you want to export these findings, see [Creating a bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) in the *Amazon S3 User Guide*.
### To attach permissions to your S3 bucket policy
1. Perform the steps under [To create or edit a bucket policy](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html) in the *Amazon S3 User Guide*, until the **Edit bucket policy** page appears.
1. The **example policy** shows how grant GuardDuty permission to export findings to your Amazon S3 bucket. If you change the path after you configure export findings, then you must modify the policy to grant permission to the new location.
Copy the following **example policy** and paste it into the **Bucket policy editor**.
If you added the policy statement before the final statement, add a comma before adding this statement. Make sure that the JSON syntax of your KMS key policy is valid.
**S3 bucket example policy**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow GetBucketLocation",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:GetBucketLocation",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012",
"aws:SourceArn": "arn:aws:guardduty:us-east-2:123456789012:detector/SourceDetectorID"
}
}
},
{
"Sid": "Allow PutObject",
"Effect": "Allow",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket[optional prefix]/*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012",
"aws:SourceArn": "arn:aws:guardduty:us-east-2:123456789012:detector/SourceDetectorID"
}
}
},
{
"Sid": "Deny unencrypted object uploads",
"Effect": "Deny",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket[optional prefix]/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "aws:kms"
}
}
},
{
"Sid": "Deny incorrect encryption header",
"Effect": "Deny",
"Principal": {
"Service": "guardduty.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket[optional prefix]/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-2:111122223333:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
}
}
},
{
"Sid": "Deny non-HTTPS access",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket[optional prefix]/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}
```
------
1. Edit the policy by replacing the following values that are formatted in **red** in the policy example:
1. Replace *Amazon S3 bucket ARN* with the Amazon Resource Name (ARN) of the Amazon S3 bucket. You can find the **Bucket ARN** on the **Edit bucket policy** page in the [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) console.
1. Replace *123456789012* with the AWS account ID that owns the GuardDuty account exporting the findings.
1. Replace *us-east-2* with the AWS Region where the GuardDuty findings are generated.
1. Replace *SourceDetectorID* with the `detectorID` of the GuardDuty account in the specific Region where the findings generated.
To find the `detectorId` for your account and current Region, see the **Settings** page in the [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) console, or run the [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html) API.
1. Replace *[optional prefix]* part of the *S3 bucket ARN/[optional prefix]* placeholder value with an optional folder location to which you want to export the findings. For more information about the use of prefixes, see [Organizing objects using prefixes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-prefixes.html) in the *Amazon S3 User Guide*.
When you provide an optional folder location that doesn't exist already, GuardDuty will create that location only if the account associated with the S3 bucket is the same as the account exporting the findings. When you export findings to an S3 bucket that belongs to another account, the folder location must exist already.
1. Replace *KMS key ARN* with the Amazon Resource Name (ARN) of the KMS key associated with the encryption of the findings exported to the S3 bucket. To locate the key ARN, see [Finding the key ID and ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html) in the *AWS Key Management Service Developer Guide*.
**Note**
If you're using GuardDuty in an opt-in Region, replace the value for the "Service" with the Regional endpoint for that Region. For example, if you're using GuardDuty in the Middle East (Bahrain) (me-south-1) Region, replace `"Service": "guardduty.amazonaws.com"` with `"Service": "guardduty.me-south-1.amazonaws.com"`. For information about endpoints for each opt-in Region, see [GuardDuty endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/guardduty.html).
1. Choose **Save**.
## Step 4 - Exporting findings to an S3 bucket (Console)
GuardDuty permits you to export findings to an existing bucket in another AWS account.
When creating a new S3 bucket or choosing an existing bucket in your account, you can add an optional prefix. When configuring export findings, GuardDuty creates a new folder in the S3 bucket for your findings. The prefix will be appended to the default folder structure that GuardDuty created. For example, the format of the optional prefix `/AWSLogs/123456789012/GuardDuty/Region`.
The entire path of the S3 object will be `amzn-s3-demo-bucket/prefix-name/UUID.jsonl.gz`. The `UUID` is randomly generated and doesn't represent the detector ID or the finding ID.
**Important**
The KMS key and S3 bucket must be in the same Region.
Before completing these steps, make sure you have attached the respective policies to your KMS key and existing S3 bucket.
**To configure export findings**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. In the navigation pane, choose **Settings**.
1. On the **Settings** page, under **Findings export options**, for **S3 bucket**, choose **Configure now** (or **Edit**, as needed).
1. For **S3 bucket ARN**, enter the ****bucket ARN****. To find the bucket ARN, see [Viewing the properties for an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/view-bucket-properties.html) in the *Amazon S3 User Guide*.
1. For **KMS key ARN**, enter the ****key ARN****. To locate the key ARN, see [Finding the key ID and ARN](https://docs.aws.amazon.com/kms/latest/developerguide/find-cmk-id-arn.html) in the *AWS Key Management Service Developer Guide*.
1.
**Attach policies**
+ Perform the steps to attach the S3 bucket policy. For more information, see [Step 3 – Attaching policy to Amazon S3 bucket](#guardduty_exportfindings-s3-policies).
+ Perform the steps to attach the KMS key policy. For more information, see [Step 2 – Attaching policy to your KMS key](#guardduty-exporting-findings-kms-policy).
1. Choose **Save**.
## Step 5 – Setting frequency to export updated active findings
Configure the frequency for exporting updated active findings as appropriate for your environment. By default, updated findings are exported every 6 hours. This means that any findings that are updated after the most recent export are included in the next export. If updated findings are exported every 6 hours and the export occurs at 12:00, any finding that you update after 12:00 is exported at 18:00.
**To set the frequency**
1. Open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Choose **Settings**.
1. In the **Findings export options** section, choose **Frequency for updated findings**. This sets the frequency for exporting updated Active findings to both EventBridge and Amazon S3. You can choose from the following:
+ **Update EventBridge and S3 every 15 minutes**
+ **Update EventBridge and S3 every 1 hour**
+ **Update EventBridge and S3 every 6 hours (default)**
1. Choose **Save changes**.
# Processing GuardDuty findings with Amazon EventBridge
GuardDuty automatically publishes (sends) findings as events to Amazon EventBridge (formerly Amazon CloudWatch Events), a serverless event bus service. EventBridge delivers a stream of near real-time data from applications and services to targets such as Amazon Simple Notification Service (Amazon SNS) topics, AWS Lambda functions, and Amazon Kinesis streams. For more information, see [Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html).
EventBridge enables automated monitoring and processing of GuardDuty findings by receiving [events](https://docs.aws.amazon.com/eventbridge/latest/userguide/aws-events.html). EventBridge receives events for both newly generated findings and aggregated findings, where subsequent occurrences of an existing finding are combined with the original. Every GuardDuty finding is assigned a finding ID, and GuardDuty creates an EventBridge event for every finding with a unique finding ID. For information on how aggregation works in GuardDuty, see [GuardDuty finding aggregation](finding-aggregation.md).
In addition to automated monitoring and processing, use of EventBridge enables longer-term retention of your findings data. GuardDuty stores findings for 90 days. With EventBridge, you can send findings data to your preferred storage platform and store the data for as long as you like. To retain findings for a longer duration, GuardDuty supports [Exporting generated findings to Amazon S3](guardduty_exportfindings.md).
**Topics**
+ [EventBridge notification frequency in GuardDuty](#eventbridge-freq-notifications-gdu)
+ [Set up an Amazon SNS topic and endpoint](#guardduty-eventbridge-set-up-sns-and-endpoint)
+ [Using EventBridge with GuardDuty](#eventbridge_events)
+ [Creating an EventBridge rule](#guardduty_eventbridge_severity_notification)
+ [EventBridge rule for multi-account environments](#guardduty_findings_eventbridge_multiaccount)
## Understanding EventBridge notification frequency in GuardDuty
This section explains how often you receive finding notifications through EventBridge and how to update the frequency for subsequent finding occurrences.
**Notifications for newly generated findings with a unique finding ID**
GuardDuty sends these notifications in near real-time when it generates a finding with a unique finding ID. The notification includes all subsequent occurrences of this subsequent occurrences of this finding ID during the notification generation process.
The notification frequency for newly generated findings is in near real-time. By default, you can not modify this frequency.
**Notifications for subsequent finding occurrences**
GuardDuty aggregates all subsequent occurrences of a particular finding type that take place within the 6-hour intervals into one single event. Only an administrator account can update the EventBridge notification frequency for subsequent finding occurrences. A member account can't update this frequency for their own account. For example, if the delegated GuardDuty administrator account updates the frequency to one hour, all member accounts will also have one hour notification frequency about the subsequent finding occurrences sent to EventBridge. For more information, see [Multiple accounts in Amazon GuardDuty](guardduty_accounts.md).
As an administrator account, you can customize the default frequency of notifications about the subsequent finding occurrences. Possible values are 15 minutes, 1 hour, or the default 6 hours. For information about setting the frequency for these notifications, see [Step 5 – Setting frequency to export updated active findings](guardduty_exportfindings.md#guardduty_exportfindings-frequency).
For more details about administrator account receiving EventBridge notifications for member accounts, see [EventBridge rule for multi-account environments](#guardduty_findings_eventbridge_multiaccount).
## Set up an Amazon SNS topic and endpoint (Email, Slack, and Amazon Chime)
Amazon Simple Notification Service (Amazon SNS) is a fully managed service that provides message delivery from publishers to subscribers. Publishers communicate asynchronously with subscribers by sending messages to a *topic*. A topic is a logical access point and communication channel that lets you group multiple endpoints such as AWS Lambda, Amazon Simple Queue Service (Amazon SQS), HTTP/S, and an email address.
**Note**
You can add an Amazon SNS topic to your preferred EventBridge event rule during or after the creation of the rule.
**Create an Amazon SNS topic**
To begin, you must first set up a topic in Amazon SNS and add an endpoint. To create a topic, perform the steps in [Step 1: Creating a topic](https://docs.aws.amazon.com/sns/latest/dg/sns-create-topic.html) in the *Amazon Simple Notification Service Developer Guide*. After the topic gets created, copy the topic ARN to the clipboard. You will use this topic ARN to continue with one of the preferred setups.
Choose a preferred method to establish where you want to send GuardDuty finding data.
------
#### [ Email setup ]
**To set up an email endpoint**
After you [Create an Amazon SNS topic](#guardduty-set-up-sns-topic-eventbridge), the next step is to create a subscription to this topic. Perform the steps under [Step 2: Creating a subscription to an Amazon SNS topic](https://docs.aws.amazon.com/sns/latest/dg/sns-create-subscribe-endpoint-to-topic.html) in the *Amazon Simple Notification Service Developer Guide*.
1. For **Topic ARN**, use the topic ARN created in the [Create an Amazon SNS topic](#guardduty-set-up-sns-topic-eventbridge) step. The topic ARN looks similar to the following:
```
arn:aws:sns:us-east-2:123456789012:your_topic
```
1. For **Protocol**, select **Email**.
1. For **Endpoint**, enter an email address where you want to receive the notifications from Amazon SNS.
After the subscription gets created, you will need to confirm it through your email client.
------
#### [ Slack setup ]
**To configure an Amazon Q Developer in chat applications client - Slack**
After you [Create an Amazon SNS topic](#guardduty-set-up-sns-topic-eventbridge), the next step is to configure the client for Slack.
Perform the steps under [Tutorial: Get started with Slack](https://docs.aws.amazon.com/chatbot/latest/adminguide/slack-setup.html) in the *Amazon Q Developer in chat applications Administrator Guide*.
------
#### [ Chime setup ]
**To configure an Amazon Q Developer in chat applications client - Chime**
After you [Create an Amazon SNS topic](#guardduty-set-up-sns-topic-eventbridge), the next step is to configure Amazon Q Developer for Chime.
Perform the steps under [Tutorial: Get started with Amazon Chime](https://docs.aws.amazon.com/chatbot/latest/adminguide/chime-setup.html.html) in the *Amazon Q Developer in chat applications Administrator Guide*.
------
## Using Amazon EventBridge for GuardDuty findings
With EventBridge, you create rules to specify the events that you want to monitor. These rules also specify the target services and applications that can perform automated actions if these events occur. A [target](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-targets.html) is a destination (a resource or an endpoint) that EventBridge sends an event to when the event matches the event pattern defined in the rule. Each event is a JSON object that conforms to the EventBridge schema for AWS events and contains a JSON representation of a finding. You can tailor the rule to send only those events that meet a certain criteria. For more information, see [JSON Schema topic]. Because the findings data is structured as an [EventBridge event](https://docs.aws.amazon.com/eventbridge/latest/userguide/eventbridge-and-event-patterns.html), you can monitor, process, and act upon findings by using other applications, services, and tools.
In order to receive notifications about GuardDuty findings based on events, you must create an EventBridge rule and a target for GuardDuty. This rule enables EventBridge to send notifications for findings that GuardDuty generates to the target that is specified in the rule.
**Note**
EventBridge and CloudWatch Events are the same underlying service and API. However, EventBridge includes additional features that help you receive events from software as a service (SaaS) applications and your own applications. Because the underlying service and API are the same, the event schema for GuardDuty findings is also the same.
**How archived and non-archived findings in GuardDuty work with EventBridge**
For findings that you manually archive, the initial and all subsequent occurrences of these findings (generated after the archiving is complete) are sent to EventBridge based on a specific notification frequency. For more information, see [Understanding EventBridge notification frequency in GuardDuty](#eventbridge-freq-notifications-gdu).
For the findings that are automatically archived with [Suppression rules](findings_suppression-rule.md), the initial and all subsequent occurrences of these findings (generated after the archiving is complete) are *not* sent to EventBridge. You can view these automatically archived findings in the GuardDuty console.
### Event schema
An [event pattern](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-patterns.html) defines the data EventBridge uses to determine whether to send the event to the target. The EventBridge event for GuardDuty has the following format:
```
{
"version": "0",
"id": "cd2d702e-ab31-411b-9344-793ce56b1bc7",
"detail-type": "GuardDuty Finding",
"source": "aws.guardduty",
"account": "111122223333",
"time": "1970-01-01T00:00:00Z",
"region": "us-east-1",
"resources": [],
"detail": {GUARDDUTY_FINDING_JSON_OBJECT}
}
```
The `detail` value returns the JSON details of a single finding as an object, as opposed to returning the entire *findings* response syntax which supports multiple findings within an array.
For a complete list of all the parameters included in `GUARDDUTY_FINDING_JSON_OBJECT`, see [GetFindings](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetFindings.html#API_GetFindings_ResponseSyntax). The `id` parameter that appears in `GUARDDUTY_FINDING_JSON_OBJECT` is the finding ID previously described.
## Creating an EventBridge rule for GuardDuty findings
The following procedures explain how to use the Amazon EventBridge console and the [AWS Command Line Interface (AWS CLI)](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) to create an EventBridge rule for GuardDuty findings. The rule detects EventBridge events that use the event schema and pattern for GuardDuty findings, and it sends those events to an AWS Lambda function for processing.
AWS Lambda is a compute service that you can use to run code without provisioning or managing servers. You package your code and upload it to AWS Lambda as a *Lambda function*. AWS Lambda then runs the function when the function is invoked. A function can be invoked manually by you, automatically in response to events, or in response to requests from applications or services. For information about creating and invoking Lambda functions, see the [AWS Lambda Developer Guide](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html).
Choose your preferred method to create an EventBridge rule that sends your GuardDuty finding to a target.
------
#### [ Console ]
Follow these steps to use the Amazon EventBridge console to create a rule that automatically sends all GuardDuty finding events to a Lambda function for processing. The rule uses default settings for rules that run when specific events are received. For details about rule settings or to learn how to create a rule that uses custom settings, see [Creating rules that react to events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) in the *Amazon EventBridge User Guide*.
Before you create this rule, create the Lambda function that you want the rule to use as a target. When you create the rule, you'll need to specify this function as the target for the rule. Your target can also be the SNS topic that you created earlier. For more information, see [Set up an Amazon SNS topic and endpoint (Email, Slack, and Amazon Chime)](#guardduty-eventbridge-set-up-sns-and-endpoint).
**To create an event rule by using console**
1. Sign in to the AWS Management Console and open the Amazon EventBridge console at [https://console.aws.amazon.com/events/](https://console.aws.amazon.com/events/).
1. In the navigation pane, under **Buses**, choose **Rules**.
1. In the **Rules** section, choose **Create rule**.
1. On the **Define rule detail** page, do the following:
1. For **Name**, enter a name for the rule.
1. (Optional) For **Description**, enter a brief description of the rule.
1. For **Event bus**, ensure that **default** is selected and **Enable the rule on the selected event bus** is turned on.
1. For **Rule type**, choose **Rule with an event pattern**.
1. When you finish, choose **Next**.
1. On the **Build event pattern** page, do the following:
1. For **Event source**, choose **AWS events or EventBridge partner events**.
1. (Optional) For **Sample event**, review a sample finding event for GuardDuty to learn what an event might contain. To do this, choose **AWS events**. Then, for **Sample events**, choose **GuardDuty Finding**.
1.
**Option 1 - Using pattern form, a template that EventBridge provides**
In the **Event pattern** section, you can do the following:
1. For **Creation method**, select **Use pattern form**.
1. For **Event source**, choose **AWS services**.
1. For **AWS service**, choose **GuardDuty**.
1. For **Event type**, choose **GuardDuty Finding**.
When you finish, choose **Next**.
1.
**Option 2 - Using custom event pattern in JSON**
In the **Event pattern** section, you can do the following:
1. For **Creation method**, select **Custom pattern (JSON editor)**.
1. For **Event pattern**, paste the following custom JSON that will create an alert for medium, high, and critical findings. For more information, see [Findings severity levels](guardduty_findings-severity.md).
```
{
"source": [
"aws.guardduty"
],
"detail-type": [
"GuardDuty Finding"
],
"detail": {
"severity": [
4,
4.0,
4.1,
4.2,
4.3,
4.4,
4.5,
4.6,
4.7,
4.8,
4.9,
5,
5.0,
5.1,
5.2,
5.3,
5.4,
5.5,
5.6,
5.7,
5.8,
5.9,
6,
6.0,
6.1,
6.2,
6.3,
6.4,
6.5,
6.6,
6.7,
6.8,
6.9,
7,
7.0,
7.1,
7.2,
7.3,
7.4,
7.5,
7.6,
7.7,
7.8,
7.9,
8,
8.0,
8.1,
8.2,
8.3,
8.4,
8.5,
8.6,
8.7,
8.8,
8.9,
9,
9.0,
9.1,
9.2,
9.3,
9.4,
9.5,
9.6,
9.7,
9.8,
9.9,
10,
10.0
]
}
}
```
When you finish, choose **Next**.
1.
**Option A - Selecting AWS service - AWS Lambda as target**
On the **Select target(s)** page, do the following:
1. For **Target types**, select **AWS service**.
1. For **Select a target**, choose **Lambda function**. Then, for **Function**, choose the Lambda function that you want to send finding events to.
1. For **Configure version/alias**, enter version or alias settings for the target Lambda function.
1. (Optional) For **Additional settings**, enter custom settings to specify which event data you want to send to the Lambda function. You can also specify how to handle events that aren't delivered to the function successfully.
1. When you finish, choose **Next**.
1.
**Option B - Selecting SNS topic as target**
On the **Select target(s)** page, do the following:
1. For **Target types**, select **AWS service**.
1. For **Select a target**, choose **SNS topic**. Then, for **Target location**, select the suitable option based on your target location. For **Topic**, choose the name of the SNS topic that you created.
1. Expand **Additional settings**. For **Configure target input**, choose **Input transformer**.
1. Choose **Configure input transformer**.
1. Copy the following code and paste it in the **Input Path** field under the **Target input transformer** section.
```
{
"severity": "$.detail.severity",
"Account_ID": "$.detail.accountId",
"Finding_ID": "$.detail.id",
"Finding_Type": "$.detail.type",
"region": "$.region",
"Finding_description": "$.detail.description"
}
```
1. Copy the following code and paste it into the **Template** field to format the email.
```
"You have a severity GuardDuty finding type in the Region."
"Finding Description:"
". "
"For more details open the GuardDuty console at https://console.aws.amazon.com/guardduty/home?region=#/findings?search=id%3D"
```
1. On the **Configure tags** page, optionally enter one or more tags to assign to the rule. Then choose **Next**.
1. On the **Review and create** page, review the rule’s settings and verify that they're correct.
To change a setting, choose **Edit** in the section that contains the setting, and then enter the correct setting. You can also use the navigation tabs to go to the page that contains a setting.
1. When you finish verifying the settings, choose **Create rule**.
------
#### [ API ]
The following procedure shows how to use AWS CLI commands to create a EventBridge rule and target for GuardDuty. Specifically, the procedure shows you how to create a rule that enables EventBridge to send events for all findings that GuardDuty generates to an AWS Lambda function as a target for the rule.
**Note**
In this example, we're using a Lambda function as the target for the rule that triggers EventBridge. You can also configure other AWS resources as targets to trigger EventBridge. GuardDuty and EventBridge support the following target types - Amazon EC2 instances, Amazon Kinesis streams, Amazon ECS tasks, AWS Step Functions state machines, the `run` command, and built-in targets. For more information, see [PutTargets](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html) in the *Amazon EventBridge API Reference*.
**To create a rule and target**
1. To create a rule that enables EventBridge to send events for all findings that GuardDuty generates, run the following EventBridge CLI command.
```
aws events put-rule --name your-rule-name --event-pattern "{\"source\":[\"aws.guardduty\"]}"
```
You can further customize your rule so that it instructs EventBridge to send events only for a subset of the GuardDuty-generated findings. This subset is based on the finding attribute or attributes that are specified in the rule. For example, use the following CLI command to create a rule that enables EventBridge to only send events for the GuardDuty findings with the severity of either 5 or 8:
```
aws events put-rule --name your-rule-name --event-pattern "{\"source\":[\"aws.guardduty\"],\"detail-type\":[\"GuardDuty Finding\"],\"detail\":{\"severity\":[5,8]}}"
```
For this purpose, you can use any of the property values that are available in the JSON for GuardDuty findings.
1. To attach a Lambda function as a target for the rule that you created in step 1, run the following CloudWatch CLI command.
```
aws events put-targets --rule your-target-name --targets Id=1,Arn=arn:aws:lambda:us-east-1:111122223333:function:your_function
```
Make sure to replace `your-target-name` in the command above with your actual Lambda function for the GuardDuty events.
1. To add the permissions required to invoke the target, run the following Lambda CLI command.
```
aws lambda add-permission --function-name your-target-name --statement-id 1 --action 'lambda:InvokeFunction' --principal events.amazonaws.com
```
Make sure to replace `your_function` in the command above with your actual Lambda function for the GuardDuty events.
------
## EventBridge rule for GuardDuty multi-account environments
When using a delegated GuardDuty administrator account, you can view the events generated in the member accounts and take action using other applications and services. EventBridge rules in your administrator account will trigger based on applicable findings from your member accounts. If you set up finding notifications through EventBridge in your administrator account, you will receive notifications of findings from both your account and member accounts. For example, you can use EventBridge to send specific types of findings to a Lambda function that processes and sends the data to your security incident and event management (SIEM) system.
You can identify the member account where the GuardDuty finding originated using the `accountId` field of the finding's JSON details. To create a custom event rule for specific member accounts, create a new rule and use the following template in **Event pattern**. Replace *123456789012* with the `accountId`of the member account for which you want to trigger the event.
```
{
"source": [
"aws.guardduty"
],
"detail-type": [
"GuardDuty Finding"
],
"detail": {
"accountId": [
"123456789012"
]
}
}
```
**Note**
This example creates a rule that matches all findings from the specified account ID. You can include multiple account IDs by separating them with commas, following JSON syntax.
# Understanding CloudWatch Logs and reasons for skipping resources during Malware Protection for EC2 scan
GuardDuty Malware Protection for EC2 publishes events to your Amazon CloudWatch log group **/aws/guardduty/malware-scan-events**. For each of the events related to the malware scan, you can monitor the status and scan result of your impacted resources. Certain Amazon EC2 resources and Amazon EBS volumes may have been skipped during the Malware Protection for EC2 scan.
## Auditing CloudWatch Logs in GuardDuty Malware Protection for EC2
There are three types of scan events supported in the **/aws/guardduty/malware-scan-events** CloudWatch log group.
| Malware Protection for EC2 scan event name | Explanation |
| --- | --- |
| `EC2_SCAN_STARTED` | Created when an GuardDuty Malware Protection for EC2 is initiating the process of malware scan, such as preparing to take a snapshot of an EBS volume. |
| `EC2_SCAN_COMPLETED` | Created when GuardDuty Malware Protection for EC2 scan completes for at least one of the EBS volumes of the impacted resource. This event also includes the `snapshotId` that belongs to the scanned EBS volume. After the scan completes, the scan result will either be `CLEAN`, `THREATS_FOUND`, or `NOT_SCANNED`. |
| `EC2_SCAN_SKIPPED` | Created when GuardDuty Malware Protection for EC2 scan skips all the EBS volumes of the impacted resource. To identify the skip reason, select the corresponding event, and view the details. For more information on skip reasons, see [Reasons for skipping resource during malware scan](#mp-scan-skip-reasons) below. |
**Note**
If you're using an AWS Organizations, CloudWatch log events from member accounts in Organizations get published to both administrator account and member account's log group.
Choose your preferred access method to view and query CloudWatch events.
------
#### [ Console ]
1. Sign in to the AWS Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. In the navigation pane, under **Logs**, choose **Log groups**. Choose the **/aws/guardduty/malware-scan-events** log group to view the scan events for GuardDuty Malware Protection for EC2.
To run a query, choose **Log Insights**.
For information about running a query, see [Analyzing log data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) in the *Amazon CloudWatch User Guide*.
1. Choose **Scan ID** to monitor the details of the impacted resource and malware findings. For example, you can run the following query to filter the CloudWatch log events by using `scanId`. Make sure to use your own valid *scan-id*.
```
fields @timestamp, @message, scanRequestDetails.scanId as scanId
| filter scanId like "77a6f6115da4bd95f4e4ca398492bcc0"
| sort @timestamp asc
```
------
#### [ API/CLI ]
+ To work with log groups, see [Search log entries using the AWS CLI](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SearchDataFilterPattern.html#search-log-entries-cli) in the *Amazon CloudWatch User Guide*.
Choose the **/aws/guardduty/malware-scan-events** log group to view the scan events for GuardDuty Malware Protection for EC2.
+ To view and filter log events, see [https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogEvents.html](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_GetLogEvents.html) and [https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FilterLogEvents.html](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_FilterLogEvents.html), respectively, in the *Amazon CloudWatch API Reference*.
------
## GuardDuty Malware Protection for EC2 log retention
The default log retention period for **/aws/guardduty/malware-scan-events** log group is 90 days, after which the log events are deleted automatically. To change the log retention policy for your CloudWatch log group, see [ Change log data retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) in the *Amazon CloudWatch User Guide*, or [https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutRetentionPolicy.html](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutRetentionPolicy.html) in the *Amazon CloudWatch API Reference*.
## Reasons for skipping resource during malware scan
In the events related to the malware scan, certain EC2 resources and EBS volumes may have been skipped during the scanning process. The following table lists the reasons why GuardDuty Malware Protection for EC2 may not scan the resources. If applicable, use the proposed steps to resolve these issues, and scan these resources the next time GuardDuty Malware Protection for EC2 initiates a malware scan. The other issues are used to inform you about the course of events and are non-actionable.
| Reasons for skipping | Explanation | Proposed steps |
| --- | --- | --- |
| `RESOURCE_NOT_FOUND` | The `resourceArn` provided to the initiate the on-demand malware scan was not found in your AWS environment. | Validate the `resourceArn` of your Amazon EC2 instance or container workload, and try again. |
| `ACCOUNT_INELIGIBLE` | The AWS account ID from which you tried initiating an On-demand malware scan has not enabled GuardDuty. | Verify that GuardDuty is enabled for this AWS account. When you enable GuardDuty in a new AWS Region it may take up to 20 minutes to sync. |
| `UNSUPPORTED_KEY_ENCRYPTION` | GuardDuty Malware Protection for EC2 supports volumes that are both unencrypted and encrypted with customer managed key. It doesn't support scanning EBS volumes that are encrypted using [Amazon EBS encryption](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/EBSEncryption.html). Presently, there is a regional difference where this skip reason is not applicable. For more information about these AWS Regions, see [Region-specific feature availability](guardduty_regions.md#gd-regional-feature-availability). | Replace your encryption key with a customer managed key. For more information on the types of encryption that GuardDuty supports, see [Supported Amazon EBS volumes for malware scan](gdu-malpro-supported-volumes.md). |
| `EXCLUDED_BY_SCAN_SETTINGS` | The EC2 instance or EBS volume was excluded during the malware scan. There are two possibilities - either the tag was added to the inclusion list but the resource isn't associated with this tag, the tag was added to the exclusion list and the resource is associated with this tag, or the `GuardDutyExcluded` tag is set to `true` for this resource. | Update your scan options or the tags associated to your Amazon EC2 resource. For more information, see [Scan options with user-defined tags](malware-protection-customizations.md#mp-scan-options). |
| `UNSUPPORTED_VOLUME_SIZE` | The volume is greater than 2048 GB. | Not actionable. |
| `NO_VOLUMES_ATTACHED` | GuardDuty Malware Protection for EC2 found the instance in your account but no EBS volume was attached to this instance to proceed with the scan. | Not actionable. |
| `UNABLE_TO_SCAN` | It is an internal service error. | Not actionable. |
| `SNAPSHOT_NOT_FOUND` | The snapshots created from the EBS volumes and shared with the service account was not found, and GuardDuty Malware Protection for EC2 couldn't proceed with the scan. | Check CloudTrail to ensure that the snapshots were not removed intentionally. |
| `SNAPSHOT_QUOTA_REACHED` | You have reached the maximum volume allowed for snapshots for each Region. This prevents not just retaining but also creating new snapshots. | You can either remove old snapshots or request for quota increase. You can view the default limit for Snapshots per Region and how to request quota increase under [Service quotas](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html#limits_ebs) in the *AWS General Reference Guide*. |
| `MAX_NUMBER_OF_ATTACHED_VOLUMES_REACHED` | More than 11 EBS volumes were attached to an EC2 instance. GuardDuty Malware Protection for EC2 scanned the first 11 EBS volumes, obtained by sorting the `deviceName` alphabetically. | Not actionable. |
| `UNSUPPORTED_PRODUCT_CODE_TYPE` | GuardDuty can scan majority of instances with `productCode` as `marketplace`. Some marketplace instances may not be eligible for scanning. GuardDuty will skip such instances and log the reason as `UNSUPPORTED_PRODUCT_CODE_TYPE`. This support varies in AWS GovCloud (US) and China Regions. For more information, see [Region-specific feature availability](guardduty_regions.md#gd-regional-feature-availability). For more information, see [Paid AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/paid-amis.html) in the *Amazon EC2 User Guide*. For information on `productCode`, see [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ProductCode.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ProductCode.html) in the *Amazon EC2 API Reference*. | Not actionable. |
# Reporting false positives in Malware Protection for EC2
GuardDuty Malware Protection for EC2 scans may identify a harmless file in your Amazon EC2 instance or container workload as being malicious or harmful. To improve your experience with Malware Protection for EC2 and the GuardDuty service, you can report false positive results if you believe that a file identified as being malicious or harmful during a scan doesn't actually contain malware.
**To report an Amazon EC2 malware scan result as false positive**
To initiate the process, contact Support. Use the following steps to provide details about the scanned resource:
1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Choose **EC2 malware Scans**.
1. Choose a scan to view its **Finding ID**.
1. Provide the **Finding ID**. You must also provide the SHA-256 hash of the file. This is required to ensure that GuardDuty Malware Protection for EC2 has received the correct file.
1. The Support team will provide you an Amazon Simple Storage Service (Amazon S3) presigned URL that you can use to upload the potentially malicious file and SHA-256 hash. For information about steps to upload the scanned object, see [Uploading objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html) in the *Amazon S3 User Guide*.
1. After you have uploaded the file, inform the Support team.
The Support will provide an acknowledgment after receiving the file. The GuardDuty service team members will analyze your submission, and take appropriate steps to improve your experience with Malware Protection for EC2 and the GuardDuty service. The Support team will continue to provide status update on your case. GuardDuty keeps your S3 object for no more than 30 days.
# Reporting S3 object scan result as false positive in Malware Protection for S3
A Malware Protection for S3 scan may identify an object as potentially malicious or harmful. If you believe that the indicated S3 object doesn't contain malware, report this malware scan result as a false positive.
You can submit a false positive report even when you use Malware Protection for S3 independently. In this case, GuardDuty is not designed to generate a finding. For information about checking scan status and result status, see [Monitoring S3 object scans](monitoring-malware-protection-s3-scans-gdu.md).
**To report an S3 object malware scan result as false positive**
To initiate the process, contact Support. Use the following steps to provide details about the scanned S3 object:
1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Depending on your use case, choose the appropriate steps:
------
#### [ Using Malware Protection for S3 with GuardDuty ]
1. In the navigation pane, choose **Findings**.
1. On the **Findings** page, select the false positive finding to view its details.
1. By checking the finding details, provide the **Finding ID**, **Region**, protected S3 bucket **Name**, and the scanned object **Key**.
From the **Item path** details, provide the **Hash** of the object. This is required to ensure that GuardDuty has received the correct file.
------
#### [ Using Malware Protection for S3 independently ]
Provide the protected S3 bucket name, scanned object name, and the AWS Region.
------
1. The Support team will provide you an Amazon Simple Storage Service (Amazon S3) presigned URL that you can use to upload the potentially malicious file and hash. For information about steps to upload the scanned object, see [Uploading objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html) in the *Amazon S3 User Guide*.
1. After uploading the S3 object, inform the Support team.
The Support will provide an acknowledgment of receiving the object. The GuardDuty service team members will analyze your submission, and take appropriate steps to improve your experience with Malware Protection for S3 and the GuardDuty service. The Support team will continue to provide status update on your case. GuardDuty keeps your S3 object for no more than 30 days.
# Reporting false positives in Malware Protection for Backup
To improve your experience with GuardDuty Malware Protection for Backup, you may report potential false positives and false negatives.
****To report a potential false positive or false negative identified in Malware Protection for Backup****
To initiate the process, contact Support. Use the following steps to provide details about the scanned resource:
1. Sign in to the AWS Management Console and open the GuardDuty console at [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Choose **Malware Scans**.
1. Choose a scan to view its **Finding ID**.
1. Provide the **Finding ID**. You must also provide the SHA-256 hash of the file. This is required to ensure that GuardDuty has received the correct file. Please also provide the region you will provide the sample from.
1. The Support team will provide you an Amazon Simple Storage Service (Amazon S3) presigned URL that you will use to upload the potentially malicious file and SHA-256 hash. For information about steps to upload the scanned resource, see [Uploading objects with presigned URLs](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html) in the *Amazon S3 User Guide*.
1. After you have uploaded the file, inform the Support team.
The Support will provide an acknowledgment after receiving the file. The GuardDuty service team members will analyze your submission, and take appropriate steps to improve your experience with Malware Protection for EC2. The Support team will continue to provide status updates on your case. GuardDuty keeps your S3 object for no more than 30 days.