Falsos positivos, comprobar antes del ticket

La mayoría de los falsos positivos nacen de la detección por versión. El servicio anuncia una versión que está en la lista de versiones vulnerables, el escáner marca el fallo, y resulta que esa versión llevaba el parche aplicado por detrás sin cambiar el número —algo habitual cuando el sistema operativo corrige el fallo y mantiene el número de versión del paquete, la llamada retro-adaptación del parche—. El escáner no mintió: dedujo de lo único que vio, el banner, y el banner no contaba toda la historia.

Entender el origen es lo que te dice dónde mirar para confirmar: no en el banner otra vez, sino en el estado real del parche dentro del activo. Y ahí es donde el escaneo autenticado gana al no autenticado.

Confirmar un hallazgo no es explotarlo —este oficio no entra en los sistemas—. Se confirma comprobando: entrar con el escaneo autenticado a leer la versión real del paquete y su estado de parche, revisar la configuración concreta que el fallo necesita, o ver si el servicio siquiera corre. En Ferranova, un hallazgo marcado sobre el servidor de correo se confirma leyendo, con credenciales, si el paquete tiene aplicada la corrección —no lanzándole el exploit para ver si cae—. La diferencia importa: explotar puede tumbar el servicio y sale del alcance de la gestión de vulnerabilidades.

La regla del oficio es que se confirma con evidencia de estado, no con una prueba de concepto ofensiva. Confirmar sin explotar es más seguro y casi siempre suficiente.

Un falso positivo que llega a ticket no es gratis. El dueño del sistema pierde tiempo investigando un fallo que no existe, y —peor— aprende que tus tickets no siempre son ciertos. La próxima vez que le mandes uno real, lo tratará con la misma desconfianza que ganaron los falsos. La credibilidad del analista es su herramienta de trabajo: sin ella, la remediación (que ya es la fase que se atasca) se atasca más. Por eso se comprueba antes de abrir, no después de que el dueño se queje.

Filtrar falsos positivos no es perfeccionismo: es proteger el único mecanismo que tienes para que te hagan caso. Un analista que manda ruido se queda sin voz.

Cuidado con confundir dos cosas que terminan igual —«no se abre ticket»— por motivos opuestos. Un falso positivo es un hallazgo que no existe: se comprobó y el fallo no está. Un riesgo aceptado es un hallazgo que sí existe pero que, por una decisión consciente, no se va a parchear ahora. Marcar como falso positivo algo que sí existe es peligroso: lo borras del radar y nadie vuelve a mirarlo, cuando en realidad seguía ahí. La etiqueta tiene que decir la verdad de por qué se cierra.

En Ferranova, el fallo del servicio de base de datos detenido de srv-respaldo se cierra —pero como hallazgo sin servicio detrás que lo sostenga, no inventando que no existe—. La precisión de la etiqueta es lo que deja rastro para quien lo revise después.

Confirmar sin explotar es leer el estado real del parche. Abre el laboratorio de Ferranova y aísla el hallazgo de la web pública detectado por versión que, al comprobarlo autenticado, resulta tener el parche aplicado. La nota de ese hallazgo trae un código de la sala.