Respond to Threats

This product is not supported for your selected Datadog site. ().

Workload Protection acts on threats by terminating processes and containers or blocking network traffic. The Datadog Agent runs these actions automatically when an Agent rule matches, or when you trigger them manually from a signal. Both methods depend on Agent enforcement.

Response requirements

Response actions run in the Agent, so both automated and manual response depend on Agent settings and on the right RBAC permissions.

Configure Agent enforcement

Response actions use the runtime_security_config.enforcement settings in /etc/datadog-agent/system-probe.yaml. Enforcement is enabled by default, and the default settings are sufficient for most configurations. For the full parameter reference, see Workload Protection Agent configuration.

These settings let you exclude binaries from response actions or control which rule sources can trigger them. By default, no binaries are excluded, and the file and remote-config rule sources are allowed.

Response permissions

Both automated and manual response require specific RBAC permissions:

  • The security_monitoring_cws_agent_rules_actions permission lets users configure automated response and manually respond to threats.
    • A user with the Datadog Admin role must create a role that includes this permission, then assign that role only to users who manage automated response or need to run manual response actions.
  • The Datadog Standard role lets users create and update custom rules by default, as long as the changes do not modify protection settings on the rule. Users with the Standard role cannot enable a disabled rule that includes an automated response action and cannot use manual response actions.

Automated response

Automated response enables you to proactively block threats identified by Datadog Agent detection rules by terminating matching processes or containers.

Automated response splits the decision between two teams:

  • Security decides which threats warrant an automated action.
  • DevOps decides which applications and resources are resilient enough to withstand targeted protection.

The result is threat detection followed by immediate, targeted mitigation of high-confidence threats.

Automated response availability

If automated response is active for an Agent rule, you can verify it in the rule:

  1. In Agent Configuration, open the rule.
  2. Confirm that Automated response appears in the list of active actions.

To check whether automated response applies to a rule that generated a signal:

  1. In Signals, open the signal.
  2. View Next Steps. If automated response is available for the matching rule, Proactively block threats displays Automated response enabled.

Configure automated response on Agent rules

By default, all out-of-the-box (OOTB) Agent rules are active without automated response. You must configure the automated response action manually in order to kill processes.

Protection states

An Agent rule can be in one of the following states:

  • Inactive: The Agent does not monitor for the rule events and does not send detections to the Datadog backend.
  • Active: This is the default setting for enabled rules. The Agent monitors for the enabled rule and displays detections in Signals.
  • Active with automated response: The Agent monitors for the enabled rule, terminates matching processes, and displays detections in Signals.
Automated response is applied to all threats detected after automated response is enabled. Automated response is not retroactive.

To enable automated response on an Agent rule:

  1. In Agent Configuration, open a rule. If there is no Automated response action in the Agent’s actions section, then automated response is not available for that rule.

  2. Click Edit.

  3. Under Add actions for the agent to follow, select Automated response.

    An Agent rule Protection section displaying the automated response action
  4. Under Link the rule to policies, verify that the rule is Active in at least one policy.

  5. Click Update Agent Rule.

Review blocked attack attempts

After automated response is enabled for an Agent rule, blocked threats appear in Signals.

Any automated response is listed in the Response table, along with manually submitted responses.

Manual response

Manual response lets you protect your infrastructure from the signal side panel after Workload Protection generates a signal. Use manual response if you do not want an Agent rule to terminate processes automatically.

Response section showing isolate container and kill container actions with ISOLATED and KILLED statuses

Additional requirements for manual response

Confirm that each environment with hosts or containers running the Workload Protection-enabled Agent meets these requirements:

  • Datadog Agent 7.78 or later on the hosts that should execute response actions.
  • Remote Configuration is enabled so response policies can be delivered to the Agent.
  • Enforcement is enabled by default in system-probe as described in Configure Agent enforcement.

Available actions

The Agent supports the following enforcement action types:

Kill

Terminate a malicious process or all processes in a compromised container (cgroup), depending on scope.

Network filter (network isolation)

Block network traffic using an eBPF-based filter (for example, drop egress to specific ports). Any isolation can be reverted.

Network isolation uses eBPF Traffic Control classifiers and raw packet programs. The Agent enables the required network probes by default in event_monitoring_config.network in system-probe.yaml.

Action statuses

When a response action runs, the Agent records it in the Response table, along with automated responses. Each action has a status. The table below summarizes the main outcomes for each action type.

StatusDescriptionKillNetwork isolation
performedThe action completed successfully.
partially_performedPart of the kill succeeded (for example, some processes terminated) but not all targets could be killed.
removedAn isolation rule was removed from the current ruleset while it was present before—used when reverting network isolation.
errorAn error occurred during the response. The action failed and the process or container is still running or not isolated.
not_triggeredThe Agent did not find the targeted resource. The container or process may have exited before the response action ran.

Further reading