A shell spawned by the web server at 2am.
Contained by a person, while it is still running.
Datadog Workload Protection watches process, file and network activity on every host and container from inside the Agent, using eBPF, and raises a signal when the activity matches an attack. We implement it inside the Datadog you already run, decide with you where detection ends and enforcement begins, and under Critical Support our engineers take the signal and contain the runtime, 24x7.
Quick facts
Related
- Cloud Security, the group this belongs to
- Cloud SIEM, the same attack seen in the logs rather than the kernel
- Container Monitoring, the containers the signals attach to
What the process did after it got in, seen from the kernel, while it is still happening
Posture checks say whether the door was locked. Vulnerability scans say whether the lock was weak. Neither says that something came through it at 2am and is now reading credentials from disk. Workload Protection watches the host from inside, at the point where a process is executed, a file is opened or a connection is made, and raises the signal while the activity is live.
The Agent you already run, watching the kernel. On Linux, eBPF probes in the Datadog Agent see process execution, file access, kernel activity and network connections without a separate sensor. Windows uses a driver. Fargate uses a small tracer. One rollout, one fleet.
Rules that filter on the host and reason in Datadog. Agent rules decide what is worth sending. Detection rules correlate across time and across processes. Each is mapped to a MITRE ATT&CK technique, so the signal says what kind of attack it is.
The evidence attached to the signal. The process tree, the parent that spawned it, the files it touched, the connections it opened and the container it ran in. The incident review starts with a record rather than a reconstruction.
Enforcement, where it is safe. A rule can terminate the process or the container, or block the traffic with an eBPF filter, automatically on match or manually from the signal. Which rules get that power is an implementation decision, and we make it with you.
An Agent with the feature off, a backup job that looks like credential theft, and nobody on the pager
How it bills. Workload Protection is metered per host running the Agent with the runtime security feature enabled, with containers billed against a per-host allotment. It is sold on its own and is included in CSM Enterprise. AWS Fargate tasks are counted on their own per-task meter, and on Fargate the Agent runs as a sidecar with the cws-instrumentation tracer because eBPF is not available there. Datadog publishes the meters and rates. The lever is which hosts and clusters are in scope. A production cluster facing the internet always is, a staging cluster rarely is, and the fleet of batch workers is a decision rather than a default.
The configuration traps. The Agent rolled out for metrics with runtime security left at its default, which is off, so the host list looks covered and nothing is watching. Policies pushed through Remote Configuration to a fleet where half the Agents have Remote Configuration disabled. The default rules left untouched, so the nightly backup trips the credential access rules every night until the rule is muted rather than tuned. Enforcement enabled on a rule whose first production match is a deployment hook. A signal that pages a channel with nobody on call.
Field noteThe most common gap we see is the flag. Runtime security is a feature of the Agent that is already installed, it is off by default, and the Agent dashboard shows every host as healthy either way. Nobody finds out until the first signal that should have fired, did not.
Field noteA legitimate agent-based backup reads the same files an attacker would, at the same hour every night. Within a week the signal is muted along with the rule, and the credential access technique is no longer detected on the hosts where the backup runs, which are the hosts that hold the credentials.
Field noteFargate is assumed covered because the ECS cluster shows green. There is no eBPF on Fargate, the task needs the tracer added to its definition, and the tasks that were never redeployed with it are the ones still running the old image.
Field noteThe pattern we keep finding is enforcement tested in staging, where the process never ran. Its first production match is a deploy hook that does something unusual on purpose, the hook is killed mid-deploy, and enforcement is switched off everywhere afterwards rather than on that one rule.
Detect everywhere in scope. Tune against real behaviour. Enforce one rule at a time.
Workload Protection is delivered inside the Cloud Security Accelerator, four weeks and fixed scope, alongside the other Cloud Security capabilities you have chosen. If Datadog is new to the estate, LaunchPad runs the platform rollout first. The workload sequence is the same either way.
- Scope the workloads. Which hosts, clusters and Fargate services, and which of them face the internet or hold credentials. Production first. Everything else justified.
- Enable runtime security through your deployment tooling. The Agent flag on Linux and Windows, the tracer in the Fargate task definitions. Remote Configuration confirmed on every Agent so policies reach the whole fleet.
- Deploy the default policy and watch for a fortnight. Detect mode only. Every signal reviewed against what the workload legitimately does: backups, deploy hooks, scheduled jobs, debugging sessions.
- Tune, do not mute. Rules that matched legitimate behaviour are narrowed to exclude it, by process, path or container, so the technique stays detected everywhere else. Custom rules added for the behaviour your estate treats as abnormal.
- Route the signals and decide enforcement. Critical signals page the on-call engineer, 24x7, with the evidence attached. Enforcement is enabled rule by rule, only where a match cannot be legitimate, tested against the workload's real behaviour first.
- Hand over, in writing. Workloads in scope, the policy in force with every tuning and its reason, the enforcement rules and why each was chosen. Then the routing, and every signal seen during the watch period.
Access is admin on the Datadog organisation and Agent rollout through your deployment tooling. Containment under Critical Support uses the runtime access you grant for that purpose, agreed in writing before the first signal, never assumed from the Datadog login.
Detection is only as good as the person who answers it
A cluster is rebuilt and the flag is lost. A new scheduled job trips a rule that was tuned for the old one. A signal fires on a Sunday. Managed Observability keeps the coverage and the rules matching the estate every month. Critical Support answers the signal.
Every month, the signals are reviewed. What fired, what was legitimate, what was tuned, what was contained. Rules that matched legitimate behaviour are narrowed with the reason recorded, never muted wholesale.
Coverage follows the fleet. New hosts, clusters and Fargate services are confirmed to have runtime security enabled and Remote Configuration connected. Rebuilt nodes are checked rather than assumed. Decommissioned hosts leave the bill.
Enforcement is kept honest. Each enforcement rule is re-checked against the workload's current behaviour after every significant deployment, so the rule that was safe in March is still safe in September.
The threat is contained, not forwarded. Under Critical Support a workload threat signal pages our engineers, 24x7. They isolate the host or kill the process, tell the owner, and keep the evidence, in that order.
We operate the stack. You own the product.
We are not a security company, and we do not pretend to be. We are a managed runtime operator, and workload protection is the part of security closest to what we do all day. A signal fires on a host we run. An engineer who knows the host answers it, and the runtime is contained. We operate the detection runtime, tune it, and take the page. Threat hunting, forensics beyond the evidence Datadog keeps, and the decision to involve a regulator or the police stay with you and your security team. We operate and evidence the runtime controls that support your compliance obligations.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Cloud Workload Protection, answered plainly
How does Datadog Workload Protection detect threats?
From inside the host. On Linux the Datadog Agent uses eBPF to watch process execution, file access, kernel activity and network connections, and compares them against agent rules on the host. Matches are sent to Datadog, where detection rules evaluate them across time and across processes and raise a security signal. Windows uses a driver, and AWS Fargate uses a small tracer because eBPF is not available there. Datadog ships out-of-the-box agent rules and detection rules mapped to MITRE ATT&CK techniques, and custom rules can be added, including state machines that run in the Agent.
How is Datadog Cloud Workload Protection billed?
Workload Protection is metered per host running the Agent with the runtime security feature enabled, with containers billed against a per-host allotment. It is sold on its own and is included in CSM Enterprise. AWS Fargate tasks are counted on their own per-task meter, and on Fargate the Agent runs as a sidecar with the cws-instrumentation tracer because eBPF is not available there. Datadog publishes the meters and rates. We do not publish prices. We decide with you which hosts and clusters belong in scope, because a staging cluster and a batch fleet rarely justify runtime threat detection and a production cluster facing the internet always does.
Can Datadog Workload Protection stop an attack, or only report it?
It can stop it. With enforcement enabled in the Agent, a rule can terminate the process or the container, or block the network traffic with an eBPF filter. That happens automatically when the rule matches, or on a manual action from the signal. Automatic enforcement is a decision with consequences, so we enable it rule by rule, on workloads where the match cannot be legitimate, and we test it against the workload's real behaviour before it goes live. Everything else stays in detect mode and pages a person.
Who responds to a workload threat signal at night?
Under Critical Support, our engineers do. A workload threat signal pages the on-call engineer, 24x7, with the process tree, the file and network activity and the host attached. They contain the runtime first, by isolating the host or killing the process, then tell the owner, then keep the evidence. Where you have a security team or an MDR provider, the same signal reaches them through the routing we set up, and the containment is coordinated rather than duplicated.
What does Critical Cloud do with Workload Protection every month?
Managed Observability reviews the signals that fired and tunes the rules that matched legitimate behaviour, so the noise falls without the coverage falling. It confirms that runtime security is still enabled on every host in scope after rebuilds and upgrades, and reports what fired, what was contained and what was routed. Under Critical Support, our engineers take the signal itself, 24x7, and contain the runtime before the owner is woken.
- Datadog products: every product, and how we implement and run each one
- Cloud Security: the group, with workload protection alongside posture, identity, vulnerabilities and compliance
- Cloud SIEM and Container Monitoring: the attack seen in the logs, and the containers the signals attach to
- Critical Support: the 24x7 engineers who take the signal and contain the runtime
Watched from the kernel. Answered by a person.
Tell us which clusters face the internet and who is on the pager tonight. We will show you what Workload Protection would see, which rules belong in enforcement, and what it takes to have an engineer on the signal at 2am.