Cloud y respuesta Cloud (CDR): una guía básica para arquitectos de seguridad

Cloud y respuesta Cloud (CDR) es la disciplina de tiempo de ejecución que identifica y detiene las amenazas activas dentro de cloud : la capa situada entre la gestión de la postura de seguridad y la respuesta a incidentes, donde se producen la mayoría de las brechas de seguridad actuales. También es una categoría sobre la que analistas y proveedores siguen debatiendo. Un análisis de Forrester de mayo de 2024 calificó la CDR como una «funcionalidad», no como un «mercado». Dos años más tarde, el informe «Wave for Cloud Application Protection Solutions» del primer trimestre de 2026 de Forrester evaluó a 14 proveedores con cobertura significativa de CDR. Se llame como se llame, esta capacidad es ahora fundamental para que las empresas reguladas detecten el uso indebido de identidades, los ataques al plano de control y el compromiso de cargas de trabajo efímeras: las brechas de seguridad que las herramientas tradicionales de detección y respuesta en los puntos finales y SIEM nunca fueron diseñadas para detectar.

Esta guía explica qué es el CDR, cómo funciona, en qué se diferencia del EDR, NDR, XDR, CSPM, CWPP, CNAPP y SIEM, y cómo se ajusta a las normas NIS2, NIST SP 800-61 (Revisión 3) y el RGPD del Reino Unido. Utilizamos casos reales cloud —Capital One, Snowflake, UNC6426, la Comisión Europea— para mostrar cómo son las señales de CDR en la práctica, y no en el ámbito del marketing.

¿Qué es cloud y respuesta cloud ?

Cloud y respuestaCloud (CDR) es una disciplina de supervisión continua que detecta, investiga y responde a las amenazas activas en los planos cloud , datos y gestión cloud . Recopila datos de telemetría cloud —CloudTrail, registros de actividad de Azure, registros de auditoría de GCP, eventos de procesos en tiempo de ejecución— y aplica análisis de comportamiento para detectar ataques que las herramientas tradicionales de EDR, SIEM y de evaluación de la postura de seguridad pasan por alto.

Cloud un nuevo enfoque, ya que los supuestos en los que se basaba la seguridad de los puntos finales ya no son válidos. Según el informe Cloud Security and Usage Report 2025» de Sysdig, el 60 % de los contenedores tienen una vida útil inferior a un minuto; a menudo no hay un host persistente en el que instalar un agente, y las pruebas forenses desaparecen más rápido de lo que los agregadores de registros en modo por lotes pueden conservarlas. La identidad ha desplazado a la red como vector de acceso inicial dominante: aproximadamente el 83 % de cloud en 2026 comienzan con el compromiso de la identidad, y los estudios de inteligencia sobre amenazas del sector han señalado un aumento interanual del 266 % en las intrusiones cloud para 2026. El panorama financiero coincide con el operativo: el informe «Cost of a Data Breach» del Ponemon Institute ha mostrado sistemáticamente quecloud suponen aproximadamente un millón de dólares más que los incidentes en instalaciones locales —una media cercana a los 5,05 millones de dólares en las ediciones más recientes—.

La supervisión Cloud —la práctica general de vigilar cloud para detectar riesgos e incumplimientos de las políticas— se solapa con el CDR, pero no es lo mismo. La supervisión describe la función de recopilación de datos de telemetría; el CDR es la disciplina de detección y respuesta activas que se basa en esa telemetría. Entre los términos relacionados que encontrará en los materiales de proveedores y analistas se incluyen la detección y respuesta cloud(CNDR) y la detección y respuesta cloud (CTDR). En esencia, significan lo mismo.

La propia categoría es objeto de controversia. En mayo de 2024, Forrester sostenía que «las herramientascloud y respuestacloud no existen» como mercado independiente. Dos años después, el informe «Wave for Cloud Application Protection Solutions» del primer trimestre de 2026 de Forrester evalúa a 14 proveedores con capacidades sustanciales de CDR, lo que supone un cambio significativo en la definición del concepto. Las páginas principales de los proveedores Wiz, Sysdig y Tenable describen el CDR como una disciplina emergente dentro de la familia cloud . Consideramos que la capacidad subyacente —la detección de amenazas en tiempo de ejecución en los tres cloud — es real y necesaria, independientemente de cómo se defina la línea de compra.

De dónde proviene el término «CDR»

El CDR surgió como una categoría acuñada por los proveedores entre los años 2022 y 2024, aproximadamente, a medida que las brechas cloud superaban lo que las herramientas de gestión de la postura de seguridad (CSPM) y las herramientas de refuerzo de cargas de trabajo (CWPP) podían abordar por sí solas. Gartner sitúa el CDR dentro de la familia de plataformas de protección de aplicaciones cloud(CNAPP), un posicionamiento que coincide en líneas generales con la forma en que la mayoría de las empresas estructuran actualmente sus pilas cloud.

Cómo funciona cloud y la respuesta cloud

La analogía más clara la ofrece Sysdig: piensa en el CDR como una cámara de seguridad siempre activa para la cloud. Las herramientas de endpoint te indican qué ha ocurrido en un único equipo. Las herramientas de estado de seguridad te muestran cómo estaba tu configuración en un momento determinado. El CDR te indica qué está ocurriendo en este preciso instante en todos los planos, todos los proveedores y todas las cargas de trabajo, y entrelaza esas señales en una única historia de ataque. Desde el punto de vista operativo, este enfoque se desarrolla en seis pasos:

1. Recopila datos de telemetría cloud de cualquier entorno y proveedor (AWS, Azure, GCP, Kubernetes, SaaS).
2. Normalizar los registros de los distintos proveedores: CloudTrail, los registros de actividad y los registros de auditoría utilizan esquemas diferentes.
3. Analice mediante análisis de comportamiento: establezca un perfil de referencia de la identidad y el comportamiento de los recursos, y luego señale las anomalías.
4. Enriquece las detecciones con información sobre la identidad, inteligencia sobre amenazas y metadatos de los activos.
5. Integrar las señales relacionadas en una única línea argumental de ataque alineada con la cadena de ataque cibernético.
6. Responder: automatizar la contención para las acciones de bajo riesgo; exigir la aprobación de un operador humano para las de alto riesgo (revocar la sesión, aislar la carga de trabajo, bloquear el sujeto de IAM).

Los pasos tercero y cuarto son donde CDR demuestra su valía. La detección basada únicamente en firmas no puede seguir el ritmo de la rapidez cloud , y el volumen bruto de alertas que genera CloudTrail por sí solo es inmanejable. Las referencias de comportamiento —¿qué suele hacer este usuario?; ¿con qué se comunica normalmente esta carga de trabajo?— convierten ese volumen en señales de respuesta a incidentes integradas y de alta fidelidad.

Con agente o sin agente: modelos de implementación

El debate entre los sistemas con agente y sin agente es real, pero cada vez más simplista. El CDR sin agente —basado en instantáneas y controlado por API— ofrece amplitud y una rápida implementación sin ninguna fricción en la carga de trabajo. Es excelente para la visibilidad del plano de control y del plano de gestión, la cobertura de múltiples cuentas y la rapidez de incorporación. El CDR basado en agentes (normalmente eBPF o sidecar) aporta profundidad en tiempo de ejecución: eventos a nivel de proceso, trazas de llamadas al sistema, llamadas de red dentro de contenedores y el tipo de análisis forense del plano de datos que, de otro modo, las cargas de trabajo efímeras borrarían. La mayoría de los programas modernos combinan ambos: sin agentes para la amplitud, y basado en agentes para la profundidad en cargas de trabajo críticas y clústeres de seguridad de Kubernetes donde el análisis forense en tiempo de ejecución es importante.

El papel de la inteligencia artificial y el análisis del comportamiento

La detección basada en el comportamiento ya es una práctica habitual, no un objetivo a alcanzar. Según el informe de Sysdig de 2026, más del 70 % de los equipos utilizan la detección basada en el comportamiento, que abarca el 91 % de los entornos. La terminación automática de procesos sospechosos aumentó aproximadamente un 140 % interanual. Solo alrededor del 2,8 % de cloud gestionadas cloud son humanas; el resto son entidades de servicio, identidades de máquina y tokens de carga de trabajo efímeros, lo que explica precisamente por qué el enriquecimiento del contexto de identidad es imprescindible. La adopción de paquetes específicos de IA creció unas 25 veces interanual, ampliando la superficie de ataque de la cadena de suministro que el CDR debe vigilar.

La respuesta de los defensores es la «paridad a velocidad de máquina». Dark Reading ha popularizado el criterio de referencia 5/5/5 —5 segundos para detectar, 5 minutos para clasificar y 5 minutos para responder— como objetivo operativo en escenarios de ataques cloud, en los que el tiempo de escape se mide en minutos, no en horas.

La arquitectura de tres planos: control, datos y gestión

La mayor parte de la confusión en torno al CDR se aclara en cuanto se divide la cloud en sus tres planos. Este es el esquema básico que todo arquitecto de seguridad debería ser capaz de dibujar en una pizarra en 30 segundos.

• Plano de control — la API y la interfaz de gestión donde tienen lugar los eventos de configuración, orquestación e IAM. Telemetría: AWS CloudTrail, registros de actividad de Azure, registros de auditoría de GCP. Detecciones: asunción anómala de roles de IAM, abuso de políticas de confianza de OIDC, creación inesperada de pilas de CloudFormation con CAPABILITY_NAMED_IAM fuera de los periodos de cambio, cambios anómalos en las políticas de S3.
• Plano de datos: la capa de tiempo de ejecución donde se ejecutan realmente las cargas de trabajo (contenedores, máquinas virtuales, funciones sin servidor). Telemetría: eventos de procesos, llamadas al sistema, tiempo de ejecución de contenedores, flujos de red, señales derivadas de eBPF. Detecciones: anomalías en la creación de procesos, intentos de fuga de contenedores, llamadas salientes inesperadas, ejecución de mineros de criptomonedas.
• Plano de gestión: identidad, facturación, gobernanza y superficie de federación (acciones administrativas, eventos de identidad federada, comportamiento de entidades de servicio, anomalías en la facturación). Detecciones: cadenas de escalada de privilegios, comportamiento anómalo de entidades de servicio, uso indebido de tokens federados, actividad inusual de asunción de roles entre cuentas.

Una imagen mental útil: el plano de control es la centralita cloud, el plano de datos es el taller donde realmente se lleva a cabo el trabajo, y el plano de gestión es la oficina principal donde se toman las decisiones sobre identidad y gobernanza. Los atacantes deben atravesar al menos dos planos para causar un daño significativo. Los defensores necesitan visibilidad sobre los tres para detectarlos.

Asignación de fuentes de telemetría a aviones

En la tabla siguiente se asigna cada plano a sus fuentes de telemetría habituales, un ejemplo de detección y el MITRE ATT&CK que pone de manifiesto. Esta correspondencia marca la diferencia entre el ruido de las alertas y una lista de detecciones útiles.

Tabla 1: Asignación de las fuentes cloud a los tres planos de detección del CDR.

Las cifras de 2026 explican por qué este mapa es relevante ahora. El tiempo de propagación Cloud se ha reducido a unos 29 minutos, según el informe «Threat Horizons H1 2026» Cloud Google Cloud. El clúster UNC6426, al que volveremos en los casos prácticos, logró acceso administrativo completo a AWS en menos de 72 horas a partir de un único paquete npm comprometido: toda la cadena de ataque atravesó los tres planos (creación de la pila del plano de control, abuso de la confianza OIDC en el plano de gestión y enumeración de S3 en el plano de datos). Para obtener más información sobre la superficie de ataque del plano de control en concreto, consulte la protección del planocloud .

CDR frente a EDR, NDR, XDR, CSPM, CWPP, CNAPP y SIEM

La pregunta más habitual en materia de arquitectura que surge en las evaluaciones de CDR es: «¿A qué sustituye esto?». La respuesta sincera es: a nada. El ámbito de actuación característico de CDR es la detección de amenazas en tiempo real en los tres cloud , un ámbito que las herramientas de puntos finales, de red, de estado de seguridad y de cargas de trabajo solo abarcan parcialmente. Estas categorías son complementarias, y la mayoría de los programas modernos implementan varias de ellas a la vez.

• CDR frente a EDR: la detección y respuesta en endpoints (EDR) se centra en los endpoints y servidores gestionados. La detección y respuesta en la nube (CDR) se centra en el plano cloud y en las cargas de trabajo efímeras, donde no puede instalarse ningún agente persistente en los endpoints. La EDR es esencial para flotas de ordenadores portátiles y servidores; la CDR es esencial para entornos de ejecución de AWS, Azure, GCP y Kubernetes.
• CDR frente a NDR: la detección y respuesta de red (NDR) supervisa el tráfico de red en los ejes este-oeste y norte-sur. El CDR supervisa los eventos relacionados con las API cloud y la identidad. Ambos son complementarios en entornos cloud híbrida, donde son importantes tanto la red local como el plano cloud .
• CDR frente a XDR: XDR es una capa de correlación que abarca múltiples fuentes. CDR es una capa de detección específica para cada dominio que genera señales de alta fidelidad que XDR puede procesar. Consulte «EDR frente a XDR» para conocer cómo ha evolucionado el modelo de correlación más amplio a partir de los orígenes en los puntos finales.
• CDR frente a CSPM: la gestión de la postura Cloud detecta errores de configuración en los datos en reposo. El CDR detecta ataques activos en tiempo real. El CSPM te avisa de que la puerta estaba abierta; el CDR te dice que alguien ha entrado por ella. Son complementarios, no competidores.
• CDR frente a CWPP: las plataformas de protección Cloud ) refuerzan la seguridad de las cargas de trabajo individuales (análisis de vulnerabilidades, aplicación de configuraciones y protección en tiempo de ejecución). El CDR detecta amenazas activas en toda la cloud , incluidos los planos de control y gestión que las CWPP no abarcan. A menudo se ofrecen conjuntamente dentro de una CNAPP.
• CDR frente a CNAPP: CNAPP es la familia de plataformas que agrupa CSPM, CWPP, CDR y otras. CDR es el componente de detección y respuesta en tiempo real de CNAPP, no una categoría competidora.
• CDR frente a SIEM: el SIEM agrega y correlaciona los registros de toda la empresa. El CDR está diseñado específicamente para la semántica cloud : relaciones de IAM, identificadores efímeros y grafos de cuentas múltiples. La mayoría de los programas modernos incorporan las señales del CDR en los flujos de trabajo de optimización del SIEM, en lugar de tener que elegir entre uno u otro. El análisis imparcial de TechTarget sobre el CDR frente al EDR, el NDR y el XDR llega a la misma conclusión.

Tabla 2: Comparación del alcance del CDR con el de otras categorías relacionadas de detección y respuesta.

¿Es CDR una categoría real o solo un conjunto de características?

Esto merece una respuesta directa. La postura de Forrester en mayo de 2024 era que el CDR no constituye un mercado independiente, sino que esta funcionalidad se integra en las plataformas CNAPP, SIEM y otras plataformas relacionadas, y no justifica una línea de compra separada. El argumento era razonable en 2024, pero se ha debilitado desde entonces. El informe «Wave for Cloud Application Protection Solutions» del primer trimestre de 2026 de Forrester evaluó a 14 proveedores con una cobertura significativa de CDR, lo que complica una interpretación estricta del enfoque «característica, no categoría». La consolidación de los hiperescaladores refuerza esta tendencia: Google completó la adquisición de Wiz por 32 000 millones de dólares el 11 de marzo de 2026, según la cobertura de TechCrunch sobre el cierre de la operación, incorporando una capacidad significativa de CDR a la cartera de un hiperescalador.

Nuestra opinión: esta capacidad subyacente es real y necesaria, y no queda suficientemente cubierta por EDR, NDR, CSPM, CWPP o SIEM por sí solos. El hecho de adquirirla como producto independiente o como un componente del CNAPP depende de la composición de la pila. Los programas nuevos suelen integrarse en el CNAPP. Los programas maduros que cuentan con importantes inversiones en SIEM y EDR suelen utilizar el CDR como una capa independiente que alimenta al resto de la pila.

Cloud y respuesta Cloud en la práctica

Los argumentos abstractos se contrarrestan más fácilmente con ataques concretos. Las cuatro brechas que se exponen a continuación muestran cómo se presentan las señales de CDR en los tres planos y qué consecuencias tuvo su ausencia para las organizaciones afectadas.

Caso 1 — Capital One (julio de 2019, retrospectivo). Una configuración errónea de AWS WAF, combinada con una falsificación de solicitudes del lado del servidor (SSRF), permitió a un atacante hacer un uso indebido de un rol IAM de metadatos de una instancia EC2 para enumerar y extraer aproximadamente 106 millones de registros de solicitantes de tarjetas de crédito de EE. UU. y Canadá desde S3. El ataque se prolongó durante meses antes de ser detectado. Señal de CDR: comportamiento anómalo en el plano de datos y el plano de control: un único sujeto de IAM que extraía volúmenes inusuales de lectura de S3, procedentes de una instancia de EC2 cuyo comportamiento normal nunca incluía la enumeración masiva de S3. Esta es precisamente la señal entre planos que el análisis de comportamiento de CloudTrail, junto con la detección de amenazas de AWS, está diseñado para detectar.

Caso 2 — Snowflake (2024). La reutilización de credenciales (algunas de las cuales se remontan a registros de programas de robo de información de 2020), junto con la falta de aplicación de la autenticación de dos factores (MFA) por parte de los clientes, provocó que unas 165 organizaciones de clientes se vieran afectadas. La retrospectiva de Snowflake de 2024 deCloud es el análisis público de referencia. Señales de CDR: inicios de sesión con ubicaciones geográficas anómalas, volúmenes elevados de consultas y la ausencia de MFA en superficies de autenticación SaaS con privilegios elevados, todo ello detectable a través de la telemetría de identidad del plano de gestión. La lección es que las consecuencias del robo de credenciales son una preocupación de CDR a nivel de SaaS, no solo de los puntos finales.

Caso 3 — UNC6426 (primer trimestre de 2026). Este es el caso práctico más claro de los tres planos que se conoce públicamente. Un paquete npm comprometido (QUIETVAULT), un ejemplo de libro de texto ataque a la cadena de suministro — robó tokens de GitHub. Una política de confianza OIDC entre GitHub y AWS excesivamente amplia permitió que esos tokens asumieran un rol de IAM de AWS. Se utilizó CloudFormation para crear una pila de IAM con CAPABILITY_NAMED_IAM, lo que le permitió al atacante obtener acceso administrativo a AWS en menos de 72 horas. A continuación, el atacante realizó un escaneo de S3, cerró instancias de EC2 y RDS, y descifró las claves de las aplicaciones. La secuencia de eventos se documenta en La cobertura de The Hacker News sobre el ataque a la cadena de suministro de npm relacionado con UNC6426, el Sesión informativa de la Cloud Alliance sobre el uso indebido de la cadena de confianza OIDCy Informe «Threat Horizons» del primer semestre de 2026 Cloud Google Cloud. Señal CDR: Emisión de tokens STS desde un principal que no sea CI en combinación con CloudFormation CAPABILITY_NAMED_IAM creación de pilas fuera de la ventana de cambios: una narrativa que entrelaza el plano de control y el plano de gestión, y que ninguna categoría de herramientas puede abarcar por sí sola.

Caso 4 — Comisión Europea, Europa.eu (marzo de 2026). Una brecha en la cadena de suministro de Trivy permitió que el atacante permaneciera en el sistema durante cinco días, en los que se sustrajeron aproximadamente 91,7 GB de la infraestructura de AWS alojada en la UE. El blog de CERT-EU sobre cloud de la Comisión Europea, la cobertura de BleepingComputer y el informe de Help Net Security documentan la cronología de los hechos. Señal de CDR: anomalías en la API del plano de control que se mantuvieron durante un periodo de cinco días, el tipo de patrón que las herramientas basadas únicamente en la postura de seguridad no pueden detectar y que la correlación SIEM en modo por lotes suele pasar por alto sin un contexto cloud.

Tabla 3: Cronología de los incidentes y señales del CDR en cloud recientes cloud .

Análisis forense de cargas de trabajo efímeras

Las cargas de trabajo efímeras desmienten los supuestos de la informática forense tradicional. Cuando el 60 % de los contenedores tienen una vida útil inferior a un minuto, la recogida de pruebas a posteriori suele ser imposible. La solución operativa pasa por la captura en tiempo real y la conservación inmutable:

1. Captura eventos de procesos y datos de telemetría de red en tiempo real mediante agentes basados en eBPF en cargas de trabajo críticas: la única forma fiable de conservar pruebas a nivel de llamada al sistema antes de que finalice un contenedor.
2. Amplíe el periodo de conservación de los registros de auditoría cloud más allá del plazo predeterminado habitual de entre 30 y 90 días, especialmente en el caso de los eventos relacionados con el plano de control y la gestión de identidades y accesos (IAM). Las intrusiones de larga duración, como la filtración de datos de la Comisión Europea, pueden superar el plazo de conservación predeterminado.
3. Conserve cloud en el momento de la detección —instantáneas de EBS, instantáneas de discos gestionados de Azure, instantáneas de discos persistentes de GCP— y etiquételas como pruebas forenses para evitar que se eliminen automáticamente.
4. Mantenga la cadena de custodia forense utilizando primitivas de almacenamiento cloud(S3 Object Lock con modo de cumplimiento normativo, almacenamiento de blobs inmutables de Azure). La retención de datos de escritura única es la base de cloud admisible.

Detección y prevención de cloud

Las siete prácticas defensivas que se exponen a continuación se han recopilado a partir de las directrices generales de distintos proveedores y se relacionan con MITRE ATT&CK específicas MITRE ATT&CK cuando procede. Considéralas controles defensivos, no listas de verificación de proveedores.

1. Cubra todos los entornos: públicos, privados,cloud y SaaS. La supervisión por parte de un único proveedor es el tipo de silo más habitual y la laguna de detección más común.
2. Supervisión continua en tiempo real: ingesta de CloudTrail, registros de actividad y registros de auditoría en tiempo de ejecución. La agregación de registros en modo por lotes no cumple con el criterio de referencia 5/5/5 ni con los plazos de 24 horas de NIS2.
3. El análisis del comportamiento frente a la detección basada únicamente en firmas: correlaciona eventos de distintos recursos en narrativas únicas. El 70 % de los equipos que actualmente utilizan la detección basada en el comportamiento, y que cubren el 91 % de los entornos, lo hacen porque la detección basada en reglas no puede seguir el ritmo de la rapidez cloud .
4. El contexto de identidad es obligatorio — correlacionar los eventos en tiempo de ejecución con las acciones de identidad (T1078.004, T1552). Esa cifra del 83 % de casos de suplantación de identidad es la única razón detección y respuesta ante amenazas a la identidad y detección y contención de ataques basados en la identidad ahora se encuentran junto al CDR.
5. Respuesta automatizada con controles de seguridad que incluyen la intervención humana: revocar sesiones automáticamente; exigir la aprobación humana para la suspensión de roles de IAM en cuentas de producción. La automatización sin controles de seguridad provoca interrupciones del servicio.
6. Integración con SIEM y SOAR: el CDR mejora las plataformas existentes en lugar de sustituirlas. Envía a las operaciones del SOC detecciones combinadas de alta precisión, en lugar de un volumen de alertas sin procesar.
7. Prepárate para lo efímero: recopila pruebas forenses en tiempo real, no a posteriori. Asume que la carga de trabajo habrá desaparecido antes de que termines de clasificarla.

Tabla 4: Siete prácticas de seguridad que garantizan la eficacia operativa de cloud y la respuesta cloud .

Para un análisis más detallado de la disciplina de detección subyacente, véase la detección de amenazas y la Cloud MITRE ATT&CK Cloud . Como marco complementario de casos de uso, el análisis de casos de uso de CDR de TechTarget constituye una referencia imparcial muy útil. Entre los marcos del sector con los que conviene alinearse se incluyen el «Top 10 de seguridad de aplicaciones Cloud de OWASP y la «Guía Cloud de ENISA.

Cloud y respuesta Cloud y cumplimiento normativo

El CDR es hoy en día una herramienta de cumplimiento normativo tanto como de seguridad. Los plazos de 24 y 72 horas establecidos en la normativa vigente de la UE y del Reino Unido no pueden cumplirse mediante la revisión de registros en modo por lotes y la clasificación manual.

• NIST SP 800-61, revisión 3 (abril de 2025): la primera actualización de la guía del Gobierno de EE. UU. sobre gestión de incidentes desde 2012. Aborda explícitamente cloud y las limitaciones en la conservación de registros, y vincula la respuesta a incidentes con las funciones de detección, respuesta y recuperación del NIST CSF 2.0. El texto completo está disponible en el NIST. Se complementa con la NIST SP 800-207 Zero Trust ; véase zero trust para conocer el contexto arquitectónico más amplio—, como guía federal fundamental para los programas cloud .
• NIS2 (UE): el artículo 23 sobre notificación de incidentes exige una alerta temprana en un plazo de 24 horas y una notificación del incidente en un plazo de 72 horas, acompañada de una evaluación inicial. Las multas máximas ascienden a 10 millones de euros o al 2 % de la facturación global en el caso de las entidades esenciales. La página de la Comisión Europea dedicada a la Directiva NIS2 es la fuente principal. La detección de CDR en tiempo real es lo que hace que el plazo de 24 horas sea viable desde el punto de vista operativo.
• RGPD del Reino Unido: el artículo 33 exige la notificación de las violaciones de datos a la ICO en un plazo de 72 horas. El mismo requisito operativo: una detección que identifique los incidentes sujetos a la normativa con la suficiente rapidez como para iniciar el plazo con seguridad. Consulte las directrices de la ICO del Reino Unido sobre la Directiva NIS y el RGPD del Reino Unido, así como el cumplimiento del RGPD, para conocer el contexto normativo más amplio.
• Proyecto de ley del Reino Unido sobre ciberseguridad y resiliencia: en fase de redacción en el momento de redactar este documento; su entrada en vigor está prevista para mediados o finales de 2026. Establece nuevas obligaciones en materia de información y resiliencia para las entidades de servicios esenciales y digitales del Reino Unido.
• MITRE ATT&CK Cloud : el pilar defensivo que demuestra la eficacia en las conversaciones de auditoría. Al relacionar las detecciones del CDR con las técnicas de ATT&CK, los equipos de cumplimiento normativo pueden demostrar la cobertura de forma concreta.
• Arquitectura de referencia Cloud de la CISA: relevante para el ámbito federal de EE. UU. y los entornos relacionados con los proveedores de servicios en la nube (CSP); la página del proyecto SCuBA de la CISA es el punto de acceso oficial.

Tabla 5: Correspondencia entre las capacidades de CDR y las principales normativas sobre cloud .

Enfoques modernos y hacia dónde se dirige la categoría

Hay tres factores que están redefiniendo el CDR en los próximos 12 a 24 meses. En primer lugar, cloud basada en la IA está pasando del concepto al producto: la corrección autónoma, que detecta una anomalía y la contiene sin intervención humana, ya es una realidad entre los principales participantes del sector CNAPP en el informe Forrester Wave del primer trimestre de 2026. En segundo lugar, la consolidación de los hiperescaladores se aceleró significativamente con el cierre de la adquisición de Wiz por parte de Google por 32 000 millones de dólares el 11 de marzo de 2026; los proveedores independientes de CDR tendrán que diferenciarse en cuanto a la calidad de las señales y la neutralidad de integración encloud. En tercer lugar, los defensores están avanzando hacia la paridad en velocidad con los atacantes asistidos por IA: el informe de Sysdig de 2026 muestra que la detección basada en el comportamiento y la terminación automática son prácticas estándar, no un factor de diferenciación.

Para los equipos de seguridad con menos de cinco empleados a tiempo completo, esto implica que algún tipo de solución gestionada de detección y respuesta se está convirtiendo cada vez más en la respuesta adecuada para cloud el ritmo operativo necesario para cumplir con los plazos de 5/5/5 y las exigencias de NIS2 las 24 horas del día es difícil de mantener internamente con equipos de tamaño reducido. La perspectiva para esta categoría es la consolidación: el CDR como línea de compra independiente seguirá existiendo para las organizaciones con pilas CNAPP maduras; se integrará en la plataforma CNAPP para las organizaciones que empiecen desde cero. En cualquier caso, la capacidad de detección en tiempo de ejecución es imprescindible. Los resúmenes de posicionamiento del sector —incluida la visión general de Medium sobre el posicionamiento de Gartner respecto al CDR y las referencias a marcos de proveedores, como el marco de mejores prácticas de CDR de Skyhawk — ofrecen contexto adicional.

Cómo Vectra AI cloud y la respuesta en cloud

El enfoque Vectra AI para cloud y respuesta cloud refleja una filosofía de «asumir la compromisión» aplicada al entorno cloud: observabilidad continua en los tres planos, Attack Signal Intelligence™ impulsada por IA para filtrar el ruido y revelar secuencias de ataque interconectadas, y medidas fundamentadas que contienen las amenazas activas antes de que se produzca el movimiento lateral. El objetivo no es generar más alertas, sino proporcionar la señal adecuada a la velocidad de las máquinas. Un análisis independiente de IDC sobre la Vectra AI reveló una cobertura MITRE ATT&CK superior al 90 % y un retorno de la inversión del 391 % con una amortización en 6 meses. Para conocer la cobertura de tiempo de ejecución específica de AWS, consulte Vectra AI para AWS.

Conclusión

Cloud y respuesta Cloud es la capa de tiempo de ejecución que transforma cloud en historias de ataques completas; no se trata de otra categoría de productos que compita con EDR, NDR o SIEM, sino de la disciplina que, por fin, hace que los tres cloud resulten comprensibles para las operaciones de seguridad. El cambio de una mentalidad centrada únicamente en la postura de seguridad y en los puntos finales ya no es opcional. La identidad es el vector de acceso inicial predominante. Las cargas de trabajo son efímeras. El tiempo de escape se mide en minutos. Los reguladores imponen plazos de 24 horas. Las organizaciones que resistirán en esas condiciones son aquellas que tratan cloud en tiempo de ejecución cloud como una capacidad de primer orden, independientemente de cómo decidan presentarla.

Si está creando o actualizando un programa cloud, comience por el modelo mental de tres planos, compare su telemetría actual con él e identifique los planos en los que dispone de detección, en lugar de limitarse al registro de datos. Combine el CDR con el análisis de comportamiento, incorpórelo a su SIEM actual y a los flujos de trabajo ampliados de detección y respuesta, y adapte la cobertura de detección a laCloud MITRE ATT&CK Cloud para que las conversaciones de auditoría cuenten con pruebas concretas en las que basarse. Para profundizar en disciplinas afines, consulta la detección y respuesta ante amenazas de identidad, la detección de amenazas de AWS y la seguridad de Kubernetes en los temas relacionados que figuran a continuación. Si deseas conocer la metodología, la página Vectra AI (enlace arriba) describe cómo Attack Signal Intelligence™ aborda el mismo problema.