--- title: Detect and Monitor description: Datadog, the leading service for cloud-scale monitoring. breadcrumbs: Docs > Datadog Security > Cloud SIEM > Detect and Monitor --- > For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt). # Detect and Monitor ## Overview{% #overview %} Monitor your Datadog telemetry and use out-of-the-box detection rules or create custom rules to detect threats. When a threat is detected, a security signal is generated. Additionally, you can add suppressions to refine detection rules so that a signal is not generated under specific conditions. This can improve the accuracy and relevance of security signals generated. {% image source="https://docs.dd-static.net/images/security/security_monitoring/detection_rules/detection_rule_side_panel.bfe99a73e4ede83621ae8ac0dfe06599.png?auto=format&fit=max&w=850 1x, https://docs.dd-static.net/images/security/security_monitoring/detection_rules/detection_rule_side_panel.bfe99a73e4ede83621ae8ac0dfe06599.png?auto=format&fit=max&w=850&dpr=2 2x" alt="The side panel of a detection rule showing the conditions that trigger a signal" /%} ## Detection rules{% #detection-rules %} ### Out-of-the-box detection rules{% #out-of-the-box-detection-rules %} Cloud SIEM provides you with an extensive list of [OOTB detection rules](https://docs.datadoghq.com/security/default_rules.md#cat-cloud-siem-log-detection). After you have enabled and configured Cloud SIEM content packs, OOTB detection rules automatically begin analyzing your logs, Audit Trail events, and events from Event Management. You can edit OOTB detection rules and do the following: - Change the name of the rule. - Extend the query. The original query cannot be edited, but you can add a custom query to it. - Change the severity setting in the Set conditions section. - Modify the playbook. #### Assess rule health{% #assess-rule-health %} {% callout %} ##### Preview Rule health insights are in Preview. {% /callout %} Rules may become less effective as your business needs change over time. Monitoring rules for drifting logic is inherently difficult: if a rule results in few signals, that might be by design, or it might be missing issues it was intended to catch. In the [Detection Rules explorer](https://app.datadoghq.com/security/siem/rules), and the side panel that appears when you click an out-of-the-box rule in that explorer, you can view information about the health of the rule: - Health Insights: Provides information on whether the fields that are part of a rule appear properly in the logs Cloud SIEM ingests. Datadog categorizes supported rules as either Monitoring or Needs attention. - Signal activity: A graph of how many signals the rule has created over the past 30 days. In the rule side panel, you can view more information about individual fields referenced in the rule. For each scope (the `source` or `service` from the query), you can see: - Field: The field Datadog evaluated. - Presence rate: The percentage of logs ingested in that scope over the last 24 hours that contain that field. - Log count change: The number of times the field has appeared in logs over the last 24 hours, compared to the average number of times over the last 29 days. Indicates whether the presence of that field is increasing, decreasing, or staying the same. - Status: Indicates Datadog's assessment of the field. Values include: - Monitoring: Datadog is still collecting information about the field and has not identified any issues that require action. - All zero: Over the last 30 days, all values have been zero. This could indicate that the detection was never active, or that it has become inactive after the rule was created. - Trailing silence: The field appeared more frequently earlier in the 30-day lookback, but appeared significantly fewer times over the last 15 consecutive business days. - Drifting: For three consecutive days, the number of times the field appeared in logs was below 5% of its median number of appearances over the previous 27 days. This indicates that there was data for the field, but that it has since experienced a steep decline. If a field's status is either Trailing silence or Drifting, under Health Insights, Datadog marks the rule as Needs attention so you can investigate whether missing or anomalous values indicate a problem. {% alert level="info" %} The service that analyzes field status runs once a day. If you edit a rule, the updated status appears after the service runs again. {% /alert %} ##### Investigate rule health alerts{% #investigate-rule-health-alerts %} In the side panel of the [Detection Rules explorer](https://app.datadoghq.com/security/siem/rules), you can click View beside a specific scope or field to view its appearances in the Logs Explorer. With this information, you can explore whether the scope or field changed, or if the problem might have another cause, such as an issue with your pipelines. ##### Mute or unmute rule health alerts{% #mute-or-unmute-rule-health-alerts %} To mute the alerts associated with a rule: 1. In the Health Insights section of the rule side panel, click Mute Alerts. The Mute alerts window opens. 1. Choose to mute alerts either For 30 days or Until this rule is updated. 1. Optionally, add a note to explain why you're muting alerts. 1. Click Mute Alerts. If a rule is muted, you can click Unmute Alerts to start getting alerts for it again. ### Custom detection rules{% #custom-detection-rules %} OOTB detection rules cover the majority of threat scenarios, but you can also create custom detection rules for your specific use cases. For custom detection rules, use the log search syntax to build and join log queries so you can target individual services, accounts, or events that you want to monitor. You can also enhance those queries with information such as the geolocation of an IP address or the status code of an HTTP request. For logs that match the query, you can set conditions to determine whether it's a threat and if a security signal should be generated, as well as indicate the severity of the threat. Security signals provide details about the threat and include a customizable playbook, which provides information such as security policies and remediation steps. See [Custom Detection Rules](https://docs.datadoghq.com/security/cloud_siem/detect_and_monitor/custom_detection_rules.md) for more information. ### Rule deprecation{% #rule-deprecation %} Regular audits of all out-of-the-box detection 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 - [Rule editor](https://docs.datadoghq.com/security/detection_rules.md#clone-a-rule) for that specific rule 1. After the rule is deprecated, the rule remains available for the length of your retention period before it is deleted. During this time, you can re-enable the rule by [cloning the rule](https://docs.datadoghq.com/security/detection_rules.md#clone-a-rule) in the UI. The retention period depends on your [Cloud SIEM product](https://docs.datadoghq.com/security/cloud_siem/guide/determine-cloud-siem-product.md): - Standalone - 12 months (365 days, usage measured in GB) - 15 months (450 days, usage measured in millions of events) - Add-on with Flex Logs and Legacy: 15 months Organizations that adopted Standalone before gigabyte-based usage was introduced have a 15-month retention period. 1. After the rule is deleted, you can no longer clone and re-enable it. ## Suppressions{% #suppressions %} Security signals warn you about possible threats to your infrastructure, but false positives can also be generated. For example, a large number of security signals might be triggered if a sudden influx of requests are generated from load testing an application. To reduce false positives in such scenarios, you can define a suppression query in a detection rule that prevents a signal from getting generated. You can also create suppression rules to set general suppression conditions across multiple detection rules. See [Suppressions](https://docs.datadoghq.com/security/cloud_siem/detect_and_monitor/suppressions.md) for more information. ## Dynamic severity{% #dynamic-severity %} You can adjust the severity of security signals based on the assets they affect. You can customize severity levels, apply custom tags, and isolate changes to specific rules. See [Dynamic Severity](https://docs.datadoghq.com/security/cloud_siem/detect_and_monitor/dynamic_severity.md) for more information. ## MITRE ATT&CK Map{% #mitre-attck-map %} After setting up your detection rules, use the Cloud SIEM [MITRE ATT&CK Map](https://docs.datadoghq.com/security/cloud_siem/detection_rules/mitre_attack_map.md) to explore and visualize your rules against the MITRE ATT&CK framework so you have visibility into attacker techniques. ## Further reading{% #further-reading %} Additional helpful documentation, links, and articles: - [Build, test, and scale detections as code with Datadog Cloud SIEM](https://www.datadoghq.com/blog/detection-as-code-cloud-siem/) - [Identify gaps to strengthen detection coverage with the Datadog Cloud SIEM MITRE ATT&CK Map](https://www.datadoghq.com/blog/cloud-siem-mitre-attack-map/) - [Build sufficient security coverage for your cloud environment](https://www.datadoghq.com/blog/building-security-coverage-for-cloud-environments/) - [Best practices for creating custom detection rules with Datadog Cloud SIEM](https://www.datadoghq.com/blog/writing-datadog-security-detection-rules/) - [Detect and Investigate Threats with Cloud SIEM](https://learn.datadoghq.com/courses/cloud-siem-detect-investigate-threats) - [Write Custom Cloud SIEM Detection Rules](https://learn.datadoghq.com/courses/cloud-siem-custom-rules)