Puntos Clave
- Cuando falle un parche, póngase en contacto con el proveedor o con el proveedor externo.
- Busque en recursos de la comunidad, como PatchManagement.org o foros relevantes, para identificar problemas conocidos.
- Pruebe cada parche en un grupo piloto representativo de endpoints para detectar conflictos específicos del entorno antes de la implementación completa.
- Mantenga procedimientos documentados y guías de referencia, incluidos recursos sobre gestión de parches basada en riesgos y Patch Tuesday, para abordar fallos y prevenir interrupciones posteriores.
Ya ha llegado ese momento: toca aplicar parches a sus endpoints. Puede que sea algo que le guste, aunque probablemente no sea así. La aplicación de parches puede ser una tarea ardua y, con muchas organizaciones que aún la realizan manualmente, se invierten en ella más tiempo y recursos de los que cualquiera querría dedicarle.
Ahora bien, dado que va a dedicar todo ese tiempo y esos recursos a la aplicación de parches, querrá asegurarse de que todo vaya bien. Nadie quiere invertir tanta energía en la gestión de parches para acabar en una maraña de confusión y errores.
Así que asegurémonos de que no cae en estos dos problemas mensuales de parches más habituales:
- ¿Funcionan sus parches?
- ¿Ha probado los parches en su entorno?
Problema de parches n.º 1: ¿funcionan sus parches?
No es raro que los parches y las actualizaciones de seguridad fallen sin más. A veces se debe a un problema específico del entorno. Otras veces, el parche en sí simplemente es defectuoso.
Menos mal que decidió comprobar ese parche antes de implementarlo a ciegas, ¿verdad? Pero ahora que está fallando, ¿qué puede hacer al respecto? Depende.
Solución 1: póngase en contacto con su proveedor externo de gestión de parches
Si utiliza un proveedor externo de parches para gestionar las actualizaciones, debería ser el primer punto de contacto.
Aunque las empresas que gestionan parches de terceros prueban rigurosamente el contenido que distribuyen a sus clientes, no pueden probar todos los escenarios de uso. Es posible que tenga una configuración poco habitual o que su endpoint esté gestionando el parche de forma distinta a la que esperaba el proveedor externo de parches.
Sea cual sea el motivo, su proveedor siempre debería ser su primer recurso. No solo es importante notificar el fallo para que pueda corregirse, sino que también resulta útil para ese proveedor externo de parches.
Puede que haya encontrado un problema sistémico. Ahora usted es quien ha alertado a la empresa sobre un problema mayor en el que pueden centrarse y solucionar rápidamente.
Puede que no sea sistémico, pero sí un problema lo bastante común como para que haya ayudado a esa empresa a estar mejor preparada para futuras llamadas de otros clientes. Por no hablar de que también le ha proporcionado un posible nuevo escenario de uso que puede incorporarse a sus protocolos de prueba predeterminados.
Solución 2: consulte a una comunidad en línea más amplia para detectar posibles problemas con los parches
Pero ¿qué ocurre si no utiliza un proveedor externo de parches? Supongamos que su organización revisa manualmente estos parches.
Existen excelentes recursos en línea para comprobar si otras organizaciones también están teniendo los mismos problemas, entre ellos:
- PatchManagement.org, «la primera lista de correo del sector dedicada al debate sobre la gestión de parches».
- Varias comunidades de Reddit y Mastodon, como r/sysadmin, infosec.exchange o cualquier comunidad específica de un proveedor.
- recursos de Patch Tuesday de Ivanti, diseñados para comentar qué parches se publican y qué puede esperarse de ellos.
Independientemente de la vía que decida seguir, hay muchas opciones entre las que elegir para identificar qué ha fallado en el parche defectuoso.
Problema de parches n.º 2: ¿ha probado los parches en su entorno?
De acuerdo, ha decidido probar todos los parches que llegan: ¡excelente! Ya está todo resuelto, ¿verdad?
No tan rápido.
Tampoco puede olvidarse de probar los parches que va a distribuir en dispositivos piloto de toda su organización.
¿Por qué? Al fin y al cabo, es solo una sencilla actualización de Chrome. Pero ¿lo es realmente?
Introducir un nuevo parche en sus sistemas no es muy distinto de introducir una nueva mascota en casa. Aunque ya haya tenido una mascota y confíe en saber cómo cuidarla, cada una tendrá sus propias reacciones ante habitaciones o personas que su mascota anterior no tenía.
Del mismo modo, cada parche tiene sus propios matices de cambios y actualizaciones. A menudo pueden entrar en conflicto con aquello para lo que se han diseñado sus sistemas o programas, lo que puede afectar al entorno o a la eficacia del parche, incluso aunque haya superado las pruebas anteriores.
Al fin y al cabo, las empresas de software no parchean sus productos pensando en sus sistemas. Se centran en actualizar y aplicar parches a sus propias aplicaciones, y no pueden contemplar todos los escenarios de uso.
Resolver el efecto dominó de los problemas de parches
Contar con un grupo piloto dedicado de endpoints en el que probar estas actualizaciones puede garantizar que no se dañen sistemas, programas ni siquiera procesos de los que depende su empresa. El efecto dominó de una pequeña actualización de parche puede ser perjudicial para las operaciones de una empresa.
Por ejemplo, a principios de abril, Chrome lanzó un parche para corregir algunos errores. Pero también introdujo errores nuevos, uno de los cuales afectaba a la capacidad de impresión desde Chrome.
¿Y si su organización trabaja en un entorno con un uso intensivo de impresión, donde poder imprimir a través de Chrome es una opción imprescindible para sus operaciones?
De este modo, probar todos los parches, incluso los pequeños y aparentemente insignificantes, puede ayudarle a evitar una catástrofe.
Recuerde: cuando algo sale mal, los errores se propagan más allá del departamento o usuario inicialmente afectado. La mayoría de los usuarios y organizaciones no piensan en los impactos posteriores que puede provocar un pequeño parche si no se ha probado por completo. Al fin y al cabo, a menudo es TI quien se encarga de solucionar los efectos de un fallo o una interrupción.
Por eso, cuando llega el momento de aplicar parches, queremos prepararnos para que todo salga bien. Para ello, buscamos una variedad sólida de endpoints en los que probar nuestros parches, con el fin de asegurarnos de no generar un impacto posterior evitable, y también tenemos preparados nuestros recursos de la comunidad por si los parches acaban fallando.
También puede consultar:
- La guía definitiva de la gestión de parches basada en riesgos para obtener más información sobre la creación de grupos piloto, la gestión priorizada de parches y otros aspectos básicos de la aplicación de parches.
- El podcast Security Insights, que analiza la importancia de la visibilidad de los activos antes de limitarse a implementar un nuevo parche.
- La serie Patch Tuesday, que ofrece todas nuestras recomendaciones y advertencias anteriores sobre parches. No se pierda la próxima sesión, que tendrá lugar el miércoles inmediatamente posterior al Patch Tuesday de cada mes.
A veces, la mejor estrategia de gestión de parches es simplemente una buena preparación. ¡Buena suerte!