Cloud Security Management Misconfigurations (CSM Misconfigurations) out-of-the-box compliance rules evaluate the configuration of your cloud resources and identify potential misconfigurations so you can immediately take steps to remediate.

The compliance rules follow the same conditional logic as all Datadog Security compliance rules. For CSM Misconfigurations, each rule maps to controls within one or more compliance frameworks or industry benchmarks.

CSM Misconfigurations uses the following rule types to validate the configuration of your cloud infrastructure:

• Cloud configuration: These compliance rules analyze the configuration of resources within your cloud environment. For example, the Cloudfront distribution is encrypted rule evaluates an Amazon CloudFront distribution’s configuration for encrypted status.
• Infrastructure configuration: These checks evaluate containers and Kubernetes clusters using rules from CIS compliance benchmarks for Docker and Kubernetes, as well as Linux workloads against CIS host benchmarks for Ubuntu, Red Hat, and Amazon Linux.

Explore default compliance rules

To filter the default compliance rules by cloud provider:

1. Navigate to the Misconfiguration Rules page.
2. Choose one of the following values from the Tag facet.
   • AWS: cloud_provider:aws
   • Azure: cloud_provider:azure
   • Google Cloud: cloud_provider:gcp
   • Docker: framework:cis-docker
   • Kubernetes: framework:cis-kubernetes

Customize how your environment is scanned by each rule

Customization of a cloud configuration query directly is not supported at this time, but you can customize how your environment is scanned by each rule.

On the Rules page, select a rule to open its details page. Under Exclude benign activity with suppression queries, set the filtering logic for how the rule scans your environment.

For example, you can exclude resources tagged with env:staging using the This rule will not generate a misconfiguration if there is a match with any of the following suppression queries function. You can also limit the scope for a certain rule to resources tagged with compliance:pci using the Only generate a misconfiguration if there is a match with any of the following queries function.

After you customize a rule, click Update Rule at the bottom of the page to apply your changes.

Set notification targets for compliance rules

You can send real-time notifications when a new misconfiguration is detected in your environment by adding notification targets. The available notification options are:

• Slack
• Jira
• PagerDuty
• ServiceNow
• Microsoft Teams
• Webhooks
• Email

On the Rules page, select a rule to open its details page. In the Set severity and notifications section, configure zero or more notification targets for each rule case. You cannot edit the preset severity. See Notifications for detailed instructions on configuring notifications for compliance rules.

Alternatively, create notification rules that span across multiple compliance rules based on parameters such as severities, rule types, rule tags, signal attributes, and signal tags. This allows you to avoid having to manually edit notification preferences for individual compliance rules.

Note: If a misconfiguration is detected for a rule with notifications enabled, the failed misconfiguration also appears on the Signals Explorer.

Create custom rules

You can create custom rules to extend the rules being applied to your environment to evaluate your security posture. You can also clone the default detection rules and edit the copies (Google Cloud only). See Custom Rules for more information.

Rule deprecation

Regular audits of all compliance rules are performed to maintain high fidelity signal quality. Deprecated rules are replaced with an improved rule.

The rule deprecation process is as follows:

1. There is a warning with the deprecation date on the rule. In the UI, the warning is shown in the:
   • Signal side panel’s Rule Details > Playbook section
   • Misconfigurations side panel
   • Rule editor for that specific rule
2. Once the rule is deprecated, there is a 15 month period before the rule is deleted. This is due to the signal retention period of 15 months. During this time, you can re-enable the rule by cloning the rule in the UI.
3. Once the rule is deleted, you can no longer clone and re-enable it.

Further Reading

Additional helpful documentation, links, and articles:

Getting Started with CSM MisconfigurationsDOCUMENTATION Custom RulesDOCUMENTATION Misconfigurations ReportsDOCUMENTATION