UTN FRSF

La parte más laboriosa y menos comprendida del SDL es el MODELADO DE AMENAZAS Y VALIDACIÓN DE LA SUPERFICIE DE ATAQUE. Llevar a cabo estas actividades a lo largo de todo el SDL permitirán maximizar nuestra capacidad para poder reducir el número de vulnerabilidades de seguridad presentes en el software.

¿Quiénes participan en el modelado y análisis de amenazas?

Usualmente el modelado de amenazas y el análisis de la seguridad arquitectónica caen en el dominio de:

Arquitectos senior de la seguridad de software

Requieren de una mayor experiencia y experticia que cualquiera de las tareas dentro del SDL. Las personas del equipo que hacen esto deben ser capaces de pensar como un adversario. Los desarrolladores y miembros de equipo que se integren en este proceso deben saber no sólo como desarrollar o construir software, sino también cómo descomponer tanto el software como su arquitectura, mientras piensan como un adversario.

El objetivo del modelado de amenazas es:

Ganar una comprensión tanto de la aplicación de software mediante su descomposición como de la manera en que interactúa con entidades externas. Esto se logra mediante la recolección y documentación de información dentro de una estructura claramente definida, lo que garantiza que se ha recolectado la Información correcta. Desde una perspectiva de la seguridad, el objetivo clave en el modelado de amenazas es ganar una comprensión de como se ven las cosas que parecen funcionar exitosamente.

Conozcamos TRIKE

Trike es una metodología de modelado de amenazas alternativa a STRIDE y DREAD propuestos por Microsoft.

STRIDE es más bien un sistema de clasificación de amenazas: Spoofing Identity (Suplantación de identidad) Tampering with Data (Manipulación de datos) Repudiation (Repudio) Information Disclosure (Revelación de información) Denial of Service (Denegación de servicio) Elevation of Privilege (Elevación de privilegios)

DREAD es un modelo que nos facilitará la puntuación : Damage potential (Daño potencial): ¿Cual es el daño que puede originar la vulnerabilidad si llega a ser explotada? Reproducibility (Reproducibilidad): ¿Es fácil reproducir las condiciones que propicien el ataque? Exploitability (Explotabilidad): ¿Es sencillo llevar a cabo el ataque? Affected users (Usuarios afectados): ¿Cuantos usuarios se verían afectados? Discoverability (Descubrimiento): ¿Es fácil encontrar la vulnerabilidad?

TRIKE Es un marco de trabajo conceptual unificado para auditar la seguridad desde una perspectiva de la gestión de riesgo mediante la generación de modelos de amenaza de una manera confiable y repetible.

Es decir, los creadores de Trike, aportan a la comunidad open source, un framework y una metodología conceptual, acompañada por una herramienta que intenta facilitar el proceso de modelado.

La metodología, está diseñada con el propósito de permitir describir de forma completa y precisa las características de seguridad de un sistema, desde los detalles de alto nivel de la arquitectura, hasta la implementación. O al menos en teoría. ;)

http://www.octotrike.org/

¿Qué hace Trike? El objetivo de la herramienta Trike es automatizar las partes repetitivas de modelado de amenazas, por lo que todo lo que el analista tiene que hacer es analizar el sistema.

Trike tiene similitudes con el proceso de modelado de amenazas de Microsoft. Sin

embargo, se diferencia utilizando un enfoque basado en el riesgo con implementación,

modelos de amenaza y riesgo distintos, en vez de utilizar un modelo de amenaza mixto (ataques, amenazas y debilidades) como se representan por STRIDE / DREAD.

Se distingue por los altos niveles de automatización posibles dentro del sistema, la perspectiva defensiva del sistema, y el grado de

formalismo presente en la metodología.

Genera

automáticamente

amenazas ( y algunos

ataques) en base a una descripción del sistema, pero esto requiere que el usuario le describa el sistema a Trike y que luego verifique si esas amenazas y ataques se aplican.

Un elemento clave de Trike es el • empoderamiento, • involucramiento y • comunicación con las partes interesadas claves, con un progreso completo y transparencia del estado de la tarea de tal manera que ellas conocen el nivel de riesgo y pueden evaluar la aceptación del riesgo a lo largo del proceso de desarrollo de software.

Tools - Spreadsheet:

- Casi todo el mundo que está utilizando actualmente Trike para crear modelos de amenaza de los sistemas actuales está utilizando la hoja de cálculo.

- Standalone Tool: - Esta herramienta fue escrita en Smalltalk, específicamente

Squeak. Trike 1.1.2

Definiciones para entender la metodología de trabajo:

• Actores: – Personas que interactúan

directamente con el sistema.

– No son actores: • Programas

• Programadores

• Administradores de Red

Definiciones para entender la metodología de trabajo:

• Activos (Assets): – Todo lo que es atacable dentro del sistema.

– Entidades de datos normalmente atacables.

– No son activos:

• Reputación de la empresa.

• Tiempo de actividad del sistema.

• Hardware del sistema.

Definiciones para entender la metodología de trabajo:

• Acciones: – Los actores realizan acciones sobre

los activos de acuerdo con las reglas.

– Las acciones se descomponen en crear, leer, actualizar y eliminar.

Definiciones para entender la metodología de trabajo: • Reglas:

– Las reglas para una acción son un conjunto de fragmentos de oraciones declarativas conectadas por conectores lógicos (y, o, y no).

– Las reglas deben ser consistentes en la redacción y terminología, para facilitar el análisis.

Definiciones para entender la metodología de trabajo: • Amenazas:

– Dos categorías:

• Denegación de servicio: acciones pretendidas no pueden suceder.

• Elevación de privilegios: la acción se produce a pesar de las reglas.

¿Cómo descargarlo ? Entrar en la siguiente dirección: http://www.octotrike.org/tools.shtml

Descargar la Hoja De Cálculo.

¿Cómo descargarlo ?

Bibliografía Páginas Web:

http://www.octotrike.org/ https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf http://es.slideshare.net/alpin984/analisis-ymodeladodeamenazas

Libro: Core Software Security, capítulo 4- Arquitecura (A2), pág. 23.