1 of 33

OWASP Testing Guide

Lic. Paola Rodríguez

Paola.rodriguez@verifone.com

2 of 33

Bienvenidos al Proyecto de OWASP: Testing Guide!

Detalla los Procedimientos y Herramientas para probar la Seguridad de las Aplicaciones.

Orientada a:

Desarrolladores de Software.
Testers de Software.
Especialistas en Seguridad.

3 of 33

OWASP Testing Guide.

Desarrollada al estilo OWASP.

Abierto
Colaborativo

Está relacionada con otras Guías de OWASP.
La metodología de testing definida es:

Consistente
Repetible
Calidad.

We need a common vulnerability list

Ref.:OWASP_Testing_Guide_-_OWASP_Summit_2011

4 of 33

Historia y Evolución

4

5 of 33

OWASP Testing Guide V4. Release en Revisión

5

1 Líder del Proyecto

Miembros del Proyecto: Más de 30 colaboradores y revisores.

Alcance: 50% dedicado a completar el capítulo y el otro 50 % de revisión según feedback.
Objetivos:

Liberar una guía de calidad.
Crear concientizacion y adopción de la misma.

6 of 33

Los diferentes Capítulos:

Introducción.
Entorno de Pruebas OWASP:

Técnicas y tareas en relación a las diferentes fases del SDLC.

Pruebas de Intrusión de Aplicaciones WEB.

Diferentes pruebas para Vulnerabilidades específicas.

Valoración del Riesgo y Redacción de Informes.

6

7 of 33

Principios de la comprobación.

No existe la bala de plata.

Piensa estratégicamente, no tácticamente.

SDLC es el Rey.

Prueba pronto y prueba a menudo.

Comprende el Alcance de la Seguridad.

7

La Seguridad es un

Proceso,

no un Producto.

8 of 33

Principios de la comprobación cont. …

Comprende el objeto de estudio (documentación) y utiliza las herramientas adecuadas.

Lo importante está en los detalles.

Usa el código fuente cuando esté disponible.

Desarrolla Métricas.

Documente los resultados de las pruebas.

8

Comprende el objeto de estudio�Una de las primeras iniciativas principales en cualquier buen programa de seguridad debería ser pedir documentación precisa de la aplicación. La arquitectura, diagramas de flujo de datos, casos de uso, y demás deberían ser escritos en documentos formales y puestos a disposición para revisión. La documentos de aplicación y especificación técnica deberían incluir información que liste no solo los casos de uso deseados, sino también cualquier caso de uso específicamente no admitido. Finalmente, es bueno tener como mínimo una infraestructura de seguridad básica que permita la monitorización y el análisis de la evolución de los ataques contra tus aplicaciones y red (por ejemplo, sistemas IDS).

Utiliza las herramientas adecuadas�Aunque ya hemos enunciado que no existe una herramienta bala de plata, las herramientas juegan un papel crítico en el programa de seguridad global. Hay toda una gama de herramientas de código abierto y comerciales que pueden ayudar en la automatización de muchas tareas de seguridad rutinarias. Estas herramientas pueden simplificar y acelerar el proceso de seguridad ayudando al personal de seguridad en sus tareas. Sin embargo, es importante comprender exactamente lo que estas herramientas pueden hacer y lo que no, de forma que no se exagere su uso o sean usadas incorrectamente.

Lo importante está en los detalles�Es un factor crítico no realizar una revisión de seguridad superficial de una aplicación y considerarla completa. Esto infundirá una falsa sensación de confianza que puede ser tan peligrosa como no haber hecho una revisión de seguridad.

Usa el código fuente cuando esté disponible�A pesar de los resultados de las pruebas de intrusión de caja negra pueden ser impresionantes y útiles para demostrar como son expuestas las vulnerabilidades en producción, no son el método más efectivo para securizar una aplicación. Si el código fuente de la aplicación está disponible, debería ser entregado al personal de seguridad para ayudarles durante la realización de la revisión. Es posible descubrir vulnerabilidades dentro del código fuente de la aplicación que se perderían durante el trabajo de caja negra.

Desarrolla métricas�Una parte importante de un buen programa de seguridad es la habilidad para determinar si las cosas están mejorando. Es importante seguir la pista de los resultados de los trabajos de prueba, y desarrollar métricas que podrán revelar la evolución de la seguridad de la aplicación en la organización. Estas métricas pueden mostrar si son necesarias más educación y formación, si hay algún mecanismo de seguridad en particular que no es comprendido con claridad por desarrollo, y si el número total de problemas relacionados con seguridad que se han encontrado cada mes se está reduciendo. Unas métricas consistentes que puedan ser generadas automáticamente a partir de código fuente disponible ayudarán también a la organización en la evaluación de la eficacia de los mecanismos introducidos para reducir el número de bugs de seguridad en el desarrollo de software. Las métricas no son fáciles de desarrollar, por lo que usar métricas estándar, como las provistas por el proyecto OWASP Metrics y otras organizaciones podría ser una buena base de la que partir para empezar.

Documente los resultados de los pruebas

Es sabio acordar un formato aceptable. El reporte debe ser claro para el desarrollador al destacar la funcion exacta que ha sido afectada por la vulnerabilidad con las asociadas recomendaciones para su resolucion en un lenguaje que el desarrollador entienda. Por ultimo, pero no menos importante, la redaccion del reporte no debe ser agobiante para los verificadores de seguridad.

9 of 33

Técnicas de comprobación.

Inspecciones y Revisiones Manuales – Es una excelente práctica de verificación y puede considerarse como una de lás técnicas mas efectivas y eficaces.

Modelado de Amenazas. Permite desarrollar estrategias de mitigación para vulnerabilidades potenciales.

9

Ventajas (Inspecciones):

No requiere tecnología de apoyo

Puede ser aplicada a una variedad de situaciones

Flexible

Fomenta el trabajo en equipo

Se aplica en una fase temprana del SDLC

Desventajas (Inspecciones):

Puede consumir mucho tiempo

Material de apoyo no siempre disponible

Precisa de bastantes conocimientos, reflexión y competencia humana para ser efectiva

Ventajas (Modelado de Amenazas)

Visión práctica del sistema desde el punto de vista de un atacante

Flexible

Se aplica en una fase temprana del SDLC

Desventajas (Modelado de Amenazas)

Nueva técnica, relativamente

Buenos modelos de amenaza no garantiza buen software .

10 of 33

Técnicas de comprobación.

Revisión de Código.

Pruebas de Intrusión.

10

Ventajas (Revisiones de Código)

Eficacia e integridad.

Precisión.

Rapidez (Para revisores competentes).

Desventajas (Revisiones de Código)

Requiere desarrolladores altamente competentes.

No puede detectar errores en tiempo de ejecución con facilidad.

El código fuente realmente en uso puede ser diferente del que está siendo analizado.

Ventajas (Pruebas de Intrusión)

Puede ser rápido (y por tanto, barato).

Requiere un conocimiento relativamente menor que una

revisión de código fuente.

Comprueba el código que está siendo expuesto realmente.

Desventajas (Pruebas de Intrusión)

Demasiado tardío en el SDLC.

Pruebas solo de impactos frontales.

Revision de codigo:si quieres saber que es lo que está pasando realmente, vete directo a la fuente´´. Casi todos los expertos en seguridad están de acuerdo en que no hay nada mejor que ver realmente el código. Toda la información necesaria para identificar problemas de seguridad está en el código en algún lugar.

Pruebas de Intrusión. Las pruebas de intrusión se han convertido desde hace muchos años en una técnica común empleada para comprobar la seguridad de una red. También son conocidos comúnmente como pruebas de caja negra o hacking ético. Las pruebas de intrusión son esencialmente el ``arte´´ de comprobar una aplicación en ejecución remota, sin saber el funcionamiento interno de la aplicación, para encontrar vulnerabilidades de seguridad. Generalmente, el equipo de prueba de intrusión tendría acceso a una aplicación como si fuesen usuarios. Los probadores actúan como un atacante, e intentan encontrar y explotar vulnerabilidades. En muchos casos al encargado de las pruebas se le da una cuenta válida en el sistema. Mientras que las pruebas de intrusión han demostrado ser efectivos en seguridad de redes, la técnica no se traslada de forma natural al caso de aplicaciones. Cuando se realizan pruebas de intrusión en redes y sistemas operativos, la mayoría del trabajo se centra en encontrar y explotar vulnerabilidades conocidas en tecnologías específicas. Dado que las aplicaciones web son casi todas hechas a medida exclusivamente, las pruebas de intrusión en el campo de aplicaciones web es más similar a investigación pura. Se han desarrollado herramientas de las pruebas de intrusión para automatizar el proceso pero, de nuevo, por la naturaleza de las aplicaciones web, su eficacia es a menudo escasa. Actualmente muchas personas emplean pruebas de intrusión sobre aplicaciones web como su técnica de comprobación de seguridad principal. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que deba ser considerado como la principal o única técnica. Gary McGraw [14] resumió bien las pruebas de intrusión cuando dijo ``Si suspendes una prueba de intrusión sabes que, de hecho, tienes un problema muy grave. Si pasas una prueba de intrusión no sabes si no tienes un problema muy grave´´. Sin embargo una prueba de intrusión enfocado (esto es, un test que intenta explotar vulnerabilidades conocidas detectadas en revisiones anteriores) puede ser de utilidad para detectar si alguna vulnerabilidad específica está realmente corregida en el código fuente desplegado en la web. �

11 of 33

Enfoque Equilibrado

El enfoque correcto es el Equilibrado, incluye varias técnicas;

y asegura la cobertura

de las pruebas en todas

las fases del SDLC.

Proporción del Esfuerzo de Pruebas en el SDLC

11

El enfoque equilibrado varía dependiendo de muchos factores: como la madurez del Proceso de Pruebas y la Cultura Corporativa.

Es esencial para las organizaciones poner mayor énfasis en las Etapas Iniciales del desarrollo.

Con tantas técnicas y enfoques para comprobar la seguridad de tus aplicaciones web, puede resultar difícil comprender que técnicas usar y cuando usarlas. La experiencia muestra que no hay una respuesta correcta o incorrecta a cuales serían exactamente las técnicas que deberían usarse para construir un marco de pruebas. Las pruebas de intrusión, a pesar de su utilidad, no puede abordar efectivamente muchas de las incidencias que requieren ser comprobadas, y simplemente es insuficiente y demasiado tarde dentro del ciclo de desarrollo del software (SDLC). El enfoque correcto es uno equilibrado que incluya varias técnicas, Un enfoque equilibrado varía dependiendo de muchos factores, como la madurez del proceso de pruebas y la cultura corporativa. Sin embargo, se recomienda que un marco de pruebas equilibrado sea semejante a las representaciones mostradas en las Figuras 3 y 4. La siguiente figura muestra una representación típica proporcional superpuesta sobre el ciclo de vida de desarrollo del software. Es esencial para las compañías poner un mayor énfasis en las etapas iniciales de desarrollo.

12 of 33

Diferentes Fases

Fase 1: Antes de empezar el Desarrollo.

Fase 2: Durante el Diseño y Definición.

Fase 3: Durante el Desarrollo.

Fase 4: Durante la Implementación.

Fase 5: Mantenimiento y Operaciones.

12

13 of 33

Antes de empezar el desarrollo.

Fase 1A: Revisión de Estándares y Políticas.

Asegurar que las políticas, documentación y estándares adecuados están implementados.

Fase 1B: Desarrollo de Métricas y Criterios de Medición.

Definir los criterios que deben ser medidos proporciona visibilidad de los defectos, tanto en el proceso como en el producto.

13

Las personas pueden hacer las cosas correctamente solo si saben que es lo correcto.

Si la aplicación va a ser desarrollada en JAVA, es esencial que haya un estándar de programación segura en Java. Si la aplicación va a usar criptografía, es esencial que haya un estándar de criptografía. Ninguna política o estándar puede cubrir todas las situaciones con las que se enfrentará un equipo de desarrollo. Documentando las incidencias comunes y predecibles, habrá menos decisiones que afrontar durante el proceso de desarrollo.

Una politica de seguridad por ejemplo debe de estar compuesta por: Principios y politicas de seguridad de la informacion, confidencialidad de claves e identificaion de usuario, requerimientos minimos de seguridad y un punto no menos importante, se dejar claro que pasa si un empleado no cumple con la misma (por ejemplo sanciones disciplinarias y se puede llegar hasta el despido con causa justa)

14 of 33

Durante el Diseño y Definición.

Fase 2A: Revisión de los Requisitos de Seguridad.

Fase 2B: Revisión de Diseño y Arquitectura.

Fase 2C: Creación y Revisión de Modelos UML.

14

FASE 2A: REVISIÓN DE LOS REQUISITOS DE SEGURIDAD.

Los requisitos de seguridad definen como funciona una aplicación desde una perspectiva de la seguridad. Es indispensable que los requisitos de seguridad sean probados. Probar, en este caso, significa comprobar los supuestos realizados en los requisitos, y comprobar si hay deficiencias en las definiciones de los requisitos.

Por ejemplo, si hay un requisito de seguridad que indica que los usuarios deben estar registrados antes de tener acceso a la sección de Documentos de un site, ¿Significa que el usuario debe estar registrado con el sistema, o debe estar autenticado? Asegúrate de que los requisitos sea lo menos ambiguo posible.

A la hora de buscar inconsistencias en los requisitos, ten en cuenta mecanismos de seguridad como:

Gestión de Usuarios (reinicio de contraseñas, etc.)

Autenticación

Autorización

Confidencialidad de los Datos

Integridad

Contabilidad

Gestión de Sesiones

Seguridad de Transporte

Segregación de Sistemas en Niveles

Privacidad

FASE 2B: REVISIÓN DE DISEÑO Y ARQUITECTURA

Las aplicaciones deberían tener una arquitectura y diseño documentados. Por documentados nos referimos a modelos, documentos de texto y semejantes. Es indispensable comprobar estos elementos para asegurar que el diseño y la arquitectura imponen un nivel de seguridad adecuado al definido en los requisitos.

Identificar fallos de seguridad en la fase de diseño no es solo una de las fases más efectiva por costes a la hora de identificar errores, sino que también puede ser la fase más efectiva para realizar cambios. Por ejemplo, ser capaz de identificar que el diseño precisa realizar decisiones de autorización en varias fases; puede ser adecuado considerar un componente de autorización centralizado.

Si la aplicación realiza validación de datos en múltiples fases, puede ser adecuado desarrollar un marco de validación centralizado (realizar la validación de entradas en un solo lugar en vez de en cientos, es mucho más sencillo).

Si se descubren vulnerabilidades, deberían serle transmitidas al arquitecto del sistema, en busca de soluciones alternativas.

FASE 2C: CREACIÓN Y REVISIÓN DE MODELOS UML

Una vez completados el diseño y arquitectura, construye modelos de Lenguaje Unificado de Modelado (de ahora en adelante y por sus siglas en inglés, Unified Modeling Language, UML), que describan como funciona la aplicación. En algunos cosas, pueden estar ya disponibles. Emplea estos modelos para confirmar junto a los diseñadores de sistemas una comprensión exacta de como funciona la aplicación. Si se descubre alguna vulnerabilidad, debería serle transmitida al arquitecto del sistema para buscar soluciones alternativas.

FASE 2D: CREACIÓN Y REVISIÓN DE MODELOS DE AMENAZA

Con las revisiones de diseño y arquitectura en mano, y con los modelos UML explicando como funciona el sistema exactamente, es hora de acometer un ejercicio de modelado de amenazas. Desarrolla escenarios de amenaza realistas. Analiza el diseño y la arquitectura para asegurarte de que esas amenazas son mitigadas, aceptadas por negocio, o asignadas a terceros, como puede ser una aseguradora. Cuando las amenazas identificadas no tienen estrategias de mitigación, revisa el diseño y la arquitectura con los arquitectos de los sistemas para modificar el diseño.

15 of 33

Durante el Desarrollo.

Fase 3A: Inspección de Códigos por Pares.
Fase 3B: Revisiones de Código.

15

FASE 3A: INSPECCIÓN DE CÓDIGO POR FASES

El equipo de seguridad debería realizar una inspección del código por fases con los desarrolladores y, en algunos casos, con los arquitectos del sistema. Una inspección de código por fases es una inspección del código a alto nivel, en la que los desarrolladores pueden explicar el flujo y lógica del código. Permite al equipo de revisión de código obtener una comprensión general del código fuente, y permite a los desarrolladores explicar porque se han desarrollado ciertos elementos de un modo en particular.

El propósito de una inspección de este tipo no es realizar una revisión del código, sino entender el flujo de programación a alto nivel, su esquema y la estructura del código que conforma la aplicación.

FASE 3B: REVISIONES DE CÓDIGO

Con una buena comprensión de como está estructurado el código y porque ciertas cosas han sido programados como lo han sido, el probador puede examinar ahora el código real en busca de defectos de seguridad.

Las revisiones de código estático validarán el código contra una serie de listas de comprobación, que incluyen:

Requisitos de negocio de disponibilidad, confidencialidad e integridad.

Guía del OWASP o Lista de Comprobación de los Top 10 (dependiendo del nivel de detalle de la revisión) de exposición técnica.

Incidencias específicas relativas al lenguaje o marco de trabajo en uso, como el Scarlet paper para PHP o las Microsoft Secure Coding checklists para ASP.NET.

Cualquier requisito específico de la industria, como Sarbanes-Oxley 404, COPPA, ISO 17799, APRA, HIPAA, Visa Merchant guidelines o cualquier otro régimen regulatorio.

Hablando en términos de retorno de los recursos invertidos, la mayoría de las veces las revisiones de código estático producen un retorno de mayor calidad que ningún otro método de revisión de seguridad, y se apoyan menos en el conocimiento y capacidad del revisor, dentro de lo posible. Sin embargo, no son una bala de plata, y necesitan ser consideradas cuidadosamente dentro de un régimen de pruebas que cubra todo el espectro de posibilidades.

Para más detalles acerca de las listas de comprobación OWASP, véase la Guía OWASP para Securizar Aplicaciones Web, o la última edición del Top 10 del OWASP.

16 of 33

Durante la Implementación.

Fase 4A: Pruebas de Intrusión en Aplicaciones.
Fase 4B: Comprobación de Gestión de Configuraciones.

16

17 of 33

Fase 5 - Mantenimiento y Operaciones.

Fase 5A: Ejecución de Revisiones de la Administración Operativa.

Fase 5B: Ejecución de Comprobaciones periódicas (mensuales o trimestrales) de mantenimiento.

Fase 5C: Asegurar la Verificación de Cambios.

17

18 of 33

Pruebas de intrusión de aplicaciones Web.

¿Qué es una prueba de intrusión de aplicación web? Es un método de Evaluación de la Seguridad de un Sistema, mediante la simulación de un ataque.

¿Qué es una vulnerabilidad? Es una debilidad en un activo que hace posible su amenza.

¿Qué es la metodología de pruebas OWASP?

18

4.1 INTRODUCCIÓN Y OBJETIVOS

¿Que es una prueba de intrusión de aplicación web?�Una prueba de intrusión o intrusión es un método de evaluación de la seguridad de un sistema de ordenadores o una red mediante la simulación de un ataque. Una prueba de intrusión de aplicación web está enfocada solamente a evaluar la seguridad de una aplicación web.

El proceso conlleva un análisis activo de la aplicación en busca de cualquier debilidad, fallos técnicos o vulnerabilidades. Cualquier incidencia de seguridad que sea encontrada será presentada al propietario del sistema, junto con una evaluación de su impacto, y a menudo con una propuesta para su mitigación o una solución técnica.

¿Qué es una vulnerabilidad?

Dado que una aplicación posee un conjunto de activos (recursos de valor como los datos en una base de datos o en el sistema de archivos), una vulnerabilidad es una debilidad en un activo que hace posible a una amenaza. Así que una amenaza es un caso potencial que puede dañar un activo mediante la explotación de una vulnerabilidad. Un test es una acción que tiende a mostrar una vulnerabilidad en la aplicación.

¿Qué es la metodología de pruebas OWASP?

Las pruebas de intrusión nunca serán una ciencia exacta mediante la cual se pueda definir una lista completa de todas las incidencias posibles que deberían ser comprobadas. De hecho, las pruebas de intrusión son sólo una técnica apropiada para comprobar la seguridad de aplicaciones web bajo ciertas circunstancias.�El objetivo es recopilar todas las técnicas de comprobación posibles, explicarlas y mantener la guía actualizada. La metodología de pruebas de intrusión de aplicación web OWASP se basa en un enfoque / acercamiento de caja negra. La persona que realiza las pruebas tiene poca, o ninguna, información sobre la aplicación que va a ser comprobada. El modelo de pruebas consta de:

Auditor: La persona que realiza las actividades de comprobación

Herramientas y metodología: El núcleo de este proyecto de guía de pruebas

Aplicación: La caja negra sobre la que realizar las pruebas

Las pruebas se dividen en 2 fases:

Modo pasivo: en el modo pasivo, la persona a cargo de la realización de las pruebas intenta comprender la lógica de la aplicación, juega con la aplicación; puede usarse una utilidad para la recopilación de información, como un proxy HTTP, para observar todas las peticiones y respuestas HTTP. Al final de esta fase esta persona debería comprender cuales son todos los puntos de acceso (puertas) de la aplicación (p.e. cabeceras HTTP, parámetros, cookies). Por ejemplo, podría encontrar lo siguiente:

https://www.example.com/login/Authentic_Form.html

Esto puede indicar un formulario de autentificación en el que la aplicación solicita un usuario y contraseña. � Los siguientes parámetros representan dos puntos de acceso (puertas) a la aplicación.

http://www.example.com/Appx.jsp?a=1&b=1

En este caso, la aplicación muestra dos puntos de acceso (parámetros a y b). Todos los encontrados en esta fase representan un punto a ser comprobado. Una hoja de cálculo con el árbol de directorios de la aplicación y todos los puntos de acceso puede ser útil para la segunda fase.

Modo activo: en esta fase la persona a cargo de la comprobación empieza a realizar las pruebas usando la metodología descrita en los siguientes apartados.

Hemos dividido el conjunto de pruebas en 9 subcategorías:

Pruebas de gestion de la configuración 2 min

Pruebas de la lógica de negocio 2min

Pruebas de Autenticación 2min

Pruebas de Autorización 2 min

Pruebas de gestión de sesiones 2 min

Pruebas de validación de datos 2 min

Pruebas de denegación de Servicio 2 min

Pruebas de Servicios Web 2min

Pruebas de AJAX 1 min, donde jugaba Diego Suarez…

19 of 33

Categorías.

Pruebas de Gestión de la Configuración
Pruebas de la Lógica de negocio
Pruebas de Autenticación
Pruebas de Autorización
Pruebas de Gestión de sesiones
Pruebas de Validación de datos
Pruebas de Denegación de Servicio
Pruebas de Servicios Web
Pruebas de AJAX

19

20 of 33

Ejemplo: Recopilación de Información.

20

21 of 33

Redacción de Informes

¿ Cómo valorar el riesgo real ?

Creeando una metodología general para

descomponer los hallazgos de seguridad y evaluar los riesgos con el objetivo de priorizarlos y gestionarlos.

21

22 of 33

Metodología de Valoración de Riesgos �

22

Modelo estándar:

Riesgo = Probabilidad de Ocurrencia

X

Impacto

23 of 33

Pasos a seguir…�

23

Identificar los Riesgos.
Determinar los Factores para estimar la Probabilidad de Ocurrencia.
Determinar los Factores para estimar el Impacto.
Determinar la Severidad del Riesgo.
Decidir que Arreglar.
Ajustar el Modelo de Valoración del Riesgo.

24 of 33

Probabilidad de Ocurrencia - Factores

24

Agentes causantes de la Amenaza

Factores que afectan a la vulnerabilidad

Nivel de Conocimiento	Motivación	Oportunidad	Tamaño

Facilidad de descubrimiento	Facilidad de explotación	Conocimiento	Detección de la Intrusión

Sin conocimientos (1)
Algunos conocimientos (3)
Usuario avanzado (4)
Conocimientos de redes y programación (6)
Conocimientos de intrusiones de seguridad (9)

Baja Motivación o ninguna recompensa (1)
Posible recompensa (4)
Recompensa alta (9)

Ningún acceso conocido (0)
Acceso limitado (4)
Acceso total (9)

Desarrolladores (2)
Administradores de sistemas (2)
Usuarios de la intranet (4)
Socios (5)
Usuarios autenticados (6)
Usuarios anónimos de Internet (9)

Prácticamente Imposible (1)
Difícil (3)
Fácil (7)
Existen herramientas automatizadas disponibles (9)

En teoría es posible explotarla (1)
Difícil (3)
Fácil (5)
Existen herramientas automatizadas disponibles (9)

Desconocida (1)
Oculta (4)
Obvia (6)
Se conoce de forma pública (9)

Detección activa en la aplicación (1)
Registrada y revisada (3)
Registrada pero no revisada (8)
No registrada (9)

Una vez has identificado un riesgo potencial, y quieres averiguar lo serio que es, el primer paso es estimar la “probabilidad de ocurrencia”. Al nivel más alto, esta es una medida aproximada de lo probable que es que la vulnerabilidad sea descubierta y explotada por un atacante. No es necesario que seamos extremadamente precisos en esta estimación. Generalmente, es suficiente con identificar si la probabilidad de ocurrencia es baja, media o alta.

Existen varios factores que pueden ayudarnos a realizar esta estimación. El primer grupo de factores están relacionados con los agentes que causan la amenaza involucrada. El objetivo es estimar la probabilidad de ocurrencia de un ataque con éxito por parte de un grupo de posibles atacantes. Nótese que podría haber múltiples agentes que exploten una vulnerabilidad en concreto, así que generalmente es mejor ponerse en el peor de los casos. Por ejemplo, una persona dentro de la organización es un atacante mucho más probable que una persona ajena a la organización – pero esto depende de varios factores.

Nótese que cada factor tiene un conjunto de opciones, y cada opción tiene asociada una valoración del 0 a 9 a su probabilidad de ocurrencia. Emplearemos estas cifras más tarde para estimar la probabilidad de ocurrencia global.

25 of 33

Impacto - Factores

25

Factores de Impacto Técnico

Factores de Impacto sobre el Negocio

Confidencialidad	Integridad	Disponibilidad	Responsabilidad

Daño Financiero	Reputación	No Conformidad	Violación de privacidad

Revelación Mínima de datos no sensibles (2)
Revelación Mínima de datos Críticos (6)
Amplia Revelación de datos no sensibles (6)
Aplica Revelación de datos Críticos (9)

Mínimo, datos ligeramente corruptos(1)
Mínimo datos seriamente dañados (3)
Gran cantidad de datos ligeramente dañados (5)
Gran cantidad de datos seriamente dañados (9)

Mínimo número de servicios secundarios interrumpidos (1)
Mínimo número de servicios primarios interrumpidos (5)
Gran número de servicios (3) secundarios interrumpidos (5)
Gran número de servicios primaros interrumpidos (7)
Todos los servicios perdidos (9)

Totalmente Trazable (1)
Es posible que se pueda trazar (7)
Completamente anónimo (9)

Menor al coste de arreglar la vulnerabilidad (1).
Leve efecto en el beneficio anual (3)
Efecto significativo en el beneficio anual (7)
Bancarrota (9)

Daño mínimo (1).
Pérdida de las cuentas principales (4)
Pérdidas del buen nombre (5)
Daño sobre la marca (9)

Violación leve (2).
Clara violación (5)
Violación prominente (7)

Un individuo (3).
Cientos de Personas (5)
Miles de Personas(7)
Millones de Personas (9)

26 of 33

Severidad del Riesgo

Determinar si la probabilidad de ocurrencia y el impacto son de nivel Alto, Medio ó Bajo.

26

Probabilidad de ocurrencia y niveles de impacto
0 a <3	ALTO
3 a <6	MEDIO
6 a 9	BAJO

27 of 33

Severidad del Riesgo (POG)

Métodos: Informal y Repetitivo

27

Factores correspondientes al agente causante de la amenaza
Nivel de habilidad	Motivo	Oportunidad	Tamaño
5	2	7	1

Factores asociados a la Vulnerabilidad
Facilidad de descubrimiento	Facilidad de explotación	Concienciación	Detección de Intrusión
3	6	9	2

Probabilidad de ocurrencia global=4.375 (MEDIA)

Método informal

En muchos entornos, no hay nada de malo en “calcular a ojo” los factores y simplemente capturar las respuestas. Deberías considerar los factores e identificar aquellos factores clave que están controlando el resultado. Puede que descubras que tu impresión inicial era incorrecta al considerar aspectos del riesgo que no eran obvios.

Método repetitivo

Si necesitas defender tus puntuaciones o hacerlas repetibles, entonces quizá quieras seguir un proceso más formal para puntuar los factores y calcular el resultado. Recuerda que existe bastante incertidumbre en estas estimaciones, y que esos factores tienen por objetivo ayudarte a alcanzar un resultado razonable. Para este proceso se pueden utilizar herramientas automatizadas para facilitar los cálculos.

El primer paso es seleccionar una de las opciones asociadas con cada factor e introducir el número asociado en la tabla. Después simplemente tomaremos la media de las puntuaciones para calcular la probabilidad de ocurrencia global. Por ejemplo:

28 of 33

Severidad del Riesgo (ITG)

28

Impacto Técnico
Pérdida de Confidencialidad	Pérdida de Integridad	Pérdida de Disponibilidad	Pérdida de control de responsabilidad
9	7	5	8

Impacto sobre el Negocio
Daño Financiero	Daño a la Reputación	No Conformidad	Violación de Privacidad
1	2	1	5

Impacto Técnico Global = 7.25 (ALTO)

Impacto Global sobre el Negocio = 2.25 (BAJO)

29 of 33

Severidad del Riesgo

29

Como quiera que hayamos llegado a la probabilidad de ocurrencia e impacto estimados, ahora podemos combinarlos para obtener una puntuación final de la severidad para este riesgo. Nótese que si dispones de buena información del impacto sobre negocio, deberías emplearla en vez de la información sobre el impacto técnico. Pero si no dispones de información sobre el negocio, entonces el impacto técnico es la siguiente mejor opción.

En el ejemplo superior, la probabilidad de ocurrencia es MEDIA, y el impacto técnico es ALTO, así que desde una perspectiva puramente técnica, parece que la severidad global es ALTA. Sin embargo, nota que el impacto sobre el negocio es BAJO, así que la severidad global se describe mejor también como BAJA. Es por ello que comprender el contexto en el negocio de las vulnerabilidades que estás evaluando es tan crítico para tomar buenas decisiones respecto al riesgo. Equivocarse en la comprensión de este contexto puede llevar a una falta de confianza entre los equipos de negocio y de seguridad que está presente en muchas organizaciones

30 of 33

Decidiendo que arreglar…

30

Lista Priorizada

Como Regla General: Riesgos Severos PRIMERO…

Riesgos Altos
Riesgos Medios
Riesgos Severos

Después de haber clasificado los riesgos de tu aplicación, tendrás una lista priorizada de qué arreglar. Como regla general, deberías arreglar los problemas que supongan un riesgo más severo primero. Solventar los riesgos menos importantes sencillamente no ayuda a reducir el riesgo global, incluso si son fáciles o baratos de arreglar.

Recuerda, no todos los riesgos merecen la pena ser arreglados, y algunas pérdidas son no solo esperadas, sino justificables, basándose en el coste de solucionar la incidencia. Por ejemplo, si costase $100,000 implementar controles para contener un fraude anual de $2,000, nos llevaría 50 años recuperar la inversión para compensar la pérdida. Pero recuerda que podría haber un daño sobre la reputación causado por el fraude que podría costarle mucho más a la organización.

31 of 33

Ajustando tu modelo de valoración

31

Añadiendo Factores.

Personalizando opciones.

Ponderando factores.

Disponer de un marco de puntuación del riesgo que sea personalizable para el negocio es una cuestión crítica para ser adoptado. Un modelo a medida es mucho más probable que produzca resultados que concuerden con las percepciones de la gente sobre lo que es un riesgo serio. Puedes malgastar mucho tiempo discutiendo sobre los sistemas de puntuación del riesgo si no están apoyados en un modelo como este. Existen varios modos de adaptar este modelo a una organización.

Añadiendo factores

Puedes escoger diferentes factores que representen mejor lo que es importante para tu organización. Por ejemplo, una aplicación militar podría añadir factores de impacto relacionados con la pérdida de vidas humanas o información clasificada. También podrías añadir factores de probabilidad de ocurrencia, como la ventana de oportunidad de un atacante o la fortaleza de un algoritmo de codificación.

Personalizando opciones

Existen algunas opciones de ejemplo asociadas con cada factor, pero el modelo será mucho más efectivo si personalizas esas opciones para tu negocio. Por ejemplo, utiliza los nombres de los diferentes grupos y tus propios nombres para diferentes clasificaciones de la información. También puedes cambiar las puntuaciones asociadas con las opciones. El mejor modo de identificar las puntuaciones correctas es comparar las puntuaciones producidas por el modelo con las producidas por un equipo de expertos. Puedes afinar el modelo ajustando cuidadosamente las puntuaciones.

Ponderando factores

El modelo anterior asume que todos los factores son igualmente importantes. Puedes asignar un peso a los factores para enfatizar aquellos más significativos para tu negocio. Esto hace que el modelo sea un poco más complejo, ya que necesitarás utilizar una media ponderada. Pero por lo demás todo funciona igual. De nuevo, puedes afinar el modelo contrastándolo con puntuaciones del riesgo que consideres que son precisas.

32 of 33

El Informe de Pruebas

32

Secciones Recomendadas:

Resumen Ejecutivo.
Consideraciones Técnicas Generales.
Hallazgos.

Realizar la parte técnica de la evaluación es solo la mitad del proceso global de evaluación; el producto final es la realización de un reporte informativo y bien escrito.

Un informe debería ser fácil de entender, remarcar todos los riesgos encontrados durante la fase de evaluación y poder dirigirse tanto al personal técnico como a dirección.

El informe debe tener tres secciones principales, y ser creado de modo que permita separar e imprimir cada sección, y darlas al equipo adecuado, como los desarrolladores o administradores de sistema.

Las secciones generalmente recomendadas son:

El resumen ejecutivo sintetiza todos los hallazgos globales de la evaluación, y da a los directores y propietarios del sistema una idea del riesgo global al que se enfrentan.

El lenguaje utilizado debería adecuarse a personas sin conocimientos técnicos, y debería incluir gráficos o tablas que muestren el nivel de riesgo. Se recomienda incluir un resumen, que detalle cuando empezaron y terminaron las pruebas.

Otra sección que suele pasarse por alto es un párrafo sobre implicaciones y acciones. Este permite a los propietarios comprender que es necesario hacer para asegurarse de que el sistema se mantiene seguro.

II. Consideraciones técnicas generales

La sección de consideraciones técnicas generales se dirige a menudo a los responsables técnicos que requieren más detalle técnico que el encontrado en el resumen ejecutivo. Esta sección debería incluir detalles como el alcance de la evaluación, los objetivos incluidos y cualquier otra advertencia, como la disponibilidad del sistema, etc. Esta sección necesita incluir también una introducción de la medida del riesgo empleada en el informe, y finalmente un resumen técnico de los hallazgos realizados.

III Hallazgos realizados durante la evaluación

La última sección del informe es la sección que incluye los detalles técnicos sobre las vulnerabilidades encontradas, y los acercamientos necesarios para asegurar que son resueltas.

Esta sección está dirigida a un nivel más técnico, y debería incluir toda la información necesaria para que los equipos técnicos puedan comprender la incidencia y ser capaces de resolverla.

La sección de hallazgos debería incluir:

Un número identificador, para poder referenciar fácilmente, con capturas de pantalla

Los elementos afectados

Una descripción técnica

Una sección sobre como resolver la incidencia

El nivel de riesgo y el valor de impacto

Cada hallazgo debería ser claro y conciso, y dar al lector del informe una comprensión completa de la incidencia. Las siguientes páginas muestran la tabla de reporte. �

33 of 33

��y ya finalizando… la recomendación es entonces, la adopción de esta guía en sus organizaciones; aunque ello implique que deban adaptarla de acuerdo a sus teconologías, procesos y estructura organizacional.��MUCHAS GRACIAS POR SU VALIOSO TIEMPO!.