Guía paso a paso sobre modelado de amenazas

¿Cómo modelamos amenazas?

El modelado de amenazas, en su esencia, trata realmente de hacer cuatro preguntas simples:

1. ¿En qué estamos trabajando?
2. ¿Qué puede salir mal?
3. ¿Qué vamos a hacer al respecto?
4. ¿Hicimos un buen trabajo?

Cómo responder: “¿En qué estamos trabajando?”

La esencia de esta pregunta es la documentación. Más específicamente, esta pregunta guía al equipo de desarrollo para que comience a pensar en (y documentar) los procesos centrales que se están desarrollando en términos de procesos, flujos de datos, almacenamiento de datos, áreas de control e identificación de lugares donde se están haciendo suposiciones de confianza entre los sistemas y procesos. La respuesta a “¿En qué estamos trabajando?” debe incluir una descripción verbal del caso de uso para la aplicación y un diagrama de flujo de datos que muestre:

• Entidades externas
  • Entidades fuera del control de la aplicación o empresa.
• Procesos
  • Código y sistemas bajo el control de la aplicación o empresa.
• Flujos de datos
  • Representación de datos que se mueven de un sistema a otro.
• Almacenamiento de datos
  • Representación de datos almacenándose en algún lugar (esto puede incluir el almacenamiento de contratos inteligentes de Stellar (Soroban), bases de datos en línea, servidores de archivos, etc.).
• Límites de confianza
  • Esbozar y agrupar áreas donde las interacciones entre sistemas generan o incluyen suposiciones de confianza. Por ejemplo, en un flujo de datos donde un usuario envía datos en una página web y se procesan en el backend, un límite de confianza debería abarcar el proceso de backend, ya que los datos pueden ser enviados al backend fuera de cualquier control de filtrado en el frontend.

Cómo responder: “¿Qué puede salir mal?”

Comprender el caso de uso y el flujo de datos de “¿En qué estamos trabajando?” puede informar en gran medida el pensamiento sobre lo que puede salir mal. Sin embargo, para garantizar la coherencia y exhaustividad en la revisión, es útil seguir un marco que ayude a guiar el pensamiento en torno a amenazas y lo que puede salir mal. La Stellar Development Foundation (SDF) sigue el modelo STRIDE. Descrito a continuación, el modelo STRIDE ayuda a proporcionar un marco coherente para garantizar modelos de amenazas de alta calidad.

Para cada uno de los acrónimos S, T, R, I, D y E en la tabla a continuación, asegúrate, como mínimo, de identificar al menos una incidencia. A menudo, habrá múltiples incidencias para cada amenaza. Es útil identificar cada incidencia con un identificador que indique tanto la amenaza con la que está conectada como su número. Dado que puede haber múltiples incidencias de suplantación, por ejemplo, puede ser útil identificar las incidencias como Spoof.1, Spoof.2, y así sucesivamente. Para flujos de datos especialmente complejos, incluso puede ser beneficioso aplicar un modelo STRIDE completo a un subproceso en el flujo. Asegúrate de que tu identificación pueda diferenciar entre estos también.

	Definición	Pregunta a hacer	Ejemplo
Suplantación	La suplantación es la capacidad de un atacante para pretender ser alguien que no es, a menudo aprovechando vacíos en la verificación del usuario final en sistemas posteriores.	¿Podría la acción que se está realizando ser inducida por alguien que no es la persona que se cree que tomó la acción?	Llamar y pedir pizza pretendiendo ser otra persona.
Tampering	La manipulación es la capacidad de un atacante para modificar datos que se están enviando o enviando para tener un efecto diferente al que se anticipó.	¿Podría haber sido modificado de alguna manera la solicitud para tomar una acción diferente a la originalmente prevista?	Un error de software cambia todos los ingredientes de pizza seleccionados a “queso.”
Repudio	El repudio es la capacidad de un usuario para afirmar que no tomó la acción que se tomó.	¿Puede el usuario “refutar” la acción, afirmando que no la tomó?	El usuario afirma que nunca pidió la pizza que pidió.
Información revelada	La divulgación de información es el exceso de compartir datos que se espera que se mantengan en privado.	¿Hay áreas donde se está compartiendo más información o información limitada se comparte con más personas de lo estrictamente necesario?	La empresa de pizzas muestra el pedido de pizza más reciente, nombre y número de teléfono en su página web.
Denegación de servicio	La denegación de servicio es la capacidad de un atacante para afectar negativamente la disponibilidad de un sistema.	¿Hay alguna parte de la aplicación que sea susceptible de ser sobrecargada o completamente inhabilitada debido a una demanda excesiva?	La empresa de pizzas tiene una única línea telefónica que solo devuelve ocupado cuando se llama mientras está en uso.
Elevar privilegios	La elevación de privilegios se refiere a la capacidad de un atacante para obtener privilegios y roles adicionales más allá de los que se le otorgaron inicialmente, ya sea por medios legítimos o ilegítimos.	¿Puede alguien obtener privilegios adicionales sin la debida autenticación y autorización?	El pizzero inicia sesión en el ordenador con la tarjeta de su jefe y elimina el pedido para no tener que hacer la pizza.

Cómo responder: “¿Qué vamos a hacer al respecto?”

Para cada incidencia identificada en el modelo STRIDE, piensa en las formas en que puede suceder y identifica un “tratamiento” o forma de abordar la incidencia. Las respuestas aquí deben ser detalladas en cómo la incidencia abordará la amenaza identificada. Esto podría incluir bloques de código que detallen los cambios o descripciones verbales de cómo se abordará la incidencia.

Cómo responder: “¿Hicimos un buen trabajo?”

El objetivo de esta sección es entender si el análisis realizado durante las otras secciones fue lo suficientemente profundo y amplio como para proporcionar valor. Algunas preguntas a hacer y responder aquí podrían incluir:

• ¿Se ha consultado el diagrama de flujo de datos desde que se creó?

  • Si es así, ¡felicitaciones, has creado una herramienta reutilizable que puede seguir añadiendo valor!
  • Si no, puede que necesites más detalle o mejor organización. El diagrama de flujo de datos debería ser una herramienta útil a la que se consulte regularmente.

• ¿El modelo STRIDE reveló alguna nueva incidencia de diseño o preocupación que no se había abordado o pensado previamente?

  • Si es así, ¡excelente! El modelo STRIDE debería ayudar a guiar el pensamiento hacia problemas de seguridad que podrían no haberse considerado durante la fase de diseño inicial.
  • Si no, asegúrate de tener al menos una incidencia para cada amenaza. Presta especial atención a los límites de confianza y a los procesos que manejan datos sensibles o llevan a cabo acciones particularmente poderosas.

• ¿Los tratamientos identificados en la sección “¿Qué vamos a hacer al respecto?” abordan adecuadamente las incidencias identificadas?

  • Si es así, ¡excelente! El ejercicio de modelado de amenazas ha ayudado a crear una aplicación más segura.
  • Si no, puede que desees proporcionar mayor detalle y reflexión sobre cómo responder a las incidencias identificadas.

• ¿Se han encontrado incidencias adicionales después del modelo de amenazas?

  • Si es así, ¡excelente! El modelo de amenazas es una herramienta viva que debería rehacerse cada vez que se realicen cambios significativos en la arquitectura. Durante la fase de diseño para estos cambios o adiciones, asegúrate de analizar el sistema con los cambios recién diseñados para identificar nuevas posibles incidencias en los cambios nuevos y en la interfaz con el sistema antiguo.
  • Si no, continúa refinando tu modelo de amenazas y diseño a medida que se aprenda nueva información sobre el sistema. El modelo de amenazas es una herramienta viva que puede seguir proporcionando beneficios a medida que se aprenda nueva información sobre el sistema.