Modelado de Amenazas para SDLC
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:
Los pasos para crear un Modelo de Amenazas básicamente son seis:
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:
Algunas preguntas a realizar por cada componente del sistema serían:
Para ello puede utilizar dos enfoques básicos:
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:
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, :
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: Blog de Willy Mejía
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:
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.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.
- 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?
Para más información consultar: Is Threat Modeling Right For You?
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.
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:
- Identificar que es lo que hace la aplicación
- Crear un diagrama de la arquitectura
- Identificar la tecnología involucrada
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?
- Identificar las fronteras de confianza
- Identificar el flujo de datos
- Identificar los puntos de entrada
- Identificar el código privilegiado
- Documentar el perfil de seguridad
Para ello puede utilizar dos enfoques básicos:
- Utilizar el modelo STRIDE para identificar las amenazas
- Utilizar listas de categorías de amenazas
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:
- Identificar las amenazas de red
- Identificar las amenazas de host
- Identificar las amenazas de aplicación
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)El documento "Improving Web Application Security" detalla cómo Microsoft emplea el DREAD para asignar prioridades a los riesgos y mitigarlos.
Reproducibility (grado de reproducción)
Exploitability (grado de explotación)
Affected users (usuarios afectado)
Discoverability (grado de descubrimiento)
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: Blog de Willy Mejía
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!