Sabés que hay una grieta en la pared y no la reparás porque "nunca ha pasado nada"
Imaginate que el inspector de tu edificio te entrega un reporte: hay una grieta estructural en la pared del tercer piso. No es urgente, te dice, pero hay que repararla antes de la temporada de lluvias. Vos lo anotás, se lo mencionás al encargado de mantenimiento, y entre la rutina diaria del negocio el reporte queda archivado. Tres meses después, durante las primeras lluvias fuertes, la pared cede. Nadie puede decir que no lo sabía. El reporte existía. La grieta estaba documentada. Solo faltó actuar. En ciberseguridad, ese reporte se llama CVE. Y ese tipo de desastre anunciado ocurre todos los días.
El informe de Verizon Data Breach Investigations 2024 es contundente: el 85% de las brechas de seguridad exitosas explotaron vulnerabilidades conocidas, con parches disponibles, que simplemente no habían sido aplicados. No fue un ataque sofisticado de día cero. No fue una técnica nueva que nadie conocía. Fue una puerta que llevaba meses abierta y que nadie cerró.
WannaCry, el ransomware que en 2017 paralizó hospitales, empresas de telecomunicaciones y entidades gubernamentales en más de 150 países causando pérdidas estimadas en $4,000 millones, explotó una vulnerabilidad llamada EternalBlue. Microsoft había lanzado el parche MS17-010 exactamente 59 días antes del ataque. 59 días en los que cualquier empresa que hubiera aplicado esa actualización habría estado completamente segura.
El ciclo de vida de una vulnerabilidad
Para entender por qué el patch management es tan crítico, hay que entender cómo nacen y mueren las vulnerabilidades.
Fase 1: Descubrimiento
Alguien —puede ser un investigador de seguridad, un empleado de la empresa de software, o un atacante— descubre un fallo en un sistema. En este momento solo esa persona lo sabe.
Fase 2: Zero-day
Si el fallo se hace público antes de que exista un parche, se llama vulnerabilidad de día cero (zero-day). En este período, todos los sistemas afectados son vulnerables y no hay mucho que hacer más que aplicar mitigaciones temporales o apagar el sistema comprometido.
Fase 3: Divulgación y CVE
Cuando el fabricante del software toma conocimiento del fallo (por reporte responsable del investigador o por detección propia), trabaja en un parche y lo publica junto a un identificador oficial llamado CVE (Common Vulnerabilities and Exposures). Por ejemplo: CVE-2024-21413. Cada vulnerabilidad documentada tiene su propio número.
Fase 4: Puntuación CVSS
Junto al CVE, se publica una puntuación CVSS (Common Vulnerability Scoring System) del 0 al 10 que indica la gravedad:
Fase 5: La carrera contra el tiempo
Aquí empieza lo más crítico: desde el momento en que se publica el CVE con su parche, los atacantes tienen toda la información que necesitan. Investigaciones de la firma Kenna Security muestran que el 50% de las vulnerabilidades críticas tienen un exploit funcional disponible en la dark web dentro de los primeros 2 días de publicación del parche. A los 7 días, ese número sube al 80%.
Esto crea una carrera: ¿quién actúa más rápido, vos aplicando el parche o el atacante desarrollando y usando el exploit?
Por qué las empresas no parchean (y por qué ese argumento no aguanta)
En auditorías con PYMEs centroamericanas, siempre escuchamos las mismas razones para no aplicar actualizaciones:
El inventario de activos: el primer paso no negociable
No podés gestionar lo que no conocés. Antes de cualquier otra cosa, necesitás saber exactamente qué sistemas, dispositivos y software hay en tu empresa.
El inventario debe incluir:
Para una empresa de 10 a 30 personas, este inventario puede hacerse manualmente en una tarde usando una hoja de cálculo. Para empresas más grandes, existen herramientas que lo automatizan.
Herramientas gratuitas para inventario y escaneo de vulnerabilidades
Cómo priorizar: no todo se puede parchear al mismo tiempo
En una empresa real con recursos limitados, no es posible parchear todo inmediatamente. Necesitás un sistema de priorización.
El framework básico de priorización
Ordenamos las vulnerabilidades por riesgo real, no solo por puntaje técnico:
Prioridad 1 — Parchear esta semana:
Prioridad 2 — Parchear este mes:
Prioridad 3 — Parchear en el próximo trimestre:
Prioridad 4 — Documentar y monitorear:
El factor de exposición
Una vulnerabilidad CVSS 8.5 en un servidor de pruebas sin datos reales y sin acceso externo es menos urgente que una CVSS 7.2 en el servidor de correo expuesto a internet. El puntaje técnico es un punto de partida; el contexto de negocio es lo que define la prioridad real.
Proceso de patch management para empresas de 10 a 100 personas
No necesitás un departamento de TI de 20 personas para hacer esto bien. Este es el proceso mínimo viable:
Paso 1: Inventario inicial (semana 1)
Documentá todos los sistemas, versiones de SO y aplicaciones críticas. Usá OpenVAS para un primer escaneo de la red. Identificá los sistemas sin soporte del fabricante.
Paso 2: Suscribirse a alertas de seguridad (permanente)
Paso 3: Ciclo mensual de parches
Establecé una ventana de mantenimiento mensual (por ejemplo, el segundo sábado del mes de 10pm a 2am) donde se aplican los parches de Prioridad 2 y 3. Los de Prioridad 1 no esperan el ciclo mensual: se aplican en menos de 72 horas.
Paso 4: Prueba antes de aplicar en producción
Para sistemas críticos (ERP, base de datos de clientes, servidor de correo), probá el parche en un entorno de pruebas o en un equipo de menor criticidad antes de aplicarlo en producción. Si en 24-48 horas no hay problemas, adelante con el resto.
Paso 5: Verificación y documentación
Después de aplicar los parches, verificá que el sistema funciona correctamente y documentá qué se parchó, cuándo y quién lo hizo. Esto es clave para evidenciar cumplimiento y para diagnósticos futuros.
Paso 6: Escaneo de seguimiento
Un mes después de cada ciclo de parches, corré OpenVAS nuevamente para verificar que las vulnerabilidades identificadas realmente fueron resueltas. A veces los parches no se aplican correctamente o nuevas vulnerabilidades surgen.
La lección de WannaCry: cuando el parche estaba disponible 59 días antes
El 12 de mayo de 2017, WannaCry comenzó a propagarse a una velocidad sin precedentes: 200,000 sistemas infectados en 150 países en menos de 24 horas. Hospitales del NHS británico cancelaron cirugías. Telefónica en España paralizó operaciones. Nissan y Renault detuvieron plantas de producción.
EternalBlue, la vulnerabilidad que WannaCry explotaba, fue desarrollada originalmente por la NSA y filtrada por el grupo Shadow Brokers. Cuando Microsoft tuvo conocimiento, lanzó el parche MS17-010 el 14 de marzo de 2017. WannaCry llegó el 12 de mayo de 2017.
Dos meses. Los sistemas que aplicaron el parche estuvieron completamente a salvo. Los que no, vivieron una de las peores semanas de su historia. Las empresas afectadas en Centroamérica incluyeron filiales de empresas multinacionales y algunas instituciones gubernamentales que operaban Windows XP, cuyo soporte había terminado en 2014.
La conclusión es dolorosa pero clara: WannaCry no fue un ataque sofisticado. Fue el triunfo de la inacción sobre el conocimiento.
Casos en Centroamérica: el costo de no parchear
En 2023, una empresa de logística en Guatemala con 80 empleados sufrió una infección de ransomware que cifró sus servidores de archivos y su sistema de facturación. El vector de entrada fue una vulnerabilidad en su versión desactualizada de Windows Server 2012 que tenía más de 18 meses sin actualizaciones.
El costo total incluyó: pago de rescate ($15,000 en criptomonedas, que no garantizó recuperación total), contratación de consultores forenses, tiempo de inoperación de 11 días, pérdida de contratos con dos clientes que no podían esperar y costos de recuperación de sistemas. Total estimado: $85,000.
El escaneo de vulnerabilidades que habría identificado el riesgo cuesta entre $300 y $800 en una PYME de ese tamaño. El parche habría tomado una tarde de trabajo.
Más allá de Windows: el software que también necesita parches
Uno de los errores más frecuentes es creer que gestión de parches equivale a actualizar Windows. Los atacantes lo saben y van por las otras puertas:
Convertir el patch management en un proceso sostenible
El mayor enemigo del patch management no es la complejidad técnica; es la falta de proceso. Las empresas que hacen esto bien tienen tres cosas en común:
La brecha que podés cerrar hoy
La gestión de vulnerabilidades no requiere un presupuesto enorme ni un equipo técnico de alto nivel. Requiere disciplina, proceso y la voluntad de actuar cuando el reporte dice que hay una grieta en la pared.
La diferencia entre una empresa que sufre un incidente devastador y una que lo evita rara vez está en cuánto invirtieron en tecnología. Está en cuánto tiempo tardaron en cerrar la ventana que el atacante necesitaba para entrar.
En CiberShield realizamos evaluaciones de vulnerabilidades y acompañamos a empresas centroamericanas en la implementación de procesos de patch management adecuados a su tamaño y presupuesto. Si querés saber exactamente cuántas vulnerabilidades conocidas tiene tu infraestructura hoy, escribinos. El primer escaneo diagnóstico es parte de nuestra evaluación inicial.