Una prueba de penetración se paga por días. Cada día que los pentesters pasan esperando una cuenta, intentando adivinar cómo debe comportarse una funcionalidad o bloqueados por su propio firewall es un día que no dedican a buscar vulnerabilidades. La mayor parte de esa espera puede eliminarse antes del inicio.
Decidir
¿Cuál es la pregunta? «¿Es seguro lanzar el nuevo flujo de pago?» y «¿Qué puede hacernos alguien desde internet?» llevan a pruebas distintas. Escriba la pregunta en una sola frase; el alcance se deriva de ella.
¿Qué está dentro del alcance y qué no? Enumere las aplicaciones, las direcciones, los entornos. Enumere también las exclusiones: el proveedor de pagos, los sistemas de la empresa matriz, el servicio heredado que se cae en cuanto alguien lo mira.
¿Qué entorno? La mejor opción es un entorno de preproducción que se corresponda con producción: los pentesters pueden ser exhaustivos y no hay nada real en juego. Si solo existe producción, acuerde el horario y las técnicas prohibidas.
¿Cuánto saben los pentesters? Las pruebas con cuentas y documentación encuentran más por día que las pruebas a ciegas. Las pruebas a ciegas responden a una única pregunta, muy acotada: qué consigue alguien de fuera sin ninguna información. Decida por cuál de las dos paga.
Preparar
Cuentas. Una por cada rol, y en dos inquilinos (tenants) separados si el producto tiene inquilinos: el control de acceso entre clientes no puede probarse con un solo cliente. Créelas antes del inicio, inicie sesión una vez con cada una y compruebe que tienen datos realistas.
Documentación. Especificaciones de la API, un diagrama de la arquitectura, una descripción de los roles y de los principales flujos de trabajo. Unos documentos imperfectos son mejores que ninguno.
Acceso. Si el entorno de pruebas está detrás de una VPN o de una lista de direcciones permitidas, organice el acceso con antelación y pruébelo. Decida si el firewall de aplicaciones web permanece activo. Si el objeto de la prueba es la aplicación, deje pasar a los pentesters a través de él; si lo es el firewall, déjelo activo e indíquelo.
Datos. Cargue en el entorno de pruebas datos que se parezcan a los reales en la estructura y no en el contenido. Los datos personales reales en un entorno de pruebas son un hallazgo antes de que la prueba haya empezado.
Copias de seguridad. Confirme que el entorno que se va a probar puede restaurarse. Los pentesters son cuidadosos; las copias de seguridad son para el caso en que el cuidado no haya bastado.
Avisar
Al equipo de operaciones y al de monitorización, salvo que la prueba tenga por objeto evaluarlos a ellos. Facilíteles las direcciones de origen de los pentesters y las fechas. De lo contrario, el primer día termina con los pentesters bloqueados y un incidente abierto.
Al proveedor de alojamiento o de nube, cuando su política lo exija. Los grandes proveedores de nube no exigen aviso previo para que usted pruebe sus propios recursos dentro de las reglas que publican; las empresas de alojamiento más pequeñas a menudo sí.
A los proveedores cuyos sistemas se vean afectados. Hace falta su consentimiento por escrito.
A una persona de contacto, localizable durante el horario de pruebas y con autoridad para tomar decisiones: ampliar la vigencia de una cuenta, reiniciar un servicio, detener la prueba.
Firmar
- el acuerdo de confidencialidad (NDA), antes de entregar nada de lo anterior;
- el contrato;
- la carta de autorización y las reglas de enfrentamiento.
Para qué sirve cada uno se explica en Qué hace legal una prueba de penetración.
Durante la prueba
- No despliegue en el entorno que se está probando sin avisar a los pentesters. Un hallazgo que desaparece de un día para otro cuesta un día de confusión.
- No corrija hallazgos a mitad de la prueba, salvo los de gravedad crítica. Si corrige alguno, dígalo.
- Responda rápido a las preguntas. Un pentester que pregunta cómo debe comportarse una funcionalidad normalmente ha encontrado algo.
- Cuente con recibir de inmediato los hallazgos urgentes. Una vulnerabilidad crítica se comunica en cuanto se confirma, no en el informe final.
Después de la prueba
- Lea el resumen con la dirección y los hallazgos con los ingenieros. Están escritos para lectores distintos.
- Asista a la reunión de presentación de resultados. Es la hora más barata del proyecto.
- Planifique las correcciones por prioridad y avise a los pentesters cuando estén desplegadas.
- Aproveche el retest. Una corrección que no se ha verificado es una suposición.
- Mantenga la confidencialidad del informe. Hasta que las correcciones estén aplicadas, es un manual para atacarle. Para clientes y auditores está la carta acreditativa (attestation letter).
La lista de verificación
| Antes del inicio | Hecho |
|---|---|
| Pregunta y alcance por escrito, exclusiones incluidas | |
| Entorno elegido, ventanas de pruebas acordadas | |
| Cuentas creadas para cada rol, en dos inquilinos si el producto tiene inquilinos | |
| Documentación entregada | |
| Acceso de red organizado y probado | |
| Datos de prueba preparados, sin datos personales reales | |
| Copias de seguridad verificadas | |
| Operaciones, monitorización y proveedores avisados | |
| Persona de contacto designada | |
| NDA, contrato, carta de autorización y reglas de enfrentamiento firmados |
La página de cada servicio indica qué necesita de usted esa prueba en concreto.