| Artículos | 01 FEB 2004

Tapando agujeros

Gestión de parches de seguridad
Nachi, Klez, Lovsan, SoBig, BugBear, Swen, Blaster y Yaha son los nombres de sólo algunos de los virus y gusanos más destacados del total que asolaron las redes corporativas el pasado otoño. La epidemia es tal que la gestión de parches es hoy uno de los problemas más espinosos a los que se enfrentan los responsables de redes.

El aluvión de virus y gusanos que hoy viajan por las redes en busca de vulnerabilidades que explotar es de tales dimensiones que la gestión de los parches que aparecen para tapar esos agujeros de seguridad se ha convertido en una de las tareas más duras y penosas de los responsables de TI. Complejidad que se ve dificultada por la rapidez con que se materializan las amenazas. Un ejemplo: Blaster apareció sólo 26 días después de que Microsoft reportara la vulnerabilidad.
Otros factores están contribuyendo en los últimos tiempos a dificultar aún más la labor defensiva de los administradores de redes en este terreno. Ahora los objetivos de los ataques son tanto los clientes como los servidores, lo que acelera la propagación de sus efectos. Además, el problema no se limita a las vulnerabilidades de Microsoft. La lista de objetivos incluye también equipos de redes, además de los sistemas Unix y Linux.

Proceso proactivo
La tarea de parcheo nunca acaba, dicen los expertos, pero hay modos de aliviar la tarea. Uno, básico, es la gestión de parches, que puede servir de gran ayuda a los departamentos de TI en su lucha por encontrar el tiempo y los recursos necesarios para poner el problema bajo control. Las implicaciones en costes son enormes. Aberdeen Group fija en 2.000 millones de dólares anuales el coste que representa la gestión de parches.
Sin herramientas de gestión de parches, los administradores de redes tendrían que dedicar muchísimo tiempo a hacer su seguimiento, tapando agujeros según vayan apareciendo. Pero en los pasados dos años, la complejidad de las redes y el número de parches que aparece convierten este método primario en tan ineficaz como, en muchos casos, inviable.
Ahora que ya existen en el mercado un buen número de productos y servicios de gestión de parches, es posible avanzar un paso más y utilizarlos siguiendo un enfoque sistemático, dentro de un proceso proactivo. La investigación, priorización y despliegue de parches ha de encuadrarse dentro de la gestión global de riesgos y cambios.
Antes de todo ello se debe consultar a los responsables del negocio a fin de decidir el nivel de tolerancia corporativa respecto de las potenciales vulnerabilidades, fijando, por ejemplo, las relaciones de prioridad entre seguridad y productividad. Así, se podría llegar a un escenario teórico en el que para maximizar la seguridad a expensas de la productividad, habría que desactivar los sistemas de producción cada vez que un fabricante publica un parche de software relevante; no se deberían poner los sistemas de nuevo en funcionamiento hasta que el parche se hubiera descargado, probado en detalle y, finalmente, desplegado. Por supuesto, en la práctica tales medidas extremas son inviables, pero dejan ver hasta qué punto la gestión de parches es un componente de la gestión de riesgos corporativa.
Lo mismo sucede con la gestión de cambios, que representa un enfoque sistemático para hacer el seguimiento de los cambios de TI. De hecho, para aquellas empresas en las que los procesos de gestión de cambios tienen una gran presencia, la gestión de parches simplemente supone una tarea más, lo que reduce enormemente el tiempo dedicado a estas tareas.
El problema es que muy pocas empresas tienen en marcha este tipo de procesos. Según CERT (www.cert.org), el mayor centro de información teórica y práctica sobre problemas de seguridad en Internet, dice que hasta el 80% de los ordenadores corporativos tienen problemas provocados por una configuración inapropiada de los servidores. En cualquier caso, los expertos aseguran que la gestión de parches puede representar una buena manera de introducirse en la más amplia gestión de cambios. Incluso sugieren considerar el plan de gestión de parches como una fase previa de pruebas de una posterior política global de gestión de cambios.

Inventario, punto cero
Usuarios, analistas y fabricantes coinciden en que un paso crucial para simplificar la “tormenta” de la gestión de cambios es partir de la realización de un inventario de la infraestructura TI en su totalidad, un trabajo de proporciones sin duda espeluznantes para las grandes organizaciones; pero, aún así, necesario. Si no se dispone del mapa completo del entorno corporativo, no se sabrá que se necesita; es más, disponer de dicho mapa ayudará a descubrir quién está parcheando qué. No es infrecuente encontrarse con que cada departamento esté haciendo un uso distinto de los parches.
Tal inventario informa de cuestiones relativas a los sistemas presentes en el entorno; sus aplicaciones y sistemas operativos, incluyendo las versiones; los parches que han sido aplicados; su propiedad e información de contacto, de importancia en las grandes compañías; y cualquier amenaza conocida pero sin parchear presente en los sistemas. Una vez recogidos estos datos, es preciso actualizarlos frecuentemente y ponerlos a disposición de todos aquellos que podrían necesitarlos, como los responsables de redes, los responsables de seguridad y los administradores de sistemas. Y una vez que esta hercúlea tarea de inventariar la infraestructura global de la empresa esté completada, hay que realizar actualizaciones periódicas, que, como regla común, podrían ser trimestrales.
Con esta primera base consolidada, ya se está en condiciones de crear una política de gestión de tareas, o de optimizar la existente. El primer paso es mejorar la evaluación de los parches y de la necesidad, y con qué urgencia, de desplegarlos en los sistemas de la empresa. Un buen consejo en este punto es actuar con frialdad, y no tomar una decisión antes de analizar las recomendaciones publicadas por los fabricantes y organizaciones del tipo de CERT y Sans.org, pero teniendo en cuenta que, al ser de aplicación general, suelen tener una naturaleza muy amplia.
Cuando, el pasado mes de agosto, surgieron noticias de la existencia de una vulnerabilidad en las implementaciones por parte de un buen número de fabricantes del protocolo SNMP, muy difundido en todo el mundo para monitorizar y gestionar dispositivos de red, la primera impresión que circuló entre los usuarios es que todas las máquinas Windows necesitaban el parche que Microsoft se apresuró a lanzar. Pero, en realidad, lo que el boletín en cuestión afirmaba es que sólo las máquinas que corrían SNMP lo necesitaban, lo que reducía el número de dispositivos al 5% del total.

Entorno de pruebas
Una vez que se decide aplicar un parche, antes conviene probarlo. Lo ideal sería hacerlo en un entorno de laboratorio específico, y, si la prueba tiene éxito y se demuestra que el parche no crea problemas, lanzarlo al 10% de los servidores menos críticos; de este modo, si falla, es relativamente fácil eliminarlo. Otra opción es poner en cuarentena los gusanos y los virus en segmentos de red concretos para parchearlos convenientemente. Sin embargo, aunque estos métodos son de gran atractivo, las presiones de tiempo y las altas cargas de trabajo obligan a muchas empresas a aplicar los parches, tras una serie limitada de pruebas, directamente

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información