Stride and dread info PDF

Preview

Summary

El modelado de amenazas de aplicaciones con STRIDE y DREAD es un enfoque para analizar la seguridad de una aplicación. Es un enfoque estructurado que le permite identificar, clasificar, calificar, comparar y priorizar los riesgos de seguridad asociados con una aplicación....

Description

Stride and dread Introducción El modelado de amenazas de aplicaciones con STRIDE y DREAD es un enfoque para analizar la seguridad de una aplicación. Es un enfoque estructurado que le permite identificar, clasificar, calificar, comparar y priorizar los riesgos de seguridad asociados con una aplicación.

El modelado de amenazas de aplicación se debe considerar separado de la evaluación de riesgos, aunque similar, pero el modelado de amenazas de aplicación es más un enfoque calculado. La inducción del modelado de amenazas de aplicaciones en el proceso SDLC tiene sus ventajas para la seguridad de todo el proyecto. Lo más importante cuando se realizan evaluaciones de seguridad siguiendo el enfoque de modelado de amenazas es darle al revisor una visión general completa de la Aplicación. ¿Por qué los probadores de penetración deben preocuparse? Si la severidad de las vulnerabilidades se mide solo por el "Nombre" de la vulnerabilidad, tiene el potencial de exagerar o subestimar el riesgo que representa. Por ejemplo, si una vulnerabilidad permite que un atacante identifique nombres de usuario en una Aplicación, en sí mismo no representa un riesgo importante, pero digamos que es una aplicación bancaria y que bloquea a los usuarios después de 5 intentos de contraseña incorrecta, el atacante podría simplemente escribir un script para rocíe la combinación de contraseña incorrecta del nombre de usuario legítimo en la aplicación y bloquearía a todos los usuarios para acceder a servicios bancarios o cualquier otro servicio de alto tráfico. Ahora que es un riesgo importante y su gravedad exacta solo se puede calcular si aplicamos un enfoque metodológico como DREAD (que se explica a continuación) Procedimiento Para llevar a cabo el Modelo de Riesgo de Amenaza de la Aplicación, use el marco de pruebas OWASP para identificar, la metodología STRIDE para clasificar y la metodología DREAD para calificar, comparar y priorizar los riesgos, según la gravedad. Los siguientes son los pasos involucrados en el modelado de amenazas de riesgo de la aplicación:

Descomponer la aplicación El primer paso del modelado de amenazas es comprender cómo interactúa con las entidades internas y externas, identificar los puntos de entrada, los límites de privilegios, la matriz de control de acceso y las pilas de tecnología que se utilizan. Este paso en la metodología de prueba de OWASP se denomina fase de recopilación de información en la que recopila la máxima información

sobre el objetivo. Tal vez escribiré otra publicación para explicar el proceso y las herramientas para la descomposición de la aplicación, pero está fuera del alcance de esta publicación. Identificar La implementación de los resultados del marco de pruebas de OWASP en la identificación de vulnerabilidades en la aplicación, esto se conoce comúnmente como Pruebas de penetración de la aplicación. Los atacantes de pruebas de penetración utilizan herramientas y técnicas para encontrar las máximas vulnerabilidades en la aplicación.

Clasificar Amenazas Una vez que se identifican las vulnerabilidades, se utiliza la metodología STRIDE introducida por Microsoft para clasificar estas vulnerabilidades. Durante los compromisos de seguridad, es vital respaldar sus reclamos (sobre vulnerabilidades) con una base sólida como un marco o estándar. Por ejemplo, si encuentra una vulnerabilidad y la clasifica de acuerdo con STRIDE, obtendré menos argumentos sobre la clasificación. Modelado de amenazas Un proceso para identificar amenazas al sistema, los riesgos asociados y determinar los controles correctos para producir contramedidas efectivas La salida es una lista de amenazas clasificadas. El modelo de amenazas te ayuda a centrarte en las amenazas más potentes. Dirigido para ser utilizado en la fase de diseño de un sistema. Sin embargo, generalmente implementado en la fase de prueba (evaluación de vulnerabilidad) No solo para aplicaciones web. Puede ser (y debería ser ...) aplicado a diferentes tipos de sistemas STRIDE Una metodología para identificar y categorizar amenazas. Spoofing identity (identidad falsificada: Un atacante intenta ser algo o alguien que él /ella no es) Tampering with data (Manipulación de datos: Un atacante intenta modificar los datos que se intercambian entre su aplicación y un usuario legítimo) Repudiation (Repudio: Un atacante o actor puede realizar una acción con su aplicación que no sea atribuible) Information disclosure (Divulgación de información: Un atacante puede redondear los datos privados que su aplicación está transmitiendo o almacenando)

Denial of service (Negación de servicio: Un atacante puede impedir que sus usuarios legítimos accedan a su aplicación o servicio) Elevation of privileges (Elevación de privilegios: Un atacante puede obtener derechos de acceso elevados a través de medios no autorizados.) DREAD Califica, compara y prioriza las amenazas La metodología DREAD se utiliza para calificar, comparar y priorizar la gravedad del riesgo que presenta cada amenaza que se clasifica mediante STRIDE. DREAD Risk = (Daño + Reproducibilidad + Explotabilidad + Usuarios afectados + Descubrimiento) / 5. El cálculo siempre produce un número entre 10. Más alto es el número, más grave es el riesgo. A continuación se presenta un enfoque matemático personalizado para implementar la metodología DREAD: Damage potential ( Daño potencial) Si se produce un ataque de amenaza, ¿cuánto daño se causará? 0 = Nada 5 = Revelación de información que podría usarse en combinación con otras vulnerabilidades 8 = Los datos de usuario no sensibles del individuo / empleador están comprometidos. 9 = Los datos administrativos no confidenciales están comprometidos. 10 = Sistema completo o destrucción de datos. 10 = Indisponibilidad de la aplicación. Reproducibility (Reproducibilidad) ¿Qué tan fácil es reproducir la amenaza? 0 = Muy difícil o imposible, incluso para los administradores de la aplicación. 5 = Se requieren pasos complejos para el usuario autorizado. 7.5 = Pasos sencillos para usuarios autenticados 10 = Solo un navegador web y la barra de direcciones es suficiente, sin autenticación. Exploitability (Explotabilidad)

¿Qué se necesita para explotar esta amenaza? 2.5 = Conocimiento avanzado de programación y redes, con herramientas de ataque personalizadas o avanzadas. 5 = Explotar salidas en público, usando las herramientas de ataque disponibles. 9 = Una herramienta de Proxy de aplicación web 10 = Sólo un navegador web Affected Users (Usuarios afectados) ¿Cuántos usuarios se verán afectados? 0 = ninguno 2.5 persona / empleador que ya está comprometido. 6 = algunos usuarios de privilegios individuales o de empleador, pero no todos. 8 = Usuarios administrativos 10 = Todos los usuarios Discover ability (Descubrir capacidad) ¿Qué tan fácil es descubrir esta amenaza? 0 = Muy difícil requiere código fuente o acceso administrativo. 5 = Se puede resolver monitoreando y manipulando solicitudes HTTP 8 = Los detalles de fallas como esta ya están en el dominio público y se pueden descubrir fácilmente usando un motor de búsqueda. 10 = la información es visible en la barra de direcciones del navegador web o en un formulario. La metodología DREAD se puede personalizar para satisfacer las necesidades de su aplicación, durante los contratos de consultoría, debe ser aprobada por el cliente antes de comenzar la evaluación de seguridad para que después de realizar el análisis, los resultados producidos por DREAD no puedan ser cuestionados. La fórmula de cálculo de la tasa global de riesgo: Clasificación = (D + R + E + A + D) / 5

Proceso de modelización y análisis de amenazas. Microsoft. Categorías STRIDE y DREAD

El acrónimo STRIDE se forma de la primera letra de cada una de las siguientes categorías:

Spoofing de identidad Es un riesgo clave para aplicaciones que tienen muchos usuarios pero proporcionan un único contexto de ejecución en el nivel de la aplicación o base de datos. En concreto los usuarios no deberían convertirse en cualquier otro usuario o asumir los atributos de otro usuario Tampering with data Los usuarios pueden cambiar potencialmente los datos entregados a ellos, devolverlos y consecuentemente manipular potencialmente la validación del lado del cliente, los resultados GET y POST, las cookies, las cabeceras HTTP, etc. La aplicación no debería enviar datos al usuario, como tasas o períodos de interés que se obtienen sólo desde dentro de la propia aplicación. La aplicación también debería comprobar con cuidado los datos recibidos del usuario y validar que son sanos y aplicables antes de almacenarlos o utilizarlos. Repudio Los usuarios pueden disputar y repudiar transacciones si existe una insuficiente auditoría o registro de sus actividades. Por ejemplo, si un usuario dice “no transfiero dinero a esta cuenta externa” y no se puede seguir sus actividades a través de la aplicación, entonces es muy probable que la transacción tendrá que escribirse como una pérdida. Consecuentemente el considerar si la aplicación requiere controles de no repudio como logs de acceso Web, registros de auditoría en cada capa o el mismo contexto de usuario de arriba abajo. Es preferible que la aplicación debería ejecutarse con los privilegios de usuario, no más, pero esto puede no puede ser posible con muchas plataformas de aplicación. Information disclosure Los usuarios son desconfiados legítimamente de emitir detalles privados a un sistema. Si es posible para un atacante revelar públicamente datos del usuario a lo grande, anónimamente o como un usuario autorizado, existirá una pérdida inmediata de confidencialidad y un período sustancial de pérdida de reputación. Por tanto, las aplicaciones deben incluir controles fuertes para prevenir la captura y abuso del identificador de usuario, concretamente si utilizan un único contexto para ejecutar toda la aplicación. También se debe considerar si el navegador Web del usuario puede fugar información. Algunos navegadores Web pueden ignorar las directivas de no caching en las cabeceras HTTP o manejarlas incorrectamente. Así mismo cada aplicación segura tiene una responsabilidad de minimizar la cantidad de información almacenada por el navegador Web, en caso de fuga de

información que puede utilizar un atacante para aprender detalles acerca de la aplicación, el usuario o potencialmente convertirse en ese usuario. A la hora de implementar valores persistentes tener en cuenta que el uso de campos ocultos es por naturaleza inseguro. Tal almacenamiento no debería descansar en información sensible segura o proporcionar las adecuadas salvaguardas de privacidad personal. Denegación de servicios Los diseñadores de aplicaciones deberían ser conscientes de que sus aplicaciones pueden ser sujeto de ataques de denegación de servicios. Por tanto, el uso de recursos caros como ficheros grandes, cálculos complejos, búsquedas muy pesadas o consultas de gran longitud deberían reservarse para usuarios autenticados y autorizados y no estar disponible para usuarios anónimos. Para aplicaciones que no tienen este lujo, cada faceta de la aplicación debería ser diseñada por ingeniería para realizar el mínimo trabajo posible, utilizar pocas queries de base de datos rápidas, evitar la exposición a ficheros largos o únicos enlaces por usuario, para prevenir ataques de denegación de servicios simples. Elevación de privilegios Si una aplicación proporciona roles administrativos y de usuario distintos entonces es vital asegurarse de que el usuario no pueda elevar su rol a un privilegio más alto. En concreto, simplemente no visualizar enlaces de rol privilegiado es insuficiente. En su lugar todas las acciones deberían controlarse a través de una matriz de autorización para asegurar que sólo los roles permitidos puedan acceder a la funcionalidad con privilegios.

STRIDE fue creado inicialmente como parte del proceso de modelado de amenaza. STRIDE es un modelo de amenazas, utilizado para ayudar a razonar y encontrar amenazas a un sistema. Está utilizado conjuntamente con un modelo del sistema objetivo que puede ser construido en paralelo. Esto incluye un desglose lleno de procesos, bancos de datos, flujos de datos y fronteras de confianza. Hoy es a menudo utilizado por expertos de seguridad para ayudar contestar la pregunta "¿Qué puede salir mal en el sistema en el que estamos trabajando?"

proceso de modelización del riesgo de amenazas de Microsoft El proceso de modelización del riesgo de amenazas de Microsoft ideado para la seguridad del desarrollo de aplicaciones Web, presenta cinco etapas:

1. Identificar los objetivos de seguridad 2. Evaluar el sistema 3. Realizar la descomposición del sistema 4. Identificar las amenazas 5. Identificar las vulnerabilidades Guzmán

Identificar los Objetivos Los objetivos se pueden clasificar en: • Objetivos de Identidad • Objetivos Financieros • Objetivos de reputación • Objetivos de integridad y confidencialidad • Objetivos de disponibilidad

Descomponer el sistema Implica identificar las características y los módulos con impacto en la seguridad que deben ser evaluados. Evaluación del sistema Una vez que se han declarado los objetivos se debe analizar el diseño del sistema para identificar los componentes, los flujos de información y los límites de confianza. Identificar las amenazas Se parte del hecho de que es imposible identificar amenazas que no son conocidas. Por lo tanto, concentrándose en los riesgos conocidos, se realiza una identificación basada en el empleo de herramientas de BugTraq Además de saber qué tipo de amenaza es el que se puede identificar, es preciso clasificar quién es el posible atacante. Se propone la siguiente clasificación: • Descubrimiento accidental • Malware automático • Atacante curioso

• Script Kiddies • Atacante Motivado • Crimen organizado...