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.
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.
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.
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:
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.
“Package” o empaquetado.
“Monitor” o monitorización.
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.
 |
| 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 |
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.
“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.
No hay comentarios:
Publicar un comentario