Los enemigos de los parches

El parcheado de los sistemas informáticos es una de las medidas mas importantes de seguridad que deben seguirse e implantarse en cualquier organización. Recientemente hemos podido ver como grandes organizaciones gubernamentales han sufrido incidentes de seguridad por propagación de gusanos, que podían haberse evitado en gran parte de una manera sencilla simplemente aplicando los parches. Si están pensando lo mismo que yo, se preguntarán cómo es posible que cualquier usuario domestico mantenga actualizado su equipo siempre que sale una vulnerabilidad y en estas organizaciones no apliquen el parcheado de manera correcta.

Francamente, no tengo la respuesta a la pregunta, pero en esta entrada pretendo hablar de cuáles son los problemas a los que los administradores TIC se deben enfrentar cuando tratan de implantar políticas de parcheado. A estos problemas los voy a llamar “Los enemigos de los parches”, que les detallo a continuación:

— Ausencia de política de parcheado. Si una organización no se plantea de manera consciente que debe actualizar sus sistemas, es muy posible que no se actualicen, o se actualicen sólo las cosas que sean automáticas. E incluso en este último caso, las actualizaciones automáticas si no se controlan pueden dar lugar a problemas de funcionamiento, compatibilidad y reinicios no programados.

Solución: Instáurese una política de parcheado y actualización de los sistemas, que contemple horarios, personal, procedimiento, y que como siempre deberá de venir aprobada por dirección.

— No disponer de herramienta de inventario. Obviamente, si no se sabe lo que se tiene es difícil mantenerlo actualizado.

Solución: Adquiera e instale un software de inventario automatizado, y no permita la instalación de nada que no se gestione con las actualizaciones automáticas del sistema (o que no venga autorizado por el Departamento de TI).

— No disponer de herramienta de alerta por parches. Los actualizadores automáticos, como los de Microsoft, cada vez están mas implantados, pero no cubren todo el software. En estos casos, ¿quién esta al tanto de que no aparezca una nueva vulnerabilidad en la BBDD Oracle o PostreSQL? ¿O en el plugin de foros instalado en el portal?

Solución: Debe enlazarse el inventario de software con las alertas de los fabricantes, si no es posible de una manera automática, de una manera manual.

— Software que no es base del sistema operativo. Todos los sistemas operativos disponen de un sistema de paquetes con los que es relativamente sencillo saber si hay actualizaciones, pero ¿qué pasa con otros productos instalados que no están en esa lista? ¿Alguien se preocupa por ellos?

Solución: Disponer de inventario automatizado de software, que incluya no sólo los paquetes del sistema, sino también otros paquetes adicionales. Asumo y reconozco que esto no siempre es sencillo, pero vale la pena hacer el esfuerzo; por ejemplo, piensen ustedes de como tener un inventario automatizado de BBDD Oracle en entorno Unix. Para entornos Microsoft, es especialmente recomendable utilizar WSUS (Windows Server Update Services), que facilita las actualizaciones distribuidas y la aplicación de políticas progresivas de instalación de parches.

— Productos de terceros incompatibles con los parches o sin soporte. Dicho de otra forma: tengo que poner el Service Pack 2 en un servidor Windows que tiene ademas una aplicación crítica del Call Center de la cual no tengo ni soporte ni el contacto de la empresa, y que si actualizo igual deja de funcionar. Cosas terribles como “Ese equipo no lo parchees que lleva el SCADA”.

Solución: Es necesario disponer de un contrato de soporte con todos los aplicativos que tenga, no sólo por los parches sino por cualquier problema que pueda tener; este aspecto debería contemplarse contractualmente y formalmente en el momento de la compra. Esto puede implicar que debido a una actualización se deba contratar los servicios de productos de terceros.

— Software hecho a medida. Este es un caso especial del anterior, pero que tiene más complejidad si cabe, ya que es relativamente sencillo contratar a una empresa para que te dé soporte de un producto comercial, pero es más complicado el disponer de soporte de desarrollos (si no se tienen en un primero momento).

Solución: Deben tenerse ese contacto, ya que si no es por el parcheado, en algún otro momento tambien lo necesitará. Esto obviamente tendrá un coste económico asociado, y debería contemplarse contractualmente y de manera formal en el momento de la compra.

— Ausencia de entornos de preproducción. Por muy inocuo que te diga el fabricante que es un parche, lo mejor es probarlo antes de implantarlo en producción. El problema es que en muchas ocasiones este entorno de preproducción ni esta, ni se le espera. Después de todo, ¿quién tiene un entorno de preproducción del servidor de Call Center? ¿Y del SCADA?

Solución: Para aquellas aplicaciones críticas de negocio, defina y adquiera un entorno de preproducción, o utilice para la aplicación de parches aquellos sistemas menos críticos cuyo entorno es similar.

— Equipos con escasa conectividad. Un problema frecuente a la hora de parchear son aquellos equipos que no disponen de una buena conectividad. Por ejemplo ¿cómo se parchean los equipos portátiles de los comerciales que solo se conectan por 3G y VPN? ¿O cómo se parchean los portátiles que nunca se usan porque están guardados siempre en un armario? ¿Y esos sistemas que carecen de salida a Internet?

Solución: La gestión de inventario y parches debe ser capaz de detectar equipos que no se hayan conectado y no estén actualizados, forzando la actualización, aunque sea acercándolos al servicio de soporte. Asimismo, en algunos casos puede ser necesario descargar los parches del fabricante desde una máquina con conectividad y aplicarlos manualmente.

— Islas o Reinos de Taifas. Todos conocemos algún caso: “las políticas de parches se aplican en todos los equipos, menos en los del departamento de I+D, que se lo gestionan ellos mismos por su idiosincrasia particular”.

Solución: Implántese la política de manera que cubra todos los casos y excepciones posibles, dado que no hay que olvidar que un equipo infectado en el departamento de I+D puede afectar a toda la organización, y eso no será “culpa” de I+D.

— Ausencia de administración centralizada. No va a ser posible gestionar los parches de equipos que no estén administrados de una manera centralizada. Esto parece de perogrullo, pero es uno de los principales problemas en entornos pequeños o medianos, o en organizaciones en las que tienen delegaciones pequeñas que son gestionadas de manera independiente por la ausencia de personal técnico especializado en cada una de ellas.

Solución: Deben implantarse herramientas de gestión centralizadas, inventario, distribución de software, acceso remoto, etc…

Estas y muchas otras cosas más deben de tenerse en cuenta cuando se implantan políticas de parcheado en las organizaciones, por lo que queda claro que, lejos de lo algunos puedan pensar no es una tarea estrictamente técnica, sino que viene apoyada por procedimientos, políticas y a veces, mucha mano izquierda.

(N.d.E.: La foto está sacada de Sociedadanonima.org, un extravagante blog donde estuve escribiendo un tiempo.)