Un test de intrusión responde a la pregunta que figura en su alcance, y a nada más. Si el alcance dice "probar nuestra aplicación web", recibirá un informe sobre lo que a los auditores les haya parecido más interesante con el tiempo disponible, que quizá no sea lo que usted necesitaba saber.
La solución es la preparación. Decida la pregunta, las reglas, los accesos, el tratamiento de los datos y la definición de "terminado" antes de pedir presupuestos.
Empiece por la pregunta, no por el objetivo técnico
Una lista de direcciones IP y URL es una lista de objetivos técnicos, no un objetivo de negocio. El objetivo es la decisión que el test debe respaldar. NIST SP 800-115 indica que las pruebas técnicas de seguridad sirven para varios fines, como encontrar vulnerabilidades en un sistema o una red y verificar el cumplimiento de una política u otros requisitos. Son trabajos distintos y requieren pruebas distintas.
Redacte el objetivo en una frase que pueda leer un patrocinador sin perfil técnico. Algunos ejemplos:
- ¿Puede un cliente autenticado leer las facturas de otro cliente en el nuevo portal?
- ¿Puede un atacante sin cuenta llegar a la interfaz de administración del sistema de reservas?
- ¿Cumple la aplicación los requisitos de control de acceso que cita el cuestionario de seguridad de nuestro cliente?
Cada uno de ellos implica un alcance, unas cuentas y un informe diferentes. Si no es capaz de escribir una sola frase, todavía no está listo para contratar. Conviene mantener una breve llamada de definición del alcance con los auditores o con un asesor, como nuestro equipo de consultoría, antes de pedir presupuestos.
Elija una referencia para "probado"
"Totalmente probado" no significa nada hasta que se indica frente a qué se ha probado. Para aplicaciones web, dos proyectos de OWASP ofrecen un vocabulario común.
El OWASP Application Security Verification Standard (ASVS) es una base para probar los controles técnicos de seguridad de las aplicaciones web y ofrece a los desarrolladores una lista de requisitos para un desarrollo seguro. La página del proyecto indica la 5.0.0 como última versión estable. Cada requisito tiene un identificador numerado, y el proyecto recomienda citarlo junto con la versión, por ejemplo v5.0.0-1.2.5. La versión importa porque los identificadores pueden cambiar entre publicaciones.
La OWASP Web Security Testing Guide describe cómo probar. Su página indica la v4.2 como versión actual, con la 5.0 todavía en desarrollo. Indique en el contrato la versión que espera; de lo contrario, cada parte dará por supuesta una distinta.
Después, señale qué partes del ASVS entran en el alcance, por capítulo y sección tal como aparecen en la versión elegida. El identificador v5.0.0-1.2.5, por ejemplo, apunta al quinto requisito de la sección "Injection Prevention" del capítulo "Encoding and Sanitization". Elija las secciones que correspondan a su objetivo y pida que los hallazgos se asocien a identificadores de requisitos. Así, los reteses y el seguimiento por parte de los desarrolladores resultan mucho más sencillos.
Reglas de compromiso
Las reglas de compromiso (rules of engagement) son los límites escritos de lo que los auditores pueden hacer. Son recomendaciones nuestras, no algo que prescriban las fuentes, pero todo documento de alcance debería resolverlas:
| Aspecto | A decidir |
|---|---|
| Entorno | Producción, preproducción o ambos. Preproducción es más seguro, pero solo resulta útil si replica la configuración de producción. |
| Ventana | Fechas y horarios, y si se puede probar fuera del horario laboral. |
| Direcciones de origen | Las IP que usarán los auditores, para que su equipo de monitorización pueda distinguirlas de un atacante real. |
| Técnicas excluidas | La denegación de servicio, la ingeniería social y el acceso físico son exclusiones habituales. Déjelo por escrito en cualquier caso. |
| Condiciones de parada | Qué hace que los auditores se detengan: una caída del servicio, el acceso a datos personales inesperados, un hallazgo crítico. |
| Contactos | Dos personas con nombre por cada parte, con teléfonos que funcionen por la noche. |
Decida de antemano si se informará del test a su SOC. Informarle pone a prueba el proceso; no hacerlo pone a prueba la detección. Ambas opciones son válidas, pero conviene elegir de forma deliberada.
Cuentas de prueba y tratamiento de datos
Facilite cuentas, porque un auditor sin credenciales no puede examinar lo que hay detrás del inicio de sesión. Proporcione una por cada rol que tenga la aplicación, además de dos cuentas del mismo rol pertenecientes a clientes o inquilinos (tenants) distintos. Sin esa pareja, nadie puede comprobar si un usuario puede acceder a los datos de otro.
Cree las cuentas con antelación, compruebe que permiten iniciar sesión e indique cómo se gestionará la autenticación multifactor.
Acuerde en el contrato el tratamiento de los datos:
- Use datos sintéticos en preproducción siempre que sea posible. Si producción está en el alcance, indique qué registros reales pueden ver los auditores y cuáles no.
- Establezca dónde se almacenarán las evidencias, como capturas de pantalla, registros de peticiones y datos extraídos, quién puede acceder a ellas y cuánto tiempo las conservarán los auditores.
- Exija que el propio informe viaje cifrado. Es una lista de sus debilidades.
- Fije la regla para hallazgos sensibles: si los auditores encuentran datos personales, se detienen, anotan la ubicación sin copiar el contenido y llaman a su contacto.
Criterios de éxito e informe
"Ningún hallazgo crítico" no es un criterio de éxito. Premia un test superficial. Defina "terminado" como cobertura más calidad del resultado: se examinaron los requisitos acordados y cada hallazgo incluye detalle suficiente para reproducirlo y corregirlo.
NIST describe su guía como una ayuda para analizar los hallazgos y desarrollar estrategias de mitigación, además de para ejecutar las pruebas. Pida lo mismo. Cada hallazgo debería incluir los pasos de reproducción, el componente afectado, una puntuación de severidad con un método declarado para que pueda comprobarla usted mismo, y una remediación concreta. Añada al presupuesto un reteste de los hallazgos corregidos y acuerde quién acepta el informe y cuándo.
Si contrata a un proveedor como nuestro servicio de pruebas de intrusión, incluya estos puntos en el documento de alcance contractual (statement of work), y no solo en la reunión de arranque.
Por dónde empezar
- Escriba el objetivo en una sola frase y consiga que el responsable de negocio lo apruebe.
- Enumere las aplicaciones, los entornos y los roles incluidos en el alcance, e indique expresamente qué queda fuera.
- Elija la referencia: los capítulos y secciones del ASVS incluidos y una versión de la Web Security Testing Guide, todo escrito con números de versión.
- Rellene la tabla de reglas de compromiso, con los contactos, la ventana y las direcciones de origen.
- Cree y verifique las cuentas de prueba, incluidas dos cuentas del mismo rol para inquilinos distintos, y fije las reglas de tratamiento de datos.
- Incluya los criterios de éxito en el contrato: formato de los hallazgos, método de severidad, asociación con identificadores de requisitos y un reteste.
