El Modelado de Amenazas de Seguridad
El Modelado de Amenazas de Seguridad es un proceso para la evaluación y documentación de los riesgos de seguridad de un sistema. El Modelado permite comprender el perfil de amenazas a las que está expuesto un sistema, mediante una evaluación a través de los ojos de sus potenciales enemigos. Con técnicas tales como la identificación de puntos de entrada, fronteras de privilegios y árboles de amenazas, se pueden identificar estrategias para mitigar las posibles amenazas del sistema. El Modelado de Amenazas también permitirá la justificación de la implementación de las características de seguridad dentro de su sistema, o las prácticas de seguridad para utilizarlo, para la protección de los activos de la empresa.
En el mundo de componentes distribuidos el compartir datos sensibles a través de las redes a significado un aumento de la exposición a los atacantes hambrientos por sus datos. Necesita crear un modelo de seguridad firme para beneficiarse de la visión de .NET de una informática totalmente funcional y distribuida. El fracaso para lograr esto puede llevar al desastre. Entonces ¿Cómo se asegura que su aplicación es tan segura como necesita ser? Bien, debería empezar con el Modelado de Amenazas (Threat Model), un acercamiento iterativo para evaluar las vulnerabilidades en su aplicación para encontrar aquéllas que son las más peligrosas porque exponen los datos más sensibles. A partir de allí, se crea un conjunto "contramedidas priorizadas" para manejar el riesgo.
Si desea adoptar el Modelado de Amenazas en su organización, primero debería preguntarse: ¿Está lista mi organización para el Modelado de Amenazas?
Para las organizaciones con incipientes procesos de seguridad de aplicaciones, Akshay Aggarwal recomienda seguir el siguiente marco de referencia para evaluar si es que están listas para adoptar un modelado amenazas:
¿Existe un referente de seguridad en la organización?
¿Está el proceso del Ciclo de vida de Desarrollo de Seguridad definido y seguido durante el desarrollo?
¿Ha acordado la organización las contra-medidas para las vulnerabilidades más comunes?
¿Están los desarrolladores capacitados para evitar las vulnerabilidades más comunes?
¿Realizan los desarrolladores una revisión del código acerca de las vulnerabilidades de seguridad?
¿Existe un equipo de evaluación de la seguridad?
Si la respuesta a más de dos de las preguntas anteriores es NO, entonces la organización probablemente aún no esté preparada para adoptar el modelado de amenazas, y debiese comenzar por hacer positivos los puntos en los que se falla.
Para más información consultar: Is Threat Modeling Right For You?
El mejor lugar para aprender acerca del Modelado de Amenazas de Microsoft, su rol en la arquitectura global y el proceso de diseño, es el documento "Improving Web Application Security: Threats and Countermeasures" del equipo de patterns & practices de Microsoft, así como el libro "Threat Modeling" de Frank Swiderski & Window Snyder, por lo que se recomienda su lectura.
Los pasos para crear un Modelo de Amenazas básicamente son seis:
Identificar los activos: Identificar los activos de valor le ayudará a centrarse en la actividad de modelado de amenazas y a determinar cuánto esfuerzo dedicará a los siguientes pasos.
Crear una descripción de la arquitectura: Utilice diagramas y tablas para documentar la arquitectura, incluyendo subsistemas, fronteras de confianza y flujo de datos.
Descomponer la aplicación: Descomponga la arquitectura de la aplicación, incluyendo la capa de red y el diseño de infraestructura, para crear un perfil de seguridad para la aplicación.
Identificar las amenazas: Utilice la información obtenida en los pasos 2 y 3 y la mentalidad de un atacante para identificar las amenazas más importantes para el contexto y el escenario del sistema.
Documentar las amenazas: Documente utilizando una plantilla que capture el conjunto básico de atributos de cada amenaza.
Asignar prioridades a las amenazas: Utilice una calificación de amenazas para centrarse en las áreas donde existe mayor vulnerabilidad y riesgo.
Comencemos con el primer paso: Identificar sus activos de valor, es decir, toda aquella información valiosa que maneja o los recursos a los que accede su aplicación. Cada sitio maneja algunos datos confidenciales, desde sueldos hasta los números del Seguro Social. Usted no sabrá qué quieren los hackers hasta que haya identificado la información sensible en su sitio.
El segundo paso es desarrollar una descripción global de la arquitectura. Usted necesita ser explícito sobre el propósito de la aplicación (Casos de Uso), sobre cómo planea llevar a cabo la arquitectura y el diseño de la aplicación para lograr esa funcionalidad, y sobre qué tecnologías se exigen para implementar el diseño. Esto le ayudará a identificar las amenazas comunes específicas a la tecnología y a implementar las soluciones para superarlas.
Durante este paso deberá realizar las siguientes tareas:
a. Identificar que es lo que hace la aplicación
b. Crear un diagrama de la arquitectura
c. Identificar la tecnología involucrada
Cuanto más sepa sobre su aplicación, más fácil es descubrir las amenazas. Los Casos de Uso y el Modelo Arquitectónico le ayudarán a descomponer su aplicación, que es el tercer paso. Este paso involucra la descomposición de su aplicación para así poder crear un "perfil de seguridad". Aceptando el axioma que todo dato de entrada es maligno, usted debe realizar la validación contra todos los datos enviados por los subsistemas. Se trata de seguir la misma ruta que seguirían los atacantes, determinando así las “rutas de amenazas”. Para ello un examen exhaustivo de los "límites de confianza", los flujos de datos, y los puntos de entrada nos asegurarán que todas las transferencias de datos son realizadas de una manera segura.
Algunas preguntas a realizar por cada componente del sistema serían:
¿De donde vienen los datos, que conexiones tiene que realizar para ello?
¿Cual es el nivel de confianza de los datos que entran y de los componentes de los cuales proviene?
¿Que procesamiento realiza el componente sobre los datos, que datos modifica?
Durante este paso deberá realizar las siguientes tareas:
a. identificar las fronteras de confianza
b. Identificar el flujo de datos
c. Identificar los puntos de entrada
d. Identificar el código privilegiado
e. Documentar el perfil de seguridad
En el cuarto paso, usted identifica las amenazas que pudieran afectar a su sistema y comprometer a sus activos.
Para ello puede utilizar dos enfoques básicos:
Utilizar el modelo STRIDE para identificar las amenazas
Utilizar listas de categorías de amenazas
Ambos descritos en el capítulo 2 del documento "Improving Web Application Security: Threats and Countermeasures".
Para tomar un acercamiento metódico, se debe trabajar por encima de la pila: Desde las amenazas a la red, a través de las amenazas al host, y finalmente las amenazas a la aplicación. Por lo que durante este paso, deberá realizar la siguientes tareas:
a. Identificar las amenazas de red
b. Identificar las amenazas de host
c. Identificar las amenazas de aplicación
Para evaluar las amenazas a la red, investigue cómo los datos pasan a través del router, firewalls, y switches. Ésta es la estrategia de "defensa a profundidad" a nivel de la red en la que necesita determinar que se requiere para pasar mas allá de cada gatekeeper. Cuando investigue el host, examine las categorías de configuración comunes aplicables a todos los recursos del servidor (parches, archivos, directorios, y así sucesivamente). Finalmente, concéntrese en la aplicación. La mejor manera de ir a lo profundo con su aplicación es usar "árboles de ataque" los cuales definan un ataque potencial en su sistema de una manera estructural y jerárquica. El documento "Improving Web Application Security" entra en mayores detalles sobre cómo crear y usar los árboles de ataque.
En el quinto paso, se documentará cada amenaza —la descripción de la amenaza, el blanco de ataque, el riesgo de llevarse a cabo el ataque, las técnicas que probablemente serán empleadas para perpetrar el ataque, y una estrategia para el manejo del riesgo. Por ejemplo, al tratar con un ataque "SQL Injection", el blanco es su base de datos y la técnica es teclear un comando en un cuadro de texto el cual se agrega automáticamente dentro de un comando T-SQL sin la validación del lado cliente. Para oponerse a ésta amenaza, utilice expresiones regulares para validar el nombre del usuario, y use una consulta con parámetros para acceder a la base de datos.
Hasta ahora ha estado en el modo de recolección de datos, determinando cada posible agujero en su aplicación. El sexto paso es asignarles una prioridad a cada amenaza. Manejar cada una de las amenazas concebibles no es práctico, pero necesita hacer una valoración de riesgo para asignarle prioridad y tratar las más importantes. Esto requiere un poco de matemática simple: la probabilidad de ocurrencia multiplicada por el daño potencial al ocurrir. La buena noticia es que ésta es una manera simple de asignar prioridad; la mala noticia es que ésta es una manera muy simple de asignar prioridad. Esto es algo subjetivo para dar un acercamiento meticuloso a la identificación de los riesgos. Hay acercamientos más completos para la valoración de riesgos.
Microsoft utiliza al modelo DREAD para evaluar el riesgo con una granularidad mayor que la matemática simple descrita anteriormente. La palabra "dread" significa "pavor" en inglés, pero en nuestro caso DREAD son las siglas en inglés que definen cinco atributos importantes para medir cada vulnerabilidad, :
Damage potential (potencial de daño)
Reproducibility (grado de reproducción)
Exploitability (grado de explotación)
Affected users (usuarios afectado)
Discoverability (grado de descubrimiento)
El documento "Improving Web Application Security" detalla cómo Microsoft emplea el DREAD para asignar prioridades a los riesgos y mitigarlos.
Estos seis pasos completan el proceso. Después de los cuales estará listo para implementar apropiadamente su estrategia de seguridad. Pero el Modelado de Amenazas es un proceso iterativo. Su modelo de amenazas deberá ser un elemento dinámico que cambie con el tiempo para hacer frente a nuevos tipos de amenazas y ataques tan pronto como son descubiertos. También deberá ser capaz de adaptarse a la evolución natural de su aplicación.
En conclusión. Mientras que se puede mitigar el riesgo de un ataque, no se puede mitigar o eliminar la amenaza actual. Las amenazas siempre existen a pesar de las acciones de seguridad que se tomen y de las contra-medidas que se apliquen. La realidad en el mundo de la seguridad es que se reconoce la presencia de amenazas y se gestiona sus riesgos. El Modelado de Amenazas nos ayuda a gestionar y comunicar los riesgos de seguridad a través del equipo y la empresa.
Fuente: https://willyxoft.wordpress.com/articulos/modelado-amenazas/
En el mundo de componentes distribuidos el compartir datos sensibles a través de las redes a significado un aumento de la exposición a los atacantes hambrientos por sus datos. Necesita crear un modelo de seguridad firme para beneficiarse de la visión de .NET de una informática totalmente funcional y distribuida. El fracaso para lograr esto puede llevar al desastre. Entonces ¿Cómo se asegura que su aplicación es tan segura como necesita ser? Bien, debería empezar con el Modelado de Amenazas (Threat Model), un acercamiento iterativo para evaluar las vulnerabilidades en su aplicación para encontrar aquéllas que son las más peligrosas porque exponen los datos más sensibles. A partir de allí, se crea un conjunto "contramedidas priorizadas" para manejar el riesgo.
Si desea adoptar el Modelado de Amenazas en su organización, primero debería preguntarse: ¿Está lista mi organización para el Modelado de Amenazas?
Para las organizaciones con incipientes procesos de seguridad de aplicaciones, Akshay Aggarwal recomienda seguir el siguiente marco de referencia para evaluar si es que están listas para adoptar un modelado amenazas:
¿Existe un referente de seguridad en la organización?
¿Está el proceso del Ciclo de vida de Desarrollo de Seguridad definido y seguido durante el desarrollo?
¿Ha acordado la organización las contra-medidas para las vulnerabilidades más comunes?
¿Están los desarrolladores capacitados para evitar las vulnerabilidades más comunes?
¿Realizan los desarrolladores una revisión del código acerca de las vulnerabilidades de seguridad?
¿Existe un equipo de evaluación de la seguridad?
Si la respuesta a más de dos de las preguntas anteriores es NO, entonces la organización probablemente aún no esté preparada para adoptar el modelado de amenazas, y debiese comenzar por hacer positivos los puntos en los que se falla.
Para más información consultar: Is Threat Modeling Right For You?
El mejor lugar para aprender acerca del Modelado de Amenazas de Microsoft, su rol en la arquitectura global y el proceso de diseño, es el documento "Improving Web Application Security: Threats and Countermeasures" del equipo de patterns & practices de Microsoft, así como el libro "Threat Modeling" de Frank Swiderski & Window Snyder, por lo que se recomienda su lectura.
Los pasos para crear un Modelo de Amenazas básicamente son seis:
Identificar los activos: Identificar los activos de valor le ayudará a centrarse en la actividad de modelado de amenazas y a determinar cuánto esfuerzo dedicará a los siguientes pasos.
Crear una descripción de la arquitectura: Utilice diagramas y tablas para documentar la arquitectura, incluyendo subsistemas, fronteras de confianza y flujo de datos.
Descomponer la aplicación: Descomponga la arquitectura de la aplicación, incluyendo la capa de red y el diseño de infraestructura, para crear un perfil de seguridad para la aplicación.
Identificar las amenazas: Utilice la información obtenida en los pasos 2 y 3 y la mentalidad de un atacante para identificar las amenazas más importantes para el contexto y el escenario del sistema.
Documentar las amenazas: Documente utilizando una plantilla que capture el conjunto básico de atributos de cada amenaza.
Asignar prioridades a las amenazas: Utilice una calificación de amenazas para centrarse en las áreas donde existe mayor vulnerabilidad y riesgo.
Comencemos con el primer paso: Identificar sus activos de valor, es decir, toda aquella información valiosa que maneja o los recursos a los que accede su aplicación. Cada sitio maneja algunos datos confidenciales, desde sueldos hasta los números del Seguro Social. Usted no sabrá qué quieren los hackers hasta que haya identificado la información sensible en su sitio.
El segundo paso es desarrollar una descripción global de la arquitectura. Usted necesita ser explícito sobre el propósito de la aplicación (Casos de Uso), sobre cómo planea llevar a cabo la arquitectura y el diseño de la aplicación para lograr esa funcionalidad, y sobre qué tecnologías se exigen para implementar el diseño. Esto le ayudará a identificar las amenazas comunes específicas a la tecnología y a implementar las soluciones para superarlas.
Durante este paso deberá realizar las siguientes tareas:
a. Identificar que es lo que hace la aplicación
b. Crear un diagrama de la arquitectura
c. Identificar la tecnología involucrada
Cuanto más sepa sobre su aplicación, más fácil es descubrir las amenazas. Los Casos de Uso y el Modelo Arquitectónico le ayudarán a descomponer su aplicación, que es el tercer paso. Este paso involucra la descomposición de su aplicación para así poder crear un "perfil de seguridad". Aceptando el axioma que todo dato de entrada es maligno, usted debe realizar la validación contra todos los datos enviados por los subsistemas. Se trata de seguir la misma ruta que seguirían los atacantes, determinando así las “rutas de amenazas”. Para ello un examen exhaustivo de los "límites de confianza", los flujos de datos, y los puntos de entrada nos asegurarán que todas las transferencias de datos son realizadas de una manera segura.
Algunas preguntas a realizar por cada componente del sistema serían:
¿De donde vienen los datos, que conexiones tiene que realizar para ello?
¿Cual es el nivel de confianza de los datos que entran y de los componentes de los cuales proviene?
¿Que procesamiento realiza el componente sobre los datos, que datos modifica?
Durante este paso deberá realizar las siguientes tareas:
a. identificar las fronteras de confianza
b. Identificar el flujo de datos
c. Identificar los puntos de entrada
d. Identificar el código privilegiado
e. Documentar el perfil de seguridad
En el cuarto paso, usted identifica las amenazas que pudieran afectar a su sistema y comprometer a sus activos.
Para ello puede utilizar dos enfoques básicos:
Utilizar el modelo STRIDE para identificar las amenazas
Utilizar listas de categorías de amenazas
Ambos descritos en el capítulo 2 del documento "Improving Web Application Security: Threats and Countermeasures".
Para tomar un acercamiento metódico, se debe trabajar por encima de la pila: Desde las amenazas a la red, a través de las amenazas al host, y finalmente las amenazas a la aplicación. Por lo que durante este paso, deberá realizar la siguientes tareas:
a. Identificar las amenazas de red
b. Identificar las amenazas de host
c. Identificar las amenazas de aplicación
Para evaluar las amenazas a la red, investigue cómo los datos pasan a través del router, firewalls, y switches. Ésta es la estrategia de "defensa a profundidad" a nivel de la red en la que necesita determinar que se requiere para pasar mas allá de cada gatekeeper. Cuando investigue el host, examine las categorías de configuración comunes aplicables a todos los recursos del servidor (parches, archivos, directorios, y así sucesivamente). Finalmente, concéntrese en la aplicación. La mejor manera de ir a lo profundo con su aplicación es usar "árboles de ataque" los cuales definan un ataque potencial en su sistema de una manera estructural y jerárquica. El documento "Improving Web Application Security" entra en mayores detalles sobre cómo crear y usar los árboles de ataque.
En el quinto paso, se documentará cada amenaza —la descripción de la amenaza, el blanco de ataque, el riesgo de llevarse a cabo el ataque, las técnicas que probablemente serán empleadas para perpetrar el ataque, y una estrategia para el manejo del riesgo. Por ejemplo, al tratar con un ataque "SQL Injection", el blanco es su base de datos y la técnica es teclear un comando en un cuadro de texto el cual se agrega automáticamente dentro de un comando T-SQL sin la validación del lado cliente. Para oponerse a ésta amenaza, utilice expresiones regulares para validar el nombre del usuario, y use una consulta con parámetros para acceder a la base de datos.
Hasta ahora ha estado en el modo de recolección de datos, determinando cada posible agujero en su aplicación. El sexto paso es asignarles una prioridad a cada amenaza. Manejar cada una de las amenazas concebibles no es práctico, pero necesita hacer una valoración de riesgo para asignarle prioridad y tratar las más importantes. Esto requiere un poco de matemática simple: la probabilidad de ocurrencia multiplicada por el daño potencial al ocurrir. La buena noticia es que ésta es una manera simple de asignar prioridad; la mala noticia es que ésta es una manera muy simple de asignar prioridad. Esto es algo subjetivo para dar un acercamiento meticuloso a la identificación de los riesgos. Hay acercamientos más completos para la valoración de riesgos.
Microsoft utiliza al modelo DREAD para evaluar el riesgo con una granularidad mayor que la matemática simple descrita anteriormente. La palabra "dread" significa "pavor" en inglés, pero en nuestro caso DREAD son las siglas en inglés que definen cinco atributos importantes para medir cada vulnerabilidad, :
Damage potential (potencial de daño)
Reproducibility (grado de reproducción)
Exploitability (grado de explotación)
Affected users (usuarios afectado)
Discoverability (grado de descubrimiento)
El documento "Improving Web Application Security" detalla cómo Microsoft emplea el DREAD para asignar prioridades a los riesgos y mitigarlos.
Estos seis pasos completan el proceso. Después de los cuales estará listo para implementar apropiadamente su estrategia de seguridad. Pero el Modelado de Amenazas es un proceso iterativo. Su modelo de amenazas deberá ser un elemento dinámico que cambie con el tiempo para hacer frente a nuevos tipos de amenazas y ataques tan pronto como son descubiertos. También deberá ser capaz de adaptarse a la evolución natural de su aplicación.
En conclusión. Mientras que se puede mitigar el riesgo de un ataque, no se puede mitigar o eliminar la amenaza actual. Las amenazas siempre existen a pesar de las acciones de seguridad que se tomen y de las contra-medidas que se apliquen. La realidad en el mundo de la seguridad es que se reconoce la presencia de amenazas y se gestiona sus riesgos. El Modelado de Amenazas nos ayuda a gestionar y comunicar los riesgos de seguridad a través del equipo y la empresa.
Fuente: https://willyxoft.wordpress.com/articulos/modelado-amenazas/
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios