Migrate from static to dynamic mute rules

This page explains how to migrate your existing static mute rules to dynamic mute rules.

We recommend using dynamic mute rules exclusively in your mute rule configurations because they are more flexible than static mute rules. Compared to static mute rules, dynamic mute rules have three key benefits:

  • Dynamic mute rules apply to existing and new findings. Dynamic mute rules automatically mute both existing and new or updated findings that match your filter criteria.
  • Dynamic mute rules offer an expiration option. Dynamic mute rules also allow you to set a custom expiration period to temporarily match specific findings. If no expiration period is set, dynamic mute rules mute findings indefinitely until they no longer match the rule.

  • Dynamic mute rules automatically unmute findings. When any of the following occurs, Security Command Center automatically unmutes the finding:

    • The dynamic mute rule expires.
    • The properties of a finding change to no longer match your filter criteria.
    • The filter criteria change to no longer match the finding.

We don't recommend using static and dynamic mute rules simultaneously. Static mute rules override dynamic mute rules when they are applied to the same finding. As a result, dynamic mute rules won't work as intended, which can create confusion when managing your findings.

If you want to use dynamic mute rules exclusively, the following sections describe the permissions and steps necessary migrate your static mute rules.

Permissions

To get the permissions that you need to perform the dynamic mute migration process, ask your administrator to grant you the following IAM roles on your Google Cloud organization, folder, or project:

For more information about granting roles, see Manage access to projects, folders, and organizations.

You might also be able to get the required permissions through custom roles or other predefined roles.

Migrate to dynamic mute rules

To use dynamic mute rules exclusively, complete the following steps to create dynamic mute rules and ensure existing muted findings remain muted after migration.

  1. Create new dynamic mute rules. You can't modify a mute rule's type after it has been created. Therefore, you must create one dynamic mute rule for each static mute rule you want to retain. Each new dynamic mute rule name must be unique from the existing mute rules. Security Command Center might take a few hours to apply the dynamic mute rules to the appropriate findings. For instructions on how to create a dynamic mute rule, see Create a mute rule.

  2. Validate the mute state of applicable findings. To validate that the dynamic mute rules have been applied appropriately, you can use the muteInfo attribute in the Security Command Center API to list the applicable findings and inspect their mute fields. This helps you to determine whether the applicable findings are using dynamic or static mute rules.

    For example, use muteInfo.dynamicMuteRecords in a query to list the applicable findings that are being muted by the new dynamic mute rule:

      contains(muteInfo.dynamicMuteRecords, muteConfig =
  "organizations/123/muteConfigs/my-dynamic-rule")

    For more information on how to list findings, see Listing security findings using the Security Command Center API.

  3. Delete all static mute rules. Applicable future findings are covered by the new dynamic rules you created. Delete all your existing static mute rules to ensure they won't override the new dynamic mute rules for new findings. For instructions on how to delete a mute rule, see Delete mute rules. Deleting static mute rules does not change the static mute state of existing findings.

  4. Reset the static mute state on all findings. To reset the static mute state of existing findings in bulk, perform one of the following actions:

    • Use either the gcloud scc findings bulk-mute command or the bulkMute API method with the muteState attribute set to UNDEFINED. Do this for each static mute rule that you deleted. For instructions on how to perform bulk mute operations, see Mute or reset multiple existing findings.

    • If the bulk mute operation times out, you can clear the static mute state from all findings by updating your bulk mute filter to use less granular filters that cover all the relevant findings you need to update.

      Consider the following example of a filter in a static mute rule:

      filter: "category = \"OPEN_SSH_PORT\" AND
(resource.parentDisplayName = \"organizations/123\"
OR resource.parentDisplayName = \"folder/456")"

      To clear the mute state on all findings that match the criteria of this static mute rule filter, you can modify the filter by removing the additional conditions that follow the finding category. For this example, the result would be as follows:

      filter: "category = \"OPEN_SSH_PORT""

      If you have manually set the mute state for any findings, this method might also reset the mute state of those findings.

      For more information on updating a mute rule, see Update mute rules.

If you need help migrating your static mute rules to dynamic mute rules, contact support.

What's next

Learn more about creating and managing mute rules.