Falso positivo

Toda detección se puede evaluar cruzando dos preguntas: qué dijo la herramienta y qué pasaba en realidad. De ahí salen cuatro casillas, y solo dos son aciertos.

Verdadero positivo: avisó y había algo. Verdadero negativo: no avisó y no había nada. Esos dos son el trabajo bien hecho, aunque solo el primero se nota.

Falso positivo: avisó y no había nada. Falso negativo: no avisó y sí había algo. Los dos son errores y no son intercambiables: el falso positivo cuesta tiempo, el falso negativo cuesta el incidente entero.

Y aquí está el nudo del asunto, porque los dos errores están unidos por un mismo mando. Bajar el umbral de una regla para no perderse nada dispara los falsos positivos; subirlo para tener paz produce falsos negativos. No hay una posición que elimine los dos, así que el trabajo no es eliminarlos, sino decidir a conciencia cuál de los dos se prefiere en cada regla, y por qué.

Reglas que describen la forma y no la intención. Una firma que busca una cadena de texto o un patrón de tráfico no sabe para qué se estaba usando. La misma herramienta de administración remota es normal en manos del equipo de sistemas y es un problema en manos de otro.

El entorno de cada empresa. Una regla que funciona bien en una organización llena otra de alertas, porque aquí hay un proceso nocturno que copia ficheros en masa y allí eso solo lo hace un atacante. Las reglas que vienen de fábrica no conocen tu casa, y ese ajuste no lo hace nadie por ti.

Firmas y configuraciones desactualizadas. Una regla escrita contra una versión antigua de una aplicación sigue disparando cuando la aplicación cambia de comportamiento por motivos legítimos.

Escáneres que deducen en vez de comprobar. Muchas herramientas de análisis marcan una vulnerabilidad porque el número de versión que anuncia el servidor está en una lista, sin comprobar si el fallo es realmente explotable ahí. Es correcto como aviso y no es un hallazgo, y confundir las dos cosas es lo que llena los informes.

Una alerta falsa cuesta el rato de descartarla. Un flujo constante de alertas falsas cuesta algo distinto y mucho peor: que el equipo aprenda que abrir alertas no compensa. A eso se le llama fatiga de alertas y no es un problema de actitud, es la respuesta razonable a un sistema que casi siempre se equivoca.

El daño no se ve mientras ocurre. Se ve después, cuando en la revisión de un incidente aparece que la señal estaba ahí, que se generó a tiempo, y que estaba enterrada entre otras doscientas que no eran nada. Un SOC con demasiado ruido no falla por falta de herramientas.

Hay un segundo coste, menos comentado: los falsos positivos deforman las prioridades. Si el listado de vulnerabilidades tiene un tercio de cosas que no son, el orden en que se arreglan las cosas deja de significar nada, y la gestión de vulnerabilidades se convierte en la gestión de una hoja de cálculo.

Aquí el término cambia un poco de sentido y conviene separarlo. Un escáner puede acertar en lo que ve y equivocarse en lo que concluye: la versión es la que dice, el CVE existe, y aun así el fallo no se puede aprovechar en ese sistema porque el componente afectado no está en uso o hay algo delante que lo impide.

Eso no es un fallo del escáner, es su límite. Una herramienta automática mide exposición potencial; solo alguien que lo intente puede decir si esa exposición es real. Por eso CVSS describe la severidad teórica de un fallo y no lo que ese fallo significa en tu red, y por eso EPSS añade la probabilidad de que se explote pero tampoco sabe cómo está montada tu casa.

Y existe el reverso, que se nombra menos y duele más: el falso negativo del escáner. Los fallos de lógica de negocio y los que hace falta encadenar no tienen firma ni versión, así que ninguna herramienta los marca. Un informe con cero hallazgos generado por una herramienta no dice que no haya nada: dice que la herramienta no vio nada.

Ajustar contra lo normal de esta empresa. Antes de escribir excepciones hay que saber qué es normal aquí: qué procesos corren de noche, qué administrador usa qué herramienta, qué tráfico sube los lunes. Sin esa base, cada excepción es un agujero abierto a ciegas.

Escribir las reglas con contexto y no solo con firma. De eso trata la ingeniería de detección: tratar las reglas como código, con su hipótesis, sus pruebas y su revisión, en vez de acumular alertas heredadas que nadie se atreve a tocar.

Automatizar el descarte, no el criterio. Un SOAR puede enriquecer una alerta y cerrar por sí solo la que cumpla una condición comprobable. Lo que no se automatiza es la decisión de qué merece mirarse.

Medir. Cuántas alertas se cierran como falso positivo, cuáles son las cinco reglas que más generan y cuánto tiempo se va en ellas. Sin ese número la conversación es de impresiones, y la regla ruidosa sigue ahí porque nadie sabe cuál es.

Y buscar en vez de esperar. El threat hunting parte de una hipótesis y no de una alarma, así que encuentra precisamente lo que las reglas no cubren. Es el contrapeso natural del falso negativo.

Un sistema de detección de intrusiones está configurado para reconocer patrones de tráfico asociados a una denegación de servicio. Un lunes por la mañana salta la alerta: volumen muy por encima de lo habitual contra el mismo servicio.

El equipo empieza a responder. Al revisar el origen aparece que el tráfico viene de rangos propios y coincide con una campaña de correo que marketing lanzó esa mañana. No había ataque: había clientes.

La alerta fue un falso positivo, pero el fallo no estaba en la regla, sino en lo que la regla no sabía. Nadie le había contado que existiera un lunes así. El arreglo tampoco es desactivarla, porque entonces el ataque de verdad tampoco se vería: es darle contexto, y de paso, que la próxima campaña se avise antes de lanzarla. Este ejemplo es ilustrativo y no describe a ningún cliente.

En nuestro pentesting web el criterio es que lo que entra en el informe se ha conseguido, no se ha deducido. Cada hallazgo va con los pasos para reproducirlo y con la evidencia de lo que se obtuvo, y lo que no se ha podido demostrar se dice como lo que es: una observación, con esa palabra delante.

Es más trabajo que exportar la lista de una herramienta, y es la diferencia entre un documento que ordena el trabajo del año y uno que lo entierra. Y por eso el retest forma parte del servicio: comprobar el arreglo con la misma prueba que encontró el fallo es lo único que cierra el asunto.