diff --git a/hugo/config/_default/menus/main.en.yaml b/hugo/config/_default/menus/main.en.yaml index 9facaa422e3..2d663cd56b0 100644 --- a/hugo/config/_default/menus/main.en.yaml +++ b/hugo/config/_default/menus/main.en.yaml @@ -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 @@ -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 @@ -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 diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/_index.md b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/_index.md index 8d9408a2530..fcec523a437 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/_index.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/_index.md @@ -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. \ No newline at end of file +[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 diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md index ad1e0b72507..9b95f3d30e0 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/policy_management.md @@ -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 diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/secl_guide.md b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/secl_guide.md index e656778b7f4..521463e59bf 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/secl_guide.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/secl_guide.md @@ -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. @@ -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. @@ -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: @@ -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 \ No newline at end of file +[3]: /security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions.md b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions.md index eaa86b91e59..90184679c4a 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/agent_rules/variables_and_actions.md @@ -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 hash, kill (Automated Response), and set actions. From a security signal, you can manually apply kill or network_filter to a targeted threat with Response. -## Overview - - | Action | Purpose | Platform | Requires enforcement | | ---------------- | ------------------------------------------------ | -------------- | -------------------- | | `set` | Store state in a variable for use by other rules | Linux, Windows | No | @@ -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. - diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/content_packs.md b/hugo/content/en/security/workload_protection/detect_and_monitor/content_packs.md index 72f3a36e20a..9c0edcf38d1 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/content_packs.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/content_packs.md @@ -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: @@ -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. diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/_index.md b/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/_index.md index f410d1783bc..dcb21241738 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/_index.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/_index.md @@ -1,5 +1,5 @@ --- -title: Detection and finding rules +title: Detection and Finding Rules disable_toc: false --- diff --git a/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md b/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md index 715f5edb613..af3e54146da 100644 --- a/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md +++ b/hugo/content/en/security/workload_protection/detect_and_monitor/detection_and_finding_rules/detection_rules.md @@ -1,5 +1,5 @@ --- -title: Detection rules +title: Detection Rules disable_toc: false aliases: - /security/workload_protection/detect_and_monitor/detection_rules