Common use cases for suppression rules and examples To create suppression rules in GuardDuty

Suppression rules

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. Your suppression rules can be edited at any time.

Suppressed findings are not sent to AWS Security Hub, Amazon Simple Storage Service, Amazon Detective, or Amazon EventBridge, reducing finding noise level if you consume GuardDuty findings via Security Hub, a third-party SIEM, or other alerting and ticketing applications. If you've enabled GuardDuty Malware Protection, 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 ListFindings 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.

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, or review the info to build a suppression rule for that finding type from the console.

Important

GuardDuty recommends that you build suppression rules reactively and only for findings you have repeatedly identified false positives for.

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS – 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, or VPC VPN connections, can result in traffic routed this way. If this is expected behavior, it's recommended that you use suppression rules in and create a rule that consists of two filter criteria. The first criteria is finding type, which should be UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration. 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 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 – 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 – 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 – 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 EKS Runtime Monitoring findings

PrivilegeEscalation: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:
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.

To create suppression rules in GuardDuty

Choose your preferred access method to create or manage suppression rules in GuardDuty.

Console

You can visualize, create, and manage suppression rules using the GuardDuty console. Suppression rules are generated in the same manner as filters, and your existing saved filters can be used as suppression rules. For more information about creating filters, see Filtering findings.

To create a suppression rule using the console:

Open the GuardDuty console at https://console.aws.amazon.com/guardduty/.
On the Findings page, choose Suppress findings to open the suppression rule panel.
To open the filter criteria menu, enter the filter criteria in the Add filter criteria. You can choose a criterion from the list. Enter a valid value for the chosen criterion.

Note
To determine the valid value, view the findings table and choose a finding that you want to suppress. Review it's details in the findings panel.

You can add multiple filter criteria and ensure that only those findings appear in the table that you want to suppress.
Enter a Name and Description for the suppression rule. Valid characters include alphanumeric characters, period (.), dash (-), underscore (_), and whitespaces.
Choose Save.

You can also create a suppression rule from an existing saved filter. For more information about creating filters, see Filtering findings.

To create a suppression rule from a saved filter:

Open the GuardDuty console at https://console.aws.amazon.com/guardduty/.
On the Findings page, choose Suppress Findings to open the suppression rule panel.
From the Saved rules drop down, choose a saved filter.
You can also add new filter criteria. If you don't need additional filter criteria, skip this step.

To open the filter criteria menu, enter the filter criteria in the Add filter criteria. You can choose a criterion from the list. Enter a valid value for the chosen criterion.

Note
To determine the valid value, view the findings table and choose a finding that you want to suppress. Review it's details in the findings panel.
Enter a Name and Description for the suppression rule. Valid characters include alphanumeric characters, period (.), dash (-), underscore (_), and whitespaces.
Choose Save.

To delete a suppression rule:

Open the GuardDuty console at https://console.aws.amazon.com/guardduty/.
On the Findings page, choose Suppress Findings to open the suppression rule panel.
From the Saved rules drop down, choose a saved filter.
Choose Delete rule.

API/CLI

To create a suppression rule using API:

You can create suppression rules through the CreateFilter 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"]. You can also filter on the basis of any one value in the list.
```
{
    "Criterion": {
        "service.archived": {
            "Eq": [
                "false"
            ]
        },
        "service.action.dnsRequestAction.domain": {
            "Eq": [
                "test.example.com"
            ]
        },
        "severity": {
            "Eq": [
                "1",
                "2",
                "3"
            ]
        }
    }
}
```
For a list of JSON field names and their console equivalent see Filter attributes.

To test your filter criteria, use the same JSON criterion in the ListFindings 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.

You can find your own detectorId for your current Region on the Settings page in the https://console.aws.amazon.com/guardduty/ console.
```
aws guardduty list-findings --detector-id 12abc34d567e8fa901bc2d34e56789f0 --finding-criteria file://criteria.json
```
Upload your filter to be used as suppression rule with the CreateFilter 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.

You can find your own detectorId for your current Region on the Settings page in the https://console.aws.amazon.com/guardduty/ console.
```
aws guardduty create-filter --action ARCHIVE --detector-id 12abc34d567e8fa901bc2d34e56789f0 --name yourfiltername --finding-criteria file://criteria.json
                
```

You can view a list of your filters programmatically with the ListFilter API. You can view the details of an individual filter by supplying the filter name to the GetFilter API. Update filters using UpdateFilter or delete them with the DeleteFilter API.

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Filtering findings

Trusted IP and threat lists