Toda la información presentada en este sitio web es propiedad intelectual tanto de ECM Chile© como de sus partners y asociados, quienes comparten y ponen a disposición de la comunidad internacional contenido, estándares, buenas prácticas, metodologías, experiencias y opiniones de manera pública.  Alpine Security©, AIIM International©,

Sherpa Software©, Docuphase©...y muchos más

8 errores comunes al seleccionar un servicio de Pen Testing

Es común encontrar Organizaciones que han contratado servicios de Pen Testing sin recibir los resultados esperados.

En este post describiremos algunas de las situaciones más frecuentes y también recomendaciones para que el próximo Pen Test realmente sea de ayuda para su Organización.


1. No comprender exactamente qué se recibirá

Muchos proveedores de seguridad ofrecen Pen Test a precio de liquidación; los que en realidad terminan siendo una Evaluación de Vulnerabilidades.

Una Evaluación de Vulnerabilidades es parte de un Pen Test pero no es lo mismo. El Pen Test es mucho más amplio e incluye técnicas automáticas y manuales. Una Evaluación de Vulnerabilidades típicamente utiliza una herramienta de escaneo. Durante nuestros Pen Tests utilizamos herramientas de escaneo de vulnerabilidades y un sinnúmero de otras herramientas y técnicas manuales que nos permiten emular el comportamiento real de los atacantes.



2. No solicitar un Re-test

Una vez que recibe el Informe del Pen Test y su equipo remedia los hallazgos; usted debería verificar si la remediación ha sido efectiva realizando un re-test.

Muchas Organizaciones reciben un informe, "arreglan" los problemas descubiertos pero nunca validan que la remediación es realmente efectiva.

Para evitar que la validación venga en la forma de un Ataque o Brecha de Seguridad; usted debe exigir un re-test.


3. No solicitar una Carta de Certificación

Una Carta de Certificación es una prueba de que ha realizado un Pen Test con resultados claros: hallazgos, mitigación y re-test. Idealmente, luego de realizar un re-test los resultados mostrarán que no quedan hallazgos críticos, altos ni medios. Esta carta es una excelente herramienta para demostrar a clientes, partners y cualquiera que necesite una constancia de que sus sistemas han sido testeados por una entidad externa independiente.

Evite que la validación de un Pen Test venga en la forma de un Ataque o Brecha de Seguridad; usted debe exigir un Re-test.


4. Contratar a un proveedor que no tiene su proceso documentado

El proveedor de seguridad debería seguir un proceso documentado. Esto debería incluir, como mínimo: Formularios Explícitos de Autorización, Reglas de Compromiso, Autorización del Proveedor Cloud, entre otros. Las Reglas de Compromiso es uno de los documentos más críticos por que define los sistemas que serán testeados, planificación, direcciones IP/URL, procedimientos de escalamiento, puntos de contacto y mucho más.


5. ¿Black Box, Grey Box o White Box?, ¿Mix?

Black Box Pen Testing es una de las técnicas más utilizadas. Esto significa que el proveedor de seguridad solo conoce la dirección IP o URL de los sistemas. Si usted tiene Aplicaciones Web o Sistemas que requieren de acceso autenticado, entonces debería también utilizar la técnica Grey Box, que se realiza a nivel de usuario autenticado y puede descubrir vulnerabilidades que Black Box no descubriría, como por ejemplo escalamiento de permisos. White Box ayuda a prepararse para el peor de los casos: cuando el atacante es un ex-empleado descontento que tiene toda la información que necesita para lanzar un ataque.


6. No solicitar un análisis conjunto del informe

Luego de que el Pen Test ha sido realizado y el reporte entregado, usted debería recibir una explicación detallada del informe.

En tal sentido, su equipo podrá comprender todos los aspectos de los hallazgos, métodos y técnicas utilizadas, remediación, planificación del re-test y mucho más. Los informes sin acciones claras, realmente no ayudarán a su Equipo de Seguridad/TI ni a su Organización.


7. No solicitar un informe con pasos detallados y resultados reproducibles

Es común recibir informes indicando que se ha accedido a alguno de sus sistemas, pero sin explicaciones de como lo hicieron y sin reproducción de los resultados en forma clara y detallada. Sin saber exactamente que vulnerabilidad se explotó y que técnica se utilizó, es imposible corregir los sistemas o validar la remediación de manera efectiva. El consultor de seguridad debería saber exactamente como accedió a sus sistemas y presentar el proceso ampliamente documentado.


8. Enfocarse sólo en Aplicaciones Web

Existen muchas categorías de riesgo que generalmente son ignoradas, tal como: Wireless, Ingeniería Social, Dispositivos: IoT, BYOD, Impresoras, Multifuncionales, Cámaras de Seguridad y muchos más. Aviones Comerciales y todo tipo de vehículo (civil y militar), Acceso Físico, ICS - SCADA.


#cybersecurity #ciberseguridad #penetrationtest #pentesting