El modelado de amenazas es realmente una habilidad, basada en la experiencia, después de aprender qué funciona y qué no.
No creo que la elección de un marco te haga las cosas mucho más fáciles, seguirás teniendo los mismos problemas y dificultades que tienes ahora.
Por el contrario, recomendaría STRIDE-per-element como el mejor lugar para comenzar, y luego agregaría técnicas adicionales según sea apropiado.
Es probable que sea más probable que solo necesite algunos consejos sobre cómo para hacer el modelado de amenazas de manera eficiente, simplemente cambiar la metodología no sería su bala de plata.
Mis recomendaciones:
- Realice primero un ejercicio completo de modelado de amenazas con alguien experimentado, que sepa cómo hacerlo; esa es realmente la mejor manera de aprender haciendo. Incluso si esto significa obtener un consultor externo durante unas horas.
- Una de las razones por las que se recomiendan los DFD es que a menudo ya existen. Trate de averiguar si alguien tiene esto, o incluso algo similar.
- Otra razón para los DFD es que pueden ser relativamente simples. Si dice que se queda atascado en las minucias, luego aléjese y mantenga el DFD en la capa 0 o capa 1, solo cavando ocasionalmente en la capa 2 según sea necesario, pero no más que eso.
- Recuerde que desea centrarse en la visión general de alto nivel, los flujos entre los módulos y los límites de confianza. Nunca debería tener que profundizar en la implementación (aunque involucre a desarrolladores / arquitectos que entienden cómo funciona, ¿puede ayudarlo a descubrir puntos interesantes que requieren mapeo adicional)? ¡No se deje llevar por los detalles!
- Microsoft tiene dos herramientas diferentes para ayudar con Threat Modeling, TAM y SDL TM. Estos se basan en diferentes perspectivas y sub-metodologías, una de ellas funciona como una aplicación similar a un "asistente". Prefiero SDL TM.
- Considere enfocar una TM en un módulo / sección de la aplicación a la vez, en lugar de intentar agarrar todo de una vez.
- Recuerda que durante TM, no estás buscando soluciones. Eso puede desviar rápidamente cualquier esfuerzo de TM.
- Idealmente, tendría los puntos de vista y los comentarios de todos los interesados (arquitectura / gestión de productos / desarrollo / control de calidad / operaciones ...), pero de manera realista, en muchas organizaciones no es posible, en su lugar, intente enfocarse en lo pequeño porciones de tiempo con representantes de cada uno, y plantea preguntas específicas que te ayudarán a desarrollar tu modelo. Si no hubo un DFD u otro diagrama, y usted lo construyó usted mismo: obtenga su retroalimentación, a menudo se lo agradecerán solo por proporcionarles eso.
Algunas reflexiones adicionales sobre TM, según sus preguntas adicionales al final:
Simplemente apuntar un escáner de aplicación web adecuado a sus servidores definitivamente será más fácil . Sin embargo, creo que la TM sería mucho más efectiva y, a largo plazo, también sería más eficiente (por muchas razones, aunque sea un tema diferente).
A pesar de que la aplicación ya existe, vale la pena volver atrás y analizarla: algunas cosas serán más fáciles (menos conjeturas), algunas pueden no tener éxito, pero puede descubrir qué tipos de fallas son interesantes . Eso es lo que puede ayudarlo a volver atrás y solucionar problemas específicos, no solo los aspectos técnicos que no se aplican a su negocio. Y en el peor de los casos, todo lo que hará es ayudarlo a enfocar sus esfuerzos de prueba en áreas que son más "interesantes", en lugar de realizar pruebas en masa de todo el sistema.
Algunos enlaces que he encontrado útiles en el pasado al enseñar a otros cómo hacer TM: