Los frenos reales de la remediación: ¿por qué el parche existe pero nadie lo aplica?

TÉCNICO-GERENCIAL · GESTIÓN DE VULNERABILIDADES · REMEDIACIÓN

Los seis frenos de la remediación. Ninguno requiere más tecnología para resolverse. Todos requieren decisión.

Ayer planteé que la brecha entre detectar una vulnerabilidad y remediarla es donde viven la mayoría de los incidentes que después llamamos evitables. Hoy quiero bajar eso a los frenos concretos que explican por qué esa brecha existe y se mantiene en organizaciones que ya saben perfectamente lo que tienen que hacer.

Porque ese es el punto que más me interesa subrayar: en la mayoría de los casos que he analizado, el problema no es falta de conocimiento técnico. El equipo sabe cuál es la vulnerabilidad, sabe cuál es el parche, sabe cómo aplicarlo. El problema es que entre saber y hacer hay una serie de fricciones organizacionales que nadie ha resuelto formalmente, y que en ausencia de un proceso que las gestione, simplemente frenan la remediación indefinidamente.

FRENO 1: LAS VENTANAS DE CAMBIO SIN CARRIL DE SEGURIDAD

El proceso de gestión de cambios es necesario. Reduce el riesgo de interrupciones no planificadas, coordina con las áreas de negocio que dependen de los sistemas, genera trazabilidad para auditoría. No estoy cuestionando su existencia.

Lo que sí es un problema es cuando ese proceso no tiene un carril diferenciado para parches de seguridad críticos. Cuando una vulnerabilidad con CVSS 9.1 y exploit público disponible tiene que esperar la próxima ventana de mantenimiento quincenal junto con el cambio de configuración del servidor de impresión y la actualización del software de inventario, el proceso de cambio está trabajando en contra de la postura de seguridad de la organización.

Un programa maduro de gestión de vulnerabilidades define, en coordinación con el proceso de gestión de cambios, un carril de emergencia para vulnerabilidades críticas con exploit activo, y un carril expedito para vulnerabilidades altas con SLA de remediación no mayor a 72 horas desde la confirmación. Ese acuerdo entre seguridad y operaciones no es técnico: es político, requiere que alguien con autoridad en ambas áreas lo respalde, y tiene que estar documentado como una política, no como una práctica informal.

FRENO 2: LOS SISTEMAS QUE "NO SE PUEDEN TOCAR"

En casi todas las organizaciones medianas hay al menos un sistema del que alguien dice "ese no se puede tocar." A veces es el ERP que corre sobre una versión de sistema operativo que ya no recibe soporte. A veces es el sistema de control de una línea de producción que nadie quiere reiniciar porque la última vez que se reinició costó cuatro horas de inactividad. A veces es el servidor de base de datos que lleva ocho años sin una actualización mayor porque "si funciona, no lo toques."

La lógica detrás de esa postura no es irracional: cambiar un sistema estable tiene un riesgo conocido de interrupción. No cambiarlo tiene un riesgo de seguridad incierto y futuro. El patrón es el mismo que describí la semana pasada con el simulacro de continuidad.

El problema es que "no se puede tocar" en muchas organizaciones no es el resultado de un análisis formal de riesgo con controles compensatorios documentados. Es una convención cultural que se fue instalando sin que nadie la cuestionara formalmente. Cuando el sistema que no se puede tocar tiene una vulnerabilidad crítica explotable, esa convención se convierte en una exposición activa que nadie ha autorizado formalmente pero que todos están aceptando de facto.

ERROR COMÚN

Dejar la decisión de "no tocar" como una práctica implícita en lugar de formalizarla como una excepción de riesgo aceptado. La diferencia importa: una excepción documentada tiene un responsable, tiene controles compensatorios definidos (segmentación de red, monitoreo intensivo, restricción de acceso), y tiene una fecha de revisión. Una práctica implícita no tiene nada de eso. El riesgo es el mismo; la gestión no lo es.

FRENO 3: EL EQUIPAMIENTO EOL SIN DECISIÓN DE REEMPLAZO

Este freno es el más costoso y el más predecible. Cuando un dispositivo o sistema llega al fin de su vida útil de soporte, las vulnerabilidades que se descubren después ya no tienen parche del fabricante. No es que el parche tarde en llegar: es que no va a llegar.

En infraestructuras con switching Cisco EOL, con versiones de FortiOS sin soporte activo, con appliances WatchGuard fuera del ciclo de actualizaciones de seguridad, o con instancias de pfSense sobre hardware sin mantenimiento, las vulnerabilidades que aparece el escáner tienen un estado especial: conocidas, no remediables con parche, y abiertas indefinidamente hasta que alguien tome la decisión de reemplazar el activo.

Esa decisión de reemplazo requiere presupuesto que excede el operacional de TI, planificación de migración, coordinación con el negocio, y en muchos casos un proceso de evaluación y licitación que toma meses. Todo eso es razonable. Lo que no es razonable es dejar esa decisión indefinidamente en el mismo estado de "está en la agenda" en que llevaba TechCorp Latam su switching Cisco EOL durante los años previos al incidente.

El EOL no resuelto no es un problema técnico pendiente. Es una exposición activa con fecha de vencimiento desconocida, que crece con cada nuevo CVE que el fabricante ya no va a parchear.

FRENOS 4, 5 Y 6: LOS QUE NADIE NOMBRA EN LAS REUNIONES

La dependencia de proveedor es un freno que aparece especialmente en software de negocio: el ERP que tiene una vulnerabilidad en la capa de aplicación y cuya solución depende del fabricante del software, no del equipo interno de TI. El equipo sabe que la vulnerabilidad existe. No puede hacer nada hasta que el proveedor libere la actualización. Y el proveedor tiene su propio calendario. Mientras tanto, la vulnerabilidad permanece abierta.

La brecha de conocimiento es menos frecuente pero más delicada. En algunos casos el equipo técnico sabe que hay una vulnerabilidad crítica en un sistema complejo, y sabe que hay un parche disponible, pero no tiene la experiencia suficiente para aplicarlo sin riesgo de afectar el sistema. Parchear un firewall Fortinet bajo carga en producción, actualizar el firmware de un switch de core con VLANs de misión crítica, o aplicar un parche a un servidor de base de datos con réplicas activas requiere conocimiento específico que no siempre está en el equipo. Y la alternativa, aplicarlo sin ese conocimiento, puede ser peor que la vulnerabilidad.

El conflicto de prioridades es quizás el más honesto de los seis frenos. Los equipos de TI en organizaciones medianas tienen más trabajo del que pueden absorber. La remediación de vulnerabilidades compite con la migración en curso, con el soporte al usuario, con el proyecto de implementación que tiene fecha de entrega comprometida con el cliente. Cuando no hay una política que establezca la prioridad relativa de la remediación de seguridad frente a otros proyectos, siempre pierde frente a lo que tiene un deadline visible.

DECISIÓN QUE DEBE TOMAR EL CIO

Identificar cuáles de estos seis frenos están activos en la organización y cuál es el que más vulnerabilidades tiene bloqueadas. Ese diagnóstico no requiere una herramienta nueva: requiere una conversación honesta con el equipo técnico sobre qué está frenando la remediación de las vulnerabilidades que ya están identificadas. La respuesta a esa conversación define dónde hay que intervenir primero, y casi nunca es en la herramienta de detección.

¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?

Lo que tienen en común los seis frenos es que ninguno es técnico. Todos son organizacionales: procesos que no contemplan la urgencia de seguridad, convenciones culturales que nunca se formalizaron, decisiones de inversión que nadie quiere llevar a la gerencia, brechas de capacidad que nadie ha priorizado cerrar.

Y todos tienen solución. No necesariamente rápida ni barata, pero sí definible. El carril de emergencia en la gestión de cambios es un acuerdo político entre dos áreas. La excepción del sistema que no se puede tocar es un proceso de documentación y controles compensatorios. El EOL es una decisión de inversión con argumentos concretos. La dependencia de proveedor es un SLA contractual que se negocia. La brecha de conocimiento es una decisión de capacitación o de soporte externo. El conflicto de prioridades es una política de clasificación de trabajo.

Mañana voy a ver cómo medir el programa de vulnerabilidades con métricas que tengan sentido para la gerencia, no solo para el equipo técnico.

El parche que no se aplica no es un problema técnico pendiente. Es una exposición activa con fecha de vencimiento desconocida. La diferencia entre las dos formas de verlo define cómo la organización va a priorizar resolverlo.

Artículo núcleo de la semana: Gestión de vulnerabilidades: la brecha entre saber y actuar. Mañana: cómo medir el programa con métricas ejecutivas.

#GestiónDeVulnerabilidades #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #CVE #ParcheoDeSeguridad #EOL #NISTCSF #ISO27001