10 errores frecuentes en la gestión de actualizaciones de seguridad

Hola,

Me ha lanzado Juan Antonio Auñón (un saludo) una pregunta por correo, en la que me viene a consultar por servicios de alertas de seguridad. Juan Antonio está evaluando las distintas soluciones que hay en el mercado, y me preguntaba qué pienso yo de las mismas. Le he comentado que si le importa que le mencione, y que abramos el debate a los lectores del blog, para lo que me ha dado su consentimiento.

A Juan Antonio ya le he dado respuesta, y no ha descubierto nada nuevo. Lo que hay es lo que hay, y todos los que nos movemos en este mundillo conocemos más o menos qué ofrecen las empresas, qué costes suele acarrear y qué nos ofrece cada servicio. No voy a entrar si es mejor Secunia, o si es mejor tirar del SANS, Security Focus, Secwatch, Securiteam, FrSIRT o los gestores de actualización inherentes a las aplicaciones o a los sistemas operativos. El objetivo de este artículo lo vamos a dirigir a repasar conceptos y a enumerar una serie de errores frecuentes cuando se realizan actividades de actualización en las plataformas que dan servicio a las operaciones de una empresa.

El debate lo vamos a centrar en lo que suelen ser los errores típicos en este tipo de actividades. Tirando un poco de la teoría, creo que todos estamos de acuerdo que los servicios de alertas son una parte importante de lo que se viene a llamar gestión de las actualizaciones, o patch management si preferís la terminología inglesa. Si tenemos que ir mejorando gradualmente la seguridad de un servicio, a medida que se van descubriendo vulnerabilidades, lo primero es enterarnos bien sobre el problema de seguridad que sufre o puede sufrir, para posteriormente tomar las oportunas medidas. Es aquí donde un servicio de alertas juega un rol importante, avisando al usuario de la existencia de un problema.

Volvemos a tirar de la teoría, para recordar que el patch management no es una actividad de gestión por sí misma, sino que debe estar integrada en un concepto mayor llamado gestión del cambio, que incluye no sólo los cambios que hay que hacer a los programas y servicios por cuestiones de seguridad, sino en general, aquellas transformaciones necesarias para dar cobertura al normal desenvolvimiento de un negocio determinado. La gestión de las actualizaciones ni tan siquiera es siempre un proceso orientado a las fallas de seguridad, ya que los parches pueden estar orientados a dotar de nuevas funcionalidades a un aplicativo o sistema operativo.

Por poner un ejemplo fácil, instalar un parche de seguridad para Microsoft Word es en sí gestionar las actualizaciones, pero a su vez también es gestionar el cambio, ya que a fin de cuentas, hay una transformación en ese componente de la suite de productividad Microsoft Office. Ni qué decir tiene que si el parche se ha generado para dotar de nuevas funcionalidades al programa, incorporando por ejemplo una nueva barra de herramientas, o un traductor de formatos, es aún más claro que hay cambios que son ajenos, en principio, a la seguridad, pero que no dejan de ser cambios en el aplicativo.

Repasemos los errores típicos cuando se realizan actividades de este tipo. Estos errores no tienen por qué ser los únicos, ni están ordenados por relevancia o probabilidad de ocurrencia. La amalgama de sucesos es amplia, y no suele haber patrones de ordenación claros, pero es posible que estos diez conceptos resuman la problemática más habitual y frecuente en los procesos de gestión de las actualizaciones.

1. El primer error es precisamente en lo que hemos comentado anteriormente. Considerar la gestión de atualizaciones como un proceso independiente, fuera de la gestión de cambios, es el primer y más importante error que podemos comenter al gobernar la tecnología. Los parches SIEMPRE incluyen cambios, y por tanto, hay que evaluar adecuadamente los impactos que éstos pueden ocasionar a la producción de la empresa. Instalar un parche y mirar para otro lado sin pensar en qué implicaciones puede tener es una práctica poco o nada recomendable, y que puede conducir a efectos indeseados con un elevado impacto en las operaciones.
2. Inundación de información. son muchos los servicios que proporcionan información sobre actualizaciones de seguridad, y dar seguimiento a todos es costoso y puede provocar que el tiempo de reacción se prolongue demasiado en el tiempo. Hay que saber elegir bien nuestras fuentes, en función de nuestros requisitos, para poder así optimizar el tiempo que dedicamos a la investigación y análisis. Es mejor basarse en un único servicio fiable que en varios servicios dudosos.
3. Información insuficiente y/o servida en plazos temporales inadecuados. Este problema consiste en disponer únicamente de un aviso que nos dice, en líneas muy generales, de qué va el problema, qué versiones están afectadas, y cuáles son las fuentes de las que podemos obtener el parche. Surge aquí la corriente que dice que una cosa es el aviso, y que luego la empresa debe evaluar el despliegue en sus propios laboratorios empleando sus propios medios. Sin quitar razón a este planteamiento, que es válido y extendido, yo sin embargo apoyo la teoría de que un servicio de avisos de seguridad sólo es excelente si hay un equipo detrás que soporta todo el proceso, evaluando mano a mano con el destinatario de las transformaciones los impactos, diseñando la estrategia de despliegue y soportando el seguimiento posterior a los cambios. Respecto a los plazos temporales, qué duda cabe que las alertas debemos recibirlas (si proceden de fuera) o recabarlas (si gestionamos internamente su seguimiento) en tiempo y forma, ya que los tiempos de reacción pueden ser cruciales, especialmente en ataques 0 day con exploits públicos, y donde el tiempo de reacción es crítico para salvaguardar en el menor plazo los activos de información que puedan quedar comprometidos como consecuencia de un problema de seguridad.
4. Aplicación indiscriminada de parches. Es un error derivado de las prácticas domésticas, donde la producción suele consistir en un único terminal sin relación con otros servicios o máquinas, y donde instalar todos los parches que se nos ofrecen no suele provocar problemas. En un entorno multiplataforma, aplicar indiscriminadamente todos los parches que nos sugieren los servicios de actualización es una práctica suicida que puede provocar problemas críticos de funcionamiento y rendimiento: consumo excesivo de tiempo, problemas de almacenamiento, aumento de gasto de CPU e impacto en el ancho de banda son sólo algunos ejemplos.
5. Análisis de impacto incompletos. Los análisis de impacto tienen que contener las probabilidades, los medios de impacto y lo que es más importante: una traducción económica de los mismos. Si consideramos que un problema de seguridad tiene una solución cuyo coste es superior a los problemas que puede desencadenar, estamos perdiendo el tiempo considerando esa actualización. Traducir a términos económicos es complejo y requiere tiempo, con lo que debe reservarse para problemas críticos o muy críticos, y no para asuntos menores que estén acotados, cuyas decisiones son más fáciles de tomar.
6. Ausencia de estrategias de despliegue. Cuando se parchea un equipo, la estrategia es clara, pero cuando hay que parchear 100.000 terminales, la cosa cambia. El ancho de banda, la disponibilidad, la continuidad de las operaciones, los impactos cruzados entre equipos … son muchos los factores que hacen obligatoria la presencia de una estrategia de despliegue de las actualizaciones. Es absurdo considerar estrategias manuales, donde sólo conseguiremos incrementar el riesgo de error derivado de la intervención humana. Normalmente será automática, y convenientemente priorizada para cubrir los riesgos más importantes en el menor plazo de tiempo, así como respetar las secuencias de actualización requeridas en cada caso.
7. Ausencia de estrategias de rollback. Bien podría ser parte del punto anterior, aunque conviene diferenciarlo para hacer hincapié en la importancia de este aspecto. Sin un plan de reversión, los errores inesperados y/o no previstos que no puedan resolverse cómodamente tras los cambios resultan mortales de necesidad. Hay que tener un as en la manga, y ese no es otro que una estrategia de recuperación para volver al punto estable inmediatamente anterior a los cambios.
8. Ausencia de planes de pruebas. Este concepto también lo podríamos ligar a la estrategia de despliegue, aunque por su importancia, lo comentamos también en un punto diferenciado. Los parches y los cambios en general pueden impactar, y de hecho, impactan gravemente en la producción. Siempre deben ser probados en el laboratorio, por inocuos que parezcan, aún a sabiendas de que los principales fabricantes someten a pruebas exhaustivas los parches antes de liberarlos. Los fabricantes tratarán siempre de maximizar el espectro de las pruebas, pero nunca podrán simular una producción real compleja, ya que las particularizaciones suelen ser abundantes y condicionadas igualmente por la presencia de productos propios interrelacionados con las plataformas y programas a parchear. Una vez evaluado el impacto, se decide sobre el despliegue, nunca antes. Cambiar programas conlleva siempre riesgos que deben ser considerados y evaluados, para poder decidir adecuadamente qué hacer, y cómo hacerlo. Con relación a las pruebas posteriores, convocar al usuario final para que certifique la idoneidad de un cambio es siempre una buena práctica, aunque hay que ser hábiles seleccionando qué se prueba, ya que, obviamente, es inviable probar todos los cambios, especialmente aquellos que son transparentes al usuario final.
9. Ausencia de conocimiento técnico suficiente. No hay nada más peligroso que actualizar una plataforma sin saber qué cambios induce, y en qué consisten los cambios. Este tipo de errores es crítico, y hace absolutamente imprescindible conocer al más mínimo detalle la actividad del parche a instalar. Aquí enlazamos con lo expuesto al principio, ¿de qué sirve un aviso de seguridad que se limita a describir el problema sucintamente, y que sólo me dice qué plataformas o versiones están afectas? Al igual que al ingerir un medicamento existe (si hay exigencia de receta, obviamente) una prescripción médica previa, y un laboratorio farmacéutico nos informa de la posología, efectos secundarios, y en general, toda la información que aparece en el prospecto, cuando desplegamos un parche importante y no trivial, lo normal es que esté prescrito por un profesional que ha considerado y conoce bien la totalidad de condiciones de contorno e implicaciones de implantar una transformación determinada. En estos términos, los parches abiertos proporcionan una ventaja consistente en poder interpretar el código, y así facilitar la comprensión del cambio propuesto, llegando incluso a modificarlo si fuera necesario.
10. Por último, y no por ello menos importante, comentar que la gestión de cambios debe ser integral, especialmente en todo aquello que tiene que ver con la interrelación de áreas involucradas. Ya no es sólo una cuestión de que el servicio de seguridad interno o externo que nos suministra la información y la organización hablen sobre cómo conviene aplicar los parches, sino que internamente, hay áreas que deben conocer los cambios para poder así planificar adecuadamente la producción, reservando espacios de tiempo para los cambios, especialmente en sistemas centrales que están en continuo funcionamiento y sometidos a múltiples modificaciones planificadas. Otras áreas, como la de continuidad, agradecerán recibir información sobre los cambios, por si éstos requieren cambios en la infraestructura o en los procedimientos de recuperación. Las áreas de diseño siempre verán con buenos ojos estar informados sobre los cambios, en caso que haya que modificar las especificaciones de un producto o desarrollo relacionado con aquello que estemos parcheando. En definitiva, constituir un comité de cambios con la representación adecuada es algo más que necesario, y otorga claridad, calidad y eficiencia a los procesos de transformación.

Espero que estos consejos os resulten de utilidad. Un saludo ;)