blog

Las buenas pruebas de penetración no simplemente verifican por cuales sistemas no tienen aplicados los parches. También prueban las capacidades de la organización en evaluación. Con este propósito, se presente a continuación un listado de elementos a comparar durante las pruebas.

• Capacidad para detectar y responder a la captura de información
• Capacidad para detectar y responder a la obtención de huellas
• Capacidad para detectar y responder a los escaneos y análisis de vulnerabilidades
• Capacidad para detectar y responder a infiltración (ataques)
• Capacidad para detectar y responder a la agregación de datos
• Capacidad para detectar y responder a la exfiltración de datos

Cuando se rastrea esta información, se debe asegurar de recolectar información sobre el tiempo. Por ejemplo si un escaneo es detectado, se debe notificar y anotar cual nivel de escanea se estaba realizando en ese momento.

Fuentes:

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

Mientras el alcance define aquello lo cual se evaluará, las reglas del contrato definen como se realizarán las pruebas. Estos son dos aspectos diferentes los cuales necesitan ser manejados independientemente el uno del otro.

Cronología

Debe ser establecida una clara cronología para el contrato. Mientras el alcance define el inicio y final del contrato, las reglas del mismo definen todo lo cual existe en el medio. Debe entenderse la cronología podría cambiar conforme progrese la evaluación. Sin embargo tener una cronología rígida no es la meta de crear una. En lugar de esto, el tener una cronología implementada para el inicio de la prueba, permitirá todos los involucrados identifiquen más claramente el trabajo a realizar y quienes serán las personas responsables del mencionado trabajo. Los diagramas de GANTT y estructuras para el Desglose del Trabajo, son frecuentemente utilizados para definir el trabajo, y la cantidad de tiempo para cada elemento específico invertido en el trabajo. Ver el cronograma dividido de esta manera ayuda a aquellos involucrados a identificar donde los recursos necesitan ser aplicados, además ayudan al cliente a identificar muchos de los posibles obstáculos los cuales son encontrados durante las pruebas.

Existen un número de herramientas gratuitas disponibles en Internet para gráficos GANTT. Muchos gerentes se identifican cercanamente con estas herramientas. Debido a esto son un medio excelente para comunicarse con la alta gerencia de la organización en evaluación.

Ubicaciones

Otro parámetro importante de cualquier contrato es establecer anticipadamente con el cliente, los destinos hacia los cuales los profesionales necesitarán viajar durante las pruebas. Esto podría ser tan simple como identificar hoteles, o algo complejo como identificar las leyes aplicables a un país específico.

Es frecuente una organización opere en múltiples ubicaciones y regiones, además será necesario elegir algunos sitios seleccionados para las pruebas. En estas situaciones se debe evitar viajar hacia todas las ubicaciones del cliente, en lugar de esto se debería determinar si están disponibles conexiones VPN hacia los sitios para realizar las pruebas remotamente.

Exposición de Información Sensible

Mientras una de las metas de un contrato puede ser ganar acceso hacia información sensible, cierta información no debería ser visualizada o descargada. Esto parecería extraño para los nuevos profesionales, sin embargo existen un número de situaciones donde los profesionales no deberían tener los datos en su posesión. Por ejemplo PHI (Personal Health Information), bajo el Acta HIPPA, estos datos deben ser protegidos. En algunas situaciones los sistemas pueden no tener un firewall o antivirus protegiéndolos. En este tipo de situación, se debe evitar absolutamente los profesionales estén en posesión de cualquier Información para la Identificación Personal (PII).

Sin embargo, si los datos no pueden ser obtenidos físicamente o virtualmente; ¿Cómo se puede probar los profesionales obtuvieron acceso hacia la información?. Este problema ha sido resuelto de diferentes maneras. Existen maneras de probar las puertas de las bóvedas han sido abiertas sin tomar el dinero. Por ejemplo una captura de pantalla del esquema de la base de datos y los permisos del archivo, o los archivos por si mismos pueden ser mostrados sin abrirlos, siempre no exista PII visible en los nombres de archivos por si mismo.
Cuan cuidadosos deben ser los profesionales en un contrato, es un parámetro el cual necesita ser discutido con el cliente, pero la firma haciendo las pruebas debe siempre asegurarse de protegerse en un sentido legal independiente de la opinión del cliente. Más allá de las supuesta exposición de datos sensibles, todas las plantillas de reporte, las máquinas para las pruebas, deben limpiarse después de cada contrato. Como una anotación especial, si datos ilegales (como explotación infantil) es descubierto por los profesionales, los oficiales encargados de hacer cumplir la ley deben ser notificados inmediatamente, seguido por el cliente. No seguir las instrucciones del cliente.

Manejo de Evidencia

Cuando se maneja evidencia de una prueba y las diferentes etapas del reporte, es increíblemente importante tener mucho cuidado con los datos. Siempre utilizar encriptación y limpiar las máquinas entre las pruebas. Nunca entregar memorias USB con los reportes de las pruebas en conferencias sobre seguridad. Y nunca reutilizar los reportes correspondientes a la evaluación de un cliente como una plantilla. Es poco profesional dejar referencia hacia otra organización en el documento.

Reuniones Regulares sobre el Estado

A través del proceso de pruebas es crítico tener reuniones regulares con el cliente, para informarle sobre el progreso global de la prueba. Estas reuniones deben realizarse diariamente, y deben ser tan cortas como sea posible. Las reuniones deben limitarse a tres conceptos; avances, progreso, y problemas.

Los planes son generalmente discutidos de tal manera las pruebas no sean realizadas durante un cambio importante o una interrupción. El progreso es simplemente una actualización hacia el cliente sobre aquello completado. Los problemas deben ser también discutidos en la reunión, pero en el interés de la brevedad, las conversaciones concernientes a las soluciones casi siempre deben mantenerse fuera de linea.

Hora del Día para Probar

Algunos clientes requieren todas las pruebas sean realizadas fuera de los horarios comerciales. Esto puede significar hasta altas horas de la noche para muchos profesionales. Los requerimientos para la hora del día deben ser bien establecidos con el cliente antes de iniciar las pruebas.

Lidiar con los Rechazos

Existen algunos momentos donde el rechazo es perfectamente aceptable, y existen momentos donde esto podría no encajar con el espíritu de las pruebas. Por ejemplo si la prueba es de tipo caja negra, donde se está probando no solo la tecnología, sino también las capacidades del equipo de seguridad de la organización, el rechazo podría estar perfectamente bien. Sin embargo, cuando se está evaluando un gran número de sistemas en coordinación con un gran equipo de seguridad en la organización, puede no ser lo mejor para las pruebas rechazar los ataques.

Permiso para la Prueba

Uno de los documentos más importantes necesarios de ser obtenidos para una prueba de penetración, es el documento con el permiso para la prueba. Este documento establece el alcance, además contiene una firma la cual reconoce el conocimiento sobre las actividades de los profesionales. Además debe establecer claramente las pruebas pueden conducir hacia la inestabilidad del sistema, además de todo el cuidado será aplicado por el profesional para no afectar los sistemas en el proceso. Sin embargo las pruebas pueden conducir a la inestabilidad, el cliente no responsabilizará al profesional por cualquier inestabilidad o falla del sistema. Es critico las pruebas no empiezan hasta este documento sea firmado por el cliente.

Además algunos proveedores de servicio requiere un aviso o permiso por adelantado, antes de probar sus sistemas. Si esto es requerido debe formar parte del documento.

Consideraciones Legales

Algunas actividades comunes en las pruebas de penetración pueden violar las leyes locales. Por esta razón se sugiere verificar la legalidad de las tareas habituales de la prueba de penetración, en la localización donde el trabajo será realizado. Por ejemplo las llamadas VoIP capturadas en el transcurso de una prueba de penetración, pueden ser consideradas como escuchas telefónicas en algunas áreas.

Fuentes:

http://www.pentest-standard.org/index.php/Pre-engagement#Rules_of_Engag…
https://en.wikipedia.org/wiki/Gantt_chart
https://www.cdc.gov/phlp/publications/topic/hipaa.html

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/