---
title: Detection and Finding Rules
description: >-
  Compare the backend detection rules and finding rules that Workload Protection
  uses to analyze Agent events.
breadcrumbs: >-
  Docs > Datadog Security > Workload Protection > Detect and Monitor > Detection
  and Finding Rules
---

> For the complete documentation index, see [llms.txt](https://docs.datadoghq.com/llms.txt).

# Detection and Finding Rules

After the Agent forwards [Agent events](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/agent_events.md) to Datadog, backend rules analyze that telemetry to produce security outcomes. Workload Protection provides two types of backend rules:

- **[Detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md)** detect threats and generate [security signals](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/security_signals.md) when suspicious activity matches your criteria. They surface real runtime security threats—for example, a reverse shell or credential access attempt.
- **[Finding rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules.md)** evaluate runtime security posture and generate [findings](https://docs.datadoghq.com/security/workload_protection/investigate_and_triage/security_findings.md) with recommendations for resources that fail a policy. They track ongoing bad practices and misconfigurations on a host or container—for example, package manager usage in a production container.

Both rule types query the same **backend event schema**. Each event includes all fields collected by the Agent, plus additional enrichment such as infrastructure context and threat intelligence. When you write a search query for a detection or finding rule, you can filter on any field in this schema. See [Linux backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_linux.md) and [Windows backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_windows.md) for the full set of available fields.

## Detection rules versus finding rules{% #detection-rules-versus-finding-rules %}

| Detection rules | Finding rules                          |
| --------------- | -------------------------------------- |
| **Output**      | Security signal                        | Finding                                     |
| **Represents**  | Real runtime security threats          | Posture issues and security recommendations |
| **Use case**    | Threat detection and incident response | Runtime posture and hardening               |

For example, `Sudoers Policy File Modification Detection` flags modifications to `/etc/sudoers` and files in `/etc/sudoers.d/`. Modifying those files is a bad practice, but it can be part of a legitimate process. Treating it as a detection rule generates excessive noise. As a finding rule, it tracks which resources have this configuration without triggering a signal for every file write.

## Next steps{% #next-steps %}

- Read [Detection rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md) to explore out-of-the-box (OOTB) threat detection rules and create custom detection rules.
- Read [Finding rules](https://docs.datadoghq.com/security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules.md) to explore OOTB posture rules and create custom finding rules.
- Browse [Linux backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_linux.md) and [Windows backend syntax](https://docs.datadoghq.com/security/workload_protection/backend_windows.md) to see every field you can use in rule queries.