Arquitectura y Diseo de Seguridad

Arquitectura y diseo de seguridad

Aplicaciones seguras desde el diseo
OWASP : Open Web Application Security Proyect
Proyectos de OWASP: (Documentos) Gua Owasp: Documento que proporciona orientacin detallada sobre la seguridad de las aplicaciones web. El Top Ten de las vulnerabilidades ms crticas de aplicaciones web. Mtricas: Un proyecto para definir las mtricas de seguridad de apliaciones web. Legal: Un proyecto de software para ayudar a compradores y vendedores a negociar una seguridad adecuada en sus contratos

Gua de testeo: Una gua eficaz centrada en pruebas de seguridad para aplicaciones web. ISO 17799: Documentos de soporte para organizaciones. AppSec FAQ: Preguntas frecuentes y respuestas sobre seguridad de las aplicaciones.

Proyectos de Desarrollo WebScarab: Es una aplicacin web que incluye una suite de evaluacin de vulnerabilidades y herramientas proxy. WebGoat: Herramienta de capacitacin y evaluacin interactiva que los usuarios utilizar para aprender sobre seguridad de aplicaciones web en un lugar seguro y legal. DotNet: Una variedad de herramientas para asegurar entornos .NET

Marcos de poltica
La aplicaciones seguras no se dan por si solas.

Requieren de una decisin organizacional

Gestin organizacional que abogue por la seguridad
organizacin Polticas de seguridad documentadas Metodologa de desarrollo con puntos de control y actividades de seguridad Gestin segura de versiones y configuracin

Muchos contenidos de la gua OWASP derivan desde estndares internacionales o marcos de control como COBIT.
COBIT

Gua OWASP ISO 17799

COBIT: Control Objectives for Information and Related Technology. (objetivos de control para tecnologa de informacin y tecnologas relacionadas).
Objetivos del COBIT: Investigar, desarrollar, publicar y promover un conjunto internacional, autorizado y actual de objetivos de control en tecnologa de informacin generalmente aceptados para el uso cotidiano de gerentes de empresa y auditores.

Audiencias COBIT
GERENTES Balancear la inversin en controles, en un ambiente de riesgos frecuentemente impredecible. USUARIOS Obtener el aseguramiento de los controles y seguridad que proveen los servicios de IT internos/externos AUDITORES

Sustentar ante la gerencia su opinin de la efectividad del control interno y actuar como asesores proactivos del negocio.

Mejores prcticas para la gestin y control (IT)

ISACA
Information Systems Audit and Control Association

WWW.ISACA.ORG
WWW.ISACA.CL

Componentes de COBIT

Marco Referencial
El concepto fundamental del marco referencial de CobiT, se refiere a: El enfoque de control en TI se lleva a cabo visualizando la informacin necesaria para dar soporte a los procesos de negocio. La Informacin es el resultado de la aplicacin combinada de recursos relacionados con la Tecnologa de Informacin, que deben ser administrados por procesos TI.

Principios del marco de Trabajo

REQUERIMIENTOS DEL NEGOCIO

PROCESOS DE T.I.

RECURSOS DE T.I.

 Para satisfacer los objetivos del negocio, la informacin necesita concordar con ciertos criterios a los que CobiT hace referencia como requerimientos de negocio para la informacin.
REQUERIMIENTO DE CALIDAD: Calidad, Costo, Entrega de Servicio.
REQUERIMIENTOS FIDUCIARIOS : Efectividad y Eficiencia de Operaciones, Confiabilidad de la Informacin, Cumplimiento de las Leyes y Regulaciones. REQUERIMIENTOS DE SEGURIDAD: Confidencialidad, Integridad, Disponibilidad.

Estructura de COBIT

Criterios de la informacin
EFECTIVIDAD

EFICIENCIA
CONFIDENCIALIDAD INFORMACION INTEGRIDAD

DISPONIBILIDAD
CUMPLIMIENTO

CONFIABILIDAD

 Efectividad: La informacin relevante y pertinente al proceso de negocio existe y es entregada a tiempo, correcta, consistente y de una manera usable. Eficiencia: Relativo a la entrega de informacin a travs del ptimo ( ms productivo y econmico ) uso de los recursos. Confidencialidad: Relativo a la proteccin de informacin sensitiva de acceso y divulgacin no autorizada. Integridad: Relativo a la exactitud y completitud de la informacin as como a su validez de acuerdo con el conjunto de valores y expectativas del negocio.

 Disponibilidad: Relativo a que la informacin debe estar disponible cuando es requerida por el proceso de negocio y por lo tanto tambin relativo a la salvaguarda de recursos. Cumplimiento: relativo al cumplimiento de leyes, regulaciones y acuerdos contractuales los cuales el proceso de negocio debe cumplir. Confiabilidad: Relativo a que los sistemas proveen a: la gerencia con la informacin apropiada para ser usada en la operacin de la empresa; reportes a los usuarios de la informacin financiera e informacin a los organismos reguladores en cumplimiento de leyes y regulaciones.

Recursos T.I.
DATOS SISTEMAS APLICATIVOS

T.I. TECNOLOGIA INSTALACIONES

GENTE

 Datos externos e internos , estructurados y no estructurados, grficos, sonidos, etc. Sistemas Aplicativos es entendido como la suma de los procedimientos manuales y de los procedimientos automatizados. Tecnologa se refiere a hardware, Sistemas operativos, Bases de Datos, Sistemas de administracin, redes, multimedia. Instalaciones lugar usado para el propsito de TI. Recursos para albergar y apoyar los sistemas de informacin. Gente habilidades, conocimientos y productividad para planear, organizar, adquirir, entregar, mantener y monitorear los sistemas de informacin y servicios.

Resumen
COBIT es un marco de gestin de riesgos que se estructura alrededor de cuatro dominios

COBIT
PLANEAR Y ORGANIZAR ADQUIRIR E IMPLEMENTAR ENTREGAR Y DAR SOPORTE MONITOREAR Y EVALUAR

 Cada uno de los cuatro dominios posee 13 objetivos de control de alto nivel. Ej.
DS5 Garantizar la seguridad de los sistemas.

Cada objetivo de alto nivel contiene un nmero de objetivos detallados. Ej.

DS5.2 Identificacin, Autenticacin y Acceso

Los objetivos pueden ser cumplidos con una variedad de mtodos dependiendo de cada organizacin.

ISO 17799
ISO 17799 es un marco de gestin de seguridad basado en riesgos
Ampliamente utilizado en Europa

www.iso17799software.com
www.bsi-global.com

SOX
La Ley Sarbanes Oxley nace en Estados Unidos con el fin de monitorear a las empresas que cotizan en bolsa, evitando que las acciones de las mismas sean alteradas de manera dudosa, mientras que su valor es menor. Su finalidad es evitar fraudes y riesgo de bancarrota, protegiendo al inversor.

Esta ley, ms all del mbito nacional, afecta a todas las empresas que cotizan en NYSEC (Bolsa de Valores De Nueva York), as como a sus filiales.

Un motivador importante para muchas organizaciones en Estados Unidos para adoptar controles OWASP es para asistir con el cumplimento de Sarbanes-Oxley.

www.aicpa.org/info/sarbanes_oxley_summary.htm

Metodologas de desarrollo
Fuerte aceptacin de diseo, testeo, y documentacin Espacios para insertar controles de seguridad METODOLOGIA Funciona para el tamao y nivel de maduracin de la organizacin Permite reducir la tasa actual de errores y mejorar la productividad de los desarrolladores. Anlisis: de riesgo y amenazas. Revisin por parte de pares. Revisiones de cdigo. Etc.

Estndares de codificacin
Una metodologa no es un estndar de codificacin; cada empresa de software necesitara determinar que utilizar basado en prcticas comunes, o simplemente cumplir la ley basado en mejores prcticas conocidas.

 Orientacin de arquitectura (por ejemplo la capa Web no debe llamar a la base de datos directamente) Niveles mnimos de documentacin requerida Requerimientos de testeo mandatarios Niveles mnimos de comentarios entre cdigo y estilo de comentarios preferidos Manejo de excepciones Uso de flujo de bloques de control (por ejemplo Todos los usos de flujos condicionales deben usar bloques de sentencias especficos) Mtodo de nombramiento preferido para variables, funciones, clases y tablas. Cdigo mantenible y legible es preferido ante cdigo inteligente o complexo

Control de cdigo fuente

Esto se puede hacer copiando carpetas a un servidor de documentos, pero es mejor si se utilizan herramientas de revisin de cdigo: Subversion CVS SourceSafe ClearCase.

Los atacantes
En el diseo de controles para prevenir el mal uso de su aplicacin, debe considerar los atacantes ms probables

 Equipo o desarrolladores descontentos. Ataques Accionados por como efectos secundarios o consecuencias directas de un virus, o ataque de gusano o troyano. Atacantes criminales motivados, tales como el crimen organizado. Atacantes criminales contra tu organizacin sin motivo, como defacers. Script kiddies

Pilares esenciales de la seguridad de la informacin.

CONFIDENCIALIDAD

INTEGRIDAD asegurar que los datos no se falsifican o alteran por usuarios no autorizados

DISPONIBILIDAD asegurar que los sistemas y datos estn disponibles para los usuarios autorizados cuando lo necesiten.

permitir acceso nicamente a los datos a los cuales el usuario est permitido

considerar cada pilar sucesivamente ayudar en la produccin de un robusto control de seguridad.

Arquitectura de Seguridad
Los arquitectos de aplicaciones son responsables de la construccin y diseo para cubrir riesgos
RIESGOS DE USO

ATAQUES EXTERNOS

Arquitectura de seguridad no es una markitecture. Donde un conjunto de productos y tecnologas son una solucin en si mismo

Cuando se comienza el desarrollo de una nueva aplicacin o se redisea una existente, se debe considerar cada caracterstica funcional:
Son los procesos de alrededor de esta caracterstica lo mas seguro posible?
Es este un proceso con defectos? Si fuera malintencionado, cmo abusara de esta caracterstica? Se requiere esta caracteristica por defecto?, si es as, existen lmites u opciones que ayuden a reducir el riesgo?

El proceso anterior se conoce cmo:

Thinking Evil
Se recomienda:
Ponerse en el lugar del atacante y pensar en todas las posibles vas en que se puede abusar de cada caracteristica.

La seguridad es un proceso de larga vida y no un disparo por accidente

Principios de Seguridad
Minimizando el rea de superficie de ataque Seguridad por defecto Principio del mnimo privilegio Principio de defensa en profundidad Fallar de manera segura Sistemas externos inseguros Separacin de funciones Seguridad a travs de la oscuridad Simplicidad Correcciones de seguridad correctamente

Minimizando el rea de superficie de ataque

Cada caracterstica que se agrega a una aplicacin aade cierto riesgo a la aplicacin total.
El objetivo del desarrollo seguro es reducir el total del riesgo, reduciendo el rea de la superficie de ataque. Una menor superficie de ataque, reduce los riesgos.

Ejemplo: Una aplicacin web implementa ayuda online, con una funcin de bsqueda.

Funcin de Bsqueda

VULNERABLE

Ataques de inyeccin SQL

Limitar la funcin de bsqueda a usuarios autorizados. Se reduce la probabilidad de ataques

Introducir la funcin de bsqueda a travs de la validacin de datos centralizados. Se reduce la habilidad para realizar inyeccin SQL

Si se re-escribe la caracterstica de ayuda para eliminar la funcin de bsqueda, por una interfaz de usuario mejorada. Esto eliminara el rea de ataque

Seguridad por Defecto

Existen muchas formas de entregar una experiencia out of the box a los usuarios.
Sin embargo la experiencia debera ser segura, y debe depender del usuario reducir su seguridad. Ejemplo:
Por defecto debe habilitarse la complejidad y duracin de la contrasea. A los usuarios se les permite deshabilitar esas caractersticas para simplificar su uso e incrementar su riesgo.

Principio del Mnimo Privilegio

El principio de mnimo privilegio recomienda que las cuentas tengan la mnima cantidad de privilegios para realizar sus procesos de negocios.
Derechos de usuario
Permisos de recursos Permisos del sistema de archivos

Principio de defensa en profundidad

Donde un control sera razonable, ms controles contra diferentes tipos de riesgos seran mayores.
Los controles en profundidad disminuyen las vulnerabilidades y la probabilidad que ocurran.

Con la codificacin segura, esto puede tomar la forma de validacin basada en filas, controles de auditoria centralizados y requerir a los usuarios hacer login en todas las pginas

Ejemplo: Una interfaz administrativa con defectos es poco probable que sea vulnerable a ataques annimos si incorpora el acceso correctamente a redes de administracin en produccin, chequea la autorizacin administrativa del usuario y hace log de todos los accesos.

Fallar de manera segura

Las aplicaciones fallan regularmente al procesar transacciones debido a diversas razones. De la manera en que fallan se puede determinar si una aplicacin es segura o no.

Ejemplo: isAdmin = true; try { codeWhichMayFail(); isAdmin = isUserInRole( Administrator ); } catch (Exception ex) { log.write(ex.toString()); } S el cdigo codeWhichMayFail() falla, el usuario es administrador por defecto. Obviamente esto es un riesgo de seguridad.

Sistemas externos inseguros

Muchas organizaciones utilizan las capacidades de procesamiento de terceras compaas, las cuales ms que a menudo tienen diferentes polticas de seguridad y posturas.
La confianza implcita de ejecutar sistemas externos, no est garantizada.

Ejemplo: Un proveedor de programas proporciona datos que son utilizados para la Banca en Internet, proporciona el nmero de puntos de premio y una pequea lista de objetos potenciales de reembolso. Sin embargo, los datos deberan ser comprobados para asegurarse que es seguro mostrarlo al usuario final.

Separacin de Funciones
Un control clave del fraude es la separacin de funciones.
Por ejemplo, alguien que solicita un equipo no puede confirmarlo tambin, no debera recibir directamente el equipo. Esto previene que el usuario solicite varios equipos y reclame que nunca le llegaron. Ciertos roles tienen niveles diferentes de confianza que los usuarios normales. En particular, los administradores son diferentes que los usuarios normales. En general, los administradores no deberan ser usuarios de la aplicacin.

Por ejemplo, un administrador debera ser capaz de apagar y encender el sistema, configurar polticas de contraseas pero no debera ser capaz de hacer login en la aplicacin como un superusuario privilegiado, que fuera capaz de comprar objetos en nombre de otros usuarios.

Seguridad a travs de la oscuridad

La seguridad a travs de la oscuridad es un control de seguridad dbil, y adems siempre fallan cuando son el nico control. Esto no significa que mantener secretos es una mala idea, significa simplemente que la seguridad de los sistemas clave no debera basarse en mantener detalles ocultos.

Ejemplo: la seguridad de una aplicacin no debera basarse en mantener en secreto el conocimiento del cdigo fuente. La seguridad debera basarse en muchos otros factores, incluyendo: polticas razonables de contraseas defensa en profanidad lmites en las transacciones de negocios arquitectura de red slida controles de auditoria y fraude.

Simplicidad
El rea de la superficie de ataque y la simplicidad van de la mano. Ciertos ingenieros de software prefieren aproximaciones demasiado complejas hacia lo que de otra manera sera un cdigo relativamente sencillo y simple. Los desarrolladores deben evitar el uso de dobles negaciones y complejas arquitecturas en donde un enfoque simple sera ms rpido y simple.

Por ejemplo, aunque pueda estar a la ltima tener unas cuantas entidades sencillas ejecutndose en un servidor separado, es ms seguro y rpido usar simplemente variables globales con un mecanismo apropiado de mutex para proteger contra las condiciones de carrera.

Arreglar cuestiones de seguridad correctamente

Una vez que un fallo de seguridad ha sido identificado, es importante desarrollar un test para l y comprender la raz del problema. Cuando se usan los patrones de diseo, es muy probable que el fallo de seguridad se encuentre muy extendido en todo el cdigo base, por lo que desarrollar la solucin correcta sin introducir regresiones es esencial. Ejemplo: un usuario ha visto que es capaz de ver las cuentas de otro usuario simplemente ajustando su cookie. La solucin parece ser relativamente sencilla pero como el manejo de la cookie es compartido entre todas las aplicaciones, un cambio en una simple aplicacin repercutir en todas las dems. La solucin por lo tanto debe testearse en todas las aplicaciones afectadas.

Modelado de Riesgo de Amenaza

Durante el diseo de su aplicacin, es esencial que la disee utilizando controles evaluados de riesgo de amenaza, de otra forma malgastara recursos, tiempo y dinero en controles intiles y no suficiente en los riesgos reales.

Modelado de Amenaza de Riesgo Microsoft

Modelado de amenaza es un proceso esencial para el desarrollo de aplicaciones web seguras. Permite a las organizaciones determinar el control correcto y producir contramedidas efectivas dentro del presupuesto. Por ejemplo hay poco sentido en agregar un control de US$100.000 a un sistema que tiene una posibilidad de fraude insignificante.

Ejecutando el modelado de riesgo de amenazas

Hay cinco pasos en el proceso de modelado.

Identificar objetivos de seguridad

Revisin aplicacin Identificar Vulnerabilidades Identificar amenazas Descomponer aplicacin

Identificar Objetivos de Seguridad

El negocio en coordinacin con el equipo de desarrollo necesita entender los probables objetivos de seguridad. Los objetivos de seguridad en aplicaciones necesitan ser divididos en:
Identidad
Reputacin Financiero Privacidad y regulaciones

Disponibilidad de garantas

Identidad
protege est aplicacin al usuario de mal uso? Hay controles adecuados para asegurar evidencia de identidad? (requerido para muchas aplicaciones bancarias)

Reputacin
la prdida de reputacin derivada de la aplicacin siendo mal usada o atacada exitosamente

Reputacin
el nivel de riesgo que la organizacin esta preparada para tomar en la remediacin de potencial prdida financiera. Un software de foros tendra menor riesgo financiero que la banca por Internet

Privacidad y regulaciones
En que medida las aplicaciones deben proteger la informacin del usuario. Software de foros es pblico por naturaleza, pero un programa de impuestos esta intrnsecamente vinculado a las regulaciones y legislacin de privacidad en la mayora de los pases

Disponibilidad de garantas
tiene este software que estar disponible por un SLA o un acuerdo similar? Es infraestructura protegida nacionalmente? A que nivel tiene que estar disponible la aplicacin? Aplicaciones y tcnicas altamente disponibles son extraordinariamente caras, as que la fijacin de controles correctos puede ahorrar una gran cantidad de recursos y dinero.

Un SLA (Service Level Agreement) o Acuerdo de Nivel de Servicio es un contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad del servicio

Visin General de la Aplicacin

Una vez que los objetivos han sido definidos, la aplicacin debera ser analizada para determinar: Componentes Flujos de datos Lmites de confianza Busque diagramas de componentes UML. Los diagramas de componentes de alto nivel son generalmente todo lo que se requiere para entender como y porque la informacin fluye a distintos lugares.

Descomponer la aplicacin
Una vez que la arquitectura de la aplicacin es entendida, la aplicacin necesita ser descompuesta, esto significa que las caractersticas y mdulos que tienen un impacto de seguridad necesitan ser descompuestas. Por ejemplo cuando se investiga el mdulo de autenticacin, es necesario entender como los datos entran al mdulo de autenticacin, como el mdulo valida y procesa la informacin, a donde fluyen los datos, si la informacin es guardada, y que decisiones son hechas por el mdulo.

Documentar las amenazas conocidas Es imposible escribir amenazas desconocidas. Se debe concentrar en los riesgos que son conocidos, que pueden ser fcilmente demostrados.
Para documentar una amenaza existen dos enfoques. Grfico de amenazas Lista estructurada

Grfico de amenazas
Un atacante podra leer los mensajes de otros usuarios

El usuario tal vez no haya terminado una sesin en un PC compartido

Validacin de datos pueden fallar, permitiendo inyeccin SQL

Autorizacin puede fallar, permitiendo acceso no autorizado

Cach del navegador puede contener parte del mensaje

Implementar validacin de datos

Implementar revisiones de autorizacin

Implementar cabeceras HTTP anticach

Si el riesgo es alto usar SSL

Lista Estructurada
1. Un atacante podra leer los mensajes de otros usuarios El usuario tal vez no haya terminado sesin en una computadora compartida 2. Validacin de datos puede permitir inyeccin SQL 3. Implementar validacin de datos 4. Autorizacin puede fallar, permitiendo acceso no autorizado 5. Implementar revisiones de autorizacin 6. Cach del navegador puede contener parte del mensaje 7. Implementar cabeceras HTTP anti-cach 8. Si el riesgo es alto, usar SSL

Las amenazas son atacantes motivados, ellos generalmente quieren algo de su aplicacin o burlar controles.

Para entender que amenazas son aplicables, utilice los objetivos de seguridad para entender quien podra atacar la aplicacin:

 Descubrimiento accidental:
Usuarios autorizados pueden toparse con un error en la lgica de su aplicacin utilizando simplemente un navegador

Malware automatizado (buscando

vulnerabilidades conocidas pero con un poco de malicia e inteligencia)

 Atacante Curioso (como investigadores de seguridad o usuarios que notaron algo mal en su aplicacin y prueban ms all).
Script kiddie: criminales computacionales atacando o desfigurando aplicaciones por respeto o motivos polticos

 Atacantes motivados (como personal disgustado o un atacante pagado) Crimen organizado (generalmente para aplicaciones de alto riesgo, como comercio electrnico o bancario Es vital entender el nivel del atacante contra el que se esta defendiendo. Un atacante informado que entiende sus procesos es mucho ms peligroso que un script kiddie

 STRIDE: Burlando Identidad: Burlar identidad es un riesgo clave para las aplicaciones que tienen muchos usuarios pero un contexto de ejecucin simple a nivel aplicacin y base de datos. Los usuarios no deben ser capaces de actuar como otro usuario o convertirse en otro usuario.

Manipulacin de Informacin:

Los usuarios pueden cambiar cualquier informacin entregada a ellos, y por lo tanto pueden cambiar validacin del lado del cliente, datos GET y POST, cookies, cabeceras HTTP, y ms. La aplicacin no debera enviar informacin al usuario, como tasas de inters o periodos que son obtenibles de la aplicacin misma. La aplicacin debe revisar cuidadosamente cualquier informacin recibida del usuario para identificar si es sensata y aplicable.

Repudacin: Los usuarios pueden disputar transacciones si hay trazabilidad y auditoria insuficiente de la actividad del usuario.
Por ejemplo, si un usuario dice, yo no transfer dinero a est cuenta externa y usted no puede seguir sus actividades desde el frente al dorso de la aplicacin, es extremadamente posible que la transaccin tendr que deshacerse. Las aplicaciones deberan tener controles de repudiacin adecuados, como registros de accesos web, pistas de auditorias en cada nivel, y un contexto de usuario.

 Divulgacin de Informacin Los usuarios se resisten a enviar detalles privados a un sistema. Es posible para un atacante revelar detalles de usuario, ya sea annimamente o como un usuario autorizado, habr un periodo de reputacin perdido. Las aplicaciones deben incluir controles fuertes para prevenir manipulacin de identificacin de usuario, particularmente cuando ellos usan una nica cuenta para correr la aplicacin entera.

 Denegacin de Servicio Las aplicaciones deberan estar conscientes que podran ser objeto de un ataque de denegacin de servicio. Para aplicaciones autenticadas, recursos costosos como archivos grandes, clculos complejos, bsquedas pesadas, o consultas largas deberan estar reservadas para usuarios autorizados, no para usuarios annimos.

 Elevacin de Privilegios Si una aplicacin provee roles de usuario y administrador, es vital asegurarse que el usuario no puede elevarse a algn rol de privilegios ms altos. En particular, simplemente no proveer links al usuario es insuficiente todas las acciones deben estar cerradas a travs de una matriz de autorizacin para asegurarse que solamente los roles correctos pueden acceder funcionalidades privilegiadas.

Dread
DREAD es usado para formar parte del razonamiento detrs de la clasificacin de riesgos, y es usada directamente para ordenar riesgos.
DREAD es usado para computar un valor de riesgo, que es un promedio de cinco elementos: RiskDread

=(

Dao + Reproducibilidad + Explotabilidad + Usuarios Afectados + Descubribilidad

)/5

Esto produce un nmero entre 0 y 10. Mientras ms alto el nmero, ms serio es el riesgo.

Dao Potencial
Si una amenaza es cumplida Cunto dao es causado?
0 = Nada 5 = Informacin individual del usuario es comprometida o afectada. 10 = Destruccin completa del sistema.

Reproducibilidad
Qu tan fcil es reproducir esta amenaza?
0 = Muy difcil o imposible, incluso para los administradores de la aplicacin. 5 = Uno o dos pasos requeridos, tal vez necesite ser un usuario autorizado. 10 = Requiere slo una barra de direcciones sin estar registrado en la aplicacin.

Explotacin
Qu necesita tener para explotar esta amenaza?
0 = Habilidades avanzadas de programacin y redes, herramientas de ataque avanzadas o personalizadas 5 = Malware 10 = Solamente un existente o navegador. fcilmente realizado utilizando herramientas normales de ataque.

Usuarios afectados
Cuntos usuarios sern afectados por esta amenaza?
0 = Ninguno 5 = Algunos usuarios, pero no todos. 10 = Todos

Descubrimiento
Qu tan fcil es descubrir esta amenaza? Cuando se est realizando una revisin de cdigo de una aplicacin existente, la facilidad para descubrirla es usualmente establecida como 10 ya que se tiene que asumir que estas cuestiones sern descubiertas.
0 = De muy difcil a imposible. Requiere acceso al cdigo. 5 = Se podra dar con el problema de estar adivinando u observando las huellas de la red. 9 = Detalles de fallas como esta son del dominio pblico, y pueden ser descubiertas utilizando google. 10 = Est en la barra de direcciones o en una forma

 Realizar modelado de amenazas provee un retorno mucho mayor que cualquier control.

Es vital que el modelado de amenaza se lleve acabo.

Sistemas alternativos de modelado de amenazas.

Trike AS/NZ 4360 CVSS Octave