Como continuación al número anterior donde introducimos el mundo de la seguridad de aplicaciones, en este artículo vamos a hablar de una de las herramientas más importantes y eficaces para prevenir vulnerabilidades de seguridad durante el desarrollo de cualquier software: el modelado de amenazas, más conocido por su nombre en inglés, threat modeling. Ofreceremos una visión general, explicando en que consiste, como se implementa y aunque se mencionarán algunas de las principales metodologías que pueden utilizarse, nos centraremos en la que resulta más reconocida en el campo de la seguridad de aplicaciones (AppSec).
¿Qué es el Threat Modeling?
Se trata de una actividad proactiva que tiene lugar en las fases tempranas del ciclo de vida del desarrollo, más concretamente, durante la fase de diseño. Consiste principalmente en identificar y evaluar las amenazas y potenciales vulnerabilidades en un sistema informático.
Permite a los equipos de desarrollo y seguridad anticipar los posibles ataques, mejorar la seguridad del diseño del sistema, así como garantizar la integración de las medidas de mitigación necesarias desde el principio del desarrollo, lo que facilitará su implantación y reducirá los costes y tiempos asociados.
Para el correcto desarrollo de esta actividad, es importante contar con la participación de todas las funciones involucradas en el desarrollo, por lo que será necesario involucrar a los principales desarrolladores, arquitectos de software, personal de operaciones e infraestructura, y equipos de seguridad.
Metodologías de análisis
Existen diferentes enfoques a la hora de identificar las posibles amenazas, y en este sentido, cada equipo puede decidir la que mejor se ajuste a sus necesidades y su contexto, o incluso, por qué no, desarrollar la suya propia. A continuación, se mencionan algunas de las más conocidas:
- STRIDE: fue inicialmente desarrollada por Microsoft y se basa principalmente en tratar de identificar posibles amenazas basada en una lista de seis categorías diferentes, de donde veremos que procede su nombre.
- PASTA: es un proceso de análisis y evaluación de amenazas basado en siete pasos y principalmente enfocado en la aplicación que se está analizando y sus riesgos potenciales. Su nombre proviene de las siglas en inglés, Process for Attack Simulation and Threat Analysis.
- Trike: como en el caso anterior, su enfoque está basado en los riesgos y por tanto, evalúa las posibles amenazas y las vulnerabilidades identificadas en ese contexto. Se trata de una metodología open source y actualmente la versión 2 es la última disponible.
- VAST: está especialmente indicada para entornos ágiles de desarrollo, y se centra principalmente en la representación visual de las amenazas, priorizando la automatización, colaboración e integración. Su nombre proviene de las siglas en inglés, Visual, Agile, Simple Threat modeling.
La metodología STRIDE
Como se ha mencionado anteriormente, STRIDE se basa en la identificación de amenazas de acuerdo a las seis principales categorías de amenazas que pueden comprometer la seguridad de una aplicación. De sus siglas en inglés deriva el nombre de esta metodología: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service and Elevation of privileges.
Antes de continuar, veamos muy brevemente en que consiste cada una de estas categorías:
- Spoofing (falsificación o suplantación), se relaciona con el riesgo de suplantación de identidad de un usuario o de un dispositivo.
- Tampering (alteración o manipulación), tiene que ver con la modificación maliciosa de cualquier tipo de dato e impacta principalmente en la integridad de la información.
- Repudiation, o non-repudiation (rechazo o renuncia), se basa en la posibilidad de que un atacante o usuario malicioso pueda realizar cualquier tipo de acción sin dejar evidencia, pasando desapercibido.
- Information disclosure (revelación de información), ocurre cuando determinada información confidencial es expuesta.
- Denial of service (DoS, denegación de servicio), consiste en la interrupción de un determinado servicio de forma que quede inaccesible.
- Elevation of privileges (elevación de privilegios), tiene que ver con la posibilidad de que un usuario pueda llegar a obtener un nivel de acceso superior al que debería tener.
Implementación de STRIDE
El primer paso para llevar a cabo este tipo de análisis, consiste en la creación de un diagrama de flujo en el que se identifiquen todos los componentes del sistema, así como los datos que se mueven a través de la aplicación desde o hacia cada uno de los componentes o subsistemas. En este paso, se deben identificar además las distintas zonas de confianza (o trust boundaries) en las cuales se encontrarán cada uno de los componentes, de forma que se presente especial atención durante el posterior análisis cuando alguno de los datos atraviesa o cruza alguna de esas zonas.
Este diagrama de flujo, una vez terminado, ayudará a comprender el sistema completo desde la perspectiva de un posible atacante, por lo que se procederá a analizar y evaluar cada uno de los componentes atendiendo a las seis categorías mencionadas anteriormente. Se creará un registro de cada una de las amenazas encontradas, detallando a que categoría atiende, cual es la severidad del impacto de esa potencial amenaza (¿qué grado de criticidad tendría el daño sobre los datos o el propio sistema?) así como la probabilidad de su explotación (¿cuál es la dificultad para un atacante de poder explotar esta vulnerabilidad?).
Una vez finalizado ese registro de amenazas, se deben priorizar atendiendo a la severidad y la explotabilidad identificadas, de forma que se puedan desarrollar las estrategias de mitigación más adecuadas para cada una de ellas, contemplando aspectos tales como los controles técnicos a implementar (sistemas de autenticación, implementación de sistemas de cifrado, controles de acceso y sistema de autorización, validaciones de entrada, …), la aplicación de distintas políticas y procedimientos (formación y capacitación de usuarios, definición y establecimientos de nuevas políticas de seguridad, procesos de auditoría) e incluso de distintos controles físicos (seguridad física en el acceso a los servidores o a otros componentes que puedan ser críticos para el sistema).
Cuando se haya completado todo el análisis y la documentación mencionada, se implementarán las medidas de mitigación seleccionadas y se realizarán las pruebas necesarias para validar su efectividad. Estas pruebas pueden ser desde algunos tests funcionales, pasando por análisis y revisiones de código o implicar incluso test de penetración.
Todo este proceso de análisis e identificación de amenazas, no debe entenderse como una actividad puntual, y debe revisarse y mantenerse actualizada con cada una de las nuevas releases del sistema que se vayan liberando, de forma que sea una actividad más incorporada como parte del ciclo normal de diseño e implementación de cualquier nueva versión.
Conclusión
Como se desprende de la explicación anterior, el desarrollo del diagrama de flujo es tan sólo el comienzo del proceso de modelado de amenazas. sin embargo, seguir todo los pasos que se han expuesto e incorporarlo como una actividad más habitual en cualquier desarrollo, garantiza que los sistemas sean más resistentes y que están más preparadas para adaptarse a las nuevas amenazas que puedan ir apareciendo, manteniendo de este modo una postura de seguridad mucho más robusta a lo largo del tiempo.
Deja una respuesta