El modelado de amenazas (Parte III)

Continuamos con la serie del modelado de amenazas en Flu Project. Hoy hablaremos de otras metodologías que se utilizan y complementan en algunas ocasiones a las tratadas anteriormente. Otra metodología de interés para su estudio es CORAS. CORAS, Consultative Objectire Risk Analysis System, es una metodología de la Unión Europea con la intención de dar un framework orientado a sistemas críticos. Lo que proporciona CORAS es un método basado en modelos con el fin de analizar los riesgos. Para cumplir esta función utilizar tres componentes en la metodología:

• Un lenguaje de modelado de riesgos basado en el UML.
• Descripción de un paso a paso del proceso de análisis con una directriz para construir los diagramas CORAS.
• Una herramienta para documentar, mantener y crear los informes del análisis.

La última metodología que se presenta es Trike. Este framework open source estaba acompañado de una herramienta que intenta facilitar el proceso del modelado de amenazas. La metodología pretende que el analista describa de forma completa las características de seguridad de un sistema, desde el alto nivel hasta la implementación. Trike se quedó en borrador de metodología, por lo que quedó un poco estancada allá por el año 2006. 

¿Con cuál te quedas?

Esto siempre es una pregunta difícil, pero la elegida esta vez es Microsoft Threat Analysis and Modeling. Los pasos de la metodología con mayor detalle son los siguientes: 

1. Identificar los objetivos de seguridad. Se determinan los objetivos que ayudan a cuantificar el esfuerzo necesario para llevar a cabo lo siguiente.

2. Crear una descripción general de la aplicación. Se identifican los actores involucrados y características importantes de la aplicación. Esta tarea facilita la identificación de amenazas.

3. Descomponer la aplicación. A partir de la arquitectura general se identifican los componentes que la forman. Se deben analizar de manera independiente y sobretodo sus interacciones. 

4. Identificar amenazas. Con toda la información se identifican las amenazas más importantes, deben estar priorizadas anteriormente. 

5. Identificar vulnerabilidades. Se revisan las diferentes capas de la aplicación y se identifican los puntos débiles de ésta. 

A través de los flujos de datos se comprende la lógica de la aplicación y se conoce cómo puede afectar al tratamiento de los datos a la integridad de los activos. Se tiene claro que para conocer las amenazas se debe conocer los puntos de entrada a la aplicación, niveles de confianza y activos. 

Por otro lado, los árboles de ataques permiten identificar amenazas y analizar cuáles son las formas de mitigación. ¿Cómo funciona? En el nodo principal o raíz del árbol se sitúa un objetivo del atacante. Los hijos representan los caminos que tiene el atacante para conseguir dicho objetivo. Los nodos hijo representan métodos y/o técnicas para conseguir los objetivos.

Una vez se han llevado a cabo los pasos iniciales del proceso, se debe proceder a la clasificación de las amenazas. Deben ser además puntuadas para poder priorizar. Existen dos esquemas, uno de clasificación denominado STRIDE y otro de puntuación denominado DREAD. Estos esquemas pueden variar en función de las necesidades de la organización o del proyecto en el que se lleven a cabo.

STRIDE

El esquema STRIDE, Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege, es un método de clasificación de amenazas. Según el método STRIDE el sistema se descompone en componentes y se analiza cada componente para comprobar que amenazas le pueden afectar. Cuando se detectan amenazas se proponen acciones para mitigarlas. El modelo utilizado está basado en patrones, con el que se puede identificar problemas repetibles y organizarlos en categorías. Estas categorías facilitan la descomposición de la aplicación para un análisis mejor. La metodología recomienda la reutilización de información y comunicación entre las partes. 

A continuación se detallan las partes de STRIDE. Comenzamos por la suplantación de identidad. Se debe prestar atención a las situaciones en las que se pueda llevar a cabo un robo de sesión, validaciones erróneas, sistemas de autenticación, etcétera.

La segunda propiedad es la manipulación de datos, la cual se debe tener en cuenta que durante la implementación se mejora tiempos de respuesta contra seguridad en la manipulación. El filtrado y validación de datos, tanto enviados como recibidos, de una aplicación se deben tener muy en cuenta ya que son procesos propensos a reclutar amenazas. Un ejemplo serían los típicos ataques web, como XSS, con el que una no validación correcta por parte del servidor hace que la amenaza se convierta en realidad. 

La tercera propiedad es el repudio. Las aplicaciones deben intentar garantizar el no repudio de los usuarios, por lo que un sistema de seguimiento de acciones realizadas es útil para cumplir con esta premisa. Las aplicaciones y sus características presentan diferentes riesgos, por lo que las medidas de registro de actividades de los usuarios también serán diferentes. En función del contexto de la aplicación se necesitará un sistema de seguimiento más rígido que en otras. 

La cuarta propiedad es la revelación de información. Cualquier tipo de información que ayude a un atacante indicándole el funcionamiento de la aplicación es un riesgo de este tipo. 

La quinta propiedad es denegación de servicio. Algunas funcionalidades de las aplicaciones dificultan la optimización de los recursos, para estos casos se debe realizar un uso racional y evitar que la aplicación pueda caer en una denegación de servicio. Se deben estudiar estos casos para evitar estas amenazas. 

La sexta propiedad es la elevación de privilegios. La aplicación puede tener diferentes niveles de privilegios, en función de distintos roles o tipos de usuarios. Hay que vigilar todas las acciones que conlleven el uso de privilegios y deben ser filtradas a través de una capa de autorización. La validación de privilegios debe ser robusta e impedir la escalada de privilegios. 

DREAD

Cuando se ha identificado la lista de amenazas se debe puntuar en función del riesgo que éstas suponen a la aplicación. Con esto se consigue priorizar las actuaciones a llevar a cabo con el objetivo de mitigar el riesgo. 

La fórmula del riesgo es R = probabilidad de ocurrencia * Daño potencial [ * valor]. En este caso el valor es opcional. Al menos debemos tomar R como la probabilidad de que la amenaza ocurra y el daño que ésta proporciona al sistema. Lo normal es utilizar una escala del 1 al 10 para cuantificar la probabilidad, 1 es poco probable y 10 es altamente probable. Por otro lado el daño se valora igual. Con esto Microsoft clasifica las amenazas en 3 categorías, alta, media y baja, dónde los valores van del 1 al 100 según la fórmula.