Falsos positivos y validación sin explotar

Un falso positivo es un hallazgo que el escáner reporta y que, mirado de cerca, no existe: la versión era distinta, el parche sí estaba aplicado o la herramienta se equivocó en algo. Un falso negativo es lo contrario: una vulnerabilidad real que el escáner no reportó. El primero cuesta tiempo y credibilidad si llega al cliente; el segundo cuesta seguridad, y por eso nunca se concluye que un equipo está limpio solo porque la lista sale corta.

Algunos falsos positivos nacen de la propia corrida. Si el reloj del equipo del consultor está adelantado, un certificado vigente aparece como caducado. Lee la evidencia del hallazgo que se detectó comparando una fecha con el reloj del escáner y contrástala con la fecha real de la corrida.

Muchas distribuciones corrigen una vulnerabilidad sin cambiar el número de versión: aplican la corrección a la versión antigua, un parche retroportado, y el banner sigue anunciando el número de siempre. Un escáner que se fía del banner reporta una vulnerabilidad que ya no está. Por eso la lista de paquetes y su registro de cambios son mejor evidencia que lo que el servicio dice de sí mismo.

Cantera firmó que la validación es por lectura y no por explotación. No es una limitación arbitraria: lanzar un exploit en un servidor en producción puede causar la caída que el escaneo se esforzó por evitar. Comprobar una vulnerabilidad casi siempre se puede hacer de otra forma, comparando versiones instaladas, leyendo configuración o revisando si el parche aparece aplicado.

Un hallazgo validado termina en uno de tres estados: confirmado, falso positivo o no concluyente. Lee la evidencia del equipo de la bodega, la de SMBv1, y decide qué estado le toca. No hace falta más información que la que dejó la lectura con la cuenta de escaneo.