Por qué las actualizaciones de software también son una medida de seguridad

Cuando una empresa recibe una notificación de actualización de software, la reacción más común es postergarla. "Después la instalo", "no tengo tiempo ahora", "prefiero no tocar lo que funciona". Esa decisión —que parece inofensiva y puramente operativa— es en realidad una decisión de seguridad, y de las más importantes que toma una empresa todos los días.

Cada vez que un fabricante de software publica una actualización, no solo está agregando funciones o corrigiendo errores visibles. En la mayoría de los casos, está cerrando vulnerabilidades de seguridad que ya son conocidas —y que por lo tanto ya pueden estar siendo explotadas—. Postergar una actualización es dejar abierta una puerta que el fabricante ya te dijo que existe y que ya te dio la llave para cerrar.

Este artículo explica, en términos no técnicos, por qué las actualizaciones de software son una medida de seguridad esencial, qué riesgos concretos implica no aplicarlas y cómo implementar una política de actualización que no paralice la operación.

Qué contiene realmente una actualización de software

No todas las actualizaciones son iguales, y entender la diferencia ayuda a priorizar. La industria del software clasifica las actualizaciones en tres categorías principales:

Actualizaciones de seguridad (parches). Corrigen vulnerabilidades específicas que un atacante podría explotar para acceder a información, tomar control de un sistema o interrumpir un servicio. Estas actualizaciones no agregan funciones nuevas: solo cierran agujeros. Son las más urgentes y las que menos debate deberían generar.

Actualizaciones de mantenimiento (bug fixes). Corrigen errores de funcionamiento que afectan la estabilidad o el rendimiento del software. Aunque no siempre tienen implicancias directas de seguridad, un error de funcionamiento puede convertirse en un vector de ataque si se combina con otras condiciones.

Actualizaciones de funcionalidad (feature releases). Agregan capacidades nuevas al software. Son las que más se parecen a lo que intuitivamente pensamos cuando hablamos de "una actualización": nuevas funciones, cambios de interfaz, mejoras de usabilidad. Son las menos urgentes desde el punto de vista de la seguridad.

Un dato que sorprende a muchos empresarios: la mayoría de las actualizaciones que publican los sistemas operativos, los navegadores web, los servidores y las aplicaciones empresariales son de seguridad o de mantenimiento, no de funcionalidad. Cuando Windows, macOS, Android o iOS te piden reiniciar para instalar una actualización, en más de la mitad de los casos lo que están instalando son parches de seguridad.

Por qué las empresas postergan las actualizaciones —y por qué esos motivos no son buenos

Las razones por las que una empresa decide no actualizar suelen ser comprensibles pero equivocadas cuando se las examina de cerca.

"Prefiero no tocar lo que funciona." El temor a que una actualización rompa algo es real. Hay casos documentados de actualizaciones que introdujeron nuevos errores o incompatibilidades. Pero la probabilidad de que una actualización de seguridad cause un problema operativo es mucho menor que la probabilidad de que una vulnerabilidad sin parchear sea explotada. Dicho de otra forma: el riesgo de no actualizar es mayor que el riesgo de actualizar.

"No tengo tiempo para ocuparme de esto." La actualización de seguridad de un sistema operativo o de una aplicación empresarial suele tomar minutos. Recuperarse de un incidente de seguridad causado por una vulnerabilidad sin parchear toma días, semanas o meses. El argumento de la falta de tiempo solo se sostiene si se ignora el costo de la alternativa.

"Mi proveedor se ocupa de la seguridad." Si tu empresa usa un software desarrollado a medida o gestionado por un proveedor, es posible que la responsabilidad de aplicar actualizaciones esté delegada. Pero delegar la ejecución no significa delegar la responsabilidad. La empresa sigue siendo la dueña del sistema y la que sufre las consecuencias si algo sale mal. Preguntarle al proveedor cada cuánto aplica actualizaciones de seguridad y exigir evidencia de que lo hace es una práctica razonable.

"No entiendo qué estoy instalando." La terminología de las actualizaciones —"CVE-2024-1234", "parche crítico para el kernel", "actualización acumulativa"— es confusa para quien no tiene formación técnica. Pero no hace falta entender el detalle técnico para entender el principio: si el fabricante dice que hay que actualizar por seguridad, hay que actualizar.

El impacto real de no actualizar: tres escenarios concretos

Para entender el riesgo sin necesidad de tecnicismos, alcanza con imaginar tres escenarios que ocurren todos los días:

Un servidor web con una versión desactualizada del sistema operativo. El servidor donde corre el sitio web o la aplicación de la empresa ejecuta una versión del sistema operativo que dejó de recibir actualizaciones de seguridad hace seis meses. El fabricante ya no publica parches para esa versión. Cualquier vulnerabilidad descubierta después de esa fecha queda sin corregir para siempre. El servidor está expuesto y la única solución es migrar a una versión soportada —una operación mucho más costosa que haber aplicado las actualizaciones a tiempo.

Una computadora de la empresa con el navegador desactualizado. Un empleado usa el navegador web para acceder al sistema de gestión, al correo corporativo y a la plataforma de facturación. Ese navegador tiene tres meses de actualizaciones sin aplicar. Una de esas actualizaciones corregía una vulnerabilidad que permite a un sitio web malicioso ejecutar código en la computadora del visitante. El empleado hace clic en un enlace que recibe por correo, y el atacante obtiene acceso a todo lo que el empleado tenía abierto.

Una base de datos con un parche de seguridad sin aplicar. La base de datos donde la empresa almacena información de clientes, facturación y operaciones corre una versión con una vulnerabilidad conocida para la que existe parche desde hace dos meses. Esa vulnerabilidad permite a un atacante que ya obtuvo acceso a la red interna —por ejemplo, a través del escenario anterior— extraer toda la información de la base de datos sin necesidad de credenciales adicionales.

Lo que estos tres escenarios tienen en común es que el daño no ocurre por un ataque sofisticado: ocurre porque una actualización que estaba disponible y era gratuita no se aplicó a tiempo.

Para entender mejor cómo una vulnerabilidad sin corregir se convierte en una brecha real, el artículo sobre qué es una brecha de seguridad explica el proceso en detalle. Y si todavía no identificaste los puntos débiles de tus sistemas, riesgos técnicos que nadie revisa hasta que es tarde describe otros frentes que suelen pasarse por alto.

Cómo armar una política de actualizaciones que funcione en la práctica

Actualizar todo, todo el tiempo, sin criterio, no es realista. Pero postergar todo hasta que algo se rompe tampoco lo es. La solución está en una política de actualizaciones con tres niveles de urgencia:

Nivel 1: actualizaciones de seguridad críticas. Se aplican tan pronto como están disponibles, idealmente dentro de las 24 a 48 horas siguientes a su publicación. Incluyen parches para vulnerabilidades que ya están siendo explotadas activamente —los fabricantes suelen marcarlas como "críticas" o "zero-day"— y actualizaciones de sistemas expuestos a internet, como servidores web, firewalls y servicios en la nube.

Nivel 2: actualizaciones de seguridad estándar. Se aplican dentro de la misma semana o del mismo mes, según el ritmo que la operación permita. Incluyen parches para vulnerabilidades conocidas pero no explotadas masivamente, y actualizaciones de sistemas internos que no están expuestos directamente a internet.

Nivel 3: actualizaciones de funcionalidad y mantenimiento. Se planifican con anticipación, se prueban en un ambiente de prueba si es posible, y se aplican en momentos de baja actividad. No tienen la urgencia de las de seguridad, pero tampoco deberían acumularse indefinidamente.

Esta política requiere dos cosas que no dependen del presupuesto sino de la disciplina:

Un inventario de qué software usa la empresa y en qué versión está. Sin ese inventario, no hay forma de saber qué necesita ser actualizado. No hace falta un sistema complejo: una planilla con columnas de sistema, versión actual, fecha de última actualización y responsable alcanza para empezar.

Un responsable designado. Alguien en la empresa —o en el proveedor, si la gestión está delegada— debe tener la responsabilidad explícita de monitorear la publicación de actualizaciones de seguridad y asegurarse de que se apliquen según la política definida. Si la responsabilidad es difusa —"que alguien de sistemas se ocupe"—, las actualizaciones no se van a aplicar.

El caso especial del software que dejó de tener soporte

Hay una situación peor que tener actualizaciones pendientes: usar software que ya no recibe actualizaciones de ningún tipo. Cuando un fabricante anuncia el fin del soporte para una versión de su producto —lo que en la industria se llama "end of life" o EOL—, significa que no va a publicar más parches de seguridad para esa versión. Cualquier vulnerabilidad que se descubra de ahí en adelante quedará sin corregir para siempre.

Usar software en estado EOL es una de las decisiones de seguridad más riesgosas que puede tomar una empresa. Es equivalente a tener una puerta sin cerradura y confiar en que nadie va a intentar abrirla.

La solución es migrar a una versión soportada antes de que el soporte termine. Si la migración es costosa o compleja, planificarla con anticipación es parte de la gestión de riesgos de la empresa. Dejarla para después del EOL es apostar a que no se descubra ninguna vulnerabilidad grave —una apuesta que la historia de la industria demuestra que se pierde con frecuencia.

Actualizar es más barato que lamentar

El costo de aplicar una actualización de seguridad —medido en tiempo de inactividad, riesgo de incompatibilidad o esfuerzo del equipo técnico— es casi siempre menor que el costo de gestionar un incidente de seguridad causado por una vulnerabilidad sin parchear. Esa comparación de costos rara vez se hace de forma explícita, pero debería ser parte de cualquier evaluación de riesgos.

Actualizar no garantiza que un sistema sea invulnerable —ninguna medida de seguridad lo hace—. Pero no actualizar garantiza que las vulnerabilidades conocidas sigan abiertas. Y un atacante que encuentra una puerta abierta no necesita ser un genio: solo necesita llegar antes de que la empresa decida cerrarla.