5- Por qué debemos seguir una metodología para las pruebas de penetración
Como se acaba de mencionar, la corrupción del alcance es una de las razones para utilizar una metodología específica; Sin embargo, hay muchas otras razones. Por ejemplo, al realizar una prueba de penetración para un cliente, debe demostrar que los métodos que planea utilizar para las pruebas están probados y son verdaderos. Al utilizar una metodología conocida, puede proporcionar documentación de un procedimiento especializado que ha sido utilizado por muchas personas.
Consideraciones medioambientales: Por supuesto, hay varios tipos diferentes de pruebas de penetración. A menudo se combinan en el alcance general de una prueba de penetración; Sin embargo, también se pueden realizar como pruebas individuales.
La siguiente es una lista de algunas de las consideraciones ambientales más comunes para los tipos de pruebas de penetración en la actualidad:
Pruebas de infraestructura de red
Las pruebas de la infraestructura de red pueden significar varias cosas. A los efectos de este curso, decimos que se centra en evaluar la postura de seguridad de la infraestructura de red real y cómo es capaz de ayudar a defenderse contra los ataques. Esto a menudo incluye los conmutadores, enrutadores, firewalls y recursos de soporte, como servidores de autenticación, autorización y contabilidad (AAA) e IPS. Una prueba de penetración en la infraestructura inalámbrica a veces puede incluirse en el alcance de una prueba de infraestructura de red. Sin embargo, se realizarían tipos de pruebas adicionales más allá de una evaluación de redes cableadas. Por ejemplo, un probador de seguridad inalámbrico intentaría entrar en una red a través de la red inalámbrica, ya sea eludiendo los mecanismos de seguridad o rompiendo los métodos criptográficos utilizados para proteger el tráfico. Las pruebas de la infraestructura inalámbrica ayudan a una organización a determinar los puntos débiles en la implementación inalámbrica, así como la exposición. A menudo incluye un mapa de calor detallado del desembolso de la señal.
Pruebas basadas en aplicaciones
Este tipo de pruebas de penetración se centra en probar las debilidades de seguridad en las aplicaciones empresariales. Estas debilidades pueden incluir, entre otras, configuraciones incorrectas, problemas de validación de entrada, problemas de inyección y fallas lógicas. Dado que una aplicación web se crea normalmente en un servidor web con una base de datos back-end, el ámbito de las pruebas normalmente incluye también la base de datos. Sin embargo, se centra en obtener acceso a esa base de datos de soporte a través del compromiso de la aplicación web. Un gran recurso que mencionamos varias veces en este libro es el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP).
Pruebas de penetración en la nube
Los proveedores de servicios en la nube (CSP) como Azure, Amazon Web Services (AWS) y Google Cloud Platform (GCP) no tienen más remedio que tomarse muy en serio sus responsabilidades de seguridad y cumplimiento. Por ejemplo, Amazon creó el Modelo de Responsabilidad Compartida para describir en detalle las responsabilidades de los clientes de AWS y las responsabilidades de Amazon (véase https://aws.amazon.com/compliance/shared-responsibility-model).
La responsabilidad de la seguridad en la nube depende del tipo de modelo de nube (software como servicio [SaaS], plataforma como servicio [PaaS] o infraestructura como servicio [IaaS]). Por ejemplo, con IaaS, el cliente (consumidor de la nube) es responsable de los datos, las aplicaciones, el tiempo de ejecución, el middleware, las máquinas virtuales (VM), los contenedores y los sistemas operativos de las VM. Independientemente del modelo utilizado, la seguridad en la nube es responsabilidad tanto del cliente como del proveedor de la nube. Estos detalles deben resolverse antes de firmar un contrato de computación en la nube. Estos contratos varían en función de los requisitos de seguridad del cliente. Las consideraciones incluyen la recuperación ante desastres, los acuerdos de nivel de servicio (SLA), la integridad de los datos y el cifrado. Por ejemplo, ¿el cifrado se proporciona de extremo a extremo o solo en el proveedor de la nube? Además, ¿quién administra las claves de cifrado, el CSP o el cliente?
En general, desea asegurarse de que el CSP tenga las mismas capas de seguridad (lógicas, físicas y administrativas) que tendría para los servicios que controla. Al realizar pruebas de penetración en la nube, debe comprender lo que puede hacer y lo que no puede hacer. La mayoría de los CSP tienen directrices detalladas sobre cómo realizar evaluaciones de seguridad y pruebas de penetración en la nube. En cualquier caso, existen muchas amenazas potenciales cuando las organizaciones se trasladan a un modelo de nube. Por ejemplo, aunque sus datos estén en la nube, deben residir en una ubicación física en algún lugar. Su proveedor de servicios en la nube debe acordar por escrito proporcionar el nivel de seguridad requerido para sus clientes. A modo de ejemplo, el siguiente enlace incluye la política de soporte al cliente de AWS para pruebas de penetración: https://aws.amazon.com/security/penetration-testing.
NOTA Muchos probadores de penetración consideran que el aspecto físico de las pruebas es el más divertido porque esencialmente se les paga para entrar en las instalaciones de un objetivo. Este tipo de prueba puede ayudar a exponer cualquier debilidad en el perímetro físico, así como cualquier mecanismo de seguridad que esté en su lugar, como guardias, puertas y cercas. El resultado debe ser una evaluación de los controles de seguridad física externos. La mayoría de los compromisos hoy en día comienzan con algún tipo de ataque de ingeniería social. Puede ser una llamada telefónica, un correo electrónico, un sitio web, un mensaje SMS, etc. Es importante probar cómo sus empleados manejan este tipo de situaciones. Este tipo de prueba a menudo se omite del alcance de un compromiso de prueba de penetración, principalmente porque implica principalmente probar a las personas en lugar de la tecnología. En la mayoría de los casos, la gerencia no está de acuerdo con este tipo de enfoque. Sin embargo, es importante obtener una visión real de los últimos métodos de ataque. El resultado de una prueba de ingeniería social debe ser evaluar el programa de concienciación sobre seguridad para poder mejorarlo. No debe ser para identificar a las personas que no pasan la prueba. Una de las herramientas de las que hablaremos más en un módulo posterior es el Social-Engineer Toolkit (SET), creado por Dave Kennedy. Esta es una gran herramienta para realizar campañas de pruebas de ingeniería social.
PROPINA Los programas de recompensas por errores permiten a los investigadores de seguridad y a los evaluadores de penetración obtener reconocimiento (y, a menudo, una compensación monetaria) por encontrar vulnerabilidades en sitios web, aplicaciones o cualquier otro tipo de sistemas. Empresas como Microsoft, Apple y Cisco, e incluso instituciones gubernamentales como el Departamento de Defensa de los Estados Unidos (DoD), utilizan programas de recompensas por errores para recompensar a los profesionales de la seguridad cuando encuentran vulnerabilidades en sus sistemas. Muchas empresas de seguridad, como HackerOne, Bugcrowd, Intigriti y SynAck, proporcionan plataformas para que las empresas y los profesionales de la seguridad participen en programas de recompensas por errores. Estos programas son diferentes de las pruebas de penetración tradicionales, pero tienen un objetivo similar: encontrar vulnerabilidades de seguridad que permitan a la organización corregirlas antes de que los atacantes malintencionados puedan explotar dichas vulnerabilidades. He incluido diferentes consejos y recursos de recompensas por errores en mi repositorio de GitHub en: https://github.com/The-Art-of-Hacking/h4cker/tree/master/bug-bounties.
Al hablar de métodos de pruebas de penetración, es probable que escuche los términos pruebas de entorno desconocido (anteriormente conocido como caja negra), entorno conocido (anteriormente conocido como caja blanca) y entorno parcialmente conocido (anteriormente conocido como caja gris). Estos términos se utilizan para describir la perspectiva desde la que se realizan las pruebas, así como la cantidad de información que se proporciona al evaluador:
Prueba de entorno desconocido
En una prueba de penetración en un entorno desconocido, el evaluador suele recibir solo una cantidad muy limitada de información. Por ejemplo, es posible que al evaluador solo se le proporcionen los nombres de dominio y las direcciones IP que están en el alcance de un objetivo en particular. La idea de este tipo de limitación es que el evaluador comience con la perspectiva que podría tener un atacante externo. Por lo general, un atacante primero determinaría un objetivo y luego comenzaría a recopilar información sobre el objetivo, utilizando información pública, y obtendría más y más información para usar en los ataques. El evaluador no tendría conocimiento previo de la organización y la infraestructura del objetivo. Otro aspecto de las pruebas en entornos desconocidos es que, a veces, el personal de soporte de red del objetivo puede no recibir información sobre cuándo exactamente se está llevando a cabo la prueba. Esto permite que también se lleve a cabo un ejercicio de defensa, y elimina el problema de que un objetivo se prepare para la prueba y no brinde una visión del mundo real de cómo se ve realmente la postura de seguridad.
Prueba de entorno conocido
En una prueba de penetración de entorno conocido, el evaluador comienza con una cantidad significativa de información sobre la organización y su infraestructura. Normalmente, al evaluador se le proporcionarían cosas como diagramas de red, direcciones IP, configuraciones y un conjunto de credenciales de usuario. Si el ámbito incluye una evaluación de la aplicación, también se puede proporcionar al evaluador el código fuente de la aplicación de destino. La idea de este tipo de pruebas es identificar tantos agujeros de seguridad como sea posible. En una prueba de entorno desconocido, el alcance puede ser solo identificar una ruta de acceso a la organización y detenerse allí. En el caso de las pruebas de entorno conocido, el alcance suele ser mucho más amplio e incluye la auditoría de la configuración de la red interna y el análisis de los equipos de sobremesa en busca de defectos. El tiempo y el dinero suelen ser factores decisivos en la determinación de qué tipo de prueba de penetración completar. Si una empresa tiene preocupaciones específicas sobre una aplicación, un servidor o un segmento de la infraestructura, puede proporcionar información sobre ese objetivo específico para disminuir el alcance y la cantidad de tiempo dedicado a la prueba, pero aún así descubrir los resultados deseados. Con la sofisticación y las capacidades de los adversarios de hoy en día, es probable que la mayoría de las redes se vean comprometidas en algún momento, y un enfoque de caja blanca no es una mala opción.
Prueba de entorno parcialmente conocido
Una prueba de penetración de entorno parcialmente conocida es algo así como un enfoque híbrido entre pruebas de entorno desconocido y conocido. Con las pruebas de entorno parcialmente conocidas, es posible que a los evaluadores se les proporcionen credenciales, pero no documentación completa de la infraestructura de red. Esto permitiría a los evaluadores seguir proporcionando los resultados de sus pruebas desde la perspectiva del punto de vista de un atacante externo. Teniendo en cuenta el hecho de que la mayoría de los compromisos comienzan en el cliente y se abren camino a través de la red, un buen enfoque sería un ámbito en el que los evaluadores comiencen en el interior de la red y tengan acceso a una máquina cliente.
