Se trata de una fusión de CSPM (Cloud Security Posture Management, alertas sobre configuraciones de riesgo), CWPP (Cloud Workload Protection Platform, alertas sobre contenedores y máquinas virtuales), CIEM (Cloud Infrastructure Entitlement Management, que centraliza la gestión de identidades y accesos) y mucho más (análisis de «Infraestructura como código», detección de secretos, etc.). Hay unos quince proveedores que afirman ofrecer este tipo de servicio.
Habiendo participado en varias solicitudes de información (RFI) y propuestas (RFP) sobre este tema, a continuación te indico algunos aspectos que debes tener en cuenta a la hora de tomar una decisión.
Cada héroe tiene su «historia de origen»
CNAPP es el término de moda en materia de seguridad en la nube (por excelentes razones). Cada proveedor dirá que ofrece una solución CNAPP completa, pero en realidad tendrá experiencia en un sector concreto (CSPM, CWPP o CIEM, dependiendo de la funcionalidad del producto original) y el resto de funciones serán algo menos relevantes. Si utilizas muchos contenedores o Kubernetes, optar por un CNAPP que provenga de un CWPP reconocido será una estrategia coherente. Por el contrario, si utilizas recursos en la nube de forma masiva, un CSPM será más adecuado.
¡Es importante conocer la trayectoria de tu proveedor!
El mercado aún está en sus inicios
El mercado cuenta con unos quince actores desde hace tres años. Algunos se encuentran inmersos en litigios judiciales, como Wiz y Orca por robo de propiedad intelectual, lo que les está costando contratos a pesar de su condición de «challenger» o «unicornio». Hay pocos «pure players»; la mayoría cuenta con el respaldo de una gran empresa (Microsoft, Palo Alto). Adivinar quién seguirá en el mercado dentro de tres años es una tarea difícil (véase, por ejemplo, el intento de adquisición de Lacework por parte de Wiz).
Es importante saber con quién establecer una relación para garantizar la seguridad en la nube a largo plazo (¡es de esperar que se produzcan fusiones o liquidaciones en los próximos tres años!)
Efecto Frankenstein
Varios proveedores comenzaron con una funcionalidad, pero en lugar de desarrollar las demás por su cuenta, simplemente adquirieron productos que las cubrían. ¿El resultado? Una interfaz ineficaz, ya que no hay integración entre los productos: en los análisis de CI/CD se ve el código y las vulnerabilidades, pero no se pueden identificar los contenedores en los que está implementado. Hay que ir a la sección de contenedores para ver cuáles se ven afectados. Sin duda, esto irá mejorando, pero la integración es un proceso lento.
Tener acceso a la información relevante desde cualquier lugar es fundamental, al igual que la capacidad de integración del proveedor.
La contextualización de los riesgos
En cuanto conectes tu CNAPP a tus entornos en la nube, generará miles de alertas, lo que pondrá en alerta máxima a tus equipos de DevOps y ciberseguridad. Por suerte, la función de contextualización de riesgos está ahí para filtrar y priorizar las alertas según su gravedad.
Durante una prueba de una solución, se identificó una vulnerabilidad de máximo nivel en mi suscripción de Azure. Un poco sorprendido, voy a investigarlo. El problema es que había un NSG (grupo de seguridad de red) que permitía el puerto 22 desde Internet, pero no estaba conectado a ninguna instancia ni subred. El riesgo era nulo y he perdido tiempo con una alerta irrelevante...
¡La idoneidad de la priorización de las alertas debe confirmarse durante la prueba de concepto antes de firmar!
Cobertura de los grupos socioeconómicos
Es bastante obvio, pero la lista de proveedores de servicios en la nube (CSP) que se admiten puede reducir drásticamente las opciones. Casi todos ofrecen AWS, Azure y GCP, pero si necesitas OCI, Alibaba o IBM, eso puede marcar la diferencia y reducir tu lista de opciones.
Hay que tener en cuenta también lo que significa «cubrir»: ¿se tienen en cuenta todos los recursos? ¿Se gestiona el IAM?
Es fundamental comprobar que las capacidades sean equivalentes entre los CSP que utilices.
Sin agente
La mayoría de las soluciones son sin agente, a menos que necesites la parte de CWPP. Para obtener la mejor visión de Kubernetes, tendrás que instalar el agente en los distintos nodos. Es relativamente sencillo y los procedimientos están bien guiados. Sin embargo, hay que tener en cuenta el posible impacto de este agente en el rendimiento. Puede consumir entre 300 y 700 MB de RAM y entre el 3 % y el 7 % de la CPU. Algunas soluciones ofrecen la función de parada automática del agente durante los picos de carga, aunque yo no la recomiendo desde el punto de vista de la seguridad.
Durante la prueba de concepto (POC), es fundamental comprobar el consumo del agente y su posible impacto en sus aplicaciones.
Integración
Todos los proveedores prometen una integración muy rápida con tus recursos en la nube, que aparecen en menos de dos horas. Así es, pero lo más importante será la integración con tus herramientas: SIEM para notificar las vulnerabilidades más críticas, Jira o un equivalente para crear tickets que los desarrolladores deben gestionar, y CMDB si quieres que tus recursos se reflejen en tus herramientas habituales.
También hay que comprobar que el registro se realice a nivel de tenant/organización, para que ninguna suscripción, cuenta o proyecto quede fuera de la supervisión.
La capacidad de escribir tus propias reglas o controles también es fundamental y puede ser necesaria para clientes exigentes que quieran comprobar si se puede hacer fácilmente (algunos son reacios a las expresiones regulares).
Interfaz
La UI/UX es, sin duda, fundamental; la primera impresión es que se trata de una herramienta de seguridad que deben utilizar los equipos de ciberseguridad. Sin embargo, resulta mucho más eficaz si también la utilizan los equipos de DevOps con un contenido claro y práctico.
A continuación se muestra una vulnerabilidad CVE para la que el proveedor aún no ha publicado una corrección.
Y aquí tienes una explicación paso a paso sobre cómo solucionarlo.
Esto facilitará la adopción del producto por parte de los equipos operativos, evitando así que los equipos de ciberseguridad se conviertan en un cuello de botella.
El gráfico de la ruta de ataque también resulta muy eficaz para presentar un problema a la dirección (ya sea para tomar una decisión o para explicar un incidente).
Competidor indirecto
Herramientas nativas de los CSP
Los tres hiperescaladores ofrecen sus propias herramientas, lo cual constituye un buen punto de comparación durante la prueba de concepto. Son adecuadas y se integran muy bien entre sí cuando se utiliza un único proveedor de servicios en la nube. Sin embargo, la fragmentación de la información en varias herramientas reduce la eficiencia si se utilizan varios proveedores de servicios en la nube.
Código abierto
Elegir una solución de código abierto es complicado, ya que hay que mantenerse al día con las actualizaciones de los CSP y las amenazas. Un cliente se equipó con un CSPM de código abierto y, a pesar de contar con una decena de personas dedicadas a su mantenimiento, no fue posible generar controles para varios CSP en los recursos solicitados.
Nota : una pregunta que plantear a los editores de CNAPP sobre el tiempo que tardan en incluir nuevos recursos en la nube en su control (Azure Open AI es un buen ejemplo reciente).
Conclusión
No he escrito ningún artículo sobre por qué debes elegir una CNAPP, ya que cada vez que se lo muestro a los responsables de seguridad de la información (RSSI) y a los equipos de DevOps, la reacción es de asombro. La pregunta no es «¿Vas a necesitar una CNAPP para mejorar tu seguridad en la nube?», sino más bien: «¿Qué CNAPP elegir?».
Cabe destacar que, más allá de la herramienta, establecer un proceso claro y supervisado de gestión de vulnerabilidades será un factor clave para el éxito de este tipo de proyectos.
¡Espero que este artículo os ayude a tomar una decisión informada!
Matthieu GAILLARD-MIDOL
Responsable de la práctica de CloudSec y SecOps
