blog

Obviamente el ser capaz de contactarse con el cliente o la organización en una emergencia es vital. Las emergencias pueden surgir, y un punto de contacto debe ser establecido para poder manejarlas. Crear una lista de contacto para emergencias. Esta lista debe incluir información de contacto para todas las partes dentro del alcance de las pruebas. Una vez creada, la lista de contactos para emergencia debe ser compartida con todos aquellos incluidos en la lista. Tener en consideración la organización en evaluación puede no ser el cliente.

Obtener la siguiente información sobre cada contacto para emergencia:

• Nombre completo
• Título y responsabilidad operacional
• Autorización para discutir los detalles sobre las actividades de las pruebas, si aún no se ha especificado
• Dos formas para contacto inmediato 24/7, como un teléfono celular, o teléfono de hogar si es posible
• Una forma para transferencia segura masiva de datos, como SFTP, o correo electrónico encriptado

Anotar: El número para un grupo como la mesa de ayuda o centro de operaciones puede reemplazar un contacto para emergencia, pero únicamente si este tiene personal 24/7. La naturaleza de cada prueba de penetración incluye quien debe estar en la lista para contactos de emergencia. No únicamente debería estar disponible la información de contacto para el cliente y aquello a evaluar, sino también es posible se requiera comunicar a los profesionales en caso de una emergencia. Esta lista debe incluir preferiblemente a las siguientes personas:

• Todos los profesionales en pruebas de penetración quienes realiza las evaluaciones
• El gerente del grupo para pruebas
• Dos contactos técnicos para cada organización en evaluación
• Dos contactos técnicos en el cliente
• Un contacto de la alta gerencia o contacto empresarial en el cliente

Es posible haya alguna superposición en el listado anterior. Por ejemplo, la organización en evaluación puede ser el cliente, el gerente del grupo para pruebas puede también realizar la prueba de penetración, o un contacto técnico del cliente puede estar en la alta gerencia. También se recomienda definir una persona para contacto único por cada parte involucrada, quien lo lidere y asuma responsabilidad en su nombre.

Proceso para Reportar Incidentes

Es importante por varias razones, discutir las capacidades actuales para la respuesta de incidentes en la organización, antes de realizar una evaluación. Una prueba de penetración no únicamente evalúa la seguridad de una organización, sino también sus capacidades para respuesta ante incidentes.

Si se puede realizar una evaluación completa, sin los equipo de seguridad interna lo perciban, se ha identificado una brecha importante en la seguridad. Es también importante asegurarse antes de la prueba inicie, alguien en la organización es consciente de donde las pruebas están siendo realizadas, de tal manera el equipo para respuesta de incidentes no empiece a llamar a cada miembro de la alta gerencia en el medio de la noche, porque creyó fueron atacados o comprometidos.

Definición de Incidente

El Intituto Nacional de Estándares y Tecnologías (NIST), define un incidente como; “una violación o amenaza inminente de violación a las políticas de seguridad en computadoras, políticas de uso aceptable, o prácticas estándar de seguridad”. Un incidente también puede ocurrir sobre un nivel físico, en el cual una persona gana acceso físico no autorizado hacia un área por cualquier medio. La organización en evaluación debe tener diferentes categorías y niveles para diferentes tipos de incidentes.

Frecuencia para Reportar el Estado

La frecuencia para reportar los estados puede variar ampliamente. Algunos factores influenciando en la programación de los reportes, incluyen la duración total de la evaluación, al alcance de la prueba, la madurez en seguridad de aquello en evaluación. Una programación efectiva permite al cliente sentirse comprometido. Un cliente ignorado es un cliente antiguo.

Una vez se establece la frecuencia y programación para los reportes de estado, se debe cumplir. Posponer o retrasar los reportes de estado puede ser necesario, pero no debe volverse crónico. El cliente puede ser consultado para este de acuerdo en una nueva programación si es necesario. Saltarse un reporte del estado por completo no es profesional, y debe evitarse si es posible.

PGP y Otras Alternativas

La encriptación no es opcional. La comunicación con el cliente es una parte absolutamente necesaria en cualquier prueba de penetración, además debido a su naturaleza sensible de la evaluación, las comunicaciones de información sensible deben ser encriptadas, especialmente en el reporte final. Antes de iniciar las pruebas debe ser establecido un medio seguro para la comunicación con el cliente. Algunos medios comunes para encriptación son los siguientes:

• PGP/GPG puede ser utilizado para comunicarse ya sea a través de correo electrónico, y para encriptar el reporte final (recordar las lineas del asunto son pasadas en texto plano)
• Un buzón de correo seguro hospedado en la red del cliente
• Teléfono
• Reuniones cara a cara
• Al entregar el reporte final, se puede también almacenar el reporte en un archivo encriptado con AES, pero asegurarse de la utilidad para archivo soporte encriptación AES utilizando CBC.

Preguntar también cual tipo de información puede ser puesto en escrito, y cual debe ser comunicado solo verbalmente. Algunas organizaciones tienen muy buenas razones para limitar cual información de seguridad es transmitida hacia ellos por escrito.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Emergency_Cont…
https://csrc.nist.gov/publications/detail/sp/800-86/final

Cada prueba de penetración debe estar orientada a metas. Es decir el propósito de las pruebas debe ser identificar vulnerabilidades específicas, las cuales conduzcan hacia el compromiso de la empresa, u objetivos por misión del cliente. No se trata de encontrar sistemas sin parchar. Esto se trata sobre identificar el riesgo el cual impactará negativamente a la organización.

Primario

La principal meta de la prueba no debe ser conducida por el cumplimiento. Existen un número de diferentes justificaciones para este razonamiento. Primero, el cumplimiento no es igual a seguridad. Mientras esto debe ser entendido como muchas organizaciones se someten a las pruebas debido al cumplimiento, esta no debe ser la principal meta de la prueba. Por ejemplo, se puede contratar una firma para completar una prueba de penetración como parte de requerimientos sobre PCI-DSS.

No faltan compañías las cuales procesan información sobre tarjetas de crédito. Sin embargo los rasgos los cuales hacen a la organización en evaluación única y viable en un mercado competitivo, tendrán un gran impacto si son comprometidos. Los sistemas procesando tarjetas de créditos siendo comprometidos, ciertamente serán un serio problema; pero los números de tarjetas de crédito junto con los datos asociados del cliente expuestos; serían catastróficos

Secundario

Las metas secundarias están directamente relacionadas con el cumplimiento. Es común para las metas primarias y secundarias estar muy cercanamente relacionadas. Por ejemplo en las pruebas conducidas por PCI-DSS, obtener las tarjetas de crédito es la meta secundaria. Vincular esta brecha de datos hacia la empresa o conductores de misión de la organización es la meta principal. Las metas secundaria significan algo para el cumplimiento y/o TI. Las metas principales obtienen la atención de la alta gerencia.

Análisis Comercial

Antes de realizar una prueba de penetración, es beneficioso determinar el nivel de madurez sobre la postura de seguridad del cliente. Existen diversas organizaciones las cuales eligen saltar directamente hacia la prueba de penetración, evaluando primero este nivel de madurez. Para los clientes con un programa de seguridad inmaduro, es frecuentemente una buena idea realizar primero un análisis de madurez.

Algunos profesionales creen existe un estigma alrededor de un trabajo de Análisis de Vulnerabilidades. Estos profesionales olvidan la meta es identificar riesgos en la organizaciones evaluadas. Si una compañía no está lista para una prueba de penetración completa, obtendrá de lejos más valor de un buen Análisis de Vulnerabilidades, comparado con una prueba de penetración.

Se debe establecer con el cliente por adelantado cual información será proporcionada sobre los sistemas. También puede ser de ayuda consultar por información sobre las vulnerabilidades ya documentadas. Esto ahorrará tiempo a los profesionales, además de ahorrar dinero el cliente al no superponer los descubrimientos de las pruebas con problemas conocidos. Del mismo modo una prueba de caja blanca completa o parcial podría proporciona más valor al cliente, comparado con una prueba de caja negra, si el cumplimiento no es absolutamente requerido.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Goals
https://www.pcisecuritystandards.org/

Las pruebas de estrés o denegación de servicio deben discutirse antes de empezar las pruebas. Puede ser un tema incómodo para muchas organizaciones, esto debido a la naturaleza potencialmente dañina de las pruebas. Si una organización está únicamente preocupada por la confidencialidad o integridad de sus datos, las pruebas de estrés pueden no ser necesarias; pero si la organización está preocupada sobre la disponibilidad de sus servicios, entonces las pruebas de estrés deben ser realizadas en un entorno de no producción, el cual es idéntico al entorno en producción.

Denegación de Servicio (DoS)

Un ataque para Denegación de Servicio (DoS) es un ciberataque en el cual el perpetrador busca hacer una máquina o recurso no disponibles para sus usuarios; ya sea temporalmente o indefinidamente; afectando los servicios de un host conectado hacia Internet. Típicamente la Denegación de Servicio se logra inundando la máquina o recurso con una cantidad ingente de peticiones, con el propósito de sobrecargar los sistemas, evitando o previniendo algunas o todas las peticiones legítimas sean completadas.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#DoS_Testing
https://en.wikipedia.org/wiki/Denial-of-service_attack

Muchas organizaciones requerirán se pruebe la postura de seguridad, de una manera la cual se alinee con las ataques actuales. Los ataques de Ingeniería social y Spear-Phishing son ampliamente utilizados por muchos atacantes en la actualidad. Mientras la mayoría de los ataques exitosos utilizan pretextos como sexo, drogas, etc. algunos de estos pretextos podría no ser aceptable en el entorno de la organización. Consecuentemente se debe estar seguro de cualquier pretexto elegido sea aprobado por escrito antes de iniciar las pruebas.

Ingeniería Social

Es la manipulación sicológica de las personas, para realicen acciones o divulguen información confidencial. Un ejemplo de ingeniería social es utilizarlo en la función de “olvidar la contraseña”, para un sitio web en el cual se requiere hacer login. Un sistema inadecuadamente asegurado para la recuperación de contraseñas, puede ser utilizado para otorgar a un atacante malicioso acceso completo hacia la cuenta del usuario, mientras el usuario original perdería el acceso hacia su cuenta.

Spear Phishing

El Spear-Phishing involucra a un atacar directamente a una persona u organización específica, utilizando mensajes de correo electrónico a medida para “pescar”. En contraste con el Bulk-Pishing, en el Spear-Phishing los atacantes frecuentemente obtienen y utilizan información personal sobre aquellos a atacar, incrementando así la probabilidad de un ataque exitoso. El Spear-Phishing típicamente ataca ejecutivos u aquellos quienes trabajan en departamentos financieros, los cuales tienen acceso hacia datos y servicios financieros sensibles.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Define_Accepta…
https://en.wikipedia.org/wiki/Social_engineering_(security)
https://en.wikipedia.org/wiki/Phishing#Spear_phishing

Existen una serie de situaciones donde el contrato incluirá probar un servicio o aplicación el cual se hospedada en un tercero. Esto se torna más frecuente en los recientes años, conforme los servicios en la “nube” se han convertido en algo más popular. Lo más importante es recordar, si bien el cliente ha otorgado el permiso, este no habla por sus proveedores externos. Por lo tanto se debe obtener permiso explicito de estos para probar los sistemas hospedados. Fallar en la obtención del permiso adecuado, como siempre puede traerá consigo la posibilidad de violar la ley, lo cual puede causar muchos dolores de cabeza.

Servicios en la Nube

El más grande problema con probar servicios en la nube, son los datos de múltiples organizaciones almacenándose en un medio físico. Frecuentemente la seguridad entre estos diferentes dominios de datos es muy laxa. El proveedor de servicios en la nube necesita estar alerta sobre las pruebas, y necesita conocer las pruebas suscitándose, además de otorgar el permiso a la organización para realizar las pruebas. Además necesita existir un contacto directo de seguridad dentro del proveedor de servicios de la nube, el cual pueda ser contactado en caso se descubra una vulnerabilidad de seguridad, el cual impacte a otros clientes de la nube. Algunos proveedores de la nube tienen procedimientos específicos a seguir para las pruebas de penetración, además de requerir formularios de petición, programación, o permiso explícito de ellos antes de iniciar las pruebas.

ISP

Verificar los terminos del servicio correspondiente al ISP (Proveedor de Servicio de Internet) con el cliente. En muchas situaciones comerciales el ISP tiene disposiciones específicas para las pruebas. Revisar estos terminos cuidadosamente antes de lanzar los ataques. Existen situaciones donde el ISP podría evitar o bloquear cierto tráfico el cual se considera malicioso. El cliente puede aprobar este riesgo, pero siempre debe ser comunicado claramente antes de empezar. El hospedaje web al igual de todos los demás terceros, el alcance y el tiempo de las pruebas necesita ser claramente comunicado con el proveedor del hospedaje web. También cuando se comunique con el cliente, asegurarse de claramente articular la prueba únicamente buscará vulnerabilidades web. Las pruebas podrían no descubrir vulnerabilidades en la infraestructura subyacente , el cual podría proporcionar una vía para comprometer la aplicación.

MSSPs

Los MSSP (Proveedores de Servicios para Seguridad Gestionada) también necesitan ser notificados de las pruebas. Especialmente ellos necesitan ser notificados cuando los sistemas y servicios bajo su posesión sean probados. Sin embargo existen circunstancias bajo las cuales el MSSP podría no ser noticiado. Si parte de la prueba es probar el tiempo de respuesta del MSSP, ciertamente no es lo mejor para la integridad de la prueba notificar al MSSP. Como una regla general, cada vez se pruebe un dispositivo o servicio explícitamente perteneciente al MSSP, será necesario notificarlo.

Países donde se Hospedan los Servidores

También entre los mejores intereses del profesional, está el verificar los países donde los servidores están hospedados. Después de validar el país, revisar las leyes específicas del país antes de iniciar las pruebas. No se debe asumir el equipo legal de la empresa proporcionará al equipo de pruebas una completa sinopsis de las leyes locales. Tampoco se debe asumir la empresa asumirá responsabilidad legal por cualquier violación de la ley realizado por los profesionales. Es responsabilidad de cada profesional verificar las leyes para cada región donde se realizarán las pruebas antes de iniciarlas, pues será el profesional quien finalmente deberá responder por cualquier transgresión.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Dealing_with_T…
https://aws.amazon.com/es/security/penetration-testing/
https://docs.microsoft.com/en-us/azure/security/fundamentals/pen-testing
https://support.google.com/cloud/answer/6262505?hl=en

Antes de iniciar la prueba de penetración, debe ser identificada toda la infraestructura a evaluar. Esta infraestructura debe ser obtenida desde el cliente durante la fase inicial de preguntas. La infraestructura puede ser proporcionada en la forma de direcciones IP, rangos de red, o nombres de dominio del cliente. En algunas instancias el único dato proporcionado por el cliente es el nombre de la organización, quien espera los profesionales en pruebas de penetración sean capaces de identificar el resto por si mismos. Es importante definir si los sistemas como firewalls e IDS/IPS, o equipo de red, los cuales están entre el profesional y la infraestructura final también son parte del alcance. Elemento adicionales como proveedores de servicios deben ser identificados y definir si están dentro del alcance.

Validar los Rangos

Es imperativo antes de empezar a atacar la infraestructura, validar si esta es propiedad del cliente. Se debe analizar cuidadosamente las consecuencias legales a enfrentar, si se empieza a atacar una máquina y se la penetra exitosamente, solo para descubrir más adelante la máquina pertenece a otra organización (como un hospital o una agencia del gobierno).

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Specify_IP_Ran…

Otro componente clave a enfrentar para la definición del alcance, es indicar explícitamente las fechas de inicio y finalización para realizar la Prueba de penetración. Esto permite el proyecto tenga un final definido. Una de las áreas más comunes donde ocurre al desplazamiento del alcance, es durante la repetición de las pruebas o verificaciones. Esto siempre parece una buena idea cuando se busca un contrato. Demuestra la empresa es cuidadosa y diligente, intentando asegurarse el cliente esté lo más seguro posible. El problema inicia cuando se olvida el trabajo no es pagado hasta se culmine. Lo cual incluye volver a realizar las pruebas.

Para mitigar el riesgo se sugiere agregar una declaración simple en el contrato, el cual mencione todas las pruebas o verificaciones deben ser realizadas dentro de un cierto periodo de tiempo, después de entregar el reporte final. Luego los profesionales tienen la responsabilidad de encabezar los esfuerzos de las nuevas pruebas o verificaciones. Si el cliente solicita una extensión, permitirla siempre con la condición del pago se cumpla en la fecha originalmente especificada. Finalmente, y lo más importante, realizar una prueba o verificación de calidad. Recodar la mejor fuente de trabajo futuro se basa en los clientes existentes.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Specify_Start_…

Todo lo cual no esté explícitamente abarcado dentro del alcance del contrato debe manejarse muy cuidadosamente. La primera razón para esto es el desplazamiento del alcance original. Conforme el alcance se expande se consumen recursos, lo cual reduce las ganancias para el profesional en pruebas de penetración, además incluso crea confusión y enojo en el cliente. Existe otro problema el cual muchos profesionales no consideran cuando realizan trabajos adicionales de forma ad-hoc: las ramificaciones legales.

Muchas peticiones ad-hoc no son adecuadamente documentadas, por lo cual puede ser difícil determinar quien dijo algo en el caso de una disputa o acción legal. Además el contrato es un documento legal especificando el trabajo a ser realizado. Debe estar estrechamente vinculado hacia el memo conteniendo el permiso para la prueba.

Cualquier petición fuera del alcance original debe ser documentado en la forma de una declaración de trabajo, el cual claramente identifique el trabajo a ser realizado. También se recomienda claramente declarar en el contrato, la realización de trabajo adicional deberá ser hecho considerando una tarifa por hora, además de explícitamente definir el trabajo adicional no puede ser completado hasta se haya firmado y refrendando una declaración de trabajo.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement
http://everyspec.com/MIL-HDBK/MIL-HDBK-0200-0299/MIL-HDBK-245D_1888/

En muchos casos la reunión para definir el alcance ocurrirá después del contrato haya sido firmado. También ocurren situaciones donde muchos de los temas relacionados con el alcance pueden discutirse antes de la firma del contrato, pero son pocos y distantes entre si. Para aquellas situaciones se recomienda firmar un acuerdo de no divulgación, antes de ocurra cualquier discusión a profundidad relacionado con el alcance. La meta de la reunión para definir el alcance es discutir aquello lo cual se evaluará.

Las reglas del contrato y los costos no serán abarcados en esta reunión. Cada uno de estos temas deberá tratarse en reuniones donde cada elemento sea enfocado en la reunión. Esto es realizado así porque las discusiones pueden fácilmente convertirse confusas si el enfoque no es explícitamente establecido. Es importante actuar como un moderador y mantener las discusiones en el tema, previniendo tangentes y aclarando ciertos temas sean los más adecuados para la discusión cuando sea necesario.

Establecida un (ROM) o por su traducción al idioma español; Orden de Magnitud Aproximado; para el proyecto, es momento de tener una reunión con el cliente para validar las suposiciones. Primero, es necesario establecer explícitamente cuales rangos de direcciones IP están en el alcance del contrato. No es raro el cliente se resista y asuma esto es una prerrogativa del profesional en pruebas de penetración, identificar la red y atacarla, para hacer las pruebas lo más reales posibles. Esto sería de hecho es una circunstancia ideal; sin embargo; las posibles ramificaciones legales deben ser consideradas por encima de todo. Debido a esto es responsabilidad del profesional transmitir al cliente estas preocupaciones, e impartirle la información de un alcance implícito. Por ejemplo en la reunión se debe verificar el cliente sea propietario de todos los entornos a evaluar; el servidor DNS, el servidor de correo electrónico, el hardware donde se ejecutan sus servidores web, sus soluciones de firewall/IDS/IPS, etc. Existen muchas empresas las cuales subcontratan la gestión de estos dispositivos a terceros.

Adicionalmente, se deben identificar los países, provincias, o estados, en los cuales operen los entornos a evaluar. Las leyes varían de región en región, y las pruebas pueden verse afectadas por estas leyes. Por ejemplo, países de la región europea son conocidos por tener leyes muy estrictas sobre la privacidad de las personas, lo cual cambia significativamente la manera en la cual se ejecutarían las pruebas de ingeniería social.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement
https://pmdocuments.com/how-to-develop-a-rough-order-of-magnitude-estim…

Las estimaciones sobre el tiempo están directamente enlazadas hacia la experiencia del profesional en ciertas áreas. Si un profesional tiene una significativa experiencia en un cierto tipo de prueba, probablemente pueda determinar cuanto tiempo durará la misma. Si el profesional tiene menos experiencia en el área, se sugiere leer nuevamente los mensajes de correo electrónico, además de los registros de escaneo correspondientes a las pruebas realizadas por la empresa anteriormente, las cuales sean similares comparadas con aquellas a realizar, esta una buena manera de estimar el tiempo requerido para el contrato actual. Una vez se determine el tiempo para la prueba, es prudente añadir el 20% adicional al tiempo.

El 20% adicional al final del valor correspondiente al tiempo se denomina relleno. El relleno es una necesidad absoluta para cualquier prueba. Esto proporciona un colchón en caso ocurriese alguna interrupción en la prueba. Existen muchos eventos los cuales comúnmente pueden ocurrir, y consecuentemente dificultar el proceso de la prueba. Por ejemplo un segmento de red puede desconectarse, o una vulnerabilidad significativa puede ser encontrada, la cual requiera muchas entrevistas con muchos niveles de gestión para abordarlo. Ambos de estos eventos consumen tiempo, y podrían significativamente impactar en el tiempo original estimado, si el relleno no fuese incluido.

¿Qué ocurre si el relleno del 20% no termina siendo necesario?. Facturar al cliente el tiempo no trabajado sería extremadamente no ético. Consecuentemente los profesionales deben proporcionar un valor adicional el cual normalmente no se hubiese proporcionado, si el limite en el proceso de evaluación se alcanzase. Ejemplos incluyen recorrer con el equipo de seguridad de la compañía, a través de todas las etapas realizadas para explotar las vulnerabilidades, proporcionar un resumen ejecutivo, si no formaba parte de la lista de entregables original, o invertir tiempo adicional intentando romper una vulnerabilidad difícil durante las pruebas iniciales.

Otro componente sobre las métricas del tiempo; además de las pruebas; es cada proyecto debe tener una fecha de entrega definitiva. Todos los buenos proyectos tienen un inicio y final bien definidos. Se necesita tener una declaración firmada del trabajo, especificando el trabajo y las horas requeridas si se alcanza la fecha específica para finalice la prueba, o si alguna prueba adicional o trabajo de prueba adicional es solicitado después de la fecha. Algunos profesionales tienen dificultades para hacer esto, pues perciben están siendo demasiado molestos cuando se trata de costos y horas. Sin embargo, según la experiencia, si se proporciona un valor excepcional para la prueba principal, el cliente no se negará a pagar el trabajo adicional.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement