Herramientas open source para adoptar DevSecOps

Herramientas open source para adoptar DevSecOps

En este artículo técnico Sumit (Sid) Siddarth, director de NotSoSecure, empresa especializada en Ciberseguridad perteneciente al Grupo Claranet, nos muestra que DevSecOps no cuesta una fortuna. Como explica, las empresas pueden hacer uso de las herramientas open-source libremente disponibles para mejorar su postura hacia la seguridad del software.

Contenidos:

Introducción

Actualmente, DevOps permite a las empresas desplegar cambios a entornos de producción a velocidades ultrarápidas. Hay muchas maneras de hacerlo, pero un proceso DevOps típico sería algo así:

  1. Un desarrollador escribe el código usando cualquier entorno de desarrollo de su elección y lo sube a un repositorio de código centralizado.
  2. El código se combina en el repositorio con el objetivo de versionarlo.
  3. Entonces, el servidor de CI/CD descarga el código del repositorio de código centralizado y paquetiza los artefactos/binarios construidos.
  4. Estos artefactos/binarios son entonces subidos a un repositorio de binarios.
  5. Estos artefactos/binarios son entonces descargados del repositorio para ser desplegados en los servidores de preproducción y producción, que son levantados utilizando docker.
  6. Se monitoriza la disponibilidad del servicio regularmente.

Si utilizamos las herramientas y entornos para ilustrar un proceso típico de DevOps, sería algo parecido a la imagen siguiente. Las herramientas variarán para cada empresa, pero el proceso representado aquí y en el resto del artículo sería más o menos el mismo:

claranet-herramientas-pipeline-devops.png

El mismo proceso en un pipeline de la fase de integración de Jenkins se vería así:

claranet-herramientas-pipeline-jenkins.png

Añadir seguridad a la mezcla

Una vez la aplicación está operando en un entorno de producción o preproducción, es habitual planificar un test de penetración. Imagina un escenario en el que una aplicación en producción está siendo testeada y se detecta una vulnerabilidad de alto riesgo, como una SQL injection. En ese caso, el equipo deberá volver a ejecutar todo el pipeline DevOps entero para solucionar este problema. Algo que requiere mucho tiempo y, claramente, no es la mejor manera de resolver el problema.

claranet-pipeline-devops-security-testing.png

Entonces, ¿qué pasa si acercamos un poco más la seguridad al ciclo de desarrollo incorporando un test de seguridad dentro del pipeline DevOps? Por ejemplo, con la ayuda de un escáner de código open source se habría detectado fácilmente la SQL injection en una etapa temprana del desarrollo y se habría arreglado incluso antes de empaquetar el código:

claranet-testing-early-stage-devops-pipeling.png

Beneficios e implicaciones de "desplazar a la izquierda"

Consecuentemente, estamos desplazando la seguridad más hacia la izquierda en el pipeline DevOps. Y, cuando integramos más controles, herramientas y procesos de seguridad de manera automatizada, nuestro pipeline DevOps se convierte en un pipeline DevSecOps.

Dicho de otra manera, DevSecOps es la metodología de integrar herramientas de seguridad en el proceso DevOps de forma automatizada. Igualmente importante, consiste también en poseer los conocimientos necesarios para usar estas herramientas. Esto lleva necesariamente a un cambio cultural en el normal funcionamiento de DevOps y los equipos deben ser formados para que entiendan qué herramientas tienen a su disposición, qué pueden lograr y cómo funcionan, lo que permite colaborar entre equipos de manera más eficiente, creando una "cultura de la seguridad" más robusta. Como resultado, este entorno de seguridad automatizada multicultural y multidisciplinar hace que la seguridad sea un tema que atañe a todos y no solo a un único equipo. Este es uno de los motores principales del DevSecOps.

claranet-metodologia-devsecops.png
Fuente: Claranet/NotSoSecure

Puntos de contacto para el security testing

En un modelo DevOps, los espacios donde puede inyectarse la seguridad son los mostrados abajo. Una vez más, las herramientas elegidas en cada fase variarán en función de cada organización. En los ejemplos aquí mostrados, hemos usado herramientas open source y otras alternativas gratuitas para mostrar cómo adoptar DevSecOps no requiere una fortuna. Aun con las alternativas gratuitas y la formación adecuada, se pueden conseguir unos resultados increíbles para madurar los estándares de seguridad del software.

claranet-seguridad-en-pipeline-devops.png

Herramientas

Echemos ahora un vistazo a cómo hacen habitualmente los equipos para mantener su pipeline DevOps rodando. Para cada área, sugerimos un rango de herramientas open source para ayudar a moverlo todo más rápidamente y de modo seguro sin romper la hucha.

Hooks previos a la subida de código

A menudo se filtra por error información sensible (como claves AWS, tokens de acceso o calves SSH) a través de repositorios de código fuente públicos debido a commits accidentales. Se puede evitar usando herramientas como “Talisman”, que busca información sensible en los archivos antes de hacer commit o push.

Herramientas open source para los hooks previos a la subida de código:

Gestión de secretos

Con la automatización, almacenar credenciales en archivos de configuración y variables de entorno para acceder a varios servicios es una práctica habitual seguida por desarrolladores y administradores. No obstante, almacenar credenciales en archivos o configuraciones puede llevar a exponer credenciales a una audiencia inadecuada. Servicios de gestión de secreto como “Hashicorp vault” permiten segregar credenciales en niveles separados. Cada entorno puede descargar un pull de credenciales desde un entorno específico y utilizarlo programáticamente.

Herramientas open source para gestionar secretos:

Análisis de composición del software

Empecemos con un ejemplo. En septiembre de 2017, Equifax, una famosa agencia de crédito, sufrió una brecha que llevó a la filtración de 143 millones de números de tarjetas de crédito, información de identificación personal (PII) y mucho más. La vulnerabilidad explotada se detectó en el “Struts2 Web Framework” (debido a la carencia de un parche de seguridad) sobre el que la aplicación web primaria estaba construida. Como Equifax, muchas organizaciones también utilizan librerías, frameworks y soluciones open source como WordPress, Magento, Drupal o incluso JQuery, en las que se descubren vulnerabilidad cada día.

claranet-vulnerabilities-evolution-by-ecosystem.png
Fuente: synk

Fuente: snyk

Por esta razón, es necesario realizar análisis de todas las dependencias que están siendo utilizadas en la aplicación y chequearlas en busca de vulnerabilidades que surjan de la falta de parches de seguridad. Para aplicaciones Java y .NET, se puede usar la herramienta “Dependency-Check”, que se puede ejecutar antes de crear las builds para detectar si se está usando algún software vulnerable en la aplicación. A partir de aquí, en función del número y la gravedad de las vulnerabilidades detectadas, se decide si se sigue con el pipeline o se detien para solucionarlas.

Herramientas open source para análisis de composición del software:

Static Analysis Security Testing (SAST)

Usar herramientas automatizadas para realizar controles de código de seguridad elimina mucha tarea básica como la SQL injection, cross-site scripting, vulnerabilidades de deserialización y muchas más cosas. Para las aplicaciones basadas en Java, podemos utilizar la herramienta llamada “FindSecBugs”, que realiza un análisis en profundidad del código (sin dar muchos falsos positivos) y ofrece un informe completo para todas las vulnerabilidades que se han identificado en el código. A partir de ahí, se toma la decisión de continuar con el pipeline o detenerlo, dependiendo del número y la gravedad de las vulnerabilidades, con el objetivo de solucionarlas antes de continuar. A continuación, encontrarás una lista de herramientas open source que pueden utilizarse para SAST.

claranet-sast-devsecops-tools.png
Fuente: Source Code Analysis Tool

Fuente: Source Code Analysis Tool

Testeo de seguridad de análisis dinámico

Los escáneres de aplicaciones web son una parte importante de la evaluación de vulnerabilidades de una web app. La mayoría de ellos tiene acceso vía API o CLI, que se pueden aprovechar para iniciar análisis en las aplicaciones objetivo. OWASP ZAP es una de estas herramientas, con la que se puede iniciar un escaneo de seguridad en el entorno de QA/Staging y pulir un gran número de malas configuraciones (como la revelación de información sensible en un archivo de backup, headers HTTP inseguros, etc.).

Herramientas open source para el testeo de seguridad de análisis dinámico:

Seguridad en Infrastructure as Code

Las soluciones de contenedores como Docker son muy populares pese a que construyen la infraestructura simplemente usando unas pocas líneas de código. Por ejemplo, “Docker Hub” es un famoso repositorio de imágenes de docker público de donde se pueden descargar las imágenes para generar los contenedores. No obstante, en varias instancias estas imágenes docker están mezcladas con malware o están plagadas de vulnerabilidades, como se muestra en la imagen de abajo. Por lo tanto, es extremadamente importante escanearlas.

claranet-os-vulnerabilities-by-docker-image.png
Fuente: synk

Fuente: snyk

Una solución que ofrece una buena visión de la importancia de la seguridad en relación con los contenedores/imágenes Docker es “Clair”, que escanea las imágenes base de docker y ofrece un informe exhaustivo, señalando las vulnerabilidades que existen en la imagen. Por lo tanto, es importante ejecutar una herramienta como Clair en los contenedores de producción antes de desplegarlas en la infraestructura.

Herramientas open source para seguridad en Infrastruture as Code:

Vulnerability Assessment (VA)

Una práctica habitual es la de realizar evaluaciones de vulnerabilidad en los sistemas de producción para identificar varios servicios en ejecución en el entorno y las vulnerabilidades asociadas.
A pesar de apuntar la herramienta de VA a los servidores que han sido creados con Docker, solo ejecutará el escaneo en el servicio que está siendo expuesto en ese host. No obstante, si adjuntamos la herramienta a la red docker y luego ejecutamos el escaneo, nos mostrará una buena foto de los servicios que realmente se están ejecutando.

Esto se puede hacer con varias soluciones, como OpenVas, que se integra fácilmente en el pipeline.

Herramientas open source para Vulnerability Assessment:

Compliance as Code

Las organizaciones deben aplicar controles a su infraestructura TI para cumplir con las mejores prácticas del sector y regulaciones como PCI DSS, HIPAA o SOX. Con “Infrastructure as Code” en DevOps, el entorno de producción no es estático, siempre se puede recrear de nuevo, de ahí que sea imperativo realizar un test sobre el entorno nuevo o actualizado una vez redesplegado. “Inspec” es una de las herramientas que ayuda a realizar estos tests. Solo hace falta proveer de un archivo ruby que contenga los tests a realizar de un modo simple y coherente.

Herramientas open source para Compliance as Code:

Gestión de vulnerabilidades

Las herramientas que crean el pipeline DevSecOps generarán muchas vulnerabilidades y cada una de ellas tiene su propio formato. Por eso, resulta difícil gestionar todos los datos, por no hablar de monitorizar y solucionar las vulnerabilidades. De ahí que las soluciones de gestión de vulnerabilidades sean esenciales en el proceso DevSecOps, administrando todos los datos para ser gestionados, examinados y monitorizados, y las vulnerabilidades solucionadas.

“ArcherySec” es una de estas herramientas. No solo tiene una buena integración con la mayoría de las herramientas mencionadas anteriormente, sino que también puede iniciar escaneos como ZAP u OpenVAS.

A continuación, se muestra una captura del dashboard de ArcherySec mostrando las vulnerabilidades agregadas a través de todas las herramientas:

claranet-archerysec-dashboard.png

Y aquí una lista de todas las herramientas que ArcherySec soporta y de las que puede extraer datos:

claranet-tools-archerysec-supports.png

Herramientas open source disponibles para la gestión de vulnerabilidades:

Alertas y monitorización

Las aplicaciones de producción siempre afrontan nuevas amenazas de agentes desconocidos e imprevistos. Tener activa una solución de monitorización y prevención de intrusiones puede mitigarlas. Una solución open source de este tipo es “ModSecurity WAF(Web Application Firewall)”, que detecta cuando se ataca alguna de las 10 principales vulnerabilidades OWASP – como SQL injection o cross-site scripting.

claranet-modsecurity-waf-owasp-alert.png

Herramienta open source para alertas y monitorización:

Resumen y conclusiones

En este artículo nos hemos centrado en aspectos técnicos sobre cómo puede DevSecOPs operar en un entorno. Pero solo las herramientas y técnicas no son suficiente. DevSecOps requiere de un cambio cultural que promueva una manera de trabajar de “seguridad por defecto”, que se puede lograr creando unos expertos en seguridad en cada área, incrementando la colaboración con el equipo de seguridad y con liderazgo desde arriba.

En un mundo en el que el cibercrimen va al alza y en el que se necesita desarrollar con rapidez para adaptar los negocios a las constantemente cambiantes demandas de los clientes digitales, es esencial que las organizaciones que hayan adoptado DevOps pero no posean las medidas de seguridad ágiles adecuadas cuenten con un nuevo método para detectar y corregir vulnerabilidades.

Esta es la razón por la que DevSecOps puede ser la clave y la única manera de manejar la seguridad en los procesos automatizados.

Ideas clave:

  • Se puede lograr DevSecOps son la integración de herramientas open source simples y la colaboración en el proceso DevOps existente.
  • Se puede afinar DevSecOps para eliminar muchos chequeos de seguridad rutinarios automatizándolos en el pipeline DevOps, con lo que logramos tiempo que podemos dedicar a otros temas más relevantes.
  • Con recursos limitados, DevSecOps nos asegura que DevOps escala de modo seguro.
  • Con DevSecOps, la seguridad se convierte en responsabilidad

Habla con nuestros expertos