Gestión de vulnerabilidades: del análisis a la corrección

Casi todas las pymes que encargan su primer análisis de vulnerabilidades acaban en el mismo punto: un informe con cientos de líneas, mucho rojo en la primera página y nadie con tiempo para leerlo entero. El problema rara vez está en la herramienta que genera ese informe. Está en lo que ocurre después. La gestión de vulnerabilidades es un ciclo operativo que empieza en el análisis y solo se cierra cuando alguien comprueba que el fallo ya no está ahí.

Un informe todavía no es gestión de vulnerabilidades

Un análisis de vulnerabilidades te dice qué encuentra una herramienta, en un momento concreto, contra los sistemas a los que la has apuntado. Ese es el punto de partida. La gestión empieza cuando ese listado se convierte en decisiones: qué se corrige esta semana, qué espera al próximo mantenimiento, qué se asume de forma consciente y con justificación escrita, y quién responde de cada línea.

La diferencia se nota al mes siguiente. Si repites el análisis y aparecen exactamente los mismos hallazgos, lo que tienes es un informe recurrente. Si la lista baja y lo que queda tiene responsable y fecha, tienes un proceso.

Sin inventario no hay ciclo

No puedes corregir lo que no sabes que tienes. En una empresa de 10 a 50 empleados, la lista real de activos casi siempre es más larga que la documentada:

• Servidores propios y máquinas en cloud, incluidas las que se levantaron para una prueba y siguen encendidas.
• Ordenadores y portátiles del equipo, con su sistema operativo y el software instalado en cada uno.
• La web corporativa, la tienda, el portal de clientes y cualquier API publicada.
• Servicios en la nube contratados por un departamento sin pasar por informática.
• Firewalls, routers, NAS, impresoras y cámaras conectadas a la red.

Cada activo necesita dos datos además del nombre: quién lo usa y qué ocurre en el negocio si deja de funcionar dos horas. Con eso ya puedes priorizar sin abrir un debate cada vez.

Triaje: de cientos de hallazgos a una lista de trabajo

La puntuación que trae el informe mide la gravedad técnica de un fallo en abstracto, sin saber nada de tu empresa. Tu prioridad real depende del contexto, y tres preguntas ordenan casi cualquier lista:

1. ¿Es alcanzable desde internet? El mismo fallo pesa mucho más en un servicio publicado que en una máquina interna sin salida directa.
2. ¿Hay explotación conocida y circulando? Una vulnerabilidad con código de explotación público y activo se trata antes que otra teóricamente más grave pero sin explotación práctica.
3. ¿Qué hay detrás del sistema afectado? Datos personales, facturación, credenciales de administración o acceso a la red interna cambian por completo el orden.

Con esas tres respuestas, un listado de cientos de líneas se convierte en algo manejable: unas pocas que se tocan esta semana, un grupo mediano para el próximo mantenimiento y una cola larga que se revisa por lotes. Esa reducción es la parte que ninguna herramienta hace por ti.

Cada línea necesita un responsable y una fecha

Un hallazgo asignado a «sistemas» no está asignado. Tiene que llevar el nombre de una persona concreta y una fecha de compromiso, aunque esa persona lo único que haga sea abrir el ticket al proveedor que mantiene el ERP o el hosting. Ese matiz es el que separa una lista que baja de una que se hereda de un trimestre a otro.

En una pyme, buena parte de las correcciones dependen de terceros: el proveedor del software de gestión, la empresa que administra los servidores, el fabricante del firewall. Anota también su plazo de respuesta, porque forma parte de tu tiempo de exposición aunque el trabajo no lo hagas tú.

Ventanas de parcheo y qué hacer cuando no hay parche

Parchear cuando toca, con una ventana acordada y un plan de vuelta atrás, evita el otro fallo clásico: aplicar una actualización un viernes por la tarde y pasar el fin de semana recuperando el servicio. Un calendario que funciona en empresas pequeñas combina una ventana mensual para lo ordinario y un procedimiento de excepción, con menos firmas y más rapidez, para lo que no puede esperar.

A veces sencillamente no hay parche: software descatalogado, una aplicación a medida cuyo desarrollador ya no está disponible, una máquina de producción que no se puede reiniciar. En ese caso la respuesta es la mitigación:

• Aislar el sistema en un segmento de red separado del resto.
• Restringir el acceso a las direcciones y usuarios que realmente lo necesitan.
• Poner un segundo factor de autenticación delante del servicio.
• Aumentar la monitorización de ese activo y revisar sus registros.

Una mitigación se documenta con fecha de revisión. Si no la lleva, se convierte en una excepción permanente que nadie recuerda haber aprobado.

Verificar la corrección: nada se cierra por correo

Un hallazgo no está resuelto porque alguien conteste «ya está parcheado». Está resuelto cuando un nuevo análisis del mismo activo deja de encontrarlo. Entre esas dos cosas caben muchos casos reales: un parche aplicado en el servidor equivocado, un servicio que no se reinició, una configuración que la actualización devolvió a su valor por defecto.

Ese cierre verificado es lo que distingue un servicio de gestión de vulnerabilidades de una revisión suelta. También es lo que te deja evidencia usable cuando un cliente grande te manda su cuestionario de seguridad y pregunta con qué frecuencia revisas tus sistemas y cuánto tardas en corregir. Una auditoría de seguridad anual complementa ese ciclo con una mirada más amplia, aunque no lo sustituye.

El ritmo importa más que la herramienta

La superficie expuesta cambia sola: se publica una versión, se contrata un servicio nuevo, alguien abre un puerto para depurar una incidencia y se olvida de cerrarlo. Por eso un ciclo mensual con verificación vale más que un informe anual de doscientas páginas, por muy completo que sea.

Si además publicas software con frecuencia, el análisis periódico se queda corto entre versiones y conviene apoyarlo con pentest continuo, que prueba cada despliegue en lugar de esperar a la siguiente foto del sistema.

Cómo empezar sin bloquear al equipo

1. Cierra el inventario de lo que está expuesto a internet. Es el trabajo de una tarde y ordena todo lo demás.
2. Haz un primer análisis y quédate solo con lo alcanzable desde fuera y con explotación conocida.
3. Asigna responsable y fecha a esas líneas, incluidas las que dependen de un proveedor.
4. Fija la ventana de mantenimiento mensual y el procedimiento de urgencia.
5. Vuelve a analizar y cierra solo lo que ya no aparece.

A partir del segundo ciclo el volumen baja y el trabajo deja de ser una emergencia. Ese es el objetivo: que la lista de vulnerabilidades sea una tarea de mantenimiento previsible y no la señal de alarma que llega el día que alguien las encuentra antes que tú.