Una prueba de seguridad no es una linterna que ilumina una propiedad completa. Es una comparación entre un comportamiento esperado y una observación producida bajo unas condiciones concretas. Si esas condiciones, el estímulo o el criterio de éxito están mal definidos, el resultado puede ser perfectamente reproducible y, aun así, responder a otra pregunta.
Por eso una prueba positiva, una negativa y una de regresión no son tres grados de confianza. Son familias de preguntas que usan estímulos, oráculos y comparaciones diferentes. Una prueba positiva busca confirmar que un comportamiento permitido o un control esperado funciona. Una prueba negativa intenta atravesar una frontera que debería rechazar una condición inválida o no autorizada. Una prueba de regresión comprueba que un cambio no reintrodujo un fallo conocido ni rompió una propiedad que ya se había establecido. En todas ellas, el resultado sólo tiene sentido frente a su alcance, su cobertura y sus límites.
Este capítulo enseña a diseñar esas pruebas como argumentos técnicos. El objetivo no es coleccionar casos de prueba, ni convertir un scanner en juez. Es poder explicar qué condición se introdujo, qué comportamiento se esperaba, qué se observó, qué hipótesis queda apoyada y qué sigue sin evaluarse.
Una prueba compara un estímulo con un oráculo
El elemento central de una prueba no es la herramienta, sino el oráculo: la regla que permite decidir si la observación es compatible con la propiedad que se quería evaluar. La forma mínima es:
Dadas las precondiciones C, aplicar el estímulo S al sistema X y observar O. El resultado es conforme si O satisface el oráculo Q; de lo contrario, se registra una desviación con el alcance L.
El estímulo puede ser una solicitud, una configuración, una secuencia de estados, un dato límite o una condición de fallo. Las precondiciones indican identidad, permisos, versión, estado inicial, dependencia disponible y cualquier otro supuesto que haga interpretable el resultado. El oráculo no siempre es un valor exacto: puede ser una propiedad de seguridad, una invariante o una relación entre dos ejecuciones.
Por ejemplo, «el endpoint responde 403» es un oráculo pobre si no se ha definido qué principal, recurso, operación y política intervienen. Un oráculo mejor sería: «una principal autenticada como miembro del tenant B no puede leer el objeto perteneciente al tenant A; la respuesta no revela el contenido y el intento queda registrado conforme a la política». El código de estado es una observación útil, pero no agota la propiedad.
Este diseño separa tres cosas que a menudo se mezclan:
- resultado del sistema: lo que devolvió la aplicación, el dispositivo o el control;
- decisión de la prueba: la comparación con el oráculo;
- conclusión de seguridad: qué claim limitado se puede sostener a partir de la prueba y qué supuestos conserva.
Una prueba puede pasar aunque el sistema tenga una debilidad que el oráculo no cubre. También puede fallar porque el entorno está mal preparado, sin que eso pruebe una vulnerabilidad. La adjudicación debe conservar esa diferencia.
El criterio no es sólo una convención editorial: NIST SSDF PW.8.2 pide diseñar y ejecutar las pruebas y documentar sus resultados, incidencias y remediaciones (SP 800-218, PW.8.2). Esta referencia sostiene el uso de criterios y evidencia para las comprobaciones de seguridad; no convierte una prueba concreta en cobertura universal.
Aclarar la palabra «positiva»
En la práctica, positive test se usa con dos convenciones incompatibles. En una, una prueba positiva introduce una condición válida y espera que el sistema cumpla la operación. En otra, especialmente al evaluar detectores, un resultado positivo significa que se detectó el fenómeno buscado, incluso si el fenómeno es indeseado. No se debe dejar que el adjetivo decida el significado.
En este capítulo llamaremos prueba positiva de propiedad a la que ejercita el camino que debería ser permitido o funcional y confirma su contrato. Llamaremos control positivo a una condición conocida que debe producir la señal buscada en un detector. La primera pregunta por una propiedad del sistema; la segunda comprueba que el instrumento podía reconocer el fenómeno. Cada caso debe declarar su convención.
Una prueba positiva de autorización puede usar una principal con permiso explícito para actualizar un registro de su propio tenant. El resultado esperado no es sólo «200 OK»: el cambio debe aplicarse al objeto correcto, con la identidad y el contexto correctos, sin modificar otro objeto ni saltarse auditoría. Esta prueba detecta fallos de integración y confirma que el camino legítimo no quedó roto.
La prueba positiva no demuestra que la autorización sea completa. Un servicio puede aceptar correctamente el caso permitido y aceptar también un caso que debería estar prohibido. Por eso la prueba positiva necesita su pareja negativa y una selección de fronteras: otros tenants, operaciones distintas, recursos inexistentes, estados caducados y cambios de identidad.
Las pruebas negativas ejercitan la frontera
Una prueba negativa presenta una entrada, estado o identidad fuera de las condiciones autorizadas y espera que el sistema rechace, limite o aísle el efecto. El rechazo debe definirse por la propiedad, no por una preferencia de interfaz. Un error explícito puede ser conforme; una respuesta vacía también puede ser un fallo si oculta que una operación se ejecutó parcialmente.
Considérese una API que permite a una cuenta leer sus propias facturas. Los casos negativos no son una colección aleatoria de caracteres. Deben recorrer las fronteras del claim:
- una cuenta autenticada solicita una factura de otro tenant;
- una sesión válida pero sin el scope requerido intenta exportar;
- una solicitud reutiliza un identificador de objeto después de cambiar la identidad;
- una cuenta suspendida reintenta una operación ya iniciada;
- un cliente envía un formato válido pero un valor fuera del dominio permitido.
Cada caso exige una predicción causal. Si la operación debe rechazarse antes de acceder al objeto, el oráculo debe incluir ausencia de lectura, no sólo el código 403. Si la organización permite respuestas indistinguibles para evitar enumeración, el oráculo puede aceptar el mismo código para «no existe» y «no autorizado», pero debe verificar que no se filtran tamaño, tiempo o metadatos que contradigan esa propiedad. El mecanismo concreto depende de la amenaza y del diseño.
La entrada inválida tampoco equivale siempre a un ataque. Un error de serialización o una versión incompatible puede ser una condición operacional legítima. Lo que importa es que la frontera de aceptación esté especificada y que la respuesta no produzca una transición no autorizada. Nombrar todas las entradas «maliciosas» oculta el mecanismo y confunde validación defensiva con atribución.
Tanto el caso permitido como el no permitido se comparan con su oráculo; cumplir, incumplir y no concluir no dependen del nombre positivo o negativo.
Resultado positivo, resultado negativo y control
También se confunden el tipo de prueba y el resultado. Una prueba negativa puede producir un resultado positivo si detecta que la frontera fue atravesada. Una prueba positiva puede producir un resultado negativo si el camino legítimo falló. El informe debe escribir ambos explícitamente: «tipo de prueba», «resultado observado» y «decisión respecto del oráculo».
Los detectores añaden una distinción importante. Un control positivo es una muestra o situación donde el evento que el detector busca está deliberadamente presente y debe ser identificado. Un control negativo es una muestra dentro del alcance y con ese evento ausente, que no debería activar la señal. Una condición fuera de alcance se registra aparte como límite de cobertura: su silencio no es un resultado negativo ni una medida de especificidad. El control positivo muestra que la cadena de medición puede producir una detección; el negativo ayuda a descubrir contaminación, reglas demasiado amplias o una señal de fondo. Ninguno sustituye una muestra representativa del sistema real.
En una regla de detección de ejecución sospechosa, el control positivo puede ser una telemetría sintética, autorizada y claramente marcada que conserva los rasgos que la regla pretende reconocer. El control negativo debe ser actividad administrativa normal con estructura parecida, para comprobar que la regla no alerta ante cualquier ejecución. Un paquete de pruebas que sólo incluye la muestra positiva permite inflar la sensibilidad a costa de falsos positivos; uno que sólo contiene actividad normal no demuestra capacidad de detección.
La terminología debe quedar en el artefacto de prueba. Una tabla profesional puede incluir test_role: property-positive, expected_decision: allow, observed_decision: deny, oracle: ...; para una regla de detección, control_role: positive, event_present: true, detected: true. El formato exacto es secundario. Lo esencial es que nadie tenga que inferir la convención por el nombre del archivo.
Qué autoriza un resultado negativo
Un resultado negativo significa que el fenómeno no fue observado bajo el procedimiento y la cobertura definidos, o que el sistema produjo la respuesta que el oráculo consideraba rechazo. No significa automáticamente que la vulnerabilidad no exista. La conclusión depende de qué superficie, estados, identidades, entradas y versiones se cubrieron; de si el estímulo llegó al componente correcto; y de si la instrumentación podía detectar el efecto.
Supongamos que cien solicitudes negativas a una API no revelan datos de otro tenant. Eso actualiza la confianza en la separación probada. Pero no cubre endpoints no incluidos, tareas asíncronas, exportaciones, backups, cachés, consultas con otra identidad ni una versión distinta. Si el control de acceso se aplica en un gateway y existe una ruta interna que lo evita, el resultado externo puede ser correcto sin que el claim del servicio completo lo sea.
La pregunta profesional es: «¿qué clase de fallo habría sido visible para esta prueba y cuál no?». Un resultado negativo tiene fuerza cuando el procedimiento tiene sensibilidad adecuada para la condición relevante, los controles de ejecución funcionan y la población evaluada guarda relación con la decisión. La evidencia de un negativo debe registrar límites de detección, errores del entorno, casos omitidos y cualquier supuesto sobre datos o telemetría.
Cuando falla la observabilidad, no se debe registrar «sin hallazgos». Un timeout del instrumento, de la telemetría o de una dependencia que impide saber si el estímulo alcanzó el componente produce un resultado no concluyente, no un negativo. En cambio, un timeout que es el comportamiento objeto de la prueba se adjudica contra su oráculo, incluidos límite, estado y efectos laterales. El capítulo 6 desarrolla la calibración de confianza; aquí basta una regla operativa: sólo se puede adjudicar un negativo después de demostrar que la prueba pudo producir el resultado esperado y observarlo de manera íntegra.
Regresión: preservar propiedades a través del cambio
Una prueba de regresión repite una comprobación después de un cambio para detectar la reaparición de una desviación conocida o la pérdida de una propiedad que antes se sostenía. El cambio puede ser código, configuración, dependencia, esquema, infraestructura, identidad, política, modelo de datos o procedimiento de despliegue. No es sinónimo de «volver a ejecutar toda la suite».
La regresión comienza con una línea base: qué comportamiento se estableció, bajo qué versión, con qué oráculo y mediante qué evidencia. Si el cambio corrige un bypass de autorización, la prueba de regresión debe reproducir la ruta que antes atravesaba la frontera, verificar que ahora se rechaza y conservar la prueba positiva del usuario legítimo. Si sólo se confirma el rechazo, se puede haber roto la función válida; si sólo se confirma el éxito legítimo, se puede haber reabierto el bypass.
La selección debe ser proporcional al cambio y a las dependencias. Una modificación de un parser puede requerir volver a probar límites de entrada, normalización, manejo de errores y rutas que consumen la representación resultante. Un cambio de proveedor de identidad puede exigir regresión en emisión, validación, expiración, revocación, mapeo de grupos y recuperación. La lista no se obtiene sólo del archivo modificado: se obtiene del mecanismo y de las fronteras que ese cambio puede afectar.
Hay dos objetivos relacionados pero distintos:
- regresión de corrección: la condición que debía dejar de ocurrir no vuelve a ocurrir;
- regresión de seguridad colateral: el cambio no introduce una nueva manera de atravesar otra frontera ni deteriora una propiedad vecina.
La primera puede ser una prueba concreta y estable. La segunda requiere selección de casos cercanos, invariantes y, en ocasiones, revisión de diseño. Un test verde de regresión no demuestra ausencia de efectos nuevos fuera de su cobertura.
La regresión comprueba la desviación corregida, la función legítima y las dependencias seleccionadas por su mecanismo, sin cobertura universal.
Un caso completo: separación entre tenants
Un servicio de facturación tiene dos propiedades: una cuenta autorizada puede consultar sus facturas, y una cuenta de otro tenant no puede leerlas. El sistema añade una optimización de caché para reducir consultas. La prueba positiva configura una cuenta de A, solicita su factura y verifica contenido, tenant, auditoría y consistencia. Las pruebas negativas usan una cuenta de B con el mismo identificador, una identidad cambiada en la misma sesión y una solicitud a un endpoint de exportación. No basta comparar el status: el oráculo exige que el cuerpo no contenga datos de A y que no quede un estado parcial.
La regresión reproduce el caso que motivó la corrección, pero también prueba la clave de partición del caché, expiración, invalidación, concurrencia y una ruta de lectura asíncrona. La optimización podría no modificar el código de autorización y, aun así, servir una respuesta almacenada bajo un contexto equivocado. Esa es la razón para seleccionar por mecanismo, no por proximidad textual.
Una matriz sintética puede verse así:
Desliza horizontalmente para consultar todas las columnas.
La tabla no es el informe completo. Debe acompañarse de versión, datos sintéticos, evidencias, cambios entre ejecuciones, errores del entorno y casos fuera de alcance. Si N-02 no se ejecutó porque la caché gestionada no estaba disponible, la conclusión no puede incluir esa dependencia.
Diseñar una prueba que pueda fallar de forma informativa
Antes de ejecutar, escriba la predicción y su alternativa. Si se espera que una cuenta B reciba rechazo, ¿qué significa un timeout? Si el evento debe generar una alerta, ¿qué evidencia demostraría que la telemetría llegó al detector? Si una corrección debe cerrar un bypass, ¿qué control positivo muestra que la ruta legítima sigue viva?
Use datos sintéticos y estados reconstruibles. Registre quién creó cada identidad, qué política estaba activa, qué reloj y versión se usaron, qué dependencias participaron y cómo se limpiará el estado. Una prueba que no puede repetirse puede servir como señal exploratoria, pero no debería convertirse sin más en evidencia de no regresión.
La independencia entre prueba y sistema merece atención. Un test que llama a la misma función privada que quiere evaluar puede confirmar la copia de su propio error. Un simulador puede ocultar un fallo de integración que sólo aparece en la dependencia real. Los dobles de prueba son útiles para aislar una hipótesis, pero la conclusión debe nombrar el límite. La prueba de un control aislado y la validación del sistema desplegado son argumentos distintos.
Finalmente, no multiplique casos sin razón. El criterio de parada puede ser una cobertura explícita de roles, estados y fronteras, más un conjunto de controles positivos y negativos que demuestren que la prueba es capaz de detectar el fenómeno. Añadir entradas aleatorias después de agotar el mecanismo puede descubrir sorpresas, pero no sustituye un modelo de qué debería observarse.
La evidencia disponible se compara con el oráculo y permite una conclusión acotada; la falta de observación no equivale a conformidad.
Fallos frecuentes al llamar «regresión» a cualquier prueba
Repetir sólo el caso feliz. Confirma que el servicio funciona, pero no que el límite corregido siga cerrado.
Probar sólo el código de respuesta. Una respuesta 403 no demuestra que no se haya leído, transformado o filtrado el objeto.
Usar un positivo sin un negativo. El camino permitido puede funcionar mientras la frontera de autorización esté rota.
Conservar la entrada pero cambiar el oráculo. Si se relaja el criterio para que la suite pase, no se ha probado no regresión; se ha cambiado la propiedad.
Ignorar el entorno. Un falso verde puede deberse a un mock que no reproduce caché, identidad, permisos o concurrencia reales.
Confundir un fallo de infraestructura con un negativo. Si el test no llegó al componente o perdió la evidencia, el resultado es no concluyente.
Reutilizar datos que contaminan el estado. Un caso puede pasar porque una ejecución anterior dejó un permiso, caché o token que no existiría en un despliegue limpio.
Convertir una suite en garantía universal. Las pruebas muestran propiedades cubiertas bajo condiciones concretas; no convierten un sistema cambiante en «seguro» sin alcance.
De la prueba al argumento profesional
Un informe de pruebas debería permitir reconstruir el razonamiento sin leer la mente del autor. Para cada familia, registre el claim o requisito evaluado, la versión y frontera, precondiciones, estímulo, oráculo, datos y controles, resultado observado, evidencia preservada, desviaciones, cobertura, límites y decisión. Cuando un caso falla, separe la anomalía de su explicación: un fallo del oráculo, del entorno y del sistema no son la misma conclusión.
Las pruebas positivas aportan evidencia de que la función o control esperado opera en el camino ejercitado. Las negativas aportan evidencia de que una frontera rechaza condiciones concretas. Las de regresión aportan evidencia de que un cambio no reintrodujo una desviación dentro de su alcance y de que se revisaron efectos colaterales plausibles. Juntas construyen un argumento más fuerte que cualquiera aislada, pero su composición sigue dependiendo de supuestos y cobertura.
La decisión final también debe ser calibrada. «La separación entre tenants está verificada para los endpoints A y B en la versión V» es una conclusión defendible si la evidencia la respalda. «El servicio es seguro» excede la prueba, aunque todos los casos pasen. Si aparece un resultado no concluyente, se documenta como incertidumbre y se decide si el riesgo justifica repetir, ampliar o detener la evaluación.
Síntesis
Probar es hacer explícita una comparación: condiciones, estímulo, observación y oráculo. Una prueba positiva confirma el camino o propiedad que debería funcionar; una negativa ejercita una frontera que debería contener una condición no permitida; una regresión comprueba que un cambio no reintrodujo una desviación y no dañó propiedades vecinas seleccionadas. Sus nombres no determinan el significado: cada artefacto debe declarar su convención.
Un resultado negativo no es ausencia universal de vulnerabilidad. Un test verde no prueba que el modelo de amenazas esté completo. Una regresión no es repetir mecánicamente todos los casos. La fuerza de la conclusión depende de que la prueba pudiera detectar el fenómeno, de que el entorno fuera válido, de que el oráculo expresara la propiedad y de que las rutas relevantes quedaran cubiertas.
La disciplina consiste en preservar ese vínculo hasta la decisión. Cuando una prueba falla, todavía hay que decidir qué hipótesis explica el fallo. Cuando pasa, todavía hay que declarar qué fuera de alcance queda abierto. El siguiente paso natural es coordinar cómo se comunican vulnerabilidades y cómo se reparan sin convertir una observación técnica en una acusación o una promesa ilimitada.
Comprobación de comprensión
- Construye una prueba positiva y una negativa para una operación autorizada, declarando precondiciones, estímulo y oráculo. Explica por qué un código de estado no basta.
- Distingue tipo de prueba, resultado observado y decisión respecto del oráculo en un caso donde una prueba negativa detecta una lectura no autorizada.
- Diseña un control positivo y uno negativo para un detector de actividad sospechosa. ¿Qué evidencia demostraría que el detector estaba operativo?
- Una suite no encuentra fallos, pero omite exportaciones y tareas asíncronas. ¿Qué conclusión está autorizada y cuál no?
- Tras corregir un bypass de autorización, ¿qué caso original y qué pruebas vecinas incluirías en la regresión? Justifica cada vecino por un mecanismo plausible.
- ¿Por qué una caché o un cambio de dependencia puede exigir regresión aunque el archivo de autorización no haya cambiado?
- El recolector de la prueba agota su plazo esperando eventos porque la telemetría no estaba habilitada. Distingue fallo de preparación y conclusión sobre autorización. ¿Qué comprobarías antes de adjudicar?
- Redacta una conclusión calibrada para una suite verde que cubre dos endpoints, tres roles y una versión. Incluye explícitamente lo que queda fuera de alcance.
Problema de transferencia
Una plataforma de almacenamiento añade una capa de caché y modifica el middleware de autenticación. El claim es: «una principal sólo puede descargar objetos de sus propios proyectos y una revocación se hace efectiva dentro de un plazo definido». Diseña un plan que contenga pruebas positivas, negativas, controles de ejecución y regresión. Para cada caso especifica identidad, proyecto, estado de revocación, estímulo, oráculo, evidencia y límite. Explica qué combinación de resultados permitiría hablar de no regresión para las rutas cubiertas y qué observación obligaría a detener la conclusión.
Fuentes principales
- NIST. SP 800-115: Technical Guide to Information Security Testing and Assessment, §§2.1, 6.5, 7.3 y 8.2, 2008.
- NIST. SP 800-53A Rev. 5: Assessing Security and Privacy Controls in Information Systems and Organizations, metodología y procedimientos de evaluación, 2022.
- NIST. SP 800-218: Secure Software Development Framework (SSDF) Version 1.1, PW.8.2, especialmente ejemplos 1, 3 y 4, 2022.
- OWASP Foundation. Web Security Testing Guide, v4.2, estrategia y categorías de pruebas, edición congelada v4.2 utilizada aquí, no afirmación de última versión.