SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

SecDevOps, DevOpsSec, DevSecOps o como lo quieras llamar, supone un gran avance en el diseño y la programación de código seguro. Nuestro libro Docker: SecDevOps estaba centrado en la importancia de este paradigma dentro del diseño de una aplicación hoy en día. Vamos a intentar explicarlo en este post de la forma más simplificada posible siguiendo los principales pasos de este nuevo paradigma que más vale que domines si quieres estar en equipos de creación de tecnología de alto rendimiento, pues se aplica en todos ellos.

Figura 1: SecDevOps: Una explicación en cinco minutos (o poco más) #SecDevOps

DevOps es un cambio en la forma y la cultura de trabajo entre programadores o desarrolladores (“Dev”, developers) y el personal encargado de las operaciones (“Ops”, operations) o mejor dicho de los encargados de la infraestructura (como por ejemplo los administradores de sistemas). Al principio no existía una estrecha relación entre ellos, y una gran mayoría de ocasiones, acarreaba problemas como por ejemplo que la aplicación no funcionara o la típica frase “pues en mi máquina funciona” que tanto hemos oído.

Figura 2: Libro de Docker:SecDevOps en 0xWord de

Fran Ramírez, Elías Grande y Rafael Troncoso

Uno de los pilares de DevOps no es más que acercar a ambos grupos para que al fin y al cabo trabajen juntos y así rellenar ese hueco que antes existía entre ambos departamentos, en definitiva: "Colaboración".

De esta forma el desarrollador, tendrá mayor conocimiento sobre la infraestructura donde correrá su aplicación, y los de operaciones, los recursos que la aplicación necesitará. Y las ventajas son enormes. Por ejemplo, el técnico de operaciones sabrá en todo momento qué librerías/entorno de ejecución, necesitaría para satisfacer las necesidades de la aplicación, y así detectar aquellas que faltan o que son necesarias.

Otro de los pilares de DevOps, es la automatización. En general, la automatización debería aplicarse a todo el proceso. Todo esto incluso implica a la provisión de entornos y recursos. De esta forma llegamos a otros de los pilares que es el feedback o retroalimentación continua. Así podremos observar no solo errores, sino hasta la evolución misma de la aplicación. En definitiva, el desarrollo ya no será sólo cosa de uno, ahora entrarán más actores en el proceso.

Ciclo de vida DevOps

En la siguiente imagen podemos ver el ciclo de vida “típico” de una aplicación en un entorno DevOps.

Figura 3: Modelo clásico DevOps

En “Plan” se recogen los requerimientos de la aplicación, “Code” es donde se comienza a escribir código, “Test” es la fase de ejecución pruebas, “Package” es donde empaquetamos la aplicación para su despliegue (por ejemplo, un contenedor Docker) y luego “Release” es cuando subimos el artefacto (como el contenedor Docker del ejemplo anterior). En la siguiente fase “Deploy” es cuando se comienzan a aplicar los controles de seguridad.

Demasiado tarde. El equipo encargado de la seguridad (“Sec”, Security) encontrará problemas en esta fase reportándolos al equipo de desarrollo y esto provocará un tapón o retraso en los tiempos de entrega. Pero no sólo eso, una vez aplicados los parches o soluciones, estos deberán de ser probados de nuevo o simplemente se darán por resueltos sin estarlo al 100%, lo cual afectará a la calidad y seguridad del producto final. Hay que aplicar una mitigación a este problema, y se llama SecDevOps.

Ciclo de vida: SecDevOps

Simplemente, consiste mover la aplicación de los controles de seguridad desde la primera fase, en lo que se denomina “Shift Left” o desplazamiento hacia la izquierda. Este sería el esquema visto anteriormente adaptado a SecDevOps:

Figura 4: Nuevo modelo SecDevOps

Y visto esto, la pregunta es ¿Qué funciones hay que realizar de Sec en cada una de las fases de este nuevo modelo de ciclo de vida? Pues vamos a verlo.

“Plan” o planificación.

En esta fase es donde se analiza el modelo de amenazas o Threat Modeling. Por ejemplo autenticación de usuarios, servidores externos, cifrado, etcétera. Aquí se generarán “tickets” también conocidos como “stories” destinados específicamente a la seguridad.

Figura 4: Evil User Stories

Algunas herramientas o recursos son OWASP Application Threat Modeling o Don´t forget EVIL user stories, que básicamente es lo que hacen muchos hackers en sus procesos de research.

 “Code” o programación.

El técnico del equipo de seguridad se convierte en formador y proveedor explicando e informando al equipo de desarrollo cómo utilizar ciertas herramientas de seguridad (análisis de código estático), pero sobre todo a familiarizar al programador términos relacionado con la seguridad como por ejemplo qué son los ataques SQLi, XSS, DDoS, etcétera. Vamos, en el mundo de aplicaciones web debes conocerte los temas de Hacking de Aplicaciones Web: SQL Injection, de Hacking Web Technologies y de Hacking de Aplicaciones Web: Client-Side Attacks al dedillo.

Figura 5: Hacking Web Technologies

Aquí también entrarían herramientas como como Git-Secrets o Git-Hound pueden ser algunas de las que se podrían utilizar, las cuales permiten analizar el envío de un git commit no contiene datos críticos como contraseñas, tokens, etcétera.

“Test” o pruebas.

Aquí se ejecutan los tests unitarios y de integración, pero en el caso que nos ocupa, aquí nos enfocaríamos a tests que verifiquen aspectos de seguridad. Estas pruebas deberían de ser totalmente automáticas para de esa forma no dejar pasar ningún problema de los detectados en la fase principal (detección temprana). Las herramientas para esta fase son varias y dependen del entorno donde se realiza el desarrollo. Tal vez en otros artículos podamos ir viendo algunos ejemplos.

“Package” o empaquetado.

Aquí es donde se unifica todo el código en un sólo paquete o artefacto como por ejemplo un programa compilado, etc. Un escaneo de seguridad para las librerías externas donde se detecten posibles vulnerabilidades, sería la operativa de seguridad a aplicar. En el caso de Docker es el momento de comprobar la seguridad de las imágenes. 

Figura 6: Dagda Docker Security Suite 

Para Ruby, por poner algún ejemplo, existen herramientas como bundler-audit, para Docker tenemos Dagda (creada por nuestro colega y co-autor del mismo libro, Elías Grande) o Docker Bench, para Node tenemos nsp, etcétera.

“Release” o entrega.

Aquí es donde ponemos nuestro artefacto en algún repositorio central desde el cual será consumido durante la fase de despliegue. En el caso de Docker, muchos registros ofrecen escáneres de seguridad ya integrados que escasearán nuestra image, en este caso se podría evitar el escaneo de la imagen en la fase anterior.

“Deploy” o despliegue.

La aplicación se despliega o se instala en un entorno preparado para probarla. Podrán existir varios entornos de pruebas específicos para que cada equipo pueda trabajar en una parte concreta del programa. Esta fase se podría llamar también fase de pre-producción. 

Figura 7: Ethical Hacking

Aquí es donde aparece el equipo de QA para realizar los test de calidad y es donde se realiza un análisis dinámico de la aplicación (XSS, SQLi, SSL habilitado, etcétera). Las herramientas del equipo de seguridad son las típicas de cualquier fase de Ethical Hacking, como por ejemplo nmap, sqlmap, Nikto, o la FOCA.

“Operate”, fase de operación.

La aplicación ya está desplegada y funcionando. Entonces es ahora cuando hay que probar la seguridad realizando pruebas RedTeam de seguridad, resiliencia (Chaos Engineering, Circuit Breaker, etc.), etcetera.

View this post on Instagram

Esta es la portada del nuevo libro de 0xWord "CISO: El Red Team de la Empresa" que ha diseñado Rodol. Lo tienes disponible en https://0xword.com/es/libros/114-chief-information-security-office-el-red-team-de-la-empresa.html

A post shared by Chema Alonso (@chemaalonso) on Jun 22, 2018 at 11:58pm PDT

“Monitor” o monitorización. 

Partiendo de la premisa que los logs están centralizados (práctica más que recomendable de seguridad), es cuando estos se analizan de forma automática para detectar posibles ataques como XSS, SQLi, DoS, DDoS, etcétera o incluso situaciones de stress en los equipos como falta de memoria o uso de CPU excesiva. Splunk o Devo de licencias comerciales o ELK sean posiblemente las herramienta más conocidas de las utilizadas en esta fase.

Pues esto es todo, esperamos que este breve artículo sirva de introducción al SecDevOps y entre todos consigamos realizar aplicaciones más seguras.

Fran Ramírez,  es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Rafael Troncoso es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" y del blog Cyberhades.

Evaluar la calidad de un escáner de vulnerabilidades web

Como ya os he contado, en Eleven Paths estamos creando una nueva cosa que internamente llamamos Foca as a Service. No es nada más que una FOCA mutada para encargarse de hacer los servicios de Pentesting Continuo que vamos a empezar a ofrecer desde el próximo mes de septiembre para crear una nueva forma de hacer auditorías continuas a los sitios web de las organizaciones que lo contraten.

Ayer tuve la ocasión de sentarme a ver en detalle los resultados que estamos obteniendo, y la verdad es que estoy muy contento de la cantidad de pruebas que se hacen en un sitio, y los resultados obtenidos en cada una de las prueba contra sitios que ya habían tenido una auditoría previa. Ahora bien, en los scanners de vulnerabilidades web siempre queda la pregunta que te hace un cliente.

¿Cómo saber que este escaneo de un escáner de vulnerabilidades es suficientemente bueno?

Es difícil de valorar, y dependiendo de la naturaleza de las vulnerabilidades que tenga el sitio web unos encontrarán más o menos resultados. En un trabajo del 2013 realizado por Fernando Román Muñoz y Luis Javier García Villalba en la Universidad Complutense de Madrid titulado "METHODS TO TEST WEB APPLICATION SCANNERS" se hacía una curiosa comparativa sobre varios tests de comparación de resultados sobre escáners de vulnerabilidades web.

Figura 1: Clasificación de escáners web en 4 comparativas distintas

En él se concluye al final que es necesario crear un conjunto de vulnerabilidades de referencia en aplicaciones web que vayan adaptándose a la realidad del tiempo, es decir, que vaya cambiando el conjunto de referencia a medida que avanza el estudio de nuevas vulnerabilidades o técnicas de descubrimiento.

Figura 2: Tipos de vulnerabilidades que se evalúan en las diferentes comparativas

En PCI DSS, el famoso estándar para los medios de pago con tarjetas de crédito, existe la figura del ASV (Approved Scanning Vendors) que no es más que escáners de vulnerabilidades aprobados por PDI DSS para ser utilizados en la búsqueda de vulnerabilidades para pasar la certificación PCI. Estos escáners deben buscar y encontrar un conjunto de vulnerabilidades antes de conseguir el nivel de aprobación, y estas van desde nivel de red o versiones de software desactualizadas hasta las que aparecen en aplicaciones web.

La descripción de las vulnerabilidades que debe buscar y encontrar un ASV las podéis ver en la guía "Payment Card Industry (PCI) Approved Scanning Vendors" donde en la parte relativa a web se describe lo siguiente:

Figura 3: ¿Qué vulnerabilidades web debe encontrar un ASV?

Por supuesto, los ASV no tienen necesariamente que ser los mejores del mundo, pero sí que han pasado al menos un conjunto estandarizado de vulnerabilidades que eliminarían las que PCI ha definido como más importantes.

En un entorno real, puede que la vulnerabilidad sea muy gorda, pero ningún escáner sea capaz de localizarla. De hecho, hace tiempo hicimos una comparativa con los escáners más populares y las Inverted Queries, es decir, consultas SQL escritas al revés con vulnerabilidades de SQL Injection, y los resultados fueron bastante sorprendentes.

Figura 4: How "·$% developers defeat the web vulnerability scanners de Chema Alonso

Al final, la recomendación más efectiva es utilizar cuantos más escáners se pueda mejor para buscar las vulnerabilidades, porque no todos utilizan las mismas técnicas de detección y no buscan las mismas vulnerabiliades y fallos en las aplicaciones web, que estas pueden aparecer y ser encontradas de formas muy diversas.

Saludos Malignos!