Introducción a la modelación de riesgos de seguridad (Security Threat Modeling)

Security Threat Modeling (STM por sus siglas en inglés, modelación de riesgos de seguridad) consiste en analizar las amenazas relativas a la seguridad de las IT a las que se expone un sistema, una aplicación, una interfaz o un modelo operativo (en la nube o local), etc. Este tipo de análisis de riesgos no se limita exclusivamente a los sistemas de IT, sino que también tiene relevancia cuando las empresas y organizaciones tienen relación o trabajan con activos digitales que requieren protección.

Un ejemplo muy sencillo, fuera del ámbito de las IT: Cuando la persona propietaria de una vivienda instala un detector de humo en la sala de estar que debe activar la alarma al notar la presencia de humos, lo hace porque esa persona ha analizado el peligro de intoxicación por gases o humos provocados por un incendio y ha decidido mitigar esa amenaza.

Ahora traslademos ese ejemplo al ámbito de las tecnologías de la información: los riesgos potenciales que amenazan a un sistema de IT se deben analizar y mitigar. Idealmente, esto tiene lugar antes del desarrollo del sistema. En nuestro ejemplo del detector de humo sería antes del incendio, claro. Durante la construcción de la vivienda, por ejemplo, elegir materiales no inflamables sería una medida de mitigación. Ese mismo ejemplo deja patente que, una vez finalizada la construcción, existirá cierta clase de riesgos que ya serán inevitables.

Por eso conviene no olvidar lo siguiente: Todo proceso de desarrollo de software debería contar como elemento imprescindible con un análisis de riesgos, para poder abordar las amenazas detectadas ya durante la fase de diseño y construcción del propio sistema.

¿Y QUÉ VIRTUDES TIENE LA MODELACIÓN DE RIESGOS DE SEGURIDAD?

Sigamos con el ejemplo de la vivienda. Las decisiones que se toman en etapas muy tempranas acarrean efectos drásticos para la seguridad de la propiedad inmobiliaria. Naturalmente, siempre es posible (y recomendable) instalar detectores de humo. Pero ¿no sería todavía mejor que hubiésemos apostado desde el principio por materiales no inflamables?

Un análisis de riesgos puede evitar que tomemos decisiones incorrectas o poco favorables para la arquitectura de IT y, desde luego, puede hacerlo antes de que se escriba una sola línea de código. Además, también puede ser útil para comprender y especificar cuáles son los requisitos de seguridad del sistema.

Veamos un ejemplo, este sí, del campo de la IT ¿Hace falta cifrar los datos? Quizás no sea una medida imprescindible en un servidor, pero sí es más que recomendable si se utilizan en un terminal móvil. Como se puede ver, existe una relación de estrecha dependencia entre el escenario de amenazas, las medidas de prevención (y mitigación) y los requisitos del sistema. Si se detectan y contemplan las necesidades de seguridad en las primeras etapas del diseño de cada solución, se podrá conformar un sistema más seguro.

¿Y CÓMO SE APLICA LA MODELACIÓN DE RIESGOS DE SEGURIDAD EN LA PRÁCTICA?

Dicho en palabras muy simples, la Security Threat Modeling no es otra cosa que reflexionar con antelación sobre todo lo que puede ocurrir en relación con la seguridad de IT y definir en consecuencia una estrategia de protección apropiada para evitar el peor de los casos. Para eso hay que responder a las siguientes preguntas:

1. ¿Qué queremos desarrollar?
2. ¿Qué puede suceder?
3. ¿Qué se puede hacer para contrarrestar esos problemas?
4. ¿Cómo se evalúa la situación general?
5. ¿Qué tal fue la calidad de los análisis?
6. Cada una de estas cinco preguntas representa un paso del proceso de análisis de amenazas.

PASO 1: ¿QUÉ QUEREMOS DESARROLLAR?

Los sistemas de IT suelen describirse con diagramas o esquemas técnicos. Lo ideal en este contexto es utilizar diagramas de flujo de datos, porque permiten visualizar todas las interfaces de conexión y los flujos de transmisión de datos. Pensemos que las amenazas solamente aparecen allí donde los datos fluyen o están disponibles. Veamos una aplicación web típica, a modo de ejemplo:

Nuestra aplicación se ejecuta en un centro de datos y consta de un proxy, una aplicación web y una base de datos. Naturalmente, cada aplicación web cuenta también, como mínimo, con un agente actor. O sea, el usuario que accede a través de Internet al proxy y así accede también a la app y la base de datos.

Para crear el diagrama de flujo de datos, además de preguntar al arquitecto responsable, siempre se debería consultar a uno o más desarrolladores y administradores de sistemas, porque solo así conseguiremos que, al terminar esta fase, tengamos un diagrama que sea correcto según la opinión de todas las partes implicadas. Y trabajar con un diagrama correcto es imprescindible para las siguientes etapas del proceso de modelización de Security Threat Modeling.

PASO 2: ¿QUÉ PUEDE SUCEDER?

Una vez que ya hemos creado el diagrama de flujo de datos del sistema, en esta siguiente fase toca reflexionar sobre todo lo que pueda ocurrir. Resulta muy útil asumir suposiciones que definan y limiten los posibles escenarios de riesgo.

Por ejemplo: Si contemplamos el ejemplo del sistema del Paso 1, cabe suponer que se utilizará un sistema operativo actual, con lo cual algunas amenazas ya quedan descartadas. Pero cuidado: Este tipo de suposiciones también debe ponerse constantemente en tela de juicio y debe tomarse en consideración en el propio análisis de amenazas.

Algunas preguntas son muy claras al respecto de qué podría suceder:

• ¿El servidor web es realmente ese que se anuncia como tal?
• ¿Sería posible manipular los datos entre el proxy y la aplicación web?
• ¿Cómo se asegura la aplicación web de que la base de datos ha recibido también los datos y los conserva?
• ¿Es posible que un usuario vea cómo es la arquitectura de backend a través de la aplicación web?
• ¿Es posible doblegar a la aplicación web (o a la base de datos) sometiéndola a una carga de trabajo muy alta?
• ¿Podría un usuario utilizar la aplicación web para hacer cosas para las cuales no tenga autorización?
  
  

Evidentemente, esta lista de preguntas se podría prolongar casi hasta el infinito. Pero claro, también existe el peligro de que pasemos detalles importantes por alto. Por eso conviene actuar de forma metódica ante estas preguntas. Aquí nos decantamos por el método STRIDE, desarrollado por Microsoft. STRIDE son las siglas de:

• S: Spoofing (suplantación)
• T: Tampering (manipulación)
• R: Repudiation (repudio)
• I: Information Disclosure (revelación de información)
• D: Denial of Service (denegación de servicio)
• E: Elevation of Privilege (elevación de privilegios)
  

Este método nos ayuda a categorizar las preguntas sobre qué puede suceder y reducir el riesgo de omitir algún aspecto relevante gracias a un procedimiento estructurado. No hace falta pensar mucho para percatarse de que todas las preguntas enumeradas anteriormente se pueden asignar a estas categorías.

PASO 3: ¿QUÉ SE PUEDE HACER PARA CONTRARRESTAR ESOS PROBLEMAS?

Al final de la fase de recopilación de supuestos y preguntas, deberíamos haber sintetizado una lista de amenazas para todas las interacciones y los datos que figuren en el diagrama de flujo de datos. En el siguiente paso, repasaremos la lista y abordaremos todas las amenazas identificadas. Se puede actuar de cuatro maneras distintas:

Mitigar una posible amenaza implica adoptar medidas para debilitarla o aliviarla, o bien para hacer más difícil que alguien intente explotarla en beneficio propio.

Por ejemplo: Exigir contraseñas para acceder a una interfaz administrativa mitiga el riesgo de que alguien se cuele y pueda actuar como administrador sin la autorización debida.

Eliminar estas amenazas suele requerir que se supriman ciertas funciones.

Por ejemplo: Podemos proteger la interfaz de acceso a las funciones administrativas por medio de contraseñas, pero sigue presente el riesgo de que alguien se haga pasar por administrador. Si queremos suprimir por completo esa potencial amenaza, habrá que desactivar la interfaz administrativa.

Transferir la amenaza o el riesgo consiste en trasladarla a otra persona.

Por ejemplo: Se puede transferir a un servicio de Active Directory la autenticación para acceder a la interfaz administrativa.

Aceptar una amenaza implica que optamos por no tomar ningún tipo de medida para contrarrestar un riesgo identificado. Se puede hacer por motivos muy diversos y totalmente válidos. A menudo, el desequilibro entre costes y utilidad decanta la balanza.

Bien, pues ya tenemos una lista de amenazas y de estrategias distintas para hacerles frente. En el siguiente paso tendremos que evaluar las medidas de mitigación y asignarles niveles de prioridad. Las medidas de mitigación elegidas se incorporarán al proceso de desarrollo del software. Aquí cabe echar mano de casos reales de usuarios o incluso consultar documentación sobre fallos y bugs.

Por ejemplo: Un hacker puede provocar la caída o el colapso de una base de datos al exponerla a un número excesivo de solicitudes de información automatizadas.

Al final de esta actividad, lo más previsible es que tengamos una enorme cantidad de tareas pendientes y medidas que poner en práctica. Pero antes de hacerlas realidad, hay que evaluar todas las amenazas y medidas, para realizar un análisis de coste-utilidad sensato.

PASO 4: ¿CÓMO SE EVALÚA LA SITUACIÓN GENERAL?

Tras las dos actividades anteriores, hemos elaborado una lista de amenazas y de posibles contramedidas. Ahora toca organizarlas todas (amenazas y contramedidas) por orden de prioridad. Tendremos que asignar a cada amenaza un nivel de riesgo.

La siguiente fórmula es una buena opción para ello:

Nivel de riesgo = Probabilidad de ocurrencia x Impacto

Existen distintos enfoques sobre cómo valorar los niveles de riesgo de las amenazas. Por ejemplo, el estándar Bug Bar de Microsoft o CVSS (Common Vulnerability Scoring System).

En las grandes empresas, este apartado se suele concretar en las políticas de seguridad propias. Para no complicarnos demasiado, diremos que la probabilidad de ocurrencia y el impacto se clasifican en cuatro categorías básicas de riesgo: muy alto, alto, intermedio y bajo.

Las posibilidades para evaluar las amenazas son muy variadas. En el primer paso, lo más importante es aplicar un procedimiento adecuado y coordinado para valorar las amenazas, que se utilice de forma estable o permanente y todo el mundo siga.

Tras evaluar todas las amenazas sin contramedidas, será necesario repetir la evaluación, pero en esta segunda ocasión, teniendo en cuenta dichas medidas. Sin embargo, esto último está más orientado a la elaboración de documentación y será útil para entender qué decisiones se hayan tomado posteriormente.

PASO 5: ¿QUÉ TAL FUE LA CALIDAD DE LOS ANÁLISIS?

El último paso de la modelización Security Threat Modeling consiste en evaluar la calidad del análisis de amenazas.

Examen de la arquitectura

En primer lugar, consultaremos de nuevo el diagrama de flujo de datos y comprobaremos si continúa siendo correcto. A veces, las decisiones sobre arquitectura sufren modificaciones en plazos muy cortos: se incorporan nuevas funciones, ciertos casos prácticos no contemplados originalmente aportan nuevos conjuntos de datos, se alteran las interacciones entre sistemas, etc. Todo ello obliga a actualizar, corregir o complementar el diagrama de flujo de datos.

Examen de las amenazas

Naturalmente, es fundamental identificar las nuevas amenazas que surjan como consecuencia de las modificaciones en la arquitectura. A continuación, se deberían comprobar de nuevo todas las amenazas detectadas en relación con sus posibles medidas de mitigación. Para eso habrá que repasar una vez más la lista de amenazas planteándonos las siguientes cuestiones: ¿se ha contemplado y tratado cada una de las amenazas? ¿Se ha mitigado correctamente cada una de las amenazas?

Pruebas para las medidas

Es necesario ejecutar pruebas para verificar la eficacia de todas las medidas contempladas. Se pueden realizar de forma manual o automatizada. Se debe certificar que todas las medidas concebidas para aplicarse ante amenazas tienen garantía de calidad. Lo ideal sería que estas pruebas o tests se integrasen en un marco de pruebas que se hubiese diseñado previamente, durante la fase de desarrollo.

CONCLUSIÓN

Evidentemente, en contextos de aplicación real, la metodología de modelización Security Threat Modeling es bastante más detallada, sofisticada y completa que este esbozo que ofrecemos. Pero este breve resumen debería bastar para recalcar la importancia de integrar la seguridad desde el propio concepto del proceso de desarrollo. Y también que es fundamental actualizarla periódicamente; por ejemplo, cada vez que se desarrolle una nueva función o se modifique el modelo operativo.

El método de análisis que se plantea aquí proporciona un nivel de seguridad mayor desde el principio, de la mano de la reflexión y el análisis sobre las medidas de mitigación y el equilibrio entre costes y utilidad.