La distribución y la aplicación de parches de software son dos de las tareas más importantes que se asignan al equipo de TI de una organización.
Existen numerosas herramientas diseñadas para gestionar esas tareas, que se engloban bajo el término general de «gestión de software de código abierto» ( ).
Sin embargo, lo que a menudo se pasa por alto es que, independientemente de las herramientas que el departamento de TI elija para llevar a cabo la tarea, es necesario abordar las cuestiones relacionadas con los procesos y las políticas antes de que una organización pueda asumir realmente el control de su entorno de software.
Además, muchas organizaciones no han modificado su enfoque en materia de gestión de software desde principios de la década de 2000s. En este blog, destaco varias de estas consideraciones relativas al proceso y explico su importancia.
Lista de verificación: Prácticas modernas de gestión de software que debe conocer
La implementación centralizada de software y la aplicación de parches son las medidas más eficaces
Según mi experiencia, las empresas que utilizan un modelo descentralizado para gestionar el software presentan unos hábitos de seguridad mucho peores que las que utilizan un modelo centralizado.
Y cuando digo «centralizado», me refiero a que una organización puede contar con personal de soporte descentralizado, pero con una única autoridad centralizada que determine qué software y qué actualizaciones de software se instalarán y cuándo. Todos los equipos de asistencia distribuidos siguen el mismo ritmo.
La centralización favorece la rapidez en la realización de pruebas y la aplicación de parches
Uno de los aspectos más importantes de la gestión de software es la rapidez en la realización de pruebas y la aplicación de parches. A medida que realice la transición a un modelo centralizado, le conviene llevar a cabo una implantación por etapas o en fases. Debería realizar varias fases de pruebas antes de pasar a producción. «Unos cuantos» significa dos o tres, ¡no 20!
La cuestión es que no es conveniente que sus dispositivos finales permanezcan vulnerables durante demasiado tiempo, por lo que es importante que esas actualizaciones se implementen lo antes posible. En general, un plazo realista es de 7-15 días, aunque puede ser menor en función de la importancia de la actualización.
Esa es la vertiente normativa de la gestión de software. Defina los acuerdos de nivel de servicio (SLA) para sus parches más críticos. Intente que la cifra sea lo más baja posible. No base una cifra en lo que ha hecho durante los últimos 20 años. Fíjese objetivos ambiciosos.
30 días es mucho tiempo
Si me presento en una empresa y su ciclo de aplicación de parches es superior a 30 días, el primer paso consiste en conseguir que estas actualizaciones se publiquen y se instalen en todos los dispositivos en un plazo de 30 días. No debería ser peor que eso.
Debe comprender que, cuando se publican estas actualizaciones, los delincuentes también se enteran de ellas. Las personas que desean infiltrarse en sus sistemas pueden consultar la documentación; pueden ver qué se está corrigiendo y por qué. El tiempo apremia, y debe actualizar su software antes de que se desarrollen y utilicen vulnerabilidades. Por eso digo que 30 días es mucho tiempo.
Ahora bien, es posible que no siempre desee aplicar los parches de inmediato en sus sistemas de producción. Quizás tenga dificultades con las dependencias internas de las aplicaciones. Por ejemplo, es posible que los parches de .NET no funcionen correctamente con alguna de sus aplicaciones propias desarrolladas internamente. Estas cosas van a suceder.
Por lo general, dispone de un plazo de aproximadamente una semana para comprobar si existen dichos conflictos. Y, en definitiva, lo que usted quiere es reducir esos 30 días para que se acerquen lo más posible a una semana. Ese debería ser el objetivo.
¿Hasta qué punto es grave la situación? El mundo de las «actualizaciones de seguridad retroactivas»
Lo que más me ha llamado la atención a lo largo de los años es la cantidad de empresas que piensan que les va muy bien o, al menos, que no les va mal. Se otorgan a sí mismos un «B+».
Sin embargo, al realizar una evaluación, descubrimos miles de parches críticos que se remontan incluso al año 2007. Es evidente que algo no funciona. Por lo general, se trata de una combinación de herramientas y procesos. Es necesario abordar ambas cuestiones.
Para muchas empresas, la metodología de aplicación de parches de que utilizan en la actualidad es la misma que la de 2007 o 2010. Sin embargo, el entorno en el que operan ha cambiado. Tienen parches pendientes que abarcan una década o más, independientemente de si tenían conocimiento de ellos o no.
No es raro empezar por las actualizaciones de seguridad críticas e importantes para sus sistemas operativos. Todas estas actualizaciones tienen asignados niveles de gravedad, por lo que puede utilizarlos para hacerse una idea del grado de vulnerabilidad de sus sistemas operativos.
Asimismo, existen niveles de gravedad asociados a las actualizaciones de aplicaciones de terceros de , como Adobe Acrobat (consulte nuestra entrada de blog sobre el fin de vida útil (EOL) de Adobe Flash en ), navegadores web como Chrome y Firefox, y aplicaciones de productividad como Office365.
Para la «aplicación de parches atrasados», comience por las actualizaciones más críticas e importantes. En un entorno distribuido, esto le permite sacar el máximo partido a su inversión, pero no se quede ahí.
Evaluar técnicamente las deficiencias en la gestión del software es sencillo; resolverlas, en cambio, no lo es.
No se tarda mucho en detectar deficiencias en las metodologías de distribución de software y aplicación de parches. Sin embargo, alcanzar un consenso sobre las políticas y los procesos que permitan subsanar esas deficiencias puede llevar mucho tiempo y ser motivo de controversia.
Las personas construyen sus carreras haciendo las cosas de una determinada manera y, a menudo, no desean cambiar. En muchos casos, hasta que no empiezan realmente a evaluar y a reflexionar sobre sus políticas, ni siquiera se dan cuenta de que la única razón por la que existen esas políticas es que «siempre lo hemos hecho así». Uno de los aspectos en los que es probable que se encuentre con mayor resistencia es el de los reinicios del sistema tras una actualización.
Esto se debe a que el reinicio del sistema afecta a los usuarios finales. Las organizaciones pueden tardar, literalmente, meses en decidir cómo reiniciar los terminales, al tiempo que se garantiza una notificación adecuada —es decir, sin reiniciar el dispositivo de un usuario cuando se ausenta para ir a comer, en medio de una presentación o mientras trabaja en un documento crítico—.
Es aquí donde resulta esencial contar con un liderazgo ejecutivo firme para hacer cumplir la política de reinicio, ya que, especialmente en el entorno de Windows, un parche no se instala realmente y el código vulnerable no se sustituye hasta que el sistema o la aplicación se reinicia.
Algunas organizaciones dejan que sea el usuario final quien decida si reiniciar el sistema, y no se envía ninguna notificación indicando que es necesario reiniciarlo. Los usuarios finales se adaptarán a unas políticas más estrictas si estas se aplican.
Aprenderán a reiniciar el sistema la primera o la segunda vez que reciban una notificación —quizá antes de la comida— en lugar de hacer clic en «Aplazar» hasta que el reinicio se ejecute de forma obligatoria en un momento inoportuno.
Cuando colaboramos con un cliente en la distribución de software, una de las primeras cosas que comprobamos es cuándo se realizó el último reinicio. Y a menudo nos encontramos con que el 75 % de los sistemas de una organización están pendientes de un reinicio. Entonces, ¿esos parches que ha aplicado? En realidad, no lo son.
El riesgo forma parte de cualquier conversación sobre la aplicación de parches de software
La razón principal por la que las organizaciones no aplican los parches con rapidez es el temor a provocar algún fallo. Cuando hablo con vicepresidentes y altos directivos sobre la actualización de software, el tema del riesgo surge en todas las conversaciones. «¿Cuál es el riesgo de que mi sistema sea vulnerable durante 45 días frente al riesgo de que implemente algo en 30 días y mi aplicación deje de funcionar?» Es el miedo a lo desconocido. Es el temor a que se produzcan interrupciones en la actividad empresarial.
Si dispone de un plan de pruebas y de métricas, podrá reducir ese temor. Incluso si ese plan de pruebas consiste simplemente en: «Implemente esta actualización en varios sistemas y veamos si algo falla». Pero debería poder darse cuenta de si algo se ha roto. Debería disponer de esos datos y no tener que depender de que alguien abra un ticket de incidencia.
Si los responsables de las aplicaciones disponen de datos contrastados que demuestren que los parches son seguros, estarán más dispuestos a dar su visto bueno cuando les comunique que va a reducir el ciclo de aplicación de parches de 30 a 15 días.
Para descubrir cómo Tanium simplifica la gestión del software de terceros , no deje de consultar «9 formas en las que Tanium le permite controlar su entorno de software de terminales».
Si está listo para verlo en acción, visite y solicite una demostración en hoy mismo.
