Uno de los errores más peligrosos en ciberseguridad es confundir un PDF lleno de gráficos verdes con una infraestructura segura. Le das al botón de escanear, la herramienta hace su magia, escupe un informe de 200 páginas y, como no hay vulnerabilidades críticas a la vista, el equipo respira aliviado.
Pero la realidad técnica es mucho más terca. Un escáner de vulnerabilidades es una herramienta fantástica para automatizar el trabajo sucio, pero es esencialmente «tonto»: no tiene contexto, no entiende el negocio y sufre de una preocupante miopía frente a ataques complejos.
Para sacar valor real a estas herramientas y no convertirlas en simples generadores de burocracia, necesitas entender exactamente cómo funcionan por debajo, dónde brillan, qué puntos ciegos tienen por diseño y por qué pasar un escáner no es, ni será nunca, lo mismo que hacer un pentesting.
Índice de contenidos
El mito del informe en verde
Un escáner de vulnerabilidades es, en su forma más básica, un motor que compara lo que ve en tu red con una base de datos de firmas conocidas (como los CVEs). Hace preguntas tipo: «¿Qué versión de SSH corre en el puerto 22? Ah, la 7.2. Mi base de datos dice que la 7.2 tiene esta vulnerabilidad. Lo anoto».
El problema de este enfoque es la falsa sensación de seguridad. Si el escáner no detecta un problema, no significa que tu sistema sea inexpugnable; simplemente significa que la herramienta no encontró ninguna coincidencia en su catálogo para los vectores de ataque preprogramados.
Es una linterna que ilumina un pasillo oscuro: te mostrará los obstáculos evidentes, pero no te dirá si el suelo está a punto de ceder.
Qué detecta realmente un escáner (y lo hace bien)
No todo son malas noticias. Para mantener la higiene básica y media de una infraestructura, los escáneres son insustituibles. Ningún equipo humano debería perder tiempo buscando a mano lo que estas herramientas detectan en segundos.
CVEs conocidos, parches faltantes y software obsoleto
Es su especialidad. Identifican versiones de sistemas operativos, servicios web, bases de datos o librerías que tienen vulnerabilidades públicas documentadas y parches oficiales que el equipo de IT aún no ha aplicado.
Configuraciones por defecto y exposición básica
Son excelentes detectando despistes de hardening. Si te has dejado unas credenciales de fábrica (admin/admin) en un router, si tienes un puerto Telnet abierto al exterior, si un servicio está usando algoritmos de cifrado débiles (como SSLv3 o TLS 1.0) o si hay directorios expuestos sin protección, el escáner lo marcará en rojo inmediatamente.
Escáner de red vs. Escáner de aplicaciones: No son lo mismo
Uno de los errores de concepto más habituales, especialmente en pymes o equipos generalistas, es lanzar un escáner de infraestructura (como Nessus, OpenVAS o Qualys) contra la IP de una aplicación web y pensar que la web está segura.
- Escáner de red (Infraestructura): Evalúa el contenedor. Busca puertos abiertos, servicios corriendo (Apache, Nginx, MySQL), versiones del sistema operativo y fallos a nivel de red o protocolo.
- Escáner de aplicaciones (DAST): Evalúa el contenido. Herramientas como Burp Suite Professional, OWASP ZAP o Acunetix interactúan con la lógica web. Inyectan payloads en los formularios, manipulan cabeceras HTTP y buscan inyecciones SQL (SQLi), Cross-Site Scripting (XSS) o problemas de autenticación.
Si pasas un escáner de red a un WordPress vulnerable, te dirá que el servidor Ubuntu y el Nginx están actualizados. Se marchará feliz sin darse cuenta de que el formulario de contacto permite volcar la base de datos entera. Usa la herramienta adecuada para el objetivo adecuado.
El matiz que lo cambia todo: Escaneo autenticado vs. no autenticado
Lanzar un escáner desde fuera, sin credenciales, equivale a mirar la fachada de una casa y deducir si es segura comprobando si la puerta principal está cerrada. Detectarás lo que ve un atacante externo, pero te dejarás el 80% de los problemas reales.
El escaneo autenticado (proporcionando al escáner credenciales de SSH, WMI o acceso a la aplicación) cambia las reglas del juego. Permite a la herramienta entrar al sistema operativo, leer el registro de Windows, listar los paquetes locales instalados (como librerías de Java o módulos de Python que no exponen su versión al exterior) y evaluar las políticas de contraseñas locales.
Si quieres reducir tu superficie de ataque real, el escaneo autenticado no es opcional, es obligatorio.
La zona ciega: Las limitaciones técnicas (Qué NO detecta)
Aquí es donde el criterio del analista debe suplir las carencias del software. Un escáner automatizado jamás encontrará lo siguiente:
Fallos lógicos de negocio (Business logic flaws)
Imagina un e-commerce donde, al interceptar la petición web, puedes cambiar el parámetro precio=50.00 a precio=0.01 y la pasarela de pago lo acepta. Para el escáner, la petición HTTP es perfectamente válida. No hay inyección de código, no hay error de sintaxis. El escáner no sabe qué es «dinero» ni «fraude», por lo que este fallo crítico pasará totalmente desapercibido.
Zero-days y vulnerabilidades no documentadas
Si la vulnerabilidad fue descubierta hoy por un grupo de atacantes y aún no existe un CVE oficial ni una firma en la base de datos de tu proveedor, el escáner pasará por encima del servicio vulnerable sin emitir ni un solo warning.
Cadenas de ataque (Attack chaining)
Las herramientas analizan vulnerabilidades de forma aislada. Pueden detectar tres problemas catalogados como «Severidad Baja» e ignorarlos. Un atacante humano, o un Red Team, sabrá que combinando esa fuga de información baja, con un bypass de directorio medio, puede lograr una ejecución de código crítica. El escáner carece de ese pensamiento lateral.
Falsos positivos y falsos negativos: La pesadilla del analista
El día a día de un operador de ciberseguridad se resume en pelear contra las alucinaciones de estas herramientas.
Falsos positivos: El ruido que oculta el peligro
Ocurren cuando el escáner marca una vulnerabilidad que en realidad no es explotable. El ejemplo clásico: el Backporting en Linux. Un escáner lee el banner de un servidor Debian y ve «Apache 2.4.41». Su base de datos dice que esa versión es vulnerable y dispara una alerta crítica.
Sin embargo, el mantenedor de Debian ha parcheado la vulnerabilidad en esa misma versión sin cambiar el número (backporting). El sistema es seguro, pero el escáner, al basarse solo en la versión del banner, te acaba de hacer perder dos horas investigando un problema inexistente.
Falsos negativos: El silencio fatal
Ocurren cuando el sistema es vulnerable, pero el escáner no lo ve. A menudo sucede porque hay un WAF (Web Application Firewall) o un IPS (Intrusion Prevention System) bloqueando las peticiones ruidosas del escáner.
La herramienta recibe un «403 Forbidden», asume que el servicio es seguro y pasa a otra cosa, cuando en realidad el WAF solo está bloqueando la firma del escáner, no un ataque real y sigiloso.
Frecuencia de escaneo: ¿Cada cuánto hay que darle al botón?
La respuesta genérica es «depende», pero en la práctica necesitas una estrategia en capas:
- Perímetro externo (Exposición a Internet): Escaneo continuo o semanal. Cualquier puerto nuevo abierto por error en el firewall debe detectarse en horas, no a final de mes.
- Infraestructura interna: Mensual o quincenal, sincronizado con tu ciclo de gestión de parches (por ejemplo, después del Patch Tuesday de Microsoft).
- Aplicaciones (AppSec): Integrado en el pipeline CI/CD. El escaneo (SAST/DAST) debe lanzarse con cada subida de código o nuevo despliegue.
- Escaneos bajo demanda: Obligatorio después de cualquier cambio mayor en la arquitectura de red o tras instalar un nuevo servicio.
Buenas prácticas: Checklist para no engañarte al escanear
Si quieres que tu programa de gestión de vulnerabilidades funcione, aplica estos principios:
- Contexto antes que CVSS: Un fallo «Crítico» (CVSS 9.8) en un servidor de pruebas aislado en una VLAN sin salida a internet es menos prioritario que un fallo «Medio» (CVSS 5.0) en el firewall perimetral. No parchees a ciegas basándote solo en el color de la alerta.
- Triage manual obligatorio: Nunca pases un informe bruto exportado de la herramienta directamente al equipo de Sistemas o Desarrollo. Verifica los falsos positivos antes; si les envías ruido constante, perderán la confianza en tus alertas y dejarán de parchear.
- Gestiona las excepciones: Si un riesgo no se puede mitigar porque el software legacy de fábrica no lo soporta, documéntalo, asume el riesgo formalmente y aplica controles compensatorios (como aislar la máquina en la red), pero sácalo del radar para no ver la misma alerta durante tres años.
Conclusión
Un escáner de vulnerabilidades es el equivalente a un corrector ortográfico: te salvará de errores obvios y te evitará pasar vergüenza en las configuraciones básicas, pero no escribirá una buena novela por ti, ni detectará si el argumento de tu aplicación no tiene sentido.
Úsalo para automatizar la higiene tecnológica, aplícalo con credenciales siempre que sea posible y, sobre todo, recuerda que el verdadero valor de la ciberseguridad empieza exactamente en el punto donde la herramienta se detiene… o la IA tome el testigo.
