Protegiendo tu cloud con Dome9 (2/2)
En el post anterior escribí sobre las funcionalidades principales de Dome9 y cómo estas nos pueden ayudar a llevar nuestra infraestructura a un nivel de seguridad avanzado en tan solo unos pocos pasos, es decir, el propósito de una herramienta de CSPM.
No quería dejar sin explicar lo que, en mi opinión, son los puntos fuertes de Dome9: agilidad, flexibilidad y minimalismo. Al igual que también debo mencionar los puntos débiles y qué posibles soluciones hay para adaptarlo en nuestros proyectos.
Ahora que ya conocemos los usos básicos de Dome9 quiero daros mi punto de vista sobre como adaptar y personalizar esta herramienta a los requisitos de una organización o un proyecto concreto.
Define tu propia postura de seguridad
Las buenas practicas dictan que se debe definir un marco interno de seguridad en una primera fase de planificación, y llegados a este punto aplicarlo en la herramienta correspondiente. Pero todos sabemos que del dicho al hecho, hay un trecho y generalmente la postura de seguridad se ha venido definiendo a medida que se usan nuevas herramientas.
Sea cual sea tu caso, Dome9 facilita la implementación de unas políticas propias, en lugar de utilizar las predefinidas (CIS, HIPAA, NIST…). Estas políticas o conjuntos de pruebas son llamados Rulesets.
Definir tu propia política no significa únicamente crear tu propia Ruleset, sino adaptarla a los mecanismos de tu organización, adaptando los resultados de Dome9 al resto de servicios de seguridad (Jira, Github, Splunk, etc…), estableciendo autoremediaciones en base a la forma de trabajo del equipo u organización.
Supongamos que el marco de seguridad interno de una organización no permite que haya puertos SSH expuestos a internet y toda conexión deba proceder de una de las redes conocidas. En ese caso la Imagen 1 sirve como ejemplo de Ruleset donde estarán incluidas todas los controles de seguridad mínimos u obligatorios. Cada regla se puede personalizar para indicar la remediación adecuada a cada control (como indicar cuáles son las redes conocidas de la organización) y, por supuesto, crear una remediación para cada una de ellas.
🤔 Un paso más allá:
En una fase madura, las reglas podrían ser generadas mediante lógica interna. Por ejemplo, en la Imagen 1 vemos que una instancia expuesta a todo internet se considera incidencia pero… ¿Y si alguien pone 1.2.3.4/0 o la IP de su casa? En ese caso habría que cambiar la regla actual por la siguiente donde únicamente se permiten conexiones de la red de Madrid:
Instance should not have inboundRules with [ port=22 and scope!=’32.12.33.38/24’ ]Define tu flujo de notificaciones
Dome9, como cualquier herramienta CSPM, debe ser una ayuda para ahorrar tiempo y mejorar el nivel de seguridad, pero nunca convertirnos en una especie SOC, todo el día mirando el dashboard para ver si sale algo nuevo.
Para ello están las notificaciones, haciendo que cada vez que se detecte o remedie una incidencia se notifique al canal que usemos: Slack, Teams, Skype o Email.
Adicionalmente, estas incidencias deben ser enviadas también al sistema de gestión de incidencias de seguridad que utilicemos: AWS Pager Duty o Tenable.
Sirvete de la API, SDK, CLI…
Una vez configuradas las funcionalidades básicas de la herramienta toca automatizar los procesos intermedios para ahorrar tiempo y a su vez agilizar el trabajo. Para ello debemos conocer bien la API de Dome9.
También podéis serviros de los SDK en Python, y ahora también para Go.
Estas herramientas no permitirán automatizar todos los procesos que hemos ido viendo y también otros casos de uso cotidianos:
- Generar rulesets personalizadas
- Exportar resultados a otros servicios
- Descargar el inventario completo de nuestras clouds
- Localizar una instancia por su IP interna
Por otro lado, construirse una CLI ( Dome9 todavía no ha desarrollado una oficial) es una muy buena idea para olvidarnos de la interfaz y centrarnos en lo importante, el contenido. Gracias a Google/Python-fire puedes crearte tu propia CLI en unos pocos minutos, como puedes ver en la Imagen 3.
Dome9 + CICD
Y ahora que ya hemos visto cómo funciona esta herramienta, como podemos personalizarla y como usar las utilidades que nos ofrecen, llegamos a la parte importante: la integración continua.
La integración continua es un modelo que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes.
🤕 Problema: Las ejecuciones en Dome9 se realizan a nivel de cuenta o región, por lo tanto, al analizar nuestro entorno también obtendremos los resultados de otros proyectos en la misma cuenta/region.
💊 Solución: Parece que Dome9 van a implementar una funcionalidad para agrupar recursos concretos y lanzar Rulesets contra estos.
Aunque ya hablaremos de esto más adelante en otro post, hay que entender que el futuro de los procesos de seguridad es ser incluidos dentro del ciclo de desarrollo de software de manera que, dado un escenario inicial, obtengo un resultado dicotómico (éxito o fallo), indistintamente de como funcionan las pruebas unitarias o de aceptación. El resultado obtenido indicará si se cumplen los requisitos inicialmente definidos por el cliente.
Veamos un ejemplo práctico. Lo primero que tenemos que conseguir es realizar una ejecución, preferiblemente por linea de comandos, que devuelva SUCCESS en caso de que no haya encontrado errores o FAILED en caso contrario. Haciendo uso del CLI como vimos en el punto anterior resulta bastante sencillo esto, como podemos ver en la imagen a continuación.
En este caso la configuración es fácil, ya que toda incidencia se considerará fallo y deberá ser corregida, sin probabilidad de falso-positivo. Pero en el caso de que controles de seguridad más relativos a la configuración del proyecto, como por ejemplo “EBS Volumes with sensitive data must be encrypted”, deberemos usar un fichero de configuración. En este fichero de configuración estableceríamos la postura de seguridad definida en la fase de planificación, indicando los volúmenes que deben estar cifrados y cuales no, qué buckets deben ser públicos y cuáles privados, etc…
Llegados a este punto ya tenemos una herramienta que nos devuelve un valor booleano sin posibilidad de fallo, y por tanto, sin necesidad de revisión por nuestra parte así que podemos integrarlo dentro de los pipeline del proyecto en nuestra herramienta CI preferida (Travis, Jenkins, Github Actions…), bien para que se ejecute periodicamente o sea disparado ante una acción concreta (trigger).
En este caso he decidido hacer la prueba con Github Actions por la visualización tan clara que ofrece. En la Imagen 5 vemos el ejemplo de nuestro job ya integrado y pasando las pruebas satisfactoriamente. En la Imagen 6 se ve cómo Github representa la salida de estos jobs, y en este caso, reportando un resultado negativo (pruebas fallidas).
🤔 Un paso más allá: En entornos maduros y ágiles, cada commit despliega una infraestructura nueva donde todas las pruebas son ejecutadas (unitarias, componente, aceptación y, por supuesto, seguridad) y después el entorno es eliminado, todo esto en cuestión de minutos.
Para desplegar una infraestructura y analizar su seguridad necesitamos que Dome9 haya detectado estos nuevos activos creados, sin embargo este reconocimiento lo hace horariamente. Esto significa que dentro de esa hora, todas las faltas de seguridad que cometas no serán detectadas si son resueltas antes de que Dome9 vuelva a actualizar. Y aquí se presenta un verdadero y complicado reto para Dome9. ¿Como reducir los tiempos de actualización del inventario a 1 minuto?
Aunque parezca que lo pueda ocurrir en 60 minutos no difiere mucho de lo que ocurra al minuto, la monitorización continua y en tiempo real está muy valorada actualmente, y además permite, como hemos visto, que entornos ágiles desplieguen su propia infraestructura y conozcan al momento su nivel de seguridad.
Conclusión
Ya hemos visto todas las posibilidades que Dome9 nos ofrece, desde las oficiales y básicas hasta las personalizaciones en proyectos muy maduros. Sin embargo, no hay que tener en cuenta que Dome9 es un software preventivo, y no debemos olvidarnos de las posibilidades que las nubes nativas nos ofrecen.
Si lo que queremos es no tener ningún servicio SSH expuesto a internet bajo ninguna circunstancia, deberíamos configurar políticas nativas que prohiban la creación de máquinas virtuales con el puerto 22 expuesto, tanto en AWS, Azure y Google Cloud.
Sin embargo, las empresas raramente disponen de un gran equipo de seguridad, y mucho menos de un equipo de Secdevops y para estos casos, Dome9 es una gran solución por su sencillez y rapidez, pero no nos olvidemos que estas herramientas requieren de un seguimiento y mantenimiento, y al disponer más información, generarán más carga de trabajo y como resultado, un mejor nivel de seguridad.
