Gestión de vulnerabilidades: priorizar lo que sí importa

Ningún equipo corrige todas las vulnerabilidades que su escáner reporta, y perseguir ese objetivo garantiza atender las equivocadas. La pregunta útil no es cuántas hay, sino cuáles son alcanzables desde fuera y están siendo explotadas hoy.

A continuación: por qué la lista siempre crece, cómo se prioriza de verdad, qué exige criterio y cómo se sostiene el proceso.

El primer escaneo serio de una organización produce un número que paraliza: miles de hallazgos, muchos marcados como críticos. La reacción habitual es pedir un plan para corregirlos todos.

Ese plan no se cumple, y su incumplimiento tiene un efecto secundario peor que el original: el equipo deja de mirar la lista porque sabe que es inabarcable.

Por qué la lista siempre crece

Se publican vulnerabilidades nuevas todos los días, y cada componente que la organización usa aporta las suyas. El inventario crece con el negocio y el catálogo de fallos crece con el tiempo.

A eso se suma que una misma vulnerabilidad aparece repetida en cada equipo afectado, así que el conteo bruto describe el tamaño del parque más que el tamaño del riesgo.

Y la severidad publicada es genérica por diseño: describe qué tan grave sería el fallo en el peor escenario posible, sin saber nada del contexto donde está instalado.

Cómo se prioriza de verdad

Por exposición. Un servicio alcanzable desde internet y otro accesible sólo desde un segmento interno controlado no representan el mismo riesgo aunque compartan el mismo fallo. La exposición cambia el orden más que la severidad.

Por explotación observada. Que exista una técnica de explotación conocida y en uso activo cambia la urgencia por completo. Una vulnerabilidad grave sin explotación conocida puede esperar a la ventana de mantenimiento; una moderada que se está explotando, no.

Por criticidad del activo. El mismo fallo en el sistema del que vive la operación y en una estación de trabajo de uso ocasional no merecen el mismo lugar en la cola.

Por existencia de mitigación. Cuando no se puede parchear de inmediato, a veces se puede reducir la exposición: cerrar un puerto, restringir el acceso, deshabilitar una función. Esa opción debería evaluarse junto al parche, no después.

Lo que exige criterio

La decisión de aceptar un riesgo es del negocio y debe quedar registrada con responsable y fecha de revisión. Un riesgo aceptado y documentado es una postura defendible; uno aceptado por omisión es un hallazgo pendiente sin dueño.

También hay que decidir la ventana de corrección por categoría. Comprometer plazos iguales para todo produce incumplimiento generalizado; plazos diferenciados por exposición y criticidad se cumplen y se pueden auditar.

Y conviene resistir la métrica del conteo total. Un número que baja porque se corrigieron miles de hallazgos irrelevantes en estaciones de trabajo puede convivir con la exposición externa intacta.

Qué cambia según el activo

La infraestructura tradicional admite ventanas de mantenimiento planificadas y un ciclo de parcheo relativamente ordenado.

Las aplicaciones propias dependen de sus componentes de terceros, y ahí el trabajo no es parchear sino actualizar dependencias, lo que exige pruebas y coordinación con desarrollo.

Y los servicios en nube reparten la responsabilidad: parte la asume el proveedor y parte queda del lado del cliente, según el tipo de servicio. Suponer que el proveedor cubre todo es una de las omisiones más frecuentes y menos visibles.

Cómo se sostiene el proceso

Empiece por el inventario, porque no se puede priorizar lo que no se sabe que existe. Un escáner sobre un inventario incompleto entrega una lista tranquilizadora y falsa.

Defina y publique los plazos por categoría, y mida el cumplimiento de esos plazos en lugar del conteo total. Ese indicador es el que muestra si el proceso funciona.

Y automatice lo repetitivo: la distribución de parches conocidos y de bajo riesgo, la verificación de que se aplicaron y el reporte. El tiempo del equipo debe ir a las decisiones difíciles, no a la administración de la lista.

Qué se necesita antes

Un inventario de activos con responsable, una clasificación de criticidad acordada con el negocio y una ventana de mantenimiento pactada. Sin la tercera, cada corrección se negocia individualmente y el proceso se detiene.

Conviene además tener claro quién decide cuando parchear implica interrumpir. Esa decisión no es del equipo de seguridad ni del de operaciones por separado, y sin un mecanismo acordado se resuelve por quien insista más.

El hallazgo que suele faltar en el reporte

Los escáneres reportan lo que saben consultar, y por eso el informe describe el parque conocido. Lo que rara vez aparece es lo que nadie registró: un servidor levantado para una prueba, un servicio expuesto por una regla temporal que quedó, una aplicación que un área contrató por su cuenta.

Esos activos no salen en la lista y son, con frecuencia, los más expuestos, precisamente porque nadie los administra ni los actualiza.

Por eso conviene complementar el escaneo interno con una vista desde fuera: qué se ve de la organización desde internet sin credenciales. Ese ejercicio suele encontrar menos hallazgos que el escáner y más relevantes.

¿Hay que corregir todas las vulnerabilidades?

No es alcanzable ni útil como objetivo. Conviene priorizar por exposición, explotación observada y criticidad del activo, y registrar de forma explícita lo que se acepta.

¿La severidad publicada no basta para priorizar?

No. Describe la gravedad en el peor escenario posible, sin conocer el contexto. Un fallo grave en un sistema aislado puede importar menos que uno moderado expuesto a internet.

¿Qué indicador conviene seguir?

El cumplimiento de los plazos comprometidos por categoría, no el conteo total. El total puede bajar corrigiendo hallazgos irrelevantes mientras la exposición externa sigue intacta.

¿Quién responde por las vulnerabilidades en la nube?

Depende del tipo de servicio: parte la asume el proveedor y parte queda del lado del cliente. Suponer que el proveedor cubre todo es una de las omisiones más frecuentes.