CWPP - workload protection

Cloud Workload Protection Platform watches what happens inside the VM, container and serverless function: syscalls, connections and processes, at execution time.

CrowdStrikeSentinelOneAqua SecurityTrend Micro Cloud One

What it is

CWPP () is the sensor inside the workload: VM, container, serverless function, Kubernetes host. looks at configuration; CWPP looks at behavior. It sees syscalls, network connections, processes, file reads, binary modification, and correlates that against rules and models.

When everything goes right, CWPP does not show up: a rule detection log, a discreet alert in the SIEM, and the workload keeps running. When it goes wrong, it is the difference between a crypto miner running for six months and being cut off in three minutes.

How it works: agents and eBPF

The classic choice is agent-based (a process that starts inside the workload and intercepts events) versus eBPF-based (programs running inside the kernel, with no extra process). Each has trade-offs.

user-space agent (Falco, Aqua): broad visibility, easy to update, but it is one more attackable process
eBPF (Tetragon, Cilium Tetragon, Datadog USM): instruments the kernel directly, no extra process, but rules are more limited to what the kernel exposes via hooks
kernel module: maximum visibility, but compromises compatibility with managed kernels (GKE, optimized EKS)
per-pod sidecar: isolates the sensor from the workload, useful when the workload cannot be modified, but costs more resources

Behavioral detection: rules about what happens

The rule does not ask 'which process is running?', it asks 'is this process doing something it has never done before?'. The classic form is a signature over syscalls: process, container, syscall, condition. The modern form is a behavior model (baseline per workload) that triggers on anomalies, not signatures.

Falco is the open standard for signatures. The rule below catches the classic pattern of a shell being opened inside a container, something no legitimate application does in production:

falco-rule.yamlyaml

- rule: Terminal shell in container
  desc: >
    Detect shell spawned inside a workload container.
    Legitimate workloads never open an interactive shell at runtime;
    this is a strong indicator of intrusion or hands-on-keyboard activity.
  condition: >
    container and
    spawned_process and
    proc.name in (shell_binaries)
  output: >
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline
    container=%container.name image=%container.image.repository
    k8s=%k8s.ns.name/%k8s.pod.name
  priority: WARNING
  tags: [container, mitre_execution, mitre_T1059]

Response: from warning to cutoff

Detection without response is just noise. CWPP has three levers, in increasing order of aggressiveness:

alert: sends an event to the SIEM/, a human decides. No change to the workload
network isolation: a NetworkPolicy or starts blocking the pod/VM's egress, cutting exfiltration while keeping the process alive for forensics
kill / quarantine: terminates the process, snapshots the filesystem for analysis, container removed. It is the right response when the rule is certainty (not anomaly)

Where it fits

CWPP lives after the deploy. It assumes CSPM did its part (configuration OK), containers were hardened (runtime OK), and now the question is: what is happening in here? It plugs into the SIEM alongside CloudTrail, flow logs and endpoint EDR for correlation (shell in the container + STS AssumeRole token in the same 30s window = critical incident).

Strengths

detects what no configuration catches: in a legitimate process, exfiltration over an allowed channel, persistence on a clean filesystem
behavior-based rules catch families of attacks, not a specific : a reverse shell in any language triggers the same rule
closing the loop: a filesystem snapshot after detection becomes evidence for the incident, not a prescription for the next attacker

Limitations

an agent inside the workload is new surface: a bug in the sensor becomes RCE inside the node, and history has examples
telemetry cost at scale: instrumenting a thousand containers with eBPF seems free until the log goes to the SIEM, and the bill comes from the provider's switch
behavioral false positives break trust: a rule that is too good is a rule everyone silences; tuning is permanent work, not a one-time setup

CWPPcloud workload protection platformMonitored protection for running workloads: VMs, containers, serverless functions. It combines visibility into what runs (processes, syscalls, network) with prevention (blocking execution, isolating anomalies). It is endpoint security reworked for the ephemeral reality of the cloud.see in glossary →CSPMcloud security posture managementA tool that scans your cloud configuration against best practices and benchmarks (CIS, NIST), flagging public S3 buckets, overly broad IAM, exposed ports. It asks the question humans forget: 'what is misconfigured RIGHT NOW?'.see in glossary →SOARSecurity orchestration, automation and response: running response steps automatically, described in playbooks, with brakes such as human approval and auditing.see in glossary →Security groupsecurity groupA stateful list of rules attached to an instance or network interface in the cloud: who can come in on which port, from which source. It works as a host firewall at the cloud level, and it fails open by default: if you forget to close a port, it stays open to 0.0.0.0/0.see in glossary →VPCvirtual private cloudA logically isolated private network inside the public cloud: you choose the IP range, split it into public and private subnets, and control traffic with route tables and NAT. The VPC is your virtual datacenter; everything running inside it talks as if it were in the same rack.see in glossary →Zero-dayA vulnerability exploited before a public fix exists. Against a zero-day, only defense in depth and detection help in the moment.see in glossary →CVEcommon vulnerabilities and exposuresThe unique identifier of ONE specific public vulnerability, in the format CVE-YEAR-NUMBER. E.g., CVE-2021-44228 is Log4Shell. It is the real instance, not the class of the problem.see in glossary →

connections on the map

CWPP - workload protectionmonitors the runtimeContainers - images and supply chain
CWPP - workload protectiondetects behaviorKubernetes - secure runtime
Logging & detection - signals and alertsprovides the trailCWPP - workload protection
CWPP - workload protectionruntime alertCloud incident response

updated on 14/10/2026 · sources to go deeper · report an error

Study before

test what you learned

Loading questions…