CWPP - protección de workloads
Cloud Workload Protection Platform vigila lo que ocurre dentro de la VM, el contenedor y la función serverless: syscalls, conexiones y procesos, en tiempo de ejecución.
Qué es
CWPP () es el sensor dentro de la carga: VM, contenedor, función serverless, host de Kubernetes. mira la configuración; CWPP mira el comportamiento. Ve syscalls, conexiones de red, procesos, lectura de archivos, modificación de binarios, y los correlaciona contra reglas y modelos.
Cuando todo sale bien, CWPP no aparece: un log de detección de la regla, una alerta discreta en el SIEM, y la carga sigue corriendo. Cuando sale mal, es la diferencia entre un crypto miner corriendo seis meses y ser cortado en tres minutos.
Cómo funciona: agents y eBPF
La elección clásica es basado en agent (un proceso que arranca dentro de la carga e intercepta eventos) versus basado en eBPF (programas corriendo dentro del kernel, sin proceso extra). Cada uno tiene sus trade-offs.
- agent en user-space (Falco, Aqua): visibilidad amplia, fácil de actualizar, pero es un proceso más que se puede atacar
- eBPF (Tetragon, Cilium Tetragon, Datadog USM): instrumenta el kernel directamente, sin proceso extra, pero las reglas quedan más limitadas a lo que el kernel expone vía hooks
- módulo de kernel: máxima visibilidad, pero compromete la compatibilidad con kernels administrados (GKE, EKS optimizado)
- sidecar por pod: aísla el sensor de la carga, útil cuando la carga no se puede modificar, pero cuesta más recursos
Detección conductual: reglas sobre lo que ocurre
La regla no pregunta '¿qué proceso está corriendo?', pregunta '¿este proceso está haciendo algo que nunca hizo antes?'. La forma clásica es una firma sobre syscalls: proceso, contenedor, syscall, condición. La forma moderna es un modelo de comportamiento (baseline por workload) que dispara una anomalía, no una firma.
Falco es el estándar abierto para firmas. La regla de abajo atrapa el patrón clásico de un shell abierto dentro de un contenedor, algo que ninguna aplicación legítima hace en producción:
- rule: Terminal shell in container
desc: >
Detecta un shell lanzado dentro de un contenedor de workload.
Los workloads legítimos nunca abren un shell interactivo en runtime;
es un fuerte indicador de intrusión o de actividad manual en el teclado.
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]Respuesta: del aviso al corte
Detección sin respuesta es solo ruido. CWPP tiene tres palancas, en orden creciente de agresividad:
- alerta: envía un evento al SIEM/, un humano decide. Sin cambios en el workload
- aislamiento de red: una NetworkPolicy o un pasa a bloquear el egress del pod/VM, cortando la exfiltración pero manteniendo el proceso vivo para forense
- kill / quarantine: termina el proceso, snapshot del filesystem para análisis, contenedor eliminado. Es la respuesta correcta cuando la regla es certeza (no anomalía)
Dónde aparece
CWPP vive después del deploy. Asume que CSPM hizo su parte (configuración correcta), que los contenedores fueron endurecidos (runtime correcto), y ahora la pregunta es: ¿qué está pasando aquí adentro? Se conecta al SIEM junto con CloudTrail, flow logs y el EDR de endpoint para correlación (shell en el contenedor + token STS AssumeRole en la misma ventana de 30s = incidente crítico).
Puntos fuertes
- detecta lo que ninguna configuración atrapa: en un proceso legítimo, exfiltración por un canal permitido, persistencia en un filesystem limpio
- las reglas basadas en comportamiento atrapan familias de ataques, no un específico: un reverse shell en cualquier lenguaje dispara la misma regla
- cerrando el ciclo: el snapshot del filesystem posterior a la detección se vuelve evidencia del incidente, no una receta para el próximo atacante
Limitaciones
- un agent dentro de la carga es superficie nueva: un bug en el sensor se vuelve RCE dentro del nodo, y la historia tiene ejemplos
- costo de telemetría a escala: instrumentar mil contenedores con eBPF parece gratis hasta que el log va al SIEM, y la cuenta la cobra el switch del proveedor
- los falsos positivos de comportamiento rompen la confianza: una regla demasiado buena es una regla que todos silencian; el tuning es trabajo permanente, no un setup de una sola vez
conexiones en el mapa
- CWPP - protección de workloadsmonitorea el runtimeContainers - imágenes y cadena de suministro
- CWPP - protección de workloadsdetecta comportamientoKubernetes - runtime seguro
- Logging & detection - señales y alertasprovee el rastroCWPP - protección de workloads
- CWPP - protección de workloadsalerta de runtimeRespuesta a incidentes en la nube
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…