Metodologias más usadas en pentesting. Estudio comparativo.

MÓDULO 3: AUDITORÍAS Y SEGURIDAD. TEMA 4: COMPARATIVA METODOLOGÍAS AUDITORÍAS Y PENTESTING.

Maximiliano Camilo Pérez Fernández

Elche, Febrero de 2012

1

Índice de contenido INTRODUCCIÓN................................................................................................................................5 DEFINICIONES PREVIAS DE LAS METODOLOGÍAS:................................................................6 OWASP (manual de 349 páginas)...................................................................................................6 I. INFORMATION GATHERING:.................................................................................................6 Testing: spiders, robots, and crawlers (owasp-ig-001)...............................................................7 Search engine discovery/reconnaissance (owasp-ig-002)...........................................................7 Identify application entry points (owasp-ig-003).......................................................................7 Testing for web application fingerprint (owasp-ig-004).............................................................7 Application discovery (owasp-ig-005).......................................................................................7 Analysis of error codes (owasp-ig-006)......................................................................................7 II. CONFIGURATION MANAGEMENT TESTING.....................................................................7 SSL/TLS Testing (OWASP-CM-001).........................................................................................7 DB Listener Testing (OWASP-CM-002)....................................................................................7 Infrastructure Configuration Management Testing (OWASP-CM-03).......................................7 Application Configuration Management Testing (OWASP-CM-004)........................................8 Testing for File Extensions Handling (OWASP-CM-005).........................................................8 Old, Backup and Unreferenced Files (OWASP-CM-006)..........................................................8 Infrastructure and Application Admin Interfaces (OWASP-CM-007)........................................8 Testing for HTTP Methods and XST (OWASP-CM-008)..........................................................8 III. AUTHENTICATION TESTING...............................................................................................8 Credentials transport over an encrypted channel (OWASP-AT-001)..........................................8 Testing for user enumeration (OWASP-AT-002)........................................................................8 Testing for Guessable (Dictionary) User Account (OWASP-AT-003)........................................8 Brute Force Testing (OWASP-AT-004).......................................................................................8 Testing for bypassing authentication schema (OWASP-AT-005)...............................................9 Testing for vulnerable remember password and pwd reset (OWASP-AT-006)..........................9 Testing for Logout and Browser Cache Management (OWASP-AT-07)....................................9 Testing for CAPTCHA (OWASP-AT-008).................................................................................9 Testing Multiple Factors Authentication (OWASP-AT-009)......................................................9 Testing for Race Conditions (OWASP-AT-010).........................................................................9 IV. SESSION MANAGEMENT TESTING....................................................................................9 Testing for Session Management Schema (OWASP-SM-001)...................................................9 Testing for Cookies attributes (OWASP-SM-002)......................................................................9 Testing for Session Fixation (OWASP-SM_003).......................................................................9 Testing for Exposed Session Variables (OWASP-SM-004)........................................................9 Testing for CSRF (OWASP-SM-005).......................................................................................10 V. AUTHORIZATION TESTING.................................................................................................10 Testing for Path Traversal (OWASP-AZ-001)..........................................................................10 Testing for bypassing authorization schema (OWASP-AZ-002)..............................................10 Testing for Privilege Escalation (OWASP-AZ-003).................................................................10 VI. BUSINESS LOGIC TESTING (OWASP-BL-001)................................................................10 VII. DATA VALIDATION TESTING...........................................................................................10 Testing for Reflected Cross Site Scripting (OWASP-DV-001).................................................11 Testing for Stored Cross Site Scripting (OWASP-DV-002)......................................................11 Testing for DOM based Cross Site Scripting (OWASP-DV-003).............................................11 2

Testing for Cross Site Flashing (OWASP-DV004)...................................................................11 SQL Injection (OWASP-DV-005).............................................................................................11 LDAP Injection (OWASP-DV-006)..........................................................................................11 ORM Injection (OWASP-DV-007)...........................................................................................11 XML Injection (OWASP-DV-008)...........................................................................................11 SSI Injection (OWASP-DV-009)..............................................................................................11 XPath Injection (OWASP-DV-010)..........................................................................................11 IMAP/SMTP Injection (OWASP-DV-011)...............................................................................11 Code Injection (OWASP-DV-012)............................................................................................11 OS Commanding (OWASP-DV-013)........................................................................................11 Buffer overflow (OWASP-DV-014)..........................................................................................11 Testing for HTTP Spltting/Smuggling (OWASP-DV-016).......................................................11 VIII. DENIAL OF SERVICE TESTING.......................................................................................12 Testing_for_SQL_Wildcard_Attacks (OWASP-DS-001) ........................................................12 D Locking Customer Accounts (OWASP-DS-002) .................................................................12 Buffer Overflows (OWASP-DS-003) ......................................................................................12 User Specified Object Allocation (OWASP-DS-004) ..............................................................12 User Input as a Loop Counter (OWASP-DS-005) ...................................................................12 Writing User Provided Data to Disk (OWASP-DS-006) .........................................................12 Failure to Release Resources (OWASP-DS-007) ....................................................................12 Storing too Much Data in Session (OWASP-DS-008) ............................................................12 IX. WEB SERVICES TESTING...................................................................................................12 WS Information Gathering (OWASP-WS-001) .......................................................................13 Testing WSDL (OWASP-WS-002) ..........................................................................................13 XML Structural Testing (OWASP-WS-003) ............................................................................13 XML Content-level Testing (OWASP-WS-004) ......................................................................13 HTTP GET parameters/REST Testing (OWASP-WS-005) .....................................................13 Naughty SOAP attachments (OWASP-WS-006) .....................................................................13 Replay Testing (OWASP-WS-007) ..........................................................................................13 X. AJAX TESTING.......................................................................................................................13 AJAX Vulnerabilities (OWASP-AJ-001) .................................................................................13 How to test AJAX (OWASP-AJ-002) ......................................................................................13 XI. WRITING REPORTS: VALUE THE REAL RISK................................................................13 HOW TO VALUE THE REAL RISK.......................................................................................13 PTES (PENETRATION TESTING EXECUTION STANDARD)...............................................15 Pre-engagement Interactions:....................................................................................................15 Intelligence Gathering:..............................................................................................................16 Threat Modeling:......................................................................................................................17 Vulnerability Analysis:..............................................................................................................18 Exploitation:..............................................................................................................................19 Post Exploitation:......................................................................................................................20 Reporting:.................................................................................................................................21 ISSAF (“manualillo” de 845 páginas)...........................................................................................23 FASE 1: Planificación y preparación........................................................................................23 FASE 2: Evaluación..................................................................................................................23 Information Gathering (obtener información)......................................................................24 Network Mapping (mapeo de la red)...................................................................................24 Vulnerability Identification (identificación de vulnerabilidades)........................................24 Penetration (penetración).....................................................................................................25 Gaining Access & Privilege Escalation (ganar acceso y escalado de privilegios)...............25 3

Enumerating Further (podemos traducir como “extra” enumeración de objetivos)............25 Compromise Remote Users/Sites (usuarios y sitios remotos comprometidos)....................25 Maintaining Access (mantenimiento del acceso y privilegios ganados)..............................25 Covering Tracks (cubriendo pistas o borrado de huellas si se prefiere)...............................25 FASE 3: Informe, limpieza y destrucción de “artefactos”........................................................27 NETWORK SECURITY:.........................................................................................................27 SEGURIDAD DE CLIENTES DE RED (HOSTS):................................................................28 SEGURIDAD DE APLICACIONES:......................................................................................28 SEGURIDAD DE LAS BASES DE DATOS:..........................................................................28 ..................................................................................................................................................28 OSSTMM (Open Source Security Testing Methodology Manual)...............................................29 DEFINIR UN TEST DE SEGURIDAD:..................................................................................29 TIPOS DE TESTS DE SEGURIDAD:.....................................................................................30 EL ALCANCE (scope):............................................................................................................31 LAS REGLAS DE ACUERDOS (CONTRATOS):..................................................................32 RESULTADOS DE LOS TESTS:.............................................................................................32 COMPRENDIENDO LA METODOLOGÍA OSSTMM:.........................................................33 A. FASE REGULATORIA..................................................................................................33 B. FASE DE DEFINICIONES............................................................................................33 C. FASE DE INFORMACIÓN...........................................................................................33 D. FASE INTERACTIVA DE PRUEBA DE CONTROLES..............................................34 MÉTRICAS OPERATIVAS DE SEGURIDAD:......................................................................34 MAPA MENTAL DE OSSTMM (gracias a un ruso):..............................................................36 COMPARATIVA DE LAS METODOLOGÍAS EN CUESTIÓN:....................................................37

4

INTRODUCCIÓN Comparar cuatro de las metodologías más importantes de auditorías y “pentesting” no es fácil y es además costoso de realizar. Trataré de enmarcarlas en un concepto general de seguridad de la información y partiendo de sus definiciones, pasaremos a centrarnos en los aspectos sugeridos (aunque está claro que no se puede profundizar mucho al respecto). ¿Cuál debemos elegir? ¿cuál es la adecuada? ¿cuáles se aplican más en la práctica? ¿cuáles se adaptan mejor a las necesidades de las empresas y organizaciones? Tal y como se afirma en la introducción de la metodología OWASP, los “pentest” nunca serán una ciencia exacta. Dependen de múltiples factores y, además, todo un listado de problemas y posibles riesgos deben ser tenidos en cuenta antes de ser probados. ¿Qué es un “pentest”1? Es un método de evaluación de la seguridad de un sistema u organización, simulando un ataque tal y como la llevaría a cabo cualquier “hacker” que pretendiera hacerse con el control del sistema, manipular la información o robarla, sobre todo aquella que podemos definir como sensible y “crítica”. Generalmente, este tipo de ataques se fundamentan en fallas y vulnerabilidades conocidas por los expertos en su mayoría y no resueltas o mal “parcheadas”, incluso desconocidas, para aquellos responsables de esos sistemas. ¿Qué es una vulnerabilidad? Una debilidad en el diseño de un sistema, en su implementación, operabilidad y gestión que podría ser comprometido violando su política de seguridad2 (si es que la tuviera) Aquí es donde entran las distintas metodologías amparadas en las necesidades y el alcance que se quiera definir de antemano. Suelen ser procesos de larga duración, siempre en función de esas necesidades. Las metodologías aquí explicadas están al alcance de cualquiera; es decir, son de libre uso. Todas ellas ofrecen la posibilidad de ser usadas tanto para beneficio propio como para beneficio de la comunidad de Internet y, por supuesto, a petición de la parte interesada en conocer el nivel de seguridad dentro de su organización. Lo habitual es que aquellas personas que vayan a utilizar estas metodologías sean personas que tienen no solo la preparación precisa, sino también la madurez y prudencia moral que garantiza su objetividad, independencia y rigor ético. Todos hemos leído algo al respecto... “Cracking” puro y duro o “hacking ético”. Que si “white box” (pentesting desde dentro, con todos los recursos a tu alcance), que si “black box” (pentesting consentido, “a ciegas”, desde fuera y desde dentro)... Ambas son elementos de dichas metodologías que podemos definir como dos modos de “enfocar” las tareas, pero curiosamente, 1 Extraído de “OWASP testing guide v.3” 2 Muchas organizaciones comienzan a interesarse por los SGSI (sistemas de gestión de seguridad de la información), pero no se ve una apuesta clara por proteger su información por parte de las PYMES especialmente.

5

alguna de ellas centra su metodología en solo uno de esos enfoques: por ejemplo, OWASP usa “black box”...

DEFINICIONES PREVIAS DE LAS METODOLOGÍAS: OWASP (manual de 349 páginas) Web application test methodology. Método de test para aplicaciones web basado en dos fases: pasiva y activa. Como hemos explicado anteriormente su enfoque es “black box” preferentemente, se sabe poco o nada de la aplicación que vamos a probar, incluso del contexto en el que se van a hacer las pruebas. Fase pasiva: Se trata de hacer pruebas hasta comprender la lógica de la aplicación que está en fase de test y comprobar si arroja algún elemento que pueda significar una puerta abierta para su análisis detallado. Fase activa: El “tester” comienza a probar todos los procesos recomendados en esta metodología. Esta fase se centra, concretamente, en 9 subcategorías de 66 procesos: • • • • • • • • •

Configuration Management management). Authentication Testing Authorization testing Session Management Testing Business Logic Testing Data Validation Testing Denial of Service Testing Web Services Testing Ajax Testing

Testing

(Information

gathering

+

configuration

I. INFORMATION GATHERING: Recopilar el máximo de información acerca del objetivo. Se puede realizar de diferentes modos. Con herramientas públicas y/o software específico de libre uso la mayoría. Se trata de forzar a la aplicación objeto del análisis a mostrar una o varias debilidades o vulnerabilidades.

6

Testing: spiders, robots, and crawlers (owasp-ig-001)

Cómo poner a prueba http://www.google.com/robots.txt).

el

archivo

robots.txt

(por

ejemplo:

wget

Search engine discovery/reconnaissance (owasp-ig-002)

Remover el contenido asociado a un aweb. El robots.txt no ha sido actualizado (ejemplo: site:wasp.org, devuelve todas las páginas indexadas del sitio; cache:owasp.org, ). Identify application entry points (owasp-ig-003)

Abreviando: qué posibilidades de ataque ofrece la aplicación objetivo (GET y POST). Testing for web application fingerprint (owasp-ig-004)

Conocer la versión y tipo del servidor web es imprescindible. Application discovery (owasp-ig-005)

Qué aplicaciones en particular corren sobre el servidor objetivo. Muchas tienen vulnerabilidades conocidas (tomcat, swat, webmin...) Analysis of error codes (owasp-ig-006)

A menudo, las aplicaciones nos devuleven errores que revelan posibles vulnerabilidades. Ejemplo de error 404: Not Found The requested URL /page.html was not found on this server. Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80

II. CONFIGURATION MANAGEMENT TESTING A menudo, de la configuración y topología de la infraestructura de la aplicación, se derivan o asoman fallas que ponen en evidencia la poca consistencia en la que está “construida” la aplicación. SSL/TLS Testing (OWASP-CM-001)

¡Verificar que el cifrado es fuerte! DB Listener Testing (OWASP-CM-002)

Incorrecta configuración de bases de datos. Infrastructure Configuration Management Testing (OWASP-CM-03)

La complejidad de las infraestructuras web a veces juegan malas pasadas: un simple fallo en una sola de sus aplicaciones puede dejar en evidencia toda la infraestructura. 7

Application Configuration Management Testing (OWASP-CM-004)

Datos no revelados en los procesos de configuración, pueden quedar en evidencia a través del código fuente que se muestra en una web... Testing for File Extensions Handling (OWASP-CM-005)

La extensión de los archivos que muestra la web (php, asp, jsp...) revelan el tipo de servidor sobre el que trabajan, así como posibles conexiones con otras aplicaciones (jsp con tomcat). Old, Backup and Unreferenced Files (OWASP-CM-006)

Archivos legibles, descargables, copias de seguridad, etc... nos pueden mostrar rutas de instalación, passwords, ususarios, etc... Infrastructure and Application Admin Interfaces (OWASP-CM-007)

Muchas aplicaciones web como la mayoría de CMS tienen una interfaz administrativa que puede ser objeto de ataques de fuerza bruta e, incluso, estar configuradas por defecto. Esto facilita el acceso. Es el caso de muchos routers con interfaz web también. Testing for HTTP Methods and XST (OWASP-CM-008)

Revisar que el servidor no permite el uso de comandos http y que XST no es posible.

III. AUTHENTICATION TESTING Se trata de confirmar que todo cuanto nos presenta la aplicación tiene integridad y dice ser lo que es y de quién es... Verificar la integridad digital y el proceso de entrada al sistema. Credentials transport over an encrypted channel (OWASP-AT-001)

El uso de protocolos seguros que les protejan de un posible atacante. Testing for user enumeration (OWASP-AT-002)

Probar que resiste los embates del uso de fuerza bruta en el registro y entrada al sistema. Testing for Guessable (Dictionary) User Account (OWASP-AT-003)

¿Cuentas de usuario por defecto? Brute Force Testing (OWASP-AT-004)

Por si falla el ataque por diccionario, garantizar que el posible acceso por intentos de fuerza bruta, quede bloqueado. Testing for bypassing authentication schema (OWASP-AT-005)

Pueden existir recursos no protegidos dentro del sistema a los que se puede acceder si pasar por el proceso de autenticación (bypass).

8

Testing for vulnerable remember password and pwd reset (OWASP-AT-006)

Ojo con la función “password remember” de los navegadores. Testing for Logout and Browser Cache Management (OWASP-AT-07)

La salida del sistema se hace en las condiciones adecuadas. Testing for CAPTCHA (OWASP-AT-008)

Ya hay versiones de CAPTCHA que son vulnerables, con lo que los bots de registro masivo y ataque Ddos lo tienen más fácil. Testing Multiple Factors Authentication (OWASP-AT-009)

Probar dispositivos que contienen certificados para autenticación y que son legítimos. Card reader y USB... Testing for Race Conditions (OWASP-AT-010)

Difíciles de probar e implementar. Resultados inesperados que nos muestran impacto en otras acciones (ejemplo, aplicaciones “multihilo”)

IV. SESSION MANAGEMENT TESTING Control de la sesión. Desde que el usuario se ha autenticado hasta que abandona la sesión. Testing for Session Management Schema (OWASP-SM-001)

Comprender cómo trabaja el mecanismo de gestión de la sesión. Probar a hacer un bypass de sesión. Testing for Cookies attributes (OWASP-SM-002)

Las cookies son a menudo un vector de ataque. Las cookies deben estar debidamente protegidas. Interceptar una cookie podría llevarnos a autenticarnos en un sistema sin más. Testing for Session Fixation (OWASP-SM_003)

Si no renuevas las cookies, se pueden reutilizar. Testing for Exposed Session Variables (OWASP-SM-004)

Si podemos replicar los tokens de sesión, ya estamos dentro. Testing for CSRF (OWASP-SM-005)

Forzar a un usuario ya autenticado a hacer algo no previsto sobre una aplicación web.

9

V. AUTHORIZATION TESTING Autorizar significa que podemos usar y acceder a aquello para lo que estamos registrados... Qué roles y niveles de autorización existen... Escalar privilegios, acceso a rutas transversales, etc. Testing for Path Traversal (OWASP-AZ-001)

Acceder a información reservada a través de ataque de ruta transversal. Testing for bypassing authorization schema (OWASP-AZ-002)

Cómo ha sido implementado cada rol y privilegio para tratar de acceder a recursos reservados. Testing for Privilege Escalation (OWASP-AZ-003)

Verificar que no es posible modificar roles y privilegios para cualquier usuario.

VI. BUSINESS LOGIC TESTING (OWASP-BL-001) Este es el modo creativo para tratar de acceder a un sistema web. Digamos que se trata de buscar alternativas a las meramente técnicas. Incluimos el conocimiento de documentación, acceso a sistemas de mercadeo, productos, etc... Conocer las mejores prácticas o los documentos de seguridad de la empresa... Un poco de ingeniería social.

VII. DATA VALIDATION TESTING Croos site scripting, SQL injection, interpreter injection, ataque a sistemas de archivos, etc... Técnicas bien conocidas y documentadas. Testing for Reflected Cross Site Scripting (OWASP-DV-001) Testing for Stored Cross Site Scripting (OWASP-DV-002) Testing for DOM based Cross Site Scripting (OWASP-DV-003) Testing for Cross Site Flashing (OWASP-DV004) SQL Injection (OWASP-DV-005)

Inyectar datos a través de una consulta a la BD. LDAP Injection (OWASP-DV-006)

Similar a SQL injection. 10

ORM Injection (OWASP-DV-007) XML Injection (OWASP-DV-008)

Probamos a inyectar un documento xml. Si falla el parser, tenemos vulnerabilidad. SSI Injection (OWASP-DV-009)

Inyectar código dentro de la página html. XPath Injection (OWASP-DV-010)

Inyectar datos para bypass el mecanismo de autenticación. IMAP/SMTP Injection (OWASP-DV-011)

Aplicaciones webmail que no trabajan adecuadamente. Podemos inyectar instrucciones para el servidor de correo. Code Injection (OWASP-DV-012)

Código malicioso que pueda ser ejecutado. OS Commanding (OWASP-DV-013)

Inyectar un comando de sistema a través de una consulta http. Buffer overflow (OWASP-DV-014) Testing for HTTP Spltting/Smuggling (OWASP-DV-016)

VIII. DENIAL OF SERVICE TESTING Tratar de “tumbar” un servidor, inundar el servidor de tráfico que no puede gestionar...

11

Testing_for_SQL_Wildcard_Attacks (OWASP-DS-001) D Locking Customer Accounts (OWASP-DS-002) Buffer Overflows (OWASP-DS-003) User Specified Object Allocation (OWASP-DS-004) User Input as a Loop Counter (OWASP-DS-005) Writing User Provided Data to Disk (OWASP-DS-006) Failure to Release Resources (OWASP-DS-007) Storing too Much Data in Session (OWASP-DS-008)

IX. WEB SERVICES TESTING Vulnerabilidades en servicios web que están dentro de la aplicación web. Es similar a SQL injection y resto de técnicas de inyección. WS Information Gathering (OWASP-WS-001) Testing WSDL (OWASP-WS-002) XML Structural Testing (OWASP-WS-003) XML Content-level Testing (OWASP-WS-004) HTTP GET parameters/REST Testing (OWASP-WS-005) Naughty SOAP attachments (OWASP-WS-006) Replay Testing (OWASP-WS-007)

X. AJAX TESTING Asynchronous JavaScript and XML, técnica usada para dinamizar más si cabe las respuestas de los servidores. Se trata de ofrecer a los usuarios una experiencia más parecida al uso de aplicaciones de su escritorio. Son muy útiles, pero desde un punto de vista de un atacante, ofrecen una amplia superficie de vectores de ataque.

12

AJAX Vulnerabilities (OWASP-AJ-001)

Podemos combinar varias técnicas de ataque (SQL injection, XSS, etc) How to test AJAX (OWASP-AJ-002)

XI. WRITING REPORTS: VALUE THE REAL RISK Tan importante como los tests, es el modo en que vamos a presentar nuestro informe. Este también tiene sus criterios. Debe ser una tabla con una imagen lo más exacta posible de la evaluación de la que ha sido objeto.

HOW TO VALUE THE REAL RISK Descubrir fallas es importante, pero solamente en la medida que nos permite conocer los riesgos asociados a la información expuesta. Hacer un enfoque adecuado de la severidad de riesgos Riesgo = probabilidad de que suceda * impacto O sea, si algo puede suceder, despreciar el riesgo si no afecta a la continuidad o, por el contrario, tomar las medidas pertinentes para corregir esos fallos. 1. 2. 3. 4. 5. 6.

Identificar el riesgo. Factores para determinar la probabilidad del riesgo Factores para estimar el impacto en el negocio, en los activos, etc... Determinar la gravedad del riesgo (valoración numérica). Decidir qué corregir. Adaptar tu propio modelo de valoración del riesgo.

13

PTES (PENETRATION TESTING EXECUTION STANDARD) Interesante iniciativa que nos ofrece una guía que se une a las metodologías y guías de pruebas ya existentes. Pretende unir esfuerzos de analistas y expertos en seguridad para hacer un estándar que pueda completar una auditoría en todos sus procesos más habituales. En realidad, podemos asegurar que se enmarca en la metodología OSSTMM, aún sin depender de ella, siendo un proyecto nuevo. PTES divide la ejecución de un test de intrusión en 7 fases, estas son:

Pre-engagement Interactions: En este apartado básicamente se define el ámbito y alcance del test de intrusión. Se llega a un acuerdo con el cliente acotando la profundidad de las pruebas a realizar, permisividad de ataques (ataques DOS, fuerza bruta....), enfoque del test (caja negra, gris o blanca) presentación de evidencias (goals), etc.

14

He preferido poner la imagen del mapa mental a explicar cada una de las subcategorías de esta metodología tal y como hice con OWASP. En esta primera fase podemos destacar la idea de establecer el marco de trabajo de la auditoría, tomando acuerdos con el cliente: contrato, confidencialidad, entrevistas y alcances varios... Trato con terceras partes. Aunque no acierto a verlo claramente, se deduce que hay acuerdo de inmunidad para el tester ¿?

Intelligence Gathering: Recopilación de información de inteligencia competitiva publicada en motores de búsqueda que nos dará una idea del objetivo que estamos estudiando y de las personas que trabajan dentro de la empresa...

15

En esta fase se incluye información sobre el sistema, parte planificada de la organización a través de buscadores de todo tipo (sin que caiga en la simplicidad). Hay un análisis que yo defino como intenso en cuanto a la identificación externa e interna de servicios, mapeo, VoIP, protocolos en general que aparezcan disponibles. Y más profundización si cabe en averiguar perfiles tanto de empleados como corporativos. Hasta la localización física de empleados, uso de redes sociales, etc. Aspectos competitivos pueden ser tenidos en cuenta, planes de márketing, visión de productos...

Threat Modeling: Con la información proporcionada por las dos fases anteriores, se definen lineas de negocios existentes, importancia de los activos IT (accesibles) visibles en nuestro estudio para definir vectores de ataques posteriores.

16

Una vuelta de tuerca más: secretos comerciales, roles y privilegios, niveles ejecutivos, datos de usuarios, proveedores, clientes, etc. Perspectivas de negocio: I + D. Hasta el análisis de los competidores es tenido en cuenta para ver si hay posibilidad de fuga de información.

Vulnerability Analysis: Como su propio nombre indica entramos en materia. De forma activa y ya 'tocando' el objetivo, se identifican puertos y servicios existentes en busca, de forma manual y automática vulnerabilidades existentes.

17

Dividida esta fase en testeo (activo y pasivo), validación e investigación. Recopilamos la información referida a servicios, network y web scanner, VoIP, etc. Identificados los puertos, esquemas posibles de ataques, validamos las posibles opciones reales de ataque y comprobamos que, efectivamente, pueden ser llevados a la práctica (Investigación) con el consiguiente riesgo derivado. En la subfase de Investigación llama la atención la revisión de todo cuanto haya recopilado en internet acerca de las posibles brechas de seguridad y vulnerabilidades. Se sugiere la réplica del entorno de pruebas para garantizar, probablemente, que toda la infraestructura no se tocará hasta estar seguros de la viabilidad y verdadero alcance de la auditoría.

Exploitation: La fase de verificación y explotación de vulnerabilidades. Se contempla la forma de evasión de NIDS, HIPS, Antivirus y otras contramedidas existentes a nivel de red o EndPoint.

18

Un repaso a los vectores de explotación real de los fallos del sistema. Aquí se revisan prácticamente todas las posibilidades (dependiendo de los servicios activos en la organización), desde el acceso físico (localización, USBs, Man in the middle, etc) hasta las redes wireless, ataques web, asegurar contramedidas de bypass, una vez detectados...

Post Exploitation: • Esta fase se centra en la recopilación de evidencias y en cómo valorar el impacto real de la intrusión y hasta donde podemos llegar desde el sistema comprometido. Se contempla borrado de huellas y hacer persistente el ataque (puertas traseras, conexión inversa o rootkits).

19

¿Qué se pueden llevar de nuestra organización? Conscientes de las posibilidades de explotar las fallas, debemos centrar los esfuerzos en proteger nuestra infraestructura de red, asegurar que no hay elementos que puedan proporcionar salida de datos (voz, vídeo, cintas, discos, etc). Recintos asegurados para esos elementos señalados, más los Backups, documentación, etc... Ojo a los ataques dirigidos contra el impacto directo en el negocio (listas de clientes por ejemplo, copias de seguridad borradas, discos dañados, etc). Aquí no hay que escatimar recursos para la protección de estos elementos críticos. Atención especial merece el hecho de que nuestra auditoría debe ser limpia y no dejar rastro, como si no hubiéramos estado por allí. Garantizar que todo el sistema sea recuperable !! Por último, muy significativa la referencia a la posible persistencia del daño en forma de control de certificados, backdoors, rootkits, conexiones inversas y otras formas de postexplotación de la intrusión.

Reporting: Explica qué deben contener los reportes (ejecutivo y técnico) que entreguemos como conclusión de nuestro estudio.

20

Las razones para las que se solicitó el test deben ser los primeros aspectos relevantes del informe final. Seguido de los posibles riesgos y su valoración. Las métricas utilizadas y las contramedidas propuestas para los riesgos analizados. Especial incidencia en la información obtenida o robada. La evaluación de las vulnerabilidades encontradas, la confirmación de que esas fallas han podido ser explotadas, junto con las contramedidas propuestas y probadas y otras derivadas ¿Qué grado de exposición podemos deducir que tienen los activos de la empresa u organización? Podemos calcularlo en función de la frecuencia, magnitud y riesgos derivados. Para aclarar: frecuencia y posibilidad van de la mano. Por último, no pueden faltar en el informe nuestras conclusiones finales. Y no está de más que el CEO de la empresa nos dé su bendición :-)

21

ISSAF (“manualillo” de 845 páginas) La metodología ISSAF está diseñada para evaluar una red, los sistemas y la aplicación de controles (según la web OISSG, estos controles abarcan IEC/ISO 27001:2005(BS7799), Sarbanes Oxley SOX404, CoBIT, SAS70 and COSO). Curiosamente no está actualizada desde el año 2006. Su objetivo es proporcionar procedimientos muy detallados para el testing de sistemas de información que reflejan situaciones reales. ISSAF es utilizado en su mayoría para cumplir con los requisitos de evaluación de las organizaciones y puede utilizarse además como referencia para nuevas implementaciones relacionadas con la seguridad de la información. ISSAF está organizado según unos criterios de evaluación bien definidos, cada uno de estos ha sido revisado por expertos en la materia entre estos expertos podemos encontrarnos a Balwant Rathore, Mark Brunner, Piero Brunati, Arturo Busleiman (Buanzo), Hernán Marcelo Racciatti, Andrés Riancho, entre otros. Utiliza un enfoque que se lleva a la práctica en tres fases y se evalúa en 9 pasos. Las tres fases son las siguientes: • • •

Planificación y Preparación Evaluación (impactos, riesgos, etc...) Informe, Limpieza (borrado de pistas) y destrucción de “artefactos”.

FASE 1: Planificación y preparación. En esta fase se prepara el entorno de trabajo, el test. Antes de la planificación se firmará un “Acuerdo de Evaluación” o contrato en el que se delimitan las funciones y responsabilidades. Protección legal mutua en la que se dan “mutuas garantías”. Reuniones para decidir el alcance, el enfoque y las metodologías del test, límites del mismo y rutas de escalamiento, así como las pruebas del test.

FASE 2: Evaluación. Es donde se lleva a cabo el test de penetración propiamente dicho. Digamos que utiliza un enfoque por capas y cada una de ellas nos lleva a un nivel de acceso más grande a los activos. Las capas podemos enumerarlas como sigue:

22

Information Gathering (obtener información). Explorar las posibilidades de ataques. Tanto desde dentro como desde fuera. Vale cualquier documento que pueda desembocar en una posibilidad de comprometer los sistemas. Incluso se sugiere: empleados, partners de negocio, de tecnologías, inversiones, presencia web, topología de red, implementación de tecnologías, datos como teléfonos, e-mails, información personal, bloqueo de propiedad de IP (de modo que no se conozcan datos precisos sobre los dueños de los dominios). Quede claro que esta capa de trabajo puede hacerse de forma activa o pasiva (vemos similitudes con OWASP y PTES). Es importante reseñar que ISSAF hace, además de una explicación detallada de estas capas, acopio y ejemplo de herramientas posibles de uso, muchas de ellas contrastadas por expertos (dig, nslookup, nmap y otras herramientas disponibles como herramientas de adquisición de información en la web, inclusive P2P, IRC, foros underground, etc). Network Mapping (mapeo de la red) Esta sección se centra en aspectos más técnicos casi en exclusiva. El mapero de la red incluye las topologías, los routers, dispositivos de red, firewalls, nombres de hosts, Netbios, servidores activos, puertos abiertos en los distintos ordenadores, uso que se hace de cada uno de ellos, traceroute, sistemas operativos, acceso de cuentas de invitado, etc... Vulnerability Identification (identificación de vulnerabilidades) Es un paso más allá en la profundización del conocimiento de los sistemas objetivos. Precisamos el alcance de los tests de intrusión al poseer un conocimiento casi exhaustivo de todo cuanto se “cuece” en la organización. Es decir, vamos a refinar, a “tunear” el ataque como un sistema planificado. Todas las armas “de intrusión masiva” deben estar preparadas para el despliegue (nikto, nessus, openvas, whisker, etc). – – – – – – – –

servicios vulnerables ajustar los scanners de vulnerabilidades identificar fallas no conocidas o errores en las vulnerabilidades listar las vulnerabilidades Ojo con falsos positivos y falsos negativos medidas inmediatas de minimización de los fallos clasificar los riesgos técnicos en función de las vulnerabilidades halaldas posible impacto

Las vulnerabilidades deben ser clasificadas como: de alto riesgo (rojo), riesgo medio (naranja) y riesgo bajo (azul)... Realizar una plantilla o matriz donde se valora el riesgo y el impacto en los activos de la organización.

23

Penetration (penetración) Una vez tenemos las armas de penetración listas, probamos a ver qué resultados nos ofrecen a través de pruebas de concepto conocidas, manipuladas o hechas a medida por nosotros mismos (código + herramientas). Gaining Access & Privilege Escalation (ganar acceso y escalado de privilegios) Ganar privilegios: desde el más elemental hasta el “root” para asegurarnos de controlar y comprometer los sistemas. Probamos hasta el máximo de control posible. Enumerating Further (podemos traducir como “extra” enumeración de objetivos) Ataque a passwords, esnifar tráfico de red y analizarlo, hacernos con “cookies”, direcciones de correo (mensajes incluidos), routers y redes (passwords por defecto), maper completo de la red). Compromise Remote Users/Sites (usuarios y sitios remotos comprometidos) El auditor y asesor debería tratar de comprometer los sistemas y hacerse con el máximo de contarseñas y sistemas... Una vez conseguido le dará acceso a sistemas tanto dentro como fuera de la red objetivo. Usar firewall en escritorios remotos de los usuarios... para tratar de contener el acceso a cualquier parte de la red. Maintaining Access (mantenimiento del acceso y privilegios ganados) Se trata de lograr que el control sobre los sistemas comprometidos sea eficaz y pase desapercibido para el resto de usuarios y/o Administradores. Para ello, se habla de “canales” disimulados o secretos (¿a prueba de detecciones?). Estos canales ocultos pueden ser descritos como la escritura de datos ocultos en un medio o varios de almacenamiento no descrito, no publicado. Elegir el modo de comunicación encubierto es el objetivo de esta acción. Usaremos SSL túneles, proxys, ssh, etc... En general, se controla de forma oculta una o varias máquinas del sistema objetivo. Con troyanos, backdoors, rootkits, etc. Covering Tracks (cubriendo pistas o borrado de huellas si se prefiere). Cubrir las pistas... Todas a ser posible. Conocer todos los posibles métodos de ocultación de pruebas, ocultar keyloggers, herramientas, exploits, archivos, etc. Métodos esteganográficos. Carpetas ocultas en sistemas windows y GNU/linux... Limpiar “logs” (si es que no están en otro sitio replicados). Manipular logs en windows y en GNU/Linux. La imagen que nos muestra el esquema de áreas a tener en cuenta en la fase de evaluación es 24

muy explícita. Hay que aclarar que estas áreas son cíclicas e iterativas; es decir, que se repiten y se revisan en el mismo proceso de evaluación. No obstante, el proceso de pentesting y auditoría no termina aquí. Dejar claro que hay diferencias entre auditar y penetrar el sistema. Siempre la auditoría establece mecanismos amplios de trabajo, mientras que la penetración es una parte de la auditoría.

25

FASE 3: Informe, limpieza y destrucción de “artefactos” La fase final en la que podemos y debemos hacer dos tipos de informes: Uno de ellos verbal, solamente si hay que informar de alguna vulnerabilidad grave. El otro al que denomina “Informe final” que, lógicamente, se ra una descripción detallada al máximo. Debe contener apartados como: • • • • • • •

Sumario de la gestión llevada a cabo Alcance global del proyecto (y salida de las partes) Herramientas utilizadas (incluyendo “exploits”). Fechas y horas de los tests en los sistemas Todas las conclusiones de los tests diseñados (incluyendo informes específicos de vulnerabilidades que se adjuntan como documentos aparte). Un listado de todas las fallas y vulnerabilidades encontradas, así como las recomendaciones y contramedidas para solucionarlas. Un listado de puntos de intervención. Primero las mejoras y luego las propuestas de solución.

Por último, remover archivos, rastro de intervención, manipulación de sistemas y explotación de fallas... Si algo no se puede limpiar, hay que advertirlo para que en otro momento se proceda a ello. ANEXO IMPORTANTE: Manejo de medidas de falsos positivos. Podemos, antes de seguir profundizando en esta metodología, afirmar que las tres fases anteriores quedan establecidas como estrategia y que lo que a continuación se relata y se enumera brevemente (por falta de tiempo y no ser objeto del trabajo), se puede considerar como una metodología entendida como un todo agrupada en 4 Áreas de aplicación de tests que poseen a su vez subáreas de aplicación de tests más específicas:

NETWORK SECURITY: – – – – – – – – – –

Passwords audit Seguridad en switchs Seguridad en routers Evaluar seguridad de los firewall Evaluar seguridad de detección de intrusiones Evaluar la seguridad de las VPN Evaluar la gestión y estrategia en uso antivirus. Seguridad del área de almacenamiento de red (y en red). Evaluar seguridad Wireless Seguridad del usuario de Internet 26

– Seguridad servidores AS-400 (¿IBM?). Entiendo que extensivo a otros tipos de servidores. – Seguridad Lotus-Notes (entiendo que es aplicable a cualquier otro tipo de software de gestión y ofimática en intranet)

SEGURIDAD DE CLIENTES DE RED (HOSTS): – – – –

Evaluación de la seguridad de los sistemas GNU/Linux) Evaluación de la seguridad de los sistemas Windows Evaluación de la seguridad de los sistemas Novell Netware Evaluación de la seguridad de los servidores web

SEGURIDAD DE APLICACIONES: – Evaluación de la seguridad de las aplicaciones web en general – Evaluación de la seguridad de las aplicaciones web (SQL injection) – Auditar el código fuente de sistemas (kernel Linux puede ser, pero Windows estamos apañaos) y aplicaciones. – Auditoría de binarios – Checklist de evaluación de seguridad en las aplicaciones

SEGURIDAD DE LAS BASES DE DATOS: – Evaluar la seguridad de las BD – Ingeniería social

27

OSSTMM (Open Source Security Testing Methodology Manual). Si la anterior metodología la podemos considerar un “framework”, esta es una metodología de libro, de manual. La ISSAF se explayaba en 845 páginas y ésta, a pesar de tener solamente 213 páginas, es considerada meticulosa como ninguna. Revisada recientemente, se encuentra en la versión 3.0 lo que nos da una idea de su constante revisión y actualización tanto conceptual como estratégica. De momento, no hay traducción española. Está diseñada para ser consistente y repetible y ofrece al mismo tiempo que una estrategia, tests de evaluación y medida de riesgos, una valoración intrínseca en función de los resultados arrojados por los tests. Esto en si mismo es novedoso en comparación a las otras metodologías y garantiza esa meticulosidad de la que hace gala y comentamos en la introducción de este apartado. La valoración de las versiones anteriores son incompatibles con la nueva versión. De hecho, ya establece de antemano la posibilidad de usar hasta 4 tipos de tests en función del alcance y necesidades programadas.

DEFINIR UN TEST DE SEGURIDAD: Podemos establecer 7 pasos para la definición de las pruebas que realizará el analista: • • •

•

•

•

Definir qué queremos proteger: los activos. Los mecanismos de protección son los controles que pondrás a prueba para encontrar sus limitaciones. Identificar la zona, el área que denominaremos zona de acuerdos alrededor de la cual hay procesos , mecanismos y servicios construidos para proteger esos activos. Definir la zona externa que necesitas para proteger las operaciones de tus activos... hay aspectos sobre los que podremos incidir (electricidad, agua, aire, alimentación, etc) y otros sobre los que no (humedad, sequedad, colegas, partners, socios, etc...). Esto es, definir el alcance del test. Definir como el alcance interactúa dentro y fuera. Compartimentar los activos y la dirección desde la que se interactúa con y hacia ellos: dentro-fuera, fuera-dentro, dentrodentro, fuera-fuera, desde el Departamento A hacia el B... Estos son los vectores. Cada vector debería ser de forma ideal un test separado para proteger cada test por separado y de corta duración, antes de que pudiera incidir demasiado en cambios dentro del entorno de trabajo. Decidir qué equipamiento será necesario para cada test. Dentro de cada vector puede suceder que la interacción suceda a varios niveles. Estos niveles pueden ser muchos, pero hemos separado 5 canales por función. Cada canal debe ser probado separadamente para cada vector. Preparar qué información pretende extraer de cada prueba. La respuesta de los activos a cada medida de seguridad. Los tipos de test deben ser definidos para cada prueba 28

•

específica. Asegurar que las pruebas de cada test cumplen o están conformes con las Reglas de Acuerdos (contratos) previos. No hay que crear falsas expectativas, incomprensiones y malos entendidos.

El resultado final será lo que denominamos: Superficie de ataque (extensión y profundidad del ataque es más correcto).

TIPOS DE TESTS DE SEGURIDAD: La elección del tipo de test no determina ni orienta la aplicación de todo el sistema de la metodología. La implementación práctica de OSSTMM requiere la definición individualizada de las pruebas prácticas. Esto significa que seguir esta metodología su aplicación y su técnica reflejará el tipo de test que hayamos elegido. Estos pueden ser (y no se limita a estas combinaciones): – Blind (a ciegas): el auditor interactúa con el objetivo sin conocimiento previo de sus defensas, activos o canales (entendidos como vías de acceso)... El objetivo es preparado para ir avanzando en su conocimiento. Este tipo de test pone a prueba al propio auditor. Este conocimiento será mayor cuanta mayor sea la preparación del auditor. Unos le llaman “hacking ético” y otros “juegos de guerra”. – Double blind (doblemente a ciegas): también conocido como técnica “black box” (caja negra). No se sabe bien qué es lo que nos vamos a encontrar. Prácticamente no se sabe nada del objetivo y será puesto a prueba de forma brusca a veces. Su éxito depende de la calidad del auditor... – “Gray box” (caja gris): el auditor tiene un conocimiento limitado de las defensas del objetivo y de sus activos, pero sabe todo acerca de sus canales. El objetivo conoce el alcance de la auditoría, pero no las vías y vectores de ataque. La eficacia de este tipo de test dependerá de la calidad de la información provista al auditor antes de que el conocimiento del test revele su aplicabilidad (¿o no?). – “Double gray box” (o también “white box”): El auditor tiene también un conocimiento limitado de sus defensas y activos y un completo conocimiento de sus canales. Le diferencia del anterior el hecho de que dependerá no solamente de la calidad de la información de la que sea provista el auditor, sino también de la que reciba el objetivo. – “Tándem”: Ambas partes conocen todos los detalles de la auditoría. Se pone a prueba la protección y los controles aplicados en el objetivo. La verdadera naturaleza de los tests depende de la meticulosidad con la que se preparen para tener una visión global de los tests y sus respuestas. Se le llama “Cristal box” o proceso transparente donde el auditor ya forma parte del equipo de seguridad y control de los procesos. – “Reversal” (Reversible): el auditor trabaja con pleno conocimiento de todas las operativas, pero el objetivo (podemos traducirlo como cliente también) no sabe cómo, ni con qué, ni cuando el auditor le auditará... Todo el proceso dependerá de la creatividad y conocimientos del auditor. En el informe se hará constar cuál o cuáles tipos de tests han sido utilizados. Es importante comparar posibles desviaciones en comparación con otros procesos en similares circunstancias.

29

EL ALCANCE (scope): El alcance comprende 3 canales (vías de acceso) posibles de actuación e interacción: COMSEC (communications security), PHYSSEC (physical security), and SPECSEC (spectrum security) . Una meticulosa auditoría requiere de pruebas en los tres canales, en realidad, las auditorías van a depender de la pericia del auditor y los medios y equipamiento requerido. Este manual disecciona estos 3 canales en 5 secciones lógicas:

Queda representada así la estructura de canales y secciones: CHANNEL

SECCIÓN

DESCRIPCIÓN

HUMANO

Comprende el elemento humano de comunicación donde la interacción puede ser física o sicológica.

PHYSSEC (entorno físico) FÍSICO

SPECSEC (espectro... wireless)

Wireless communications

Pruebas de seguridad física los canales son ambos a la vez físicos y no electrónicos. Comprende elementos tangibles donde es necesario esfuerzo físico o un transmisor de enrgía para manipulación. ELSEC (comunicaciones electrónicas) SIGSEC (señales) EMSEC (emanaciones no encadenadas por cable)

30

Todos los sistemas y redes de datos sobre redes cableadas...

Redes de datos COMSEC Telecomunicaciones Comunicaciones digitales o analógicas, telefónicas sobre redes de lineas.

LAS REGLAS DE ACUERDOS (CONTRATOS): Para no extenderme en los apartados que definen los distintos acuerdos y sus contenidos, diré que OSSTMM es pulcro y claro en este terreno. Es ético hasta en el detalle. Ni ofrece más de lo necesario, ni regala los oídos del cliente. Hay ciertos límites que todo auditor que use esta metodología deberá respetar... Para muestra, un botón: “no usar el miedo, la duda y el engaño como parte del marketing y el proceso de ventas...”, “si fallan los tests, está prohibido ofrecer servicios gratis”, etc... El alcance debe estar perfectamente definido antes de proceder a la auditoría... La planificación de cada test debe estar limitada al área de experiencia de cada miembro del equipo o a la del auditor encargado... Hay más, pero no es objeto del estudio presente. Nos centraremos en los aspectos metodológicos.

RESULTADOS DE LOS TESTS: Los resultados de los tests van acompañados habitualmente de las soluciones recomendadas. Éstas a veces son un valor añadido en el trabajo de auditoría, pero no son obligatorias. Más incluso, las soluciones no forman parte de las auditorías OSSTMM. El uso de esta metodología debería concluir con STAR (Security Test Audit Report), informe de la auditoría del test de seguridad... Este tipo de certificación para empresas, requiere la siguiente información: • • • • • • • • • •

fecha y hora de los tests duración nombre de los analistas responsables tipo de test alcance del test index o método de enumeración de objetivos canales testeados vector o vectores del test métrica de la superficie de ataque (extensión del ataque) cuáles se han completado y cuáles no 31

• • •

cualquier asunto considerando la validez del test y los resultados procesos que puedan influenciar limitaciones en la seguridad cualquier anomalía detectada

El uso completo de OSSTMM muestra una actualizado medición de los controles de seguridad. La no representación de los informes puede inducir a una fraudulenta verificación de los controles de seguridad. El analista debe aceptar su responsabilidad en los informes inapropiados e imprecisos.

COMPRENDIENDO LA METODOLOGÍA OSSTMM: OSSTMM no permite una separación entre la recolección de datos activos y la verificación a través del efecto de la alteración (el proceso de tests). No diferencia entre pruebas activas y pasivas. La metodología requiere ambas cosas. Es más, el auditor puede no ser capaz de diferenciarlas. Armonizar OSSTMM con otras metodologías puede ser contraproducente, solo en la medida que esas constriñan el fluido de esta metodología ralentizando el proceso ¿? Para elegir el tipo de test adecuado hay que comprender primeramente como están diseñados los MÓDULOS para trabajar. Dependiendo de la empresa, el tipo de negocio, el tiempo disponible, los requerimientos de la auditoría, el auditor puede planificar y distribuir los detalles de la auditoría por FASES. Hay cuatro fases para la ejecución de esta metodología: A. FASE REGULATORIA

Cada viaje empieza en una sola dirección. A menudo el tipo de test se decide aquí. Habrá que tener en cuenta los requerimientos y los límites de la auditoría, así como el alcance y las restricciones del alcance. Me salto los apartados dentro de esta fase... B. FASE DE DEFINICIONES

Conocimiento del alcance interactuando con los objetivos (blancos de la auditoría) y los activos. Aquí sí se tiene constancia de la definición clara del alcance de la auditoría. Me salto los apartados dentro de esta fase...

C. FASE DE INFORMACIÓN

Muchas de las auditorías son sobre la información que no está cubierta. Los varios tipos de valores, así como los activos mal ubicados y desatendidos y mal gestionados, son sacados a la luz. 32

D. FASE INTERACTIVA DE PRUEBA DE CONTROLES

Centrada en la penetración misma y en los trastornos que conlleva. Suele ser la fase final de los tests. Asegurarse de que las perturbaciones son poco invasivas y que el efecto de la información extraída no pueda ser conocida hasta que otras fases hayan sido llevadas a efecto. Hay que verificar que las conclusiones son ciertas.

MÉTRICAS OPERATIVAS DE SEGURIDAD: Una métrica operativa es una medida constante que nos informa cuantitativamente de la relación de hechos que acontecen en nuestra vida, a nuestro alrededor. Por analogía, en OSSTMM las métricas se usan para medir el grado de seguridad de nuestros activos. En el argot de esta metodología, se usan unos patrones denominados Rav (Risk Assesment Values), valores de evaluación de riesgos.

33

Cómo se hace y calcula un Rav:

En el resto del apartado del manual se hacen sesudas consideraciones para enseñar a hacer cálculos Rav. En otra versión de este documento podríamos ocuparnos de ello. El esquema es elocuente ya que nos dice qué factores debemos tener en cuenta para hacer los cálculos en función de la permeabilidad de nuestros activos, si existen o no controles y los límites de acceso a los mismos. Las fórmulas derivan del esquema anterior y del siguiente:

En la imagen inferior aparece visible como se calcula la porosidad (término de penetración) de un activo como parte de la fórmula de un “Rav”:

34

La metodología se resume en separar lo que se necesitará hacer en: CANAL MÓDULO TAREAS Esto se puede revisar al principio del apartado de esta metodología. Hay buenas razones para usar Ravs y proteger los activos...

MAPA MENTAL DE OSSTMM (gracias a un ruso):

Puedes verlo más claramente en: http://img21.imageshack.us/img21/459/osstmm.png 35

COMPARATIVA DE LAS METODOLOGÍAS EN CUESTIÓN: No quiero ser pretencioso en la comparativa. Del estudio realizado no podemos extraer sesudas conclusiones que reflejen gran profundidad de lectura y análisis. Una aproximación, sí. MÉTODOS ISSAF

PTES

OWASP

OSSTMM

PATRONES (ÍTEMS) Alta. Alta. Muy Alta. Muy Alta. Rigor de la Desactualizada. Año Desactualizada. Año Solo centrada en la Actualizada y en metodología 2006. 2008 web, pero muy constante revisión (meticulosidad) didáctica e instructiva

Niveles de detalle

Facilidad de uso

Ámbitos de aplicación

Entornos de aplicabilidad

Uso por los auditores

Muy detallada, pero sencilla. Faltan elementos de cloud computing y Protección datos

Perfectamente detallada. Los procesos en su aplicación están perfectamente definidos aunque no se tienen en cuenta novedades en la metodología.

Muy detallada. Su Menos detalle a mi enfoque web no le juicio. Parece como si resta ni un ápice de la experiencia de uso meticulosidad. de anteriores versiones diera lugar a Orienta perfectamente crear la necesidad de el trabajo del auditor. formación previa.

Muy Alta. Se puede usar con conocimientos medios.

Alta. Aparenta sencillez, pero requiere entrenamiento.

Alta. Muy técnico, Media. Muy técnico. aunque muestra uso Requiere de herramientas, entrenamiento y sugiere usos y muestra práctica. ejemplos. Certificaciones.

GENERAL. PYMES, ORGANIZACIONES TODO TIPO DE TODO TIPO DE ORGANIZACIONES COMPLEJAS. ORGANIZACIONES ORGANIZACIONES E INSTITUCIONES PYMES, financieras. CON PRESENCIA Y PYMES. VARIAS WEB INSTITUCIONES EDUCATIVAS Todos. Genérico para auditorías de todo tipo. ¿Servidores IBM únicamente? Fácil. Es lineal y cubre las etapas típicas de una auditoría con test de intrusión. Ampliamente usado ya que respeta los modelos NIST (que se tienen muy en cuenta en USA)

Todos. En combinación con otra metodología como OWASP, sería ideal.

Menos usado. Creo que el que menos, aunque he averiguado que hay empresas que combinan esta y otras metodologías.

36

Solo web y Todos. Incluso los que aplicaciones todavía no se han enfocadas a la web. implementado. Es Servidores. dinámica y potente en su diseño. Muy usado también en combinación con el resto de metodologías por su precisión y nivel de detalle. Detrás hay muy importantes empresas e instituciones que quieren que esta metodología se desarrolle plenamente

El más usado por lo que he podido averiguar en Internet, aunque la tendencia es simplificar (tipo ISSAF), su uso supone un conocimiento y experiencia alto.

MÉTODOS ISSAF

PTES

Fase de evaluación conocida. Uso frecuente del método. Pasos más desgranados en el pentest. Facilita el informe en función de los pasos seguidos y los resultados obtenidos. Recomienda herramientas para la evaluación.

Metodología archiconocida como ISSAF. Similitudes con OSSTMM 2.1 Muy definidos los controles y las “maniobras” de pentesting.

Falta concretar acuerdos, no señala límites en el uso de los tests. Menos rigurosa que el resto. Podría escaparse de las manos el uso de los tests de intrusión. Inmaduro en cuanto a desarrollo. Estancado y menos dinámico que el resto.

Proyecto incompleto pero con buenas perspectivas. Se ha hecho un llamamiento a la colaboración, pero parece que este intento de estándar está condenado a dormirse.

OWASP

OSSTMM

PATRONES (ÍTEMS)

Ventajas

Inconvenientes

Comentario y valoración personal

Un poco desactualizada. Al ser una metodología lineal (aunque se señale como cíclica), es de fácil uso y la práctica puede aplicarla auditor sin experiencia. Metodología agresiva e intrusiva

Ofrece una buena guía de como deben ser conducidas las necesidades del testeo.

Facilidad de uso de los controles más conocidos “Top Ten”. Novedoso y bien estructurado. Se preocupa de las auditorías de la web = elemento centrado en el marketing y el negocio. Propone hasta las herramientas de uso. Muy didáctico podría servir para aprender los fundamentos de las auditorías y pentesting.

Ampliamente documentada, soporte de la Comunidad. Pone a punto plantillas de uso y medidas. Se integra y tiene en cuenta todos los estándares de seguridad de la información. Ofrece una calidad incuestionable de resultados. No se hace referencia a qué tipo de objetivos para cada tipo de test. El cambio con respecto a la 2.1 supone una lectura y práctica intensa. No recomienda ninguna herramienta.

Habría que combinar con otras herramientas y metodologías para que la auditoría fuera más completa. No olvidemos que la infraestructura de la web y los servidores no son auditados. Se basa más en la Debe actualizarse o, al creatividad del auditor menos, revisarse. y también en su experiencia. No permite o es reacia a combinar su metodología con otras. Loables y detalladísimos procesos y controles. Podría combinarse con otras metodologías porque su nivel de precisión es excelente. Junto con OWASP podría ser el primer paso en el aprendizaje de las auditorías.

Maximiliano Pérez Elche, Marzo 2012 37

Menos agresiva e intrusiva, fácilmente se pueden borrar las huellas de paso.

Al igual que ISSAF es agresiva y muy intrusiva, pero deja muy clara su postura en cuanto a los límites en los acuerdos con el cliente (objetivo)... Echo de menos un listado de herramientas sugeridas para cada fase.