Vulnerabilidades: parchear primero lo que ya se está explotando

Un análisis de vulnerabilidades suele devolver cientos de avisos. Si todos parecen urgentes, ninguno lo es, y el equipo técnico acaba parcheando por orden de aparición. Priorizar por riesgo cambia la pregunta: no qué fallos existen, sino cuáles pueden hacernos daño esta semana.

Cuando la lista no tiene fin

Una vulnerabilidad es un fallo en un programa o en un equipo que un atacante podría aprovechar para entrar, robar datos o detener un servicio. Los fabricantes las descubren y corrigen a diario, y las herramientas de análisis las detectan en tu red con eficacia implacable. El resultado es un informe largo, lleno de códigos y colores, que a menudo nadie sabe por dónde empezar a leer.

La tentación es ir de arriba abajo, o atacar primero lo que el informe marca en rojo. Pero la puntuación de gravedad que acompaña a cada fallo describe lo peligroso que podría ser en teoría, no lo probable que es que alguien lo use contra ti. Para eso hace falta contexto.

Cuatro preguntas que ordenan la cola

Con estas cuatro preguntas, una lista inabarcable se convierte en un plan:

• ¿Se está explotando ya? El catálogo de vulnerabilidades explotadas de la agencia estadounidense CISA, conocido como KEV, es una referencia pública y gratuita. Si un fallo aparece ahí, hay atacantes usándolo, y sube al principio de la cola.
• ¿Está expuesto a internet? Un fallo en el firewall, la VPN o un servidor web publicado es mucho más urgente que el mismo fallo en un equipo interno, porque cualquiera puede intentar alcanzarlo.
• ¿Qué hay en ese equipo? No pesa igual el servidor de facturación que un ordenador de la sala de reuniones.
• ¿Hay forma de mitigarlo mientras tanto? A veces se puede desactivar una función o limitar quién accede mientras llega el parche.

Cruzar estas respuestas produce algo muy distinto al informe original. Imagina dos avisos con la misma puntuación: uno en la VPN, que figura en el catálogo KEV; otro en un programa interno que nadie usa desde fuera. El primero es una urgencia de días. El segundo puede esperar a la ventana mensual sin que nadie pierda el sueño.

Parchear no es una carrera contra la lista, sino contra el atacante.

Un calendario que se pueda cumplir

Funciona mejor un ritmo estable que las carreras puntuales tras cada noticia alarmante. Un esquema razonable podría ser este:

1. Lo explotado y expuesto, en días.
2. Lo crítico interno, dentro del ciclo mensual de actualizaciones.
3. El resto, en ventanas planificadas, con aviso previo a quien pueda verse afectado.

Los plazos concretos dependen de cada empresa. Lo importante es que estén escritos, que dirección los conozca y que se cumplan. Un plazo que nadie respeta es peor que no tenerlo, porque da una falsa sensación de control.

Una aclaración útil: priorizar no significa olvidar. Lo que hoy queda al final de la cola sigue ahí, y conviene revisarlo cada cierto tiempo, porque un fallo que ayer era teórico puede aparecer mañana en el catálogo de explotación activa. La lista se recalcula, no se archiva. Por eso tiene sentido repetir el análisis con regularidad y volver a pasar las cuatro preguntas cada vez que algo cambie.

Los rincones que nadie revisa

Los fallos más peligrosos suelen estar en equipos que no aparecen en ningún inventario. Un servidor antiguo que «nadie usa» pero sigue encendido. Un NAS, el disco de red donde alguien guarda copias. Los switches y puntos de acceso, a los que casi nunca se les actualiza el software. O el propio software de seguridad, que también tiene fallos y también necesita parches.

Estos equipos tienen algo en común: no se actualizan solos y no reciben atención hasta que algo se rompe. Por eso la gestión de vulnerabilidades empieza siempre por saber qué tienes. Sin inventario, el análisis solo ve lo que alguien recordó incluir.

Lo que conviene contar a dirección

El número total de avisos impresiona, pero no dice si la empresa está mejor o peor que el mes pasado. Para dirección son mucho más útiles dos indicadores sencillos:

• Cuánto tarda en corregirse lo crítico, desde que se detecta hasta que está resuelto.
• Cuántos equipos quedan fuera de los ciclos de parcheo, porque son los que acumulan riesgo en silencio.

Esas dos cifras, seguidas mes a mes, dicen mucho más que un informe de doscientas páginas. Y permiten tomar decisiones: renovar un equipo que ya no recibe actualizaciones, acordar una ventana de mantenimiento fija o retirar un servicio publicado que nadie necesita.

Cómo lo enfocamos

En OLATIC combinamos inventario, análisis periódico y una cola de trabajo priorizada con estas cuatro preguntas. Revisamos cada semana lo que entra en el catálogo de explotación activa, aplicamos los parches por ventanas acordadas contigo y te enseñamos cada mes cuánto se ha tardado en cerrar lo importante. Así el parcheo deja de ser una lista infinita y pasa a ser un proceso con fechas.