¿Qué es DevSecOps y cuál es su función en la CD?
DevSecOps (Desarrollo, seguridad y operaciones) hace hincapié en la importancia de incorporar seguridad al ciclo de desarrollo del software (SDLC). Integrar la seguridad en la cultura, los procesos y las herramientas de su equipo evita silos y asegura que una entrega rápida no suponga vulnerabilidades en la seguridad.
DevOps
Antes de profundizar en el aspecto de la seguridad, tomémonos un momento para hablar de DevOps (Desarrollo y operaciones).
Vinculada estrechamente con un desarrollo de software ágil, DevOps se trata de crear una cultura de colaboración entre el desarrollo de software y las operaciones, en la que todos compartan el objetivo común de entregar un software funcional y de valor a los usuarios con eficiencia. Para poner en práctica esta filosofía, DevOps aboga por procesos estables y automatizados que abrevian los plazos de entrega y fomentan un feedback rápido, creando así un ciclo de mejora continua.
Hasta aquí, todo correcto. Pero, al igual que cuando corre para coger un tren, al acelerar el proceso de entrega de software vale la pena comprobar que no se deja atrás nada importante. Desafortunadamente, esto es lo que siempre ha sucedido con la seguridad, y es lo que DevSecOps trata de solucionar.
Seguridad en DevOps
Nunca debe subestimarse el impacto potencial de las vulnerabilidades de seguridad en su software.
No solo hablamos de daños económicos y a su reputación. Las brechas en la seguridad del software han dado lugar a la filtración de gran cantidad de datos confidenciales, desde documentos internos a productos todavía no lanzados e información personal acerca de sus clientes, incluyendo sus contraseñas. En algunas jurisdicciones, la filtración de datos de los usuarios puede conllevar duras sanciones financieras, así como a responsabilidades legales.
A pesar de todo, los equipos de desarrollo suelen pensar en la seguridad más como en una carga que como en una ventaja. Las auditorias y los informes de seguridad ralentizan el avance y le impiden presentar a sus usuarios las funcionalidades más novedosas y geniales. Pero esa mentalidad les viene de maravilla a los malos: si hacemos caso omiso de la importancia de la seguridad en el SDLC, nos arriesgamos a desencadenar el próximo Wannacry o Hearbleed.
Aunque estos se convirtieron en escándalos que llenaron titulares, su origen fue mucho más mundano. Las vulnerabilidades existen porque los humanos escribimos código y los humanos cometemos errores. A veces esos errores los han cometido otros antes, y son más fáciles de reconocer (si se sabe dónde mirar), y a veces son nuevos, quizá resultado de una combinación inédita de factores.
Para ponerlo todavía más difícil, casi todo el software incorpora dependencias (tanto el de código abierto como el comercial) y tampoco existen garantías de que el código de terceros no presente vulnerabilidades.
Así que, ¿cómo podemos garantizar la seguridad en el SDLC? El enfoque de DevSecOps es aplicar a las tareas de seguridad los mismos principios de colaboración, responsabilidad compartida y automatización de todo lo automatizable que han permitido obtener lanzamientos más rápidos y más estables.
Desplazar la seguridad a la izquierda
El proceso de desarrollo en cascada emplea un enfoque lineal, comenzando por la recopilación de los requisitos, seguida del diseño, compilación, integración y fases de prueba, y finalmente (normalmente meses o años tras el comienzo), el lanzamiento.
La fase de prueba solía incluir interminables procesos manuales de aseguramiento de la calidad, auditoría de seguridad y pruebas de aceptación. En un proceso denominado jocosamente "lanzar las cosas por el muro", el producto se pasa de una función a la siguiente y cada equipo escribe un extenso informe al respecto.
Una de estas etapas le correspondía al equipo de seguridad de la información, o infosec, que redactaba un informe de seguridad y hacía una lista detallada de hallazgos y recomendaciones. Estos solían requerir cambios en la base de código, después de los cuales el software pasaría de nuevo por todas las etapas para confirmar que todo se había implementado como se esperaba (o no). Con un proceso tan tedioso, ¡no es de extrañar que un lanzamiento fuese motivo de toda una celebración!
El desarrollo de software ágil, el movimiento DevOps y la aparición de la informática en la nube han cambiado todo esto. La competencia es dura y la velocidad es esencial. Si no atiende a las necesidades de sus usuarios y soluciona errores con celeridad, pronto encontrarán otro proveedor que lo haga. Entregar valor con regularidad y ser capaz de implementar los arreglos rápidamente se han convertido en la norma para muchas organizaciones, cuyo proceso de CI/CD es la piedra angular de sus operaciones.
Aunque el término DevSecOps indique lo contrario, DevOps nunca trató de excluir la seguridad.
No obstante, desafortunadamente, la realidad es que, aunque se iban eliminando los límites entre los equipos de desarrollo y operaciones, los equipos de seguridad solían quedar aislados. Tratando de resolver esta situación, se acuñó el término DevSecOps (junto con otras versiones como SecDevOps, DevOpsSec y Rugged DevOps.
DevSecOps hace hincapié en la importancia de integrar la seguridad desde el principio, ampliando la cultura de comprensión y responsabilidad compartidas a las áreas de seguridad, y creando comprobaciones de seguridad en la rutina de pruebas automatizada de un proceso de CI/CD. Como sucede con las operaciones, la idea es que, desplazando la seguridad hacia la izquierda, es más fácil incorporar los requisitos y buenas prácticas de seguridad que si se incorporan a posteriori cuando ya se ha creado el producto.
Añadir Sec a DevSecOps: seguridad como código
Para los no iniciados, puede resultar tentador pensar que desplazar la seguridad hacia la izquierda solo requiere poner su software a disposición del equipo de seguridad para que pueda realizar las pruebas, como una etapa más en el proceso de CI/CD.
Aunque hay lugar para las pruebas de seguridad manuales, como explicaremos más adelante, limitar su implicación en los requisitos de seguridad a un paso al final del proceso no es muy distinto de lanzar el software por el muro y esperar a recibir el informe.
El resultado más probable es que, o bien se haga caso omiso de las recomendaciones porque se tardará mucho en implementarlas, o todo el proceso se bloqueará y el lanzamiento se retrasará indefinidamente hasta que se solucionen las incidencias y se evalúen los riesgos. Sea como sea, esto fomenta una mentalidad de "nosotros vs. ellos" entre el equipo de seguridad y el resto de la organización que no ayuda a ninguna de las partes a lograr lo que desean, es decir, el lanzamiento de un software funcional y seguro.
Así que, ¿qué significa en la práctica la metodología del desplazamiento hacia la izquierda? Aunque no existe una solución universal, las siguientes herramientas y técnicas pueden ayudarle a integrar la seguridad en el SDLC.
Nombre embajadores de la seguridad
Aunque es importante una cultura de responsabilidad compartida, no basta con decirles a sus equipos de desarrollo que son responsables de la seguridad del software. Mantenerse al día de los últimos vectores de ataque y desarrollos de malware es un trabajo a tiempo completo, así que no puede esperar que todos tengan el mismo nivel de conocimientos. Incorporar a un embajador de la seguridad en un equipo multidisciplinar para que enseñe a los demás y comparta con ellos buenas prácticas les ayudará a comprender y a promover la cultura de la colaboración con los profesionales de la seguridad.
Considere la seguridad como restricción de diseño
Para que los desarrolladores compartan la responsabilidad de la seguridad del software que están creando, se debe pensar en la seguridad antes de escribir cualquier código. Debería incluirse entre los argumentos de los usuarios, comentarse en las reuniones de revisión de trabajo pendiente, y debatirse al planificar cada sprint. Al reflexionar acerca de cómo abordar una nueva funcionalidad, tómese su tiempo para hablar de los riesgos que puede entrañar y cómo mitigarlos.
Adoptar una estrategia de modelado de amenazas, como STRIDE, o utilizar una herramienta como OWASP, puede ayudarle a mantenerse al día mientras aprende al respecto. Aunque tener en cuenta la seguridad durante la fase de diseño no lo solucionará todo, es un buen comienzo, y le ayudará a promover la cultura DevSecOps.
Añada pruebas de seguridad automatizadas al proceso
La automatización es un principio básico de DevOps. No solo acelera las tareas y se asegura de que se realicen de forma coherente, sino que quita carga de trabajo a las personas para que puedan realizar el trabajo más creativo. Si desea entregar software a los usuarios con regularidad y con frecuencia, es esencial añadir pruebas de seguridad automatizadas a su proceso.
Al escribir pruebas de unidades, de integración y de extremo a extremo, las características de seguridad deberían considerarse tan importantes como cualquier otra funcionalidad. Si su equipo ha estado incorporando requisitos de seguridad en los argumentos de los usuarios y debatiendo sobre modelos de amenazas durante el proceso de diseño, añadir pruebas que cubran las funciones de seguridad es una extensión natural de ese trabajo.
Obtenga ayuda experta
Además de las pruebas que escribe usted mismo, existen varias herramientas de pruebas de seguridad que pueden ayudarle a generar confianza en la calidad de su código. Mientras que las herramientas de escaneo de seguridad tradicionales no eran adecuadas para un proceso automatizado de CI/CD, ahora existen herramientas para pruebas de seguridad de CI/CD que se han diseñado para la automatización, y que se integran en el proceso y muestran sus resultados a través del panel o los envían directamente a herramientas de seguimiento de incidencias. Como sucede con las pruebas automatizadas, vale la pena estructurar sus pruebas de modo que obtenga feedback lo más rápido posible.
Las herramientas de pruebas de seguridad para aplicaciones estáticas (SAST, del inglés Static application security testing), realizan análisis de código estático para comprobar si su código fuente presenta defectos de seguridad, como sobrecargas del buffer y oportunidades de inyección SQL. Como el análisis estático se ejecuta en el código fuente, puede ejecutarse en una fase temprana del proceso de CI/CD, tan pronto como se hayan confirmado los cambios.
Las herramientas de SAST son específicas de cada lenguaje, y algunas se integran con el IDE para ofrecer feedback continuo a medida que escribe, o la opción de ejecutar pruebas bajo solicitud. Al orientar a los desarrolladores hacia la línea de código específica que contiene la vulnerabilidad, las herramientas de SAST ofrecen datos objetivos que permiten solucionar las incidencias más rápidamente. No obstante, los falsos positivos pueden suponer un problema, así que ser capaz de silenciar o desechar ciertas alertas es esencial si desea evitar el riesgo de que todos los resultados de SAST se conviertan en distracciones.
La consecuencia directa del SAST son las pruebas de seguridad para aplicaciones dinámicas (DAST, del inglés Dinamic application security testing). Se basa en un enfoque de pruebas tipo caja negra para la aplicación que se está ejecutando, donde se comprueban vulnerabilidades conocidas como scripts intersitios, inyección SQL y de comandos, y configuración de servidor no segura. Como las herramientas de DAST requieren que la aplicación se compile e implemente en un entorno de pruebas, suelen utilizarse en una fase más avanzada del proceso de CI/CD.
Compruebe las dependencias
El análisis de componentes o composición del software (SCA) es otro tipo de prueba de seguridad automatizada que puede ejecutarse en un momento inicial del proceso. Como hemos dicho antes, prácticamente todas las bases de código incorporan bibliotecas de código abierto y otros componentes que pueden introducir vulnerabilidades.
Las herramientas de SCA deberían explorar no solo has dependencias que ha añadido, sino también las dependencias de éstas a lo largo de toda la cadena de suministro: un perfecto ejemplo de una tarea que es mejor encomendar a los ordenadores, especialmente si pensamos en con qué frecuencia se añaden dependencias nuevas a un proyecto.
Además de ejecutarse automáticamente como parte del proceso de CI/CD, algunas herramientas de SCA están disponibles como complementos del IDE para ofrecer feedback instantáneo. Como sucede con las pruebas de seguridad estáticas y dinámicas, las pruebas de SCA se limitan a las vulnerabilidades que las herramientas conocen, así que asegúrese de que las herramientas que escoja se actualicen con regularidad con nuevas vulnerabilidades y cubran las áreas más relevantes para su producto y organización. No obstante, encontrar vulnerabilidades nuevas e inesperadas requiere de intervención humana.
Incorpore al equipo rojo
El concepto del equipo rojo nace en los videojuegos de guerra, donde se pide a miembros de su propio equipo que desempeñen el papel de enemigo en un ataque simulado para identificar las debilidades en sus propias defensas y estrategias. Este mismo enfoque se ha utilizado con grandes resultados en el desarrollo de software, en ocasiones en forma de pruebas de penetración o pirateo ético.
Para que un equipo rojo funcione con eficacia, este no puede haber participado en el desarrollo del sistema que se va a probar. Al igual que con las pruebas exploratorias, el trabajo con un equipo rojo requiere que los testers piensen de forma diferente y utilicen el software de un modo distinto al previsto.
Un equipo rojo puede trabajar tanto un entorno representado (idealmente lo más similar posible al de producción) o en un sistema de producción en vivo. Si se decide por esta última opción, tendrá que tener una gran confianza en los modos de fallo de su producto o contar con usuarios (y directivos) muy tolerantes.
Trate todas las vulnerabilidades como errores
Un enfoque DevSecOps implica que todo el mundo asuma la responsabilidad de la seguridad de su software. Por ello, ya es hora de dejar de pensar en las incidencias de seguridad como si no tuviesen nada que ver con los errores "normales". Todos los fallos o vulnerabilidades que descubra en su sistema corresponden al mismo backlog que todas las demás incidencias, y deberían priorizarse junto con ellas.
Su resolución es responsabilidad de todo el equipo, no solo del embajador de seguridad. Adoptar este enfoque le ayuda a desarrollar conocimiento y experiencia en el equipo, y esas habilidades le serán útiles en el próximo proyecto en el que trabaje.
Siga vigilando la producción
A pesar de todos sus esfuerzos de las etapas anteriores del SDLC, todavía existe el riesgo de que un hacker encuentre alguna debilidad en su sistema en ejecución. Vale la pena invertir en firewalls y en herramientas de monitorización para proteger tanto a su organización como a sus usuarios. Las herramientas de autoprotección de aplicaciones de tiempo de ejecución (RASP, del inglés Runtime application self protection) son la última incorporación a estas defensas, y su función es detectar y bloquear el comportamiento sospechoso.
Conclusión
Desplazar la seguridad hacia la izquierda significa que todo el equipo la tenga en cuenta en todas las etapas del SDLC. Cuando emplea prácticas de DevOps, ese ciclo se repite con frecuencia, y les da a usted y a su equipo un feedback habitual sobre cómo se comporta y se utiliza su software en el mundo real. Integrar la seguridad en su proceso de CI/CD significa que obtendrá con regularidad feedback sobre la seguridad de su aplicación, y podrá mejorarla del mismo modo que el resto de sus funcionalidades.
Comprobar si existen vulnerabilidades conocidas y protegerse frente a ellas le asegurará, al menos, que su software está a la altura de los atacantes, y que no le deja indefenso ante vulnerabilidades conocidas. Tratar cualquier nueva vulnerabilidad como un error más por clasificar, reparar y testear en el futuro irá fortaleciendo su software con el tiempo.
Al fin y al cabo, DevOps (y con ello DevSecOps) es tanto una cuestión de cultura como lo es de herramientas y procesos que permitan una entrega de software rápida y frecuente. Después de todo, son las personas quien lo hacen posible. Si desea integrar la seguridad en el SDLC, la clave es crear una cultura de responsabilidad compartida en lugar de buscar culpables. Cualquiera debería poder indicar un problema de seguridad y que se le escuche, tanto si es durante la planificación de sprints, como en la revisión de código, las pruebas manuales o en el sistema en vivo, y todos deben reconocer la importancia de la seguridad e implementarla.