Penetration test

Un proyecto tiene cuatro partes y la primera no es técnica. El alcance decide qué entra, qué queda fuera, cuál es el objetivo y qué se le permite hacer a quien prueba, y se escribe como rules of engagement con personas de contacto con nombre a los dos lados. Ese documento existe para que a las tres de la mañana alguien pueda contestar si el tráfico que está mirando somos nosotros.

Después vienen el reconocimiento y la enumeración: averiguar qué existe de verdad, que con frecuencia no coincide con lo que el cliente cree que existe. Después las pruebas propiamente dichas, donde los hallazgos se confirman explotándolos y no deduciéndolos. Y después el informe, que es el entregable, y que se juzga por si un desarrollador o un administrador puede actuar sobre él sin tener que llamar para preguntar.

La metodología cambia según el objetivo. Una prueba de aplicación web recorre la autenticación, la autorización objeto a objeto, el tratamiento de la entrada, la lógica de negocio y el lado del cliente. Una prueba interna parte de una posición de red y avanza hacia el directorio. Una prueba cloud mira la identidad y las políticas antes de mirar las cargas de trabajo. Lo constante es que un hallazgo no se informa hasta haberlo demostrado, y que cada hallazgo lleva su reproducción.

La ventana de tiempo es una restricción de verdad y hay que decirlo como tal. Una prueba dice qué se encontró en el tiempo disponible, contra el alcance acordado, con el acceso facilitado. No dice que el sistema sea seguro, y cualquier informe que dé a entender lo contrario está vendiendo de más.

La forma más común de que un proyecto rinda menos de lo que podría es un alcance dibujado alrededor de lo cómodo en vez de alrededor de lo alcanzable. La aplicación entra y el proveedor de identidad que hay delante no. Una filial se excluye y tiene un enlace de red con la central. Un atacante no respeta el alcance, así que cada exclusión es una declaración de que un riesgo concreto no se va a medir, y como tal tiene que constar en el informe.

El segundo son las credenciales. Probar una aplicación autenticada sin cuentas para cada rol es probar el formulario de acceso y llamarlo prueba de aplicación. Casi todos los hallazgos serios de las aplicaciones modernas son fallos de autorización, y a ninguno se llega sin al menos dos cuentas de cada nivel.

El tercero es el retest. Un informe es una lista de cosas que eran ciertas en una fecha. Sin retest, nadie sabe si la corrección funcionó, y encontramos con regularidad que una remediación cerró exactamente el parámetro informado y dejó el mismo fallo en otros tres. Un retest que solo verifica la instancia informada es un producto más pobre que uno que comprueba si se atendió la clase entera.

El cuarto es tomar el informe por el resultado. El resultado es el cambio. Un informe que ordena hallazgos sin decir qué cambio único cierra la mayoría de ellos es técnicamente correcto e inútil en la práctica, y es buena parte de la razón de que el pentesting tenga fama de producir documentos en vez de mejoras.

Hay dos comparaciones que deciden casi todas las compras de este mercado, y merece la pena poner las dos una al lado de la otra. La primera es frente a un análisis de vulnerabilidades: se venden como productos parecidos a precios distintos y contestan preguntas distintas.

Los dos son complementarios, no alternativos. El escaneo continuo dentro de la gestión de vulnerabilidades mantiene bajo control lo conocido y parcheable. El pentesting encuentra lo que un escáner no sabe reconocer: autorización rota, lógica que se puede abusar, y cadenas donde tres problemas anodinos se combinan. Una organización que solo hace lo segundo está probando un parque cuya higiene básica nunca midió.

La segunda comparación es frente a un red team, y la respuesta cambia lo que se compra.

El requisito de la última fila es el que más se saltan los clientes. Lanzar un red team contra una organización sin capacidad de detección produce una confirmación cara de algo que ya se sabía. Primero pentesting, después ingeniería de detección y después emulación de adversarios es el orden que produce valor en cada paso.

Comprar un escaneo y llamarlo prueba. Si no se demostró nada, no se probó nada.

Excluir producción. Los entornos de prueba se diferencian de producción en configuración, datos e integraciones, que son justo las cosas que producen hallazgos.

Probar una vez al año pase lo que pase. Una prueba después de una entrega grande te habla de esa entrega. Una fecha del calendario te habla del calendario.

Juzgar un informe por su longitud. Las medidas útiles son si cada hallazgo lleva su reproducción, si la severidad está justificada en este contexto, y si las recomendaciones son específicas del sistema en vez de genéricas.

No corregir la clase. Remediar la instancia informada y no el patrón garantiza el mismo hallazgo el año que viene con otro parámetro.

Prepáralo. Facilita cuentas de todos los roles, documentación de la API, un entorno de prueba que refleje producción y una persona de contacto técnica con nombre que pueda contestar una pregunta el mismo día. La parte de un proyecto que se va en problemas de acceso es tiempo que no se dedica a encontrar nada.

Dibuja el alcance por riesgo y no por comodidad, y cuando haya que excluir algo, anota por qué en el informe para que el riesgo residual quede a la vista de quien lo lea más adelante.

Pide la ruta de ataque y no solo la lista de hallazgos. La página más valiosa de un informe interno suele ser la que enseña el camino desde un usuario corriente hasta el objetivo, porque identifica el paso único cuya eliminación rompe la cadena entera.

Acuerda el retest desde el principio, y acuerda que cubra la clase de problema y no el parámetro exacto. Después, devuelve lo encontrado al sitio del que salió: una clase de hallazgo que se repite es un problema de proceso, y sale más barato arreglarlo en el proceso que en el código.

Cuando una regulación exija las pruebas, dilo al fijar el alcance. El ENS, ISO 27001 y DORA esperan evidencia de un tipo concreto, y darle al proyecto la forma que la produce no cuesta nada si se decide al principio y sale caro después.

El informe es la evidencia de auditoría, y los auditores le hacen siempre las mismas preguntas: qué estaba dentro del alcance, cuándo se hizo, quién lo hizo, qué se encontró, con qué severidad y qué pasó después. Un informe que responde a las cinco primeras y no a la sexta deja al cliente montando el registro de remediación por su cuenta, así que estructuramos los hallazgos para que ese registro salga solo.

Cada hallazgo lleva su reproducción, el impacto observado en este entorno y una recomendación específica del sistema probado. La severidad se argumenta desde lo que alcanzamos, no se afirma desde una tabla, y cuando citamos una puntuación decimos en qué se basa. No publicamos una distribución de gravedades de la casa, porque sería un número sin población detrás.

Cada alcance necesita su proyecto, y la evaluación práctica de una aplicación de cara al cliente es la que más se pide, normalmente porque es la parte del parque que da la cara ante los clientes.

¿Qué diferencia hay entre un pentesting y un escaneo de vulnerabilidades? Un escaneo informa de lo que reconoce a partir de una base de problemas conocidos, con falsos positivos que hay que triar. Un pentesting confirma la explotabilidad, encuentra fallos de lógica y de autorización que ningún escáner reconoce, y encadena problemas entre sí. Responden preguntas distintas y casi todas las organizaciones necesitan los dos.

¿Cada cuánto hay que hacer un pentesting? Después de un cambio importante, y con la cadencia que exijan tus obligaciones. Lo habitual en cumplimiento es anual; encaja mal en un sistema que entrega todas las semanas, donde probar ligado a las entregas grandes más escaneo continuo entre medias es el arreglo más honesto.

¿Un pentesting garantiza que estamos seguros? No, y cualquier informe que lo afirme está equivocado. Dice qué se encontró en el tiempo disponible, contra el alcance acordado, con el acceso facilitado. Cambia cualquiera de esas tres cosas y cambia el resultado.

¿Hacemos un pentesting o un red team? Un pentesting si quieres encontrar y arreglar vulnerabilidades a lo ancho. Un red team si ya tienes detección y respuesta que merezca la pena medir y quieres saber si funcionan. Hacer lo segundo antes que lo primero suele producir una repetición cara de lo que ya sabías, y un ejercicio de purple team es muchas veces el mejor paso intermedio.