ESTRATEGIA · GESTIÓN DE VULNERABILIDADES · DECISIONES TI
Hay algo que me llama la atención cuando reviso el estado de seguridad de organizaciones que ya tienen herramientas de escaneo de vulnerabilidades implementadas. El escáner corre. El reporte se genera. Los CVEs están clasificados por severidad. Y en el dashboard de gestión hay vulnerabilidades críticas que llevan semanas, a veces meses, sin que nadie las haya cerrado.
El problema no es que no sepan. Es que saber no es suficiente para que algo ocurra.
Esa distancia entre detectar una vulnerabilidad y tomar la decisión de remediarla es donde vive la mayoría de los incidentes que analizamos después y llamamos "evitables." Evitables no porque nadie lo viera venir, sino porque alguien lo vio venir y la organización no tomó la decisión de actuar a tiempo.
LA ILUSIÓN DEL DASHBOARD
Implementar una herramienta de gestión de vulnerabilidades genera, en muchas organizaciones, una sensación de control que no siempre corresponde con la realidad operacional. El hecho de que las vulnerabilidades estén visibles, clasificadas y registradas crea la impresión de que están siendo gestionadas. Pero visibilidad no es gestión. Un dashboard con 200 CVEs abiertos no protege nada por sí solo.
Esta distinción parece obvia enunciada así. En la práctica, la confusión es frecuente y tiene consecuencias concretas: equipos que destinan tiempo y presupuesto a implementar herramientas de detección sofisticadas, pero que no tienen un proceso real de remediación con responsables definidos, plazos comprometidos y métricas de seguimiento. La detección está resuelta. La respuesta a lo que la detección encuentra, no.
Lo que hace que este problema sea especialmente costoso es que los atacantes no tienen ese mismo problema de proceso. Cuando una vulnerabilidad crítica se publica, el tiempo entre la publicación del CVE y la disponibilidad de un exploit funcional se ha reducido drásticamente en los últimos años. Las organizaciones que no tienen un proceso de remediación ágil están operando con una ventana de exposición que crece mientras sus ticketers de vulnerabilidades acumulan pendientes.
¿POR QUÉ LA DECISIÓN DE REMEDIAR ES MÁS DIFÍCIL DE LO QUE PARECE?
La remediación de vulnerabilidades rara vez es un problema técnico puro. El parche existe. El procedimiento para aplicarlo es conocido. El equipo técnico sabe lo que hay que hacer. El problema es que aplicar el parche requiere tocar sistemas en producción, y tocar sistemas en producción en la mayoría de las organizaciones requiere una cadena de decisiones que no siempre fluye con la velocidad que el riesgo de seguridad demanda.
Las ventanas de cambio son el primer freno. Muchas organizaciones tienen procesos formales de gestión de cambios que definen cuándo y cómo se pueden modificar sistemas productivos. Esos procesos existen por razones válidas: reducir el riesgo de interrupciones no planificadas, coordinar con áreas de negocio, documentar los cambios para auditoría. Pero cuando el proceso de cambio no tiene un carril diferenciado para parches de seguridad críticos, la vulnerabilidad espera la próxima ventana de mantenimiento como cualquier otro cambio. Y la próxima ventana puede estar a dos semanas.
El segundo freno es la tolerancia al riesgo de interrupción. Parchado un sistema puede generar incompatibilidades, puede requerir un reinicio, puede afectar temporalmente el servicio. Frente a esa posibilidad concreta y cercana, el riesgo de seguridad abstracto y futuro pierde urgencia en la evaluación de quien tiene que autorizar el cambio. El mismo patrón que describí la semana pasada con el simulacro de continuidad aparece aquí: el costo conocido de hoy frena la acción sobre el riesgo incierto de mañana.
El tercer freno, y el más difícil de resolver con un proceso, es el equipamiento EOL. Un sistema operativo que ya no recibe parches del fabricante, un dispositivo de red con firmware sin soporte, una aplicación cuya versión no se puede actualizar sin una migración mayor. En esos casos no hay parche que aplicar. La remediación requiere una decisión de inversión que excede el presupuesto operacional de TI y que nadie quiere llevar a la gerencia sin una urgencia más concreta que "es una buena práctica actualizarlo."
TechCorp Latam tenía switching Cisco con más de 12 años de antigüedad en estado EOL. Era una vulnerabilidad conocida, documentada, que aparecía en cualquier evaluación de riesgo mínimamente seria. Y estaba en la agenda de reemplazo desde hacía tiempo sin que el reemplazo ocurriera. La decisión de invertir en la renovación no llegó de un proceso de gestión de vulnerabilidades. Llegó del ransomware. Y en ese punto, la renovación costó significativamente más de lo que habría costado planificada.
LO QUE DISTINGUE DETECTAR DE GESTIONAR
Un programa real de gestión de vulnerabilidades no termina en el reporte del escáner. Tiene cuatro elementos que la mayoría de las implementaciones parciales que veo no tienen completos.
El primero es priorización con criterio de negocio, no solo de severidad técnica. Un CVE con CVSS 9.8 en un sistema que no tiene exposición externa y procesa datos no críticos no tiene el mismo impacto real que un CVE con CVSS 7.2 en el firewall perimetral o en el servidor de autenticación. La severidad técnica es un insumo; la priorización tiene que cruzarla con exposición, criticidad del activo y posibilidad real de explotación.
El segundo es un SLA de remediación por nivel de criticidad, con responsables nominados y seguimiento activo. Sin ese SLA, la vulnerabilidad queda en el dashboard indefinidamente con nadie que tenga la obligación formal de cerrarla.
El tercero es un proceso de excepción documentado para los casos donde la remediación no es posible en el plazo definido: porque el sistema es EOL, porque el parche genera incompatibilidades, porque la ventana de cambio no puede adelantarse. La excepción no elimina el riesgo; lo registra, lo asigna a un responsable y define cuándo se revisará.
El cuarto es métricas que lleguen a la gerencia. No el listado de CVEs, sino el tiempo promedio de remediación por criticidad, el porcentaje de vulnerabilidades cerradas en plazo, la tendencia. Sin esas métricas, la gestión de vulnerabilidades vive exclusivamente en TI y nunca llega a ser una conversación de riesgo organizacional.
DECISIÓN QUE DEBE TOMAR EL CIO
¿Tiene la organización un proceso de remediación con SLAs definidos, responsables nominados y métricas que lleguen a la gerencia? Si la respuesta es no, la organización tiene detección de vulnerabilidades, no gestión de vulnerabilidades. Esa diferencia no es semántica: es la diferencia entre saber que estás expuesto y tener un mecanismo real para dejar de estarlo.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
El escáner de vulnerabilidades más sofisticado del mercado no protege a una organización que no tiene el proceso y la autoridad para actuar sobre lo que el escáner encuentra. Implementar Fortinet con FortiManager y visibilidad centralizada sobre la postura de seguridad de toda la red no cierra una vulnerabilidad crítica en un servidor Windows sin parchear si nadie tiene la obligación y la autoridad de hacer el cambio esta semana.
La tecnología resuelve la visibilidad. El proceso y la decisión resuelven la exposición. Esta semana voy a desarrollar en detalle los frenos concretos de la remediación, cómo se construye un programa que funcione con los recursos reales de una organización mediana, y qué pasó en TechCorp Latam con las vulnerabilidades que estaban en el radar mucho antes del incidente.
Si esta semana alguien te preguntara cuántas vulnerabilidades críticas lleva más de 30 días abiertas en tu infraestructura, y la respuesta honesta es "no lo sé" o "varias", ya sabes que el problema no es el escáner. Es lo que pasa después de que el escáner termina.
Esta semana en el blog: cinco días analizando la brecha entre detectar y remediar. Mañana: los frenos reales que frenan la remediación en organizaciones que ya saben lo que tienen que hacer.
#GestiónDeVulnerabilidades #Ciberseguridad #CIO #ITManager #ParcheoDeSeguridad #GestiónDeRiesgos #Fortinet #Cisco #WatchGuard #pfSense #TechCorpLatam #CyberLeadership #Liderazgo #Chile #CVE #CVSS #NISTCSF #ISO27001
Comentarios
Publicar un comentario