Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions hugo/config/_default/menus/main.en.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -8750,7 +8750,7 @@ menu:
parent: workload_protection
identifier: workload_protection_detect_and_monitor
weight: 91
- name: Agent rules
- name: Agent Rules
url: security/workload_protection/detect_and_monitor/agent_rules
parent: workload_protection_detect_and_monitor
identifier: workload_protection_detect_and_monitor_agent_rules
Expand All @@ -8760,7 +8760,7 @@ menu:
parent: workload_protection_detect_and_monitor_agent_rules
identifier: workload_protection_detect_and_monitor_agent_rules_secl_guide
weight: 10
- name: Policy management
- name: Policy Management
url: security/workload_protection/detect_and_monitor/agent_rules/policy_management
parent: workload_protection_detect_and_monitor_agent_rules
identifier: workload_protection_detect_and_monitor_agent_rules_policy_management
Expand All @@ -8780,17 +8780,17 @@ menu:
parent: workload_protection_detect_and_monitor_agent_rules
identifier: workload_protection_detect_and_monitor_agent_rules_windows_expressions
weight: 50
- name: Detection and finding rules
- name: Detection and Finding Rules
url: security/workload_protection/detect_and_monitor/detection_and_finding_rules
parent: workload_protection_detect_and_monitor
identifier: workload_protection_detect_and_monitor_detection_and_finding_rules
weight: 20
- name: Detection rules
- name: Detection Rules
url: security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules
parent: workload_protection_detect_and_monitor_detection_and_finding_rules
identifier: workload_protection_detect_and_monitor_detection_and_finding_rules_detection_rules
weight: 10
- name: Finding rules
- name: Finding Rules
url: security/workload_protection/detect_and_monitor/detection_and_finding_rules/finding_rules
parent: workload_protection_detect_and_monitor_detection_and_finding_rules
identifier: workload_protection_detect_and_monitor_detection_and_finding_rules_finding_rules
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,33 +3,35 @@ title: Agent Rules
disable_toc: false
---

## Overview
Agent rules determine which runtime activity the Datadog Agent collects and sends to Datadog as Agent events. These events provide the telemetry that Workload Protection uses for threat detection and runtime security posture evaluation.

Agent events are the foundational telemetry signal used by the security platform to power both threat detection and runtime security posture evaluation. They capture low-level runtime activity from workloads and provide the raw, high-fidelity data needed to reason about what is actually happening on a system, rather than relying solely on static configuration or periodic scans.
To reduce noise, data volume, and performance impact, the Agent filters benign or low-risk activity before sending events to Datadog. Agent rules use Security Language (SECL) to define this filtering. Policies deploy Agent rules through Remote Configuration, Agent configuration files, or Terraform.

The overall design philosophy is to be selective by default. Only runtime events that are relevant for security monitoring are sent to the backend, while benign or low-risk activity is filtered out as early as possible within the agent itself. This early filtering is critical to reducing noise, limiting data volume, and minimizing the performance impact on the host where the agent is deployed.
Workload protection has a custom expression language (called SecL) to define the rules used to apply this filtering. They are deployed using policies which can be managed in Datadog with Remote Configuration or manually by modifying the agent configuration files, or using Terraform.
## Out-of-the-box Agent rules {#ootb-rules}

The goal of this page is to guide you through the different steps needed to write and deploy an agent rule.
Workload Protection includes out-of-the-box (OOTB) Agent rules, called default rules, that Datadog manages. To view them, see [Agent Rules][1] in Datadog. Datadog security engineers maintain these rules. They add rules for emerging malware behavior, evolving attack techniques, and other security-relevant activity.

### OOTB rules {#ootb-rules}
You can deploy default rules selectively to environments or workloads, clone them to customize their expressions, refine their filtering logic, or add actions. For deployment options, see [Policy Management][2].

By default, the Workload Protection agent ships with a set of out-of-the-box agent rules (called "default" rules) that are fully managed by Datadog. To view them, see [Agent Rules](https://app.datadoghq.com/security/workload-protection/agent-rules?ruleQuery=defaultRule%3Atrue) in Datadog. These rules are continuously maintained and updated by Datadog security engineers, with new rules regularly introduced to reflect emerging malware behaviors, evolving attack techniques, and patterns that are known to be malicious or security-relevant.
Agent rules can collect contextual telemetry or match high-confidence activity and execute Agent actions. Backend detection rules analyze Agent events and generate security signals.

Users retain full control over how and where these rules are applied within their infrastructure. Default rules can be selectively deployed to specific environments or workloads (see the [Policy Management](/security/workload_protection/detect_and_monitor/agent_rules/policy_management) page), cloned to customize their expressions, refined to tighten or relax filtering logic, or extended with "actions" to enable proactive response workflows.
To create an Agent rule and threat detection rule together, use the Assisted rule creator or manual flow. See [Create the custom Agent and detection rules together][3] in the [Detection Rules][4] documentation.

The scope of these rules spans a broad spectrum of security coverage. Some rules focus on collecting low-level telemetry that provides valuable context during threat investigations, while others are designed to detect high-confidence indicators of compromise that warrant immediate attention and response.
## Write custom Agent rules in SecL

To author a new Agent rule and its threat detection rule together (Assisted rule creator or manual flow), see [Create the custom Agent and detection rules together](/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules/#create-the-custom-agent-and-detection-rules-together) in the [Detection rules](/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules) documentation.
Workload Protection Agent rules use SecL to specify which events to observe, match, and send to Datadog based on runtime context. For more information, see the [SecL guide][5].

### 1) Writing custom agent rules in SecL
## Deploy Agent rules with policies

Within Workload Protection, agent rules are written with a custom expression language called SecL. SecL allows precise definitions of which events should be observed, matched, and forwarded to the Datadog backend based on runtime context. You can find more in the dedicated [SecL Guide](/security/workload_protection/detect_and_monitor/agent_rules/secl_guide) page.
Agent rules are packaged and deployed in policies. Manage policies centrally in Datadog with Remote Configuration, manually with Agent configuration files, or as code with Terraform. For more information, see [Policy Management][2].

### 2) Deploying agent rules with policies
## Use variables and actions

Agent rules are packaged and deployed using policies, which can be managed centrally in Datadog through Remote Configuration, or defined manually through agent configuration files. For infrastructure-as-code workflows, the same policies can also be managed and versioned using Terraform. You can learn more about the deployment of agent rules in the [Policy management](/security/workload_protection/detect_and_monitor/agent_rules/policy_management) page.
Variables and actions extend Agent rules beyond event matching. Actions can collect additional telemetry, such as file hashes, or respond to threats. SecL variables support stateful, multi-step detection logic. For more information, see [Variables and actions][6].

### 3) (Optional) Use variables and actions for advanced use cases

Variables and actions extend the Agent detection logic beyond event matching. Actions can be used to collect additional telemetry (such as file hashes) or to operate on SecL variables, which enable the construction of advanced, stateful detection logic based on state machines. See the [Variables and actions](/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions) page for more.
[1]: https://app.datadoghq.com/security/workload-protection/agent-rules?ruleQuery=defaultRule%3Atrue
[2]: /security/workload_protection/detect_and_monitor/agent_rules/policy_management
[3]: /security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules/#create-the-custom-agent-and-detection-rules-together
[4]: /security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules
[5]: /security/workload_protection/detect_and_monitor/agent_rules/secl_guide
[6]: /security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: Policy management
title: Policy Management
aliases:
- /security/workload_protection/workload_security_rules/custom_rules
- /security/threats/workload_security_rules/custom_rules
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,9 @@ aliases:
disable_toc: false
---

This guide shows you how to write effective SECL (Security Language) rules for Datadog Workload Protection.

## Overview

Datadog SECL is a custom domain-specific language used to create Agent expressions and policies within Datadog Workload Protection. SECL allows security teams to define real-time threat detection rules by specifying conditions, operators, and patterns that security agents can monitor across hosts, containers, applications, and cloud infrastructure.

### How SECL rules fit together
## How SECL rules fit together

Think of SECL as a local filter: it runs inside the Agent on each host, watching kernel and OS events. When an event matches your SECL expression, the Agent raises a detection.

Expand Down Expand Up @@ -67,7 +63,7 @@ SECL operators are used to combine event attributes together into a full express
| `not in [CIDR1, ...]` | Element is not in the IP ranges | 7.37 |
| `allin [CIDR1, ...]` | All the elements are in the IP ranges | 7.37 |

#### Patterns and regular expressions
### Patterns and regular expressions

Patterns or regular expressions can be used in SECL expressions. They can be used with the `in`, `not in`, `=~`, and `!~` operators.

Expand All @@ -78,7 +74,7 @@ Patterns or regular expressions can be used in SECL expressions. They can be use

Patterns on `.path` fields are used as Glob. `*` matches files and folders at the same level. `**`, introduced in 7.34, can be used at the end of a path to match all the files and subfolders.

#### Durations
### Durations

You can use SECL to write rules based on durations, which trigger on events that occur during a specific time period. For example, trigger on an event where a secret file is accessed more than a certain length of time after a process is created.
Such a rule could be written as follows:
Expand Down Expand Up @@ -229,4 +225,4 @@ rules:

[1]: /security/workload_protection/linux_expressions
[2]: /security/workload_protection/windows_expressions
[3]: /security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions
[3]: /security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,6 @@ Actions are defined in Agent policy files (`.policy`) under the `actions` field
When you create an Agent rule in Datadog, you can configure <code>hash</code>, <code>kill</code> (<a href="/security/workload_protection/respond_and_report/#automated-response">Automated Response</a>), and <code>set</code> actions. From a security signal, you can manually apply <code>kill</code> or <code>network_filter</code> to a targeted threat with <a href="/security/workload_protection/respond_and_report/#response">Response</a>.
</div>

## Overview


| Action | Purpose | Platform | Requires enforcement |
| ---------------- | ------------------------------------------------ | -------------- | -------------------- |
| `set` | Store state in a variable for use by other rules | Linux, Windows | No |
Expand Down Expand Up @@ -429,4 +426,3 @@ The Agent validates actions at policy load time:
- **Required fields**: for example, `kill.signal`, `log.level`, `network_filter.filter`.
- **Enforcement gate**: `kill` and `network_filter` require enforcement to be enabled.
- **Event type compatibility**: `network_filter` requires the `raw_packet` event type; `hash.field` must be compatible with the rule's event type.

Original file line number Diff line number Diff line change
Expand Up @@ -13,20 +13,16 @@ further_reading:
text: "Investigate security signals"
---

This topic explains how Workload Protection Content Packs help you deploy targeted detections to the workloads where they apply, and stay current with emerging threats.

## Overview

Not every detection rule is relevant to every workload. Some detections can be too noisy for environments with specific constraints, or may not apply to particular software stacks. At the same time, new threats emerge regularly, and Datadog security research team continuously develops rules to detect novel attacks and vulnerabilities.

Workload Protection [Content Packs][1] address both challenges. Each Content Pack is a Datadog-crafted bundle of optional [Agent rules][2], [detection rules][3], and supporting content built for a specific software stack, threat vector, or emerging vulnerability. You opt in to the Content Packs you need and deploy them only to the workloads where they apply.

## Why use Content Packs?
## Benefits

- **Deploy targeted detections to relevant workloads:** Opt into policies built for specific workloads or environments, and deploy them only where they apply. This avoids unnecessary noise and performance impact on workloads where those detections do not apply.
- **Stay ahead of emerging threats:** Get access to new rules as Datadog security research team identifies novel threats and vulnerabilities, complementing the coverage provided by default policies.

## What's included in a Content Pack?
## Included content

Depending on the Content Pack, a bundle can include:

Expand All @@ -40,8 +36,7 @@ Depending on the Content Pack, a bundle can include:
1. Go to [Content Packs][1].
2. Browse the available Content Packs and select one.
3. Review the included Agent rules, detection rules, and deployment requirements.
4. Click **Enable** to activate the Content Pack.
5. You are redirected to the associated policy page.
4. Click **Enable** to activate the Content Pack and go to the associated policy page.

Enabling a Content Pack adds its associated policy and rules to your organization. To start detecting threats, deploy the associated policy to your infrastructure.

Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: Detection and finding rules
title: Detection and Finding Rules
disable_toc: false
---

Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
title: Detection rules
title: Detection Rules
disable_toc: false
aliases:
- /security/workload_protection/detect_and_monitor/detection_rules
Expand Down
Loading