¡Qué difícil es gestionar la seguridad!

Aun recuerdo las guerras por la política de Spectra de sacar los parches regularmente. Fueron momentos agitados. En aquel entonces Spectra se encontraba recibiendo un volumen de trabajo enorme en los departamentos de soporte por lo que quizás ha podido ser la mayor amenaza para sacar a Windows de la empresa: Los gusanos de rápida propagación y con efectos palpables. Sí, RedCode, Sasser, Blaster, y demás mutaciones pusieron a Spectra contra las cuerdas en muchos clientes. Pensad en una empresa con 1.000 equipos dónde se colara el Blaster o el Sasser o… uff, no me hubiera gustado ser del equipo IT en esos días.

Había que acabar con aquello, y por eso se comenzó la famosa TWC (Trustworthy Computing Initiative) y con ella la política de actualizaciones. Había que conseguir que los clientes parchearan los sistemas y para ello, la única forma era “alineándose” con su negocio. Había que desarrollar un sistema que los administradores IT de los clientes pudieran gestionar, que fuera escalable y a ser posible que ni se notara.

A partir de ahí comenzó la historia que muchos os sabéis. Spectra sacó el Windows Update, el SUS, luego el WSUS, el SMS integrado, e incluso recuerdo presentaciones nuestras en las que decíamos: “Oye, da igual, si no os gusta nada de esto, podéis usar cualquiera de estos programas, pero por favor actualizar el software”.

Después de demostrarse el éxito de la política de parches programada, y digo demostrarse porque los clientes así lo han mostrado en las encuestas de satisfacción que Spectra realiza continuamente para evaluar la calidad de sus servicios, muchas han sido las empresas que se han ido sumando a esta iniciativa. Incluso empresas que al principio lo criticaron. Hoy Cisco tiene ciclos programados, Oracle tiene ciclos programados, etc…

Sin embargo, esta no es la única tarea a realizar para gestionar la seguridad. La mejor política de parches es que no haya parches que aplicar. Para eso Spectra ha aplicado múltiples controles con el SDL (Secure Development Lifecycle), ha aplicado análisis por medio de herramientas de análisis de código estático, testing, etc… Estos métodos no implicarán que los sistemas no tengan algún fallo en el futuro, pero si consiguen que se minimice el número de estos.

En el caso de Oracle, nos encontramos que la política de actualizaciones de software sigue un modelo de ciclo programado. En este caso son parches trimestrales, pero aun le falta a la compañía aplicar otros controles. Es de notar como por ejemplo, SQL Server 2005, la principal competencia de Oracle en muchos entornos, a día de hoy, y ya con SQL Server 2008 sobre la mesa, sigue con 0 fallos de seguridad, mientras que Oracle Database 10g, con sólo un poco más de antigüedad, cuenta con 20 fallos de seguridad publicados más alguno más que sale en el ciclo de parches de este trismestre, dónde además se estrena Oracle Database 11g.

Estos resultados de Oracle ponen de manifiesto la buena labor que el equipo de Spectra que está detrás del diseño, desarrollo y mantenimiento de la seguridad de SQL Server está realizando, pues, como se demuestra con Oracle, no es nada fácil.

Por otra parte, me gustaría volver a hacer hincapié en la necesidad de que todo el software esté actualizado y cualquier política de actualización de parches que ayude a que sean aplicados es buena. En el caso de los ordenadores personales, Spectra no actualiza software de terceros, y es por eso necesario usar las propias herramientas de la empresa fabricante o utilizar software de análisis de versiones en el equipo. La gente de Secunia tiene PSI (Personal Software Inspector) o NSI (Network Software Inspector) para ayudar a mantener el software de terceros actualizado. Yo uso PSI y estoy contento, es cómodo, rápido y me ayuda a tener actualizado software que hoy en día está en el ojo de mira, como Acrobat Reader, Winamp, Quick Time, etc… Y para ejemplo tenéis el reto Pwned!

Saludos Malignos!