Hace unas semanas Microsoft volvió a advertir a las empresas sobre dos nuevas vulnerabilidades críticas en Exchange Server 2013, 2016 y 2019 que permitirían a un atacante tomar el control de los servidores vulnerables de forma remota. Por lo que se sabe, las vulnerabilidades de seguridad aún no han sido explotadas, pero Microsoft tiene en cuenta que esto sucederá. Las vulnerabilidades, identificadas como CVE-2021-28480 y CVE-2021-28481, fueron calificadas ambas con un 9,8 en una escala de 1 a 10 en términos de gravedad. La agencia de inteligencia estadounidense NSA descubrió y comunicó los fallos de seguridad a Microsoft. Sin embargo, los investigadores de la empresa tecnológica también habían encontrado las vulnerabilidades independientemente de la NSA.

La única constante que reaparece en cualquier debate actual sobre un fallo de seguridad crítico es la rapidez con la que se parchean los sistemas vulnerables. En el caso de Hafnium, decenas de miles de sistemas de todo el mundo seguían sin parchear incluso más de una semana después de que se conociera la noticia, y ahora, un mes después, sólo estamos empezando a ver los efectos de algunos de los ataques, en los que se desplegó ransomware. Existen informes similares en muchos de los fallos de seguridad más destacados de los últimos años. Las razones de los retrasos en el despliegue de las actualizaciones críticas han sido más o menos las mismas desde hace décadas: El proceso de despliegue no es trivial, los parches requieren pruebas antes de pasar a producción o una actualización no se percibe como tan crítica para la empresa por diversas razones.

En los últimos años, esta situación no se ha visto favorecida por la frecuencia y el volumen cada vez mayores con que se publican las actualizaciones y los parches. Para disgusto de muchos administradores, empresas como Microsoft han aumentado sus actividades a dos actualizaciones importantes al año. Esto ha llevado a situaciones en las que los administradores acaban de terminar de limar las asperezas que surgieron durante el despliegue, momento en el que la siguiente gran actualización está a la vuelta de la esquina. Esta situación sería un reto tal y como es, pero en la mayoría de las empresas hay un montón de otras aplicaciones que requieren actualizaciones. Y aquí es donde empiezan los problemas: No todas las actualizaciones son compatibles con todas las demás. En la mayoría de los casos, la dirección de TI da por sentado que los administradores “sólo hacen las actualizaciones de forma paralela” y lo perciben como parte del trabajo diario del equipo de TI. Esto no suele estar muy lejos de la realidad. Pero en la práctica, el trabajo de mantener todo el software actualizado suele quedar enterrado bajo una carga de otras obligaciones. Y seamos sinceros: instalar actualizaciones no es la actividad más emocionante y divertida del mundo.

Los departamentos de TI que carecen constantemente de personal se convierten en la gota que colma el vaso: Simplemente no pueden seguir el ritmo.

No se trata sólo de poner parches

Llegados a este punto, debemos dar un paso atrás. Se podría tener la impresión de que la seguridad consiste en actualizaciones y parches. Y aunque estos son un componente indudablemente crítico en la cadena de seguridad, no lo son todo. Recuerde que la seguridad no debe tener puntos únicos de fallo. Es importante darse cuenta de que la gestión de parches no es garantía de una red segura. Además de la gestión de parches, son indispensables medidas como la autenticación multifactor, los cortafuegos, los IPS, el cifrado, un sistema de seguridad de puntos finales antivirus bien diseñado con las últimas tecnologías de IA y formaciones repetitivas de concienciación en materia de seguridad. Ningún componente puede garantizar la seguridad de una empresa por sí solo. La seguridad es siempre el resultado de una combinación de varios factores. Del mismo modo, para que se produzca un fallo en la seguridad siempre deben fallar varios componentes. Un fallo completo de la seguridad debido a una sola acción o factor es un claro indicador de que las cosas se han torcido gravemente.

¿Qué hacemos ahora?

Una de las razones más importantes que se aducen para no aplicar un parche o una actualización inmediatamente es la falta de un entorno de pruebas en algunas empresas. Un problema que se oye a menudo es que las empresas han tenido problemas en el pasado al aplicar un parche a una aplicación crítica. El resultado es que se muestran reticentes a desplegar los parches rápidamente y quieren probarlos ampliamente por adelantado, para minimizar cualquier impacto negativo en el negocio diario. Este hecho aparentemente mundano subraya una cruda realidad: Las empresas tienen menos miedo a un fallo de seguridad que a que las cosas se rompan por problemas con un parche o una actualización.

Esta situación no es buena. Las empresas deben establecer directrices claras sobre qué parchear y cómo, y también cuándo. El sistema CVSS es un buen punto de partida. En base a esto, cualquier actualización que sea crítica para la seguridad puede (y debe) ser acelerada de todas las maneras posibles. Aunque no sugiero que se renuncie a las pruebas de los parches críticos, el tiempo que una empresa tarda en probar un parche debe ser lo más breve posible. En última instancia, el objetivo debería ser desplegar los parches críticos en un par de días como máximo. Mientras tanto, deben evaluarse y aplicarse, si es posible, todas las soluciones o estrategias de corrección que puedan utilizarse.

Instrumentos, técnicas y procedimientos

Por desgracia, también existe el hecho de que, especialmente las pequeñas empresas, no tienen a mano las herramientas necesarias para ver qué parches están disponibles. Por ejemplo, pueden ver que hay un parche disponible para Windows, pero pueden no ser conscientes de que se han publicado parches para otras aplicaciones. Esto requiere muchos ajustes manuales y más trabajo de campo del que debería ser necesario. Parte de esto puede remediarse adquiriendo las herramientas adecuadas, en forma de una solución de gestión de parches.

Sin embargo, aunque se cuiden las herramientas y las prioridades, sigue habiendo posibilidades de que se produzcan problemas: La TI en la sombra. El término incluye cualquier software “no estándar”, es decir, programas que no están en la lista de programas utilizados por la empresa. Pueden ser programas en los dispositivos de los empleados, instalados por ellos mismos. E incluso si son programas útiles y que valen la pena tener: Si el departamento de TI no es consciente de ello, los parches de ese software simplemente se pierden, incluidos los parches que podrían resultar ser críticos. Así que si un programa “no estándar” es lo suficientemente útil y tiene una razón válida para ser utilizado, podría ser una buena idea añadirlo al catálogo de software de la empresa.

El futuro de los parches

En un futuro previsible, los humanos seguirán participando en la programación y, por tanto, cometerán errores en los miles de millones de líneas de código de software. Por lo tanto, también seguiremos viendo el parcheo como un mal necesario. Sin embargo, veo un aumento de los parches automáticos, incluso para los parches críticos, como una posible solución en los próximos años para todos los sistemas operativos. Eso no resolverá el problema de las vulnerabilidades de día cero, ya que esto podría convertirse en un problema mayor en los próximos años. Ahora que tal vez se robaron millones de códigos de programación en los ataques de Hafnium y Solarwinds, no podemos negar que las debilidades de día cero podrían convertirse en una tendencia mayor que justifique una acción mucho más rápida de lo que muchas empresas están preparadas para ofrecer.

Puedes ver el articulo original aqui