El «Patch Tuesday», el día en que Microsoft publica sus actualizaciones de software, se celebra una vez al mes con total puntualidad. Casi todo el mundo (al menos en el ámbito de la ciberseguridad) lo sabe, por lo que cabría pensar que los equipos de TI actualizarían sus sistemas tan pronto como recibieran la alerta.
Pero no es así. Un estudio reciente de « » ( ), realizado por Synopsys, reveló que el 28 % de los profesionales de TI tardan al menos tres semanas en aplicar parches a las vulnerabilidades críticas, mientras que otro 20 % admite que tarda hasta un mes.
En un momento en el que los autores de amenazas están desarrollando nuevos ataques dirigidos a aprovechar vulnerabilidades, este enfoque lento en la gestión de parches de está poniendo en mayor riesgo a innumerables redes y datos. Es como conducir un coche con el indicador de mantenimiento encendido: sabe que hay un problema, pero como el coche sigue funcionando, es fácil posponer la reparación.
Un coche puede tardar semanas o meses en averiarse después de que se encienda el indicador de mantenimiento. En materia de seguridad, cuando se recibe el aviso de un parche, dispone de unos segundos para solucionar el problema —si es que no es ya demasiado tarde—, ya que los delincuentes están constantemente buscando vulnerabilidades conocidas.
«Aunque se encuentre detrás de una red corporativa y todo esté protegido por un cortafuegos, es solo cuestión de tiempo que alguien traspase el perímetro y descubra esa vulnerabilidad», afirmó David Brumley, asesor de una agencia de inteligencia en seguridad de software, profesor de ciberseguridad en la Universidad Carnegie Mellon y director ejecutivo de ForAllSecure. «Desde el punto de vista de la seguridad, es recomendable aplicar los parches lo antes posible».
Motivos que explican la lentitud en la aplicación de parches
A lo largo del último año, los equipos de TI y seguridad se han enfrentado a vulnerabilidades como MOVEit, una vulnerabilidad de «día cero» en un sistema de transferencia de archivos que podría permitir a los atacantes tomar el control de un sistema; curl, un ataque de «día cero» contra una herramienta de código abierto que utiliza la sintaxis de las URL para transferir datos; y el Apache Superset , una vulnerabilidad de «día cero» que expone configuraciones y bases de datos. Aunque cada año se han detectado menos de 100 nuevos ataques de «día cero», estos suelen causar un daño desmesurado, ya que no se dirigen únicamente a una sola organización, sino a todos los usuarios de dicho software. La capacidad de atacar a tantos objetivos con un esfuerzo mínimo lo convierte en un vector de ataque muy utilizado por los Estados-nación y las bandas de ciberdelincuentes.
«. Aunque se encuentre detrás de una red corporativa y todo esté protegido por un cortafuegos, es solo cuestión de tiempo que alguien traspase el perímetro y descubra esa vulnerabilidad.»David Brumley, asesor en seguridad de software y catedrático de la Universidad Carnegie Mellon
Entonces, ¿por qué tardan tanto los equipos de TI y de seguridad en aplicar los parches cuando se publican?
El primer reto se refiere a la visibilidad de « »: los equipos de seguridad deben conocer el número y los tipos de activos y de terminales que se utilizan realmente en una red, tanto los equipos autorizados oficialmente por la empresa como los numerosos dispositivos y aplicaciones que los empleados incorporan por su cuenta. La vulnerabilidad podría encontrarse, por ejemplo, en , en un sistema de «TI en la sombra» utilizado por los empleados y del que el personal de TI no tiene conocimiento. O bien, es posible que el equipo de DevOps esté utilizando entornos que dependan de herramientas para las que ya no se ofrece soporte.
Un segundo factor que retrasa la aplicación de parches tiene que ver con la visibilidad del software; concretamente, con los componentes del software en los que se encuentra la vulnerabilidad. Con demasiada frecuencia, cuando se da a conocer una vulnerabilidad de «día cero», los equipos de seguridad se dan cuenta de que no conocen lo suficiente sobre su cadena de suministro de software y deben actuar con urgencia para determinar si algún componente infectado está integrado en alguna de las aplicaciones que se utilizan en su red.
[Lea también: 7 formas de proteger su cadena de suministro de software]
Eso es lo que ocurrió en December 2021 cuando se identificó una vulnerabilidad de «día cero» en Apache Log4j, la popular biblioteca de registro de Java de código abierto utilizada en decenas de miles de aplicaciones. Poco después se publicaron parches y, sin embargo, más de dos años después, un número sorprendente de empresas aún no ha solucionado la vulnerabilidad. (Una encuesta reciente de reveló que el 38 % de las aplicaciones que utilizan la versión Log4j lo hacen con una versión insegura.)
Para localizar esos componentes problemáticos, las empresas recurren cada vez más a una lista de materiales de software (SBOM) , que detalla los componentes o ingredientes de todas las aplicaciones y programas de software que utiliza una organización. «Piense en los distintos productos que tiene en su despensa», explicó Melissa Bischoping, directora de investigación en seguridad de dispositivos finales de Tanium (empresa propietaria de esta revista). Los fabricantes de alimentos realizan un seguimiento minucioso de todos los ingredientes de cada producto, lo que les permite —en caso de que se produzca, por ejemplo, un brote de listeria o de E. coli— determinar con exactitud cuándo y dónde se incorporó a su producto un ingrediente contaminado. Del mismo modo, una SBOM facilita el seguimiento de los componentes de la compilación del software y hace que dicha información esté más fácilmente disponible cuando se detecta una vulnerabilidad.
Una tercera razón posible para la lentitud en la aplicación de parches tiene que ver con aspectos empresariales.
«La actividad debe continuar, y muchos sistemas requieren cortes de servicio, periodos de inactividad o reinicios», afirmó Bischoping. «Esto puede provocar la resistencia de los propietarios de las empresas o de los equipos operativos, que afirman que la aplicación del parche debe posponerse».
Además, hay ocasiones en las que se conoce una vulnerabilidad y los responsables de la empresa están al corriente y se han comprometido a aplicar el parche, pero no se puede hacer nada hasta que el proveedor publique dicho parche. Esto supone un problema especialmente en el caso del software de código abierto o de los sistemas que utilizan componentes de código abierto.
«Hay que esperar a que los proveedores actualicen su software», añade Bischoping. «Esto implica esperar a que todo un ecosistema ponga a disposición dichas actualizaciones y, a continuación, disponer de los procesos, las tecnologías y las políticas necesarios para facilitar su implementación en nuestro entorno».
¿Por qué, en ocasiones, resulta tan tentador tomarse un respiro?
Algunas personas que posponen la instalación de parches afirman tener una excusa: temen que aplicar el parche de inmediato pueda acabar causando más daño.
«. Las interrupciones del servicio, los tiempos de inactividad o los reinicios… pueden provocar la resistencia de los propietarios de las empresas o de los equipos de operaciones, que afirman que la aplicación del parche debe posponerse.»Melissa Bischoping, directora de investigación en seguridad de dispositivos finales de Tanium
«La aplicación de parches introduce factores desconocidos», afirmó Brumley. Como usuario, usted no sabe cuánto tiempo va a tardar la actualización, si la aplicación de la corrección provocará fallos en los sistemas, ni qué problema se está solucionando o previniendo.
Desde el punto de vista de un desarrollador, mantener la estabilidad del código existente puede resultar complicado. «Cuando escribió el código, funcionaba correctamente. «Pero ahora, cuando se le pide que actualice, el desarrollador no sabe en qué parte de la dependencia se ha producido una nueva inestabilidad», señaló.
Los desarrolladores reciben mensajes contradictorios cuando se les indica que apliquen un parche. Por un lado, hay que actualizar todos los componentes vulnerables lo antes posible; por otro, hay que asegurarse de que nada deje de funcionar. «Eso segundo», añadió Brumley, «es precisamente cómo evalúan los desarrolladores su trabajo: quieren crear código sólido en lugar de tener que corregirlo».
Para aliviar en parte la carga de los desarrolladores y reducir la tentación de esperar a que se verifiquen los parches para problemas desconocidos, los equipos de TI y de seguridad podrían (y deberían) aplicar un enfoque de « » (seguridad desde el diseño) . El objetivo de este enfoque es eliminar las vulnerabilidades en la medida de lo posible mediante pruebas continuas y la incorporación de medidas de protección de la autenticación en el proceso de desarrollo. La Estrategia Nacional de Ciberseguridad « » (), publicada por la Casa Blanca en 2023, recomienda encarecidamente a las organizaciones que adopten protocolos de «seguridad desde el diseño». Según la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA), la adopción del enfoque «seguro desde el diseño» permitirá abordar mejor las deficiencias en materia de ciberseguridad, incluido el intervalo que transcurre entre el lanzamiento de un parche y su aplicación.
Hasta que lleguemos a un punto en el que la «seguridad desde el diseño» sea la norma en todas las organizaciones, necesitaremos algún tipo de proceso que resulte eficaz para los equipos de TI, seguridad y desarrollo, con el fin de garantizar que la aplicación de parches se acelere.
La aplicación de parches comienza con las políticas
A diferencia de lo que ocurre cuando una persona utiliza el ordenador de su casa y aplica actualizaciones a Chrome y Windows, la gestión de los parches en un entorno empresarial comienza con la elaboración de políticas, según Kyle Miller, socio del grupo global de privacidad de datos y ciberseguridad de Dentons.
«Si una herramienta supervisa el 80 % de sus aplicaciones, entonces el 20 % de sus aplicaciones presentarán un riesgo desmesurado de inseguridad, ya que no figuran en su herramienta de gestión de parches.»Kyle Miller, socio de Dentons
«Lo primero es documentar las políticas y los procedimientos relativos a la gestión de parches», afirmó Miller. Esto permite ejercer un control organizativo para garantizar que quien aplique el parche conozca cuáles son las expectativas de la empresa.
«La mayoría de las empresas con las que trabajo reservan un intervalo de tiempo fuera del horario laboral para aplicar las actualizaciones rutinarias», afirmó Miller. «Pero también necesitan un proceso para aprobar la corrección de vulnerabilidades críticas cuando sea necesario, y en ocasiones hay que hacerlo lo antes posible». Para ello, es necesario realizar un inventario de los sistemas, de modo que pueda identificar los posibles riesgos y el origen del parche.
Una de las razones por las que las actualizaciones se realizan fuera del horario laboral es que así se reduce el tiempo de inactividad que ello conlleva. Y si la aplicación de parches se realiza de forma manual —un proceso que lleva mucho tiempo—, a menudo este es el único momento en el que los equipos de seguridad pueden dedicarse a ello.
Esto justifica tanto la automatización de « » como la inteligencia artificial «». La automatización del proceso de aplicación de parches no solo reducirá la necesidad de intervención manual en una tarea que, de otro modo, resultaría repetitiva, sino que también permitirá prestar una atención más rápida a las actualizaciones, lo que, a su vez, acorta el periodo de vulnerabilidad. La automatización del proceso de aplicación de parches también puede mejorar la posición de la empresa en lo que respecta a los objetivos de cumplimiento normativo, al reducir el riesgo de que un ataque provoque una filtración de datos. Las organizaciones también pueden recurrir a la IA, que puede clasificar las vulnerabilidades por orden de prioridad en función de los riesgos críticos y aplicar los parches según dicha prioridad.
Existe una amplia gama de herramientas de gestión de parches, pero Miller advierte de que, para que cualquier herramienta resulte eficaz, debe adaptarse a sus necesidades específicas.
«Si una herramienta supervisa el 80 % de sus aplicaciones, entonces el 20 % de sus aplicaciones supondrá un riesgo desmesurado de inseguridad, ya que no figuran en su herramienta de gestión de parches», afirmó Miller. Del mismo modo, las herramientas de gestión de parches que permiten identificar versiones antiguas de sus sistemas internos solo resultan útiles si un miembro del personal de seguridad revisa dichas notificaciones y actualiza dichos sistemas.
Dicho esto, también debe tener cuidado con la proliferación de herramientas de « ». De hecho, disponer de demasiadas herramientas puede obstaculizar la aplicación eficaz de parches y la ciberseguridad en general. Para que el proceso de aplicación de parches resulte lo más eficaz posible, los equipos de TI y de seguridad deberán evaluar las herramientas de las que ya disponen, identificar las redundancias y las posibles lagunas, determinar la eficacia de cada una de ellas (¿abordan realmente los problemas de seguridad actuales o son compatibles con los sistemas actualmente en funcionamiento?) y determinar cuál es la mejor forma de que dichas herramientas reduzcan las tareas manuales mediante procesos automatizados de aplicación de parches .
«Es necesario combinar la adquisición de la herramienta con la garantía de que se adapta a su sistema y se implementa correctamente, y que posteriormente sea supervisada por su equipo interno de TI», afirmó Miller.
Mejorar su cultura de aplicación de parches
Independientemente de las herramientas que se utilicen, de las políticas que se establezcan o de lo sólido que sea el código en la fase de desarrollo, siempre surgirán vulnerabilidades. Conscientes de esta realidad, las empresas deben cambiar su cultura en lo que respecta a la aplicación de parches. Una forma de hacerlo es crear un programa de gestión de vulnerabilidades y de gestión de .
«La creación de un programa de gestión de vulnerabilidades propiamente dicho forma parte de la creación de un programa eficaz de gestión de parches», afirmó el Sr. Bischoping, de Tanium.
Puede que parezcan lo mismo, pero no lo son. La gestión de vulnerabilidades evalúa las amenazas y el impacto que cada una de ellas puede tener en su entorno. Algunas pueden suponer un peligro extremo para la seguridad de su organización, mientras que otras vulnerabilidades de alta gravedad quizá no sean explotables en su sistema.
Además de crear programas de gestión de vulnerabilidades, las organizaciones deben mejorar la seguridad en general y la formación en materia de concienciación. Mostrar a los usuarios las consecuencias de contar con sistemas desprotegidos, hacer hincapié en los peligros que entrañan las vulnerabilidades sin parchear y elaborar políticas y procedimientos que optimicen el sistema ayudará a los equipos de TI y de seguridad a abordar mejor los retos que impiden la aplicación oportuna de los parches.
