El entorno tecnológico de un proveedor de gestión de datos de salud había evolucionado durante tres años desde una implementación monolítica en las instalaciones hasta un entorno híbrido compuesto por una red corporativa, un entorno de infraestructura en AWS, servidores Windows para cargas de trabajo heredadas y un clúster de Kubernetes operado por un proveedor de DevOps gestionado para su aplicación de portal de pacientes. El monitoreo de seguridad del proveedor había evolucionado junto con la infraestructura (seguridad de endpoints en los servidores Windows, monitoreo de seguridad de AWS en su SIEM, monitoreo de red en la red corporativa), pero el clúster de Kubernetes era una zona gris. El acuerdo de servicio del proveedor de DevOps gestionado incluía el monitoreo del estado y el rendimiento del clúster. El monitoreo de seguridad del clúster (en concreto, la seguridad en tiempo de ejecución, la aplicación de las políticas de red y la gestión de vulnerabilidades de las imágenes de contenedores) se había discutido durante la incorporación, pero no se había asignado formalmente a ninguna de las partes. El equipo de seguridad del proveedor creía que el monitoreo del proveedor de DevOps cubría tanto la seguridad como el rendimiento. El equipo del proveedor de DevOps entendía que su alcance era el monitoreo operativo, no el monitoreo de seguridad. Cuando se explotó una vulnerabilidad de escape de contenedor en uno de los contenedores de la aplicación del portal durante una prueba de penetración encargada por el proveedor, el evaluador pudo pasar de un contenedor comprometido al nodo de Kubernetes subyacente sin generar ninguna alerta de seguridad en ninguna plataforma de monitoreo. El SIEM del proveedor no cubría el clúster. El monitoreo del proveedor de DevOps no incluía alertas de seguridad en tiempo de ejecución. La brecha existía desde que se implementó el clúster.
¿Cuál es realmente el problema de la visibilidad entre plataformas?
Las brechas de visibilidad entre plataformas son los puntos ciegos del monitoreo de seguridad que existen en las interfaces entre distintas plataformas tecnológicas, servicios gestionados y operadores externos; en concreto, los sistemas y entornos en los que el límite de la responsabilidad de monitoreo entre dos partes es ambiguo, se supone en lugar de confirmarse o se excluye explícitamente del alcance de una parte sin incluirse explícitamente en el de la otra. Estas brechas no son fallas técnicas de una plataforma de monitoreo concreta; son fallas de gobierno al definir qué parte es responsable de monitorear qué sistemas.
El problema de la responsabilidad supuesta es el mecanismo operativo. En entornos tecnológicos complejos con varios proveedores de servicios gestionados y operadores externos, el alcance del monitoreo con frecuencia se supone en lugar de especificarse por contrato. El proveedor supone que el proveedor de DevOps monitorea la seguridad del clúster. El proveedor de DevOps supone que el equipo de seguridad del proveedor monitorea los aspectos de seguridad. La suposición es razonable desde la perspectiva de cada parte: cada una cree que la otra ha aceptado la responsabilidad. Ninguna confirma la suposición. En la práctica, el monitoreo de seguridad del clúster de Kubernetes no está asignado a nadie.
El problema de la ambigüedad del alcance de los servicios gestionados es la falla de gobierno específica. Los acuerdos de servicios gestionados con frecuencia especifican el alcance del monitoreo en términos operativos (estado del clúster, rendimiento, disponibilidad) sin abordar explícitamente el monitoreo de seguridad. El paso del monitoreo operativo al monitoreo de seguridad es una distinción de alcance significativa que requiere un tratamiento explícito en el acuerdo de servicio. Sin ese tratamiento explícito, ambas partes recurren a su interpretación natural: el cliente supone que la seguridad está incluida en el monitoreo y el proveedor de servicios gestionados supone que la seguridad es responsabilidad del cliente.
- Brecha en la responsabilidad de monitoreo: cada parte supone que la otra cubre la seguridad del clúster de Kubernetes
- Acuerdo de servicios gestionados que especifica el monitoreo operativo sin abordar explícitamente la seguridad
- Inventario de cobertura incompleto: el clúster de Kubernetes no está dentro del alcance de seguridad confirmado del proveedor ni del proveedor de DevOps
- Escape de contenedor y acceso al nodo sin generar alertas en ninguna plataforma de monitoreo
- Suposición, en lugar de confirmación, del alcance del monitoreo en el límite del servicio gestionado
Por qué es importante
La visibilidad entre plataformas es importante para TPRM porque los entornos tecnológicos complejos de los proveedores (con varios servicios gestionados, operadores externos e infraestructura híbrida) crean oportunidades de brechas de monitoreo en cada interfaz entre las partes. Un proveedor cuyo monitoreo de seguridad confirmó la cobertura de endpoints, nube y red puede tener un portal de pacientes en un clúster de Kubernetes que no está cubierto por ninguno de esos tres programas de monitoreo, sin que ni el proveedor ni su proveedor de DevOps hayan confirmado la responsabilidad de su monitoreo de seguridad.
Dónde se equivocan la mayoría de los equipos
La falla más constante es aceptar confirmaciones de monitoreo por categorías (seguridad de endpoints confirmada, seguridad en la nube confirmada, seguridad de red confirmada) sin preguntar si hay componentes tecnológicos que no estén cubiertos por ninguna de esas categorías. La brecha suele encontrarse en los servicios gestionados y en los componentes operados por terceros.
- Cobertura por categorías confirmada sin inventario: qué está cubierto y qué no
- Alcance del monitoreo de seguridad del servicio gestionado no evaluado
- Seguridad de Kubernetes y de contenedores no evaluada específicamente
- Monitoreo de componentes operados por terceros no verificado
- Responsabilidad de monitoreo confirmada para cada componente en lugar de supuesta
Cómo se ve una buena práctica
Los programas maduros de visibilidad entre plataformas mantienen un inventario completo de componentes tecnológicos vinculado a una responsabilidad de monitoreo confirmada, de modo que cada sistema, servicio y componente tenga un responsable de monitoreo identificado y no una brecha cubierta por suposiciones.
- Inventario de componentes tecnológicos: todos los sistemas vinculados a un responsable de monitoreo confirmado
- Alcance del monitoreo de seguridad del servicio gestionado definido explícitamente en los acuerdos
- Monitoreo de seguridad de contenedores y de Kubernetes: seguridad en tiempo de ejecución confirmada, no supuesta
- Confirmación de la responsabilidad de monitoreo: el responsable de cada componente se confirma explícitamente, no se supone
- Revisión de identificación de brechas: revisión anual que identifica los componentes sin monitoreo confirmado
Herramientas
Seguridad de contenedores: Falco, Sysdig, Aqua Security para la seguridad en tiempo de ejecución de Kubernetes
Las plataformas de seguridad en tiempo de ejecución para Kubernetes monitorean en tiempo real el comportamiento de los contenedores, la aplicación de las políticas de red y el acceso a nivel de nodo, es decir, el monitoreo de seguridad que no ofrecen las plataformas de monitoreo operativo de DevOps. Para los profesionales de TPRM, preguntar si los entornos de Kubernetes del proveedor cuentan con monitoreo de seguridad en tiempo de ejecución (en concreto, detección de escapes de contenedores y de accesos a nodos) constituye una pregunta concreta sobre la cobertura entre plataformas.
Desafíos de gobernanza
El desafío de gobierno del monitoreo entre plataformas es el requisito de claridad en los contratos de servicios gestionados. El alcance del monitoreo debe especificarse explícitamente para cada componente en los acuerdos de servicios gestionados: el monitoreo operativo y el monitoreo de seguridad son alcances distintos que requieren un tratamiento explícito por separado. La solución de gobierno es exigir una definición del alcance del monitoreo en todos los acuerdos de servicios gestionados, junto con una revisión del inventario de cobertura para identificar brechas.
- Exigir un alcance explícito del monitoreo de seguridad en todos los acuerdos de servicios gestionados
- Mantener un inventario de monitoreo de los componentes tecnológicos: todos los componentes, con responsable confirmado
- Implementar seguridad en tiempo de ejecución de Kubernetes para los entornos de contenedores
- Revisión anual de brechas de cobertura: identificar los componentes sin monitoreo confirmado
- Confirmar el alcance de seguridad del servicio gestionado, no suponer que coincide con el alcance operativo
Si usted forma parte de un equipo pequeño
Con su proveedor de mayor riesgo, solicite su inventario de monitoreo de componentes tecnológicos: una lista de sus principales componentes tecnológicos y el responsable de monitoreo confirmado de cada uno. Si no cuenta con ese inventario, pregunte específicamente: ¿sus entornos de Kubernetes o de contenedores están cubiertos por su monitoreo de seguridad? Si se produjera un escape de contenedor en ese entorno, ¿se activaría una alerta en su SIEM? Esas dos preguntas revelan si existe la brecha de visibilidad entre plataformas en el entorno específico con más probabilidades de no estar monitoreado.
- Solicitar el inventario de monitoreo de los componentes tecnológicos
- Preguntar específicamente si los entornos de Kubernetes y de contenedores cuentan con monitoreo de seguridad en tiempo de ejecución
- Preguntar si un escape de contenedor generaría una alerta en el SIEM
- Preguntar por el alcance del monitoreo de seguridad del servicio gestionado en los contratos
Qué exigir
Pregunte directamente:
"En sus entornos de Kubernetes y de contenedores, ¿cuentan con monitoreo de seguridad en tiempo de ejecución que detecte un escape de contenedor y un acceso a nivel de nodo? ¿Ese monitoreo de seguridad está asignado explícitamente a su equipo o al equipo de su proveedor de DevOps gestionado en su acuerdo de servicio?"
Evidencia que debe esperar
- Confirmación del monitoreo de seguridad en tiempo de ejecución de Kubernetes
- Capacidad de detección de escapes de contenedores
- Alcance del monitoreo de seguridad del servicio gestionado en el acuerdo
- Inventario de monitoreo de componentes tecnológicos
A un proveedor que confirma la cobertura de endpoints, nube y red se le debe preguntar específicamente por el monitoreo de seguridad de contenedores y de Kubernetes. Las categorías confirmadas cubren los componentes confirmados. El clúster de Kubernetes que aloja los datos del cliente requiere su propia confirmación.
Cómo demostrarlo
- Inventario de monitoreo de componentes tecnológicos
- Registros de monitoreo de seguridad en tiempo de ejecución de Kubernetes
- Documentación del alcance del monitoreo de seguridad del servicio gestionado
- Registros de la revisión de brechas de cobertura
Conclusión clave
El proveedor monitorea AWS. El proveedor de DevOps monitorea el clúster a nivel operativo. Ninguno monitorea la seguridad del clúster. El portal de pacientes está en el clúster. Escape de contenedor detectado por: nadie. La brecha no existe por una limitación técnica, sino porque nadie había asignado explícitamente la responsabilidad de monitoreo ni confirmado esa asignación. La suposición no es monitoreo. Un inventario de componentes tecnológicos con un responsable de monitoreo confirmado sí lo es. Exija el inventario. Confirme la responsabilidad. Especifique explícitamente el alcance de seguridad en los acuerdos de servicios gestionados. La brecha existe en el espacio entre dos partes que creen, cada una, que la otra es la responsable.