Skip to content

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

Publicado por Sergio Hernando el 1 septiembre 2008

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 ;)

Be Sociable, Share!
5 comentarios
  1. 1 septiembre 2008
    Mini permalink

    Hola hola
    Yo pensaba más o menos como has escrito. Sin embargo ahora lo veo de otra manera. Las condiciones actuales son de una red hostil. Se libera un parche y en cuestión de días, a veces horas, ya aparece un exploit que ataca a los sistemas vulnerables.
    En esta situación hay que minimizar el daño. Si empezamos con análisis de impacto, planes de pruebas, estrategias de desplieugue, etc. llegaremos tarde: el sistema ya habrá sido atacado para cuando queramos aplicar un parche.
    Como te decía, me he vuelto un pragmático. Ahora aplico los parches en mi red inmediatamente siguiendo una progresión. Comienzo con unos pocos sistemas no críticos, poco después aumento el número de sistemas parcheados, poco después comienzo a incluir servidores más importantes, etc.
    Mi plan es tener los parches aplicados en 24h máximo.
    Sé que puede parecer arriesgado, sobre todo desde un punto de vista de auditoría. Antes yo también pensaba así, pero hoy la situación ha cambiado: he asumido que va a haber daños. Y me he preguntado ¿qué es lo que prefiero? ¿que me claven un cuchillo en el brazo o que me disparen en el pecho?
    Un saludo
    Los contenidos del blog han mejorado en las últimas semanas deasde mi punto de vista.

  2. 1 septiembre 2008

    Paaahhh… pedazo de post! Es un tema muy interesante y justamente el otro día discutíamos algunos de estos conceptos aquí en el trabajo.

    Por un lado, entiendo el punto de vista que plantean en el comentario anterior. Yo creo que depende del caso habrá que aplicar rapidamente el parche o hacer una evaluación de impacto como corresponde.

    Por otro lado, lo que me interesa comentar es el putno de los servicios de alertas, ya que yo creo que la información que brindan muchos de ellos es escasa. Como vos decís, el nobre de la vulnerabilidad, las versiones afecatadas y muchas veces hasta ahí llegamos.

    En ese caso, creo que los administradores deben tomarse el trabajo:
    1. uscar un servicio que brinde información más completa.
    2. o bien de hacer una búsqueda por varios sitios web para conocer mejor el parche y el problema.

    En fin, es un tema muy complejo y, como todo, deberá adaptarse la gestión al tamaño y características de la organización.

    ¡Felicitaciones por el post!

  3. 1 septiembre 2008

    mini,

    Gracias por el comentario, me alegra ver puntos de vista distintos al mío :)

    Te doy la razón en que efectivamente, las amenazas se han incrementado y sofisticado, y que por tanto, la probabilidad de daño es cada vez mayor. Nadie discute ese punto. Creo que es obvio que ante un evento crítico, por ejemplo un 0 day en una máquina expuesta al tráfico anónimo y un agujero listo para explotar, hay que actuar rápido. En estos casos también se puede analizar el riesgo y hacer una prueba en cuestión de poco tiempo, pero lo que prima es cerrar el grifo, y ya afinaremos la cañería. Este modus operandi tiene cabida en lo expuesto, aunque es secuencial, como tú mismo explicas.

    Aún en estos supuestos, hay que tener en cuenta que en el caso de una máquina expuesta deberían existir otros mecanismos que mitiguen el riesgo y que permitan no tener que precipitarse en la solución de un problema, como por ejemplo, cortafuegos, sondajes IDS e IPS y segmentación de redes adecuada, con lo que tirarse al charco “a lo loco” puede ser precipitado. Cada caso requerirá el conveniente estudio, qué duda cabe.

    El post está más orientado a la gestión ordinaria de parches, aquella en la que sí podemos articularla con cabeza, pensando qué hacer y escogiendo entre las distintas opciones, y en la que el riesgo primario no es un atacante externo o interno descontrolado, sino echar abajo una producción por no hacer las cosas bien.

    Ah, y por cierto, me alegro que encuentres los últimos contenidos más de tu agrado. Espero que la línea sea continuista en este sentido :)

    Un saludo,

  4. 1 septiembre 2008

    Sebastián,

    Gracias por la aportación a ti también. Como bien dices, los servicios de alertas suelen ser limitados, y no están integrados plenamente en las organizaciones, lo que plantea los problemas que hemos comentado.

    En caso de que el trabajo se haga en casa, los administradores, efectivamente, asesorados por el personal de seguridad, que son los que deben decidir qué parchear y cómo, deben aplicar los parches sugeridos disponiendo de la máxima información posible. Siempre es bueno que los administradores conozcan los parches, pero quienes deben conocerlos en profundidad, en términos de aplicabilidad, conveniencia y resolución de conflictos de seguridad, son los administradores de seguridad.

    Un saludo, y al igual que le decía a Mini en el comentario anterior, me alegro de que te haya gustado el texto :)

Trackbacks & Pingbacks

  1. Webeando 2.0 « Mundo Binario

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS