¿Cómo encaja el modelado de amenazas en el acelerado mundo de DevSecOps?
Escrito por
0 minutos de lectura
DevSecOps busca hacer posible el desarrollo de software de calidad con mayor rapidez. Sin embargo, el proceso de modelado de amenazas tiene fama de ser tan complejo y consumir tanto tiempo que muchas organizaciones creen que ralentiza el ciclo de vida del desarrollo de software (SDLC). ¿Cómo podemos combinar ambos para obtener los beneficios de seguridad del modelado de amenazas sin poner obstáculos al proceso de desarrollo de software?
Esta publicación del blog analiza el modelado de amenazas y cómo encaja de forma natural en el proceso de DevSecOps.
¿Qué es el modelado de amenazas?
El modelado de amenazas examina el diseño de las operaciones de un sistema y cómo fluyen los datos entre los límites de los subsistemas. Después, identifica todos los puntos de ataque que los hackers podrían aprovechar y cómo podrían hacerlo. Por último, diseña soluciones para mantener seguros el sistema y sus datos.
Según el destacado experto Adam Shostack, el proceso de modelado de amenazas plantea las siguientes preguntas:
¿Qué estamos construyendo? Evalúa por dónde fluyen los datos en un sistema, los límites que atraviesan y la tecnología que se usa en cada transferencia.
¿Qué puede salir mal? Analiza todas las formas posibles de aprovechar las transferencias.
¿Qué haremos al respecto? Diseña defensas contra cada exploit.
¿Hicimos un buen trabajo? La última pregunta, y la más importante, nos invita a reflexionar sobre el proceso, revisarlo y recordar que el trabajo nunca termina realmente: siempre hay margen para mejorar.
Luego, el equipo prioriza los riesgos de las amenazas y los incorpora al desarrollo.
¿Cuándo debes realizar el modelado de amenazas?
El momento ideal para realizar el modelado de amenazas es en las primeras etapas del SDLC, durante la fase de arquitectura del desarrollo de aplicaciones. Cuanto antes identifiques las amenazas, más eficientemente podrás idear soluciones para frustrar los vectores de ataque.
Es mejor incorporar la seguridad en la aplicación desde el principio, pero nunca es demasiado tarde para aprovechar los beneficios del modelado de amenazas, incluso en aplicaciones heredadas. Este ejercicio puede ser valioso para todas las personas involucradas, sin importar en qué momento del SDLC se realice.
Empieza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.
La historia del modelado de amenazas
Los primeros intentos de modelado de amenazas comenzaron en la década de 1990 con la idea de los árboles de ataque. Esto llevó a Loren Kohnfelder y Prerit Garg, de Microsoft, a distribuir un documento llamado “The Threats to Our Products”, que se considera ampliamente la primera descripción formal de un proceso de modelado de amenazas.
Desde entonces, la industria se ha unido en torno a organizaciones como Open Web Application Security Project (OWASP), que clasifican las principales amenazas, explican cuáles son y qué se debería hacer al respecto. OWASP también publicó una evaluación de amenazas similar para la seguridad de las API digitales con el fin de abordar las API de software como servicio (SaaS).
Hoy, cuando hackers han robado millones de registros de usuarios de empresas como Yahoo, Uber y First American Financial, todas las organizaciones deben estar al tanto de las amenazas digitales. Los informes de seguridad de 2020 muestran un panorama alarmante:
En 2020 se registraron más de 18,000 vulnerabilidades, y casi una cuarta parte eran de gravedad alta.
Las empresas pagaron un promedio de 3.86 millones de dólares para solucionar una filtración de datos.
Los ataques de malware y ransomware aumentaron un 358 % y un 435 %, respectivamente.
Consejos para el modelado de amenazas
El proceso de modelado de amenazas puede ser bastante complejo. Un enfoque muy conocido, la metodología STRIDE, recomienda realizar un análisis técnico independiente para cada tipo principal de ataque:
Suplantación: Violar la autenticación mediante algún tipo de suplantación de identidad.
Manipulación: Violar el sistema de una forma que permita realizar otros exploits.
Repudio: Violar la detección ocultando evidencia de ataques o falsificando registros para que parezcan normales durante los ataques, ocultar la intención y permitir que el ataque continúe.
Divulgación de información: Violar la confidencialidad buscando formas de extraer datos confidenciales de cualquier parte del sistema.
Denegación de servicio (DoS): Violar el acceso de los usuarios a los sistemas agotando deliberadamente los recursos necesarios para que el sistema funcione correctamente.
Elevación de privilegios: Violar la autorización engañando al sistema para que otorgue más privilegios a una cuenta y permita un acceso más profundo al sistema.
Los diagramas de flujo de datos (DFD), STRIDE y las metodologías más recientes similares proporcionan un marco para responder preguntas como estas:
“¿Qué estamos construyendo?” Los DFD son una forma de representar el sistema y sus distintos límites de confianza como primer paso para comprender las amenazas de seguridad.
“¿Qué puede salir mal?” STRIDE se centra en esta pregunta y examina cada tipo de ataque en función de cómo está construido el sistema.
Por ejemplo, en 2019, un ataque de denegación de servicio al servidor de API de Kubernetes aprovechó una vulnerabilidad que permitía enviar grandes cantidades de datos en la “carga útil” de la API, lo que sobrecargaba el sistema.
Entre las formas de mitigar la amenaza estaban:
Límites al tamaño de la carga útil de cada llamada
Límites a las llamadas a la API por usuario o dirección IP
Esto repelió futuros ataques DoS contra el servidor de API.
Estos esfuerzos requieren analizar a fondo las funciones del sistema y deben realizarse para cada tipo de ataque. Es posible encontrar soluciones, pero investigar, diseñar, desarrollar, probar e implementar lleva tiempo.
Por qué el modelado tradicional de amenazas representa un desafío para DevSecOps
El modelado tradicional de amenazas requiere reuniones de análisis con todas las partes interesadas, incluidos profesionales de TI y expertos en ciberseguridad. Estas reuniones permiten compartir muchos conocimientos e información sobre amenazas y estrategias de mitigación que todas las partes consideran valiosos.
Sin embargo, las reuniones en sí consumen mucho tiempo y pueden mantener ocupadas a muchas personas durante días. Por eso, no se pueden convocar antes de cada sprint. Estas reuniones van en contra de la cultura de DevSecOps, que se centra en acelerar el ciclo de vida del desarrollo de software.
Tendencias populares de DevOps que aceleran el desarrollo:
Impulsa la automatización y las pruebas lo más temprano posible en el proceso de compilación (“shift left”).
La automatización no es solo para el código de las aplicaciones, sino también para la infraestructura del sistema, donde las nuevas tecnologías permiten definir la infraestructura mediante código y, por lo tanto, probarla.
Esta automatización acelera la integración continua y la entrega continua (CI/CD), lo que permite implementar funciones y correcciones de errores con mayor frecuencia y confianza.
El resultado: el desarrollo de software es cada vez más rápido, y algunos equipos implementan código nuevo en producción cada dos a cuatro semanas. ¿Cómo encontrar tiempo para reuniones de seguridad largas con ese ritmo?
Capacitación del equipo en modelado de amenazas para orientar el proceso de DevOps
La capacitación es clave para incorporar una mentalidad de modelado de amenazas al SDLC seguro, como destaca Brandon Jeanmarie, experto en seguridad de IBM. Sin embargo, no es posible tener reuniones largas y numerosas con frecuencia. Por eso, recomienda un enfoque de capacitación “justo a tiempo” para los miembros del equipo de desarrollo que trabajan con clientes:
El modelado de amenazas no es difícil de entender: Aprovecha las oportunidades para explicarlo a desarrolladores y gerentes, de modo que comprendan lo que se puede hacer, empezando “ahora”, desde el punto en el que se encuentran actualmente en el desarrollo de su sistema.
Todas las partes interesadas del sistema se benefician de aprender: Presenta el modelado de amenazas de una forma que tenga sentido para el rol de cada integrante del equipo. Una vez que sean conscientes, podrán participar en la solución durante la planificación de las historias del sprint y establecer prioridades en consecuencia.
La capacitación también puede “moverse hacia la izquierda”: Lleva la concientización sobre el modelado de amenazas lo más temprano posible en el proceso. Esto crea buenas prácticas en DevSecOps y permite incorporar la identificación y mitigación de amenazas lo antes posible.
Las herramientas de modelado de amenazas pueden “extenderse hacia la derecha”: Las herramientas de terceros pueden ofrecer detección automática de amenazas y automatización de su mitigación en etapas posteriores del SDLC, incluso en producción, donde pueden seguir protegiendo el sistema.
Jeanmarie concluye que la capacitación contextual y basada en roles fomenta una mentalidad de “seguridad desde el diseño” que fortalece DevSecOps en una organización. Y esto puede lograrse sin reuniones frecuentes y extensas. Una vez que este conocimiento forme parte de la cultura, todas las personas podrán ayudar cuando les toque mitigar amenazas.
Empieza con Capture the Flag
Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.
4 pasos para incorporar el modelado de amenazas al diseño de historias ágiles
La defensora de la seguridad Alyssa Miller lleva el modelado de amenazas un paso más hacia la izquierda. Analizó cómo incorporar el modelado de amenazas a DevSecOps de forma más fluida. Su propuesta:
Limita el alcance del modelado de amenazas a los requisitos de cada historia de usuario. Ese es el punto más temprano al que puedes llegar en DevSecOps.
El procedimiento consiste en incluir al usuario de negocio en la conversación de análisis de la historia. Esto funciona porque los requisitos de la historia están antes que los detalles técnicos. Hazle estas preguntas al usuario de negocio:
¿Cuáles son los activos críticos relacionados con la nueva función?
¿Qué es lo peor que podría pasarle a cada activo crítico?
La conversación permite identificar de forma natural los requisitos de seguridad y agregarlos a la historia con un lenguaje sencillo que todos puedan entender, por ejemplo:
Las funciones críticas F1 y F2 deben protegerse contra el uso no autorizado.
Los datos privados XYZ deben protegerse para evitar su exposición.
La transacción monetaria para la compra P debe protegerse contra el robo durante la transmisión.
Estas declaraciones en lenguaje sencillo, agregadas a la historia, desencadenarán una serie de actividades posteriores en el proceso de desarrollo.
Al replantear así el proceso de modelado de amenazas, pudo definirlo de forma más concisa: “Identificar las amenazas probables para un sistema con el fin de orientar el diseño de contramedidas de seguridad”.
Miller cree que esto lleva la cultura de DevSecOps a las primeras etapas del SDLC y permite que todo el equipo de desarrollo incorpore el modelado de amenazas contextual al objetivo general de mejora continua. Esto sucede porque todas las personas adoptan una mentalidad de seguridad y llevan esa conciencia a las reuniones de planificación de sprints y a todas las actividades posteriores:
Planificar: Incluye los requisitos de seguridad en la historia.
Desarrollar: Incorpora medidas de mitigación de amenazas (controles de seguridad) al SDLC.
Probar: Escribe historias con casos de uso para mitigar amenazas y conviértelos en casos de prueba.
Implementar: Crea monitores que implementen los casos de prueba y configura alertas.
Miller concluye que, con este proceso, es posible incorporar el modelado de amenazas sin afectar la velocidad de DevSecOps.
Conclusión
La cultura de DevSecOps consiste en dividir el SDLC en partes que se puedan automatizar para incorporar calidad desde el principio del ciclo (“shift left”) y ampliar las herramientas hacia la derecha (“extend right”) para cubrir todo el proceso de entrega de software. Capacitar a todo el equipo sobre el modelado de amenazas y cómo también puede dividirse en etapas del SDLC, empezando por los requisitos, permite que la conciencia sobre las amenazas esté presente y oriente cada paso de DevSecOps.