Cómo funciona el proceso antes de hacer un test de penetración y qué debemos preparar como empresa

Si se lo vas a presentar a un cliente corporativo, pide directamente un test de aplicación web en caja gris. La prueba de caja negra se hace desde la perspectiva de un atacante externo pero no llega a pillar los fallos de escalada de privilegios en la lógica de la aplicación. Crea sí o sí al equipo de auditoría al menos dos usuarios de prueba con niveles de acceso distintos.

Abre ahora mismo una lista y apunta todas tus IP de servidor expuestas a internet el enlace de acceso a la web app q se va a probar y el número de servicios por detrás. Si envías esta lista al pedir presupuesto, las empresas entienden el alcance al instante y el trámite se liquida en tres días.

En la fase de preparación no te saltes estos cuatro pasos: 1) Saca un backup completo de la imagen de tus servidores. 2) Pon en lista blanca en tu firewall las IP del equipo que hará el test. 3) Limita los servicios de envío de emails y SMS en el entorno de pruebas. 4) Avisa con tiempo a tu proveedor de hosting cloud sobre la fecha de la prueba.

si lo vais a hacer en entorno real tened mucho cuidado con la base de datos. mientras los auditores tiran comandos al azar en los campos de los formularios a vuestros clientes les pueden llegar sin querer cientos de facturas de prueba o sms de notificación. desactivad temporalmente los servicios de aviso durante el test.

¿Su cliente corporativo solo quiere auditar la aplicación web o también exige pruebas en la red local interna y de phishing para los empleados? Si el alcance es solo su aplicación SaaS, un presupuesto de 70.000 TL será más que suficiente.

El mes pasado hicimos una prueba para una integración de retail similar con 1 aplicación web y 6 IP externas. Tardó 5 días y en el borrador del informe salieron 2 vulnerabilidades críticas y 4 medias. Tardamos 20 días en total entre corregir los fallos y completar la prueba de reevaluación.

En el mercado hay empresas que ejecutan un escáner automático de vulnerabilidades, te sacan un PDF estándar de 100 páginas y a eso lo llaman pentest. Al pedir presupuesto, pongan sí o sí por escrito que el informe incluya verificación manual y revisión de fallos de lógica de negocio.

En resumen: saquen su inventario de IP y URL, acuerden una metodología de caja gris, creen un entorno de pruebas con su copia de seguridad y confirmen que el precio incluye la prueba de reevaluación. El proceso suele cerrarse del todo en un mes.

Yo también estaba pensando en lo mismo. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

También me gustaría saber si alguien lo hace de otra manera.

Voy a detallar un poco el aspecto técnico. Si el camino de la notificación es largo la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Ánimo.

Es correcto en general pero falta un detalle. El error cometido por cómo hacer una prueba de penetración suele ser reversible pero caro.

La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación. Comprobado por experiencia.

Tomo nota, gracias.

Guardado.

El año pasado nos pasó casi exactamente lo mismo. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Lo dejo como nota, por si sirve.

No te olvides de: Una copia de seguridad no probada no es una copia de seguridad.

Eso es todo, disculpa si me he extendido demasiado.

Llevé mucho tiempo con este asunto. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

El punto que más se pasa por alto sobre cómo hacer una prueba de penetración es este: La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Por supuesto, cambia si tu situación es diferente.

Totalmente. Si tuviera que añadir algo más: El tiempo que tardas en detectar un problema determina directamente su coste.

Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.