A principios de 2002 se presentaba en España, bajo el nombre de
Strategic Technology Protection Program (STPP), la iniciativa de
Microsoft para mejorar la seguridad de sus productos. Tras la
experiencia acumulada en estos últimos meses podríamos resumirla
en una sola palabra: automatización.
Bajo el título de «Microsoft STPP, ¿estrategia tecnológica o lavado
de cara?», intenté por aquel entonces balancear entre los pros y
los contras de la iniciativa, con un pequeño listado de problemas
por resolver que Microsoft arrastraba y que entendía eran críticos
(http://www.hispasec.com/unaaldia.asp?id=1213).
En la situación actual, tras casi un año de STPP, parte de esos
problemas se han minimizado, otros se agravan, y surgen nuevas
interrogantes.
El usuario final mejora su seguridad
Queda claro que Microsoft ha puesto especial empeño en facilitar la
vida a los usuarios automatizando todo el proceso de actualizaciones,
tanto en el ámbito de notificaciones, descarga e instalación. Parece
que nos dirige hacía sistemas totalmente autosuficientes y
transparentes, que se encargarán por nosotros de estar actualizados
puntualmente.
Este planteamiento, que ya se intuía con servicios como Windows
Update y que se hacen más evidentes en sistemas como Windows XP,
corrige en gran parte los problemas de regresión de vulnerabilidades
de antaño, al menos los inducidos directamente por el usuario.
Básicamente, estos problemas aparecían por la instalación de parches
específicos sin el orden adecuado, lo que llevaba a sobrescribir
bibliotecas y componentes con versiones más antiguas y, por tanto, la
aparición de vulnerabilidades anteriores. Con los nuevos servicios de
actualización automática, como Windows Update, es el propio sistema
el que decide que parches y en que orden deben ser instalados,
minimizando este riesgo.
Por contra, esta misma automatización, agrava el enmascaramiento
de nuevas versiones y funcionalidades con la excusa de la seguridad,
lo que en algunos casos ha supuesto la aparición de nuevas
vulnerabilidades. Lo ideal es que cada vulnerabilidad cuente con un
parche específico diseñado para corregirla. Sin embargo, Microsoft
suele ofrecer como solución la actualización a nuevas versiones del
software o componente afectado, algunas veces de forma pública, y
otras veces ocultando las nuevas funcionalidades o modificaciones
en un parche de seguridad.
Las implicaciones de esta política en el ámbito de seguridad son
varias, por un lado las nuevas funcionalidades incorporadas en los
parches o nuevas versiones son en muchos casos origen de nuevas
vulnerabilidades, problemas que no habrían aparecido en los
componentes anteriores si se hubieran limitado a corregir la
vulnerabilidad. Por otro lado, esta práctica es la que provoca la
mayoría de incompatibilidades o mal funcionamiento del sistema con
el hardware / software ya existente tras haber realizado una
actualización de seguridad.
En líneas generales, en lo que respecta al usuario final y balanceando
lo dicho anteriormente, la iniciativa STPP representa un avance
significativo, ya que ha mejorado los tiempos de actualización de los
PCS y facilita en gran manera la tarea al usuario.
Pérdida de control por parte de los administradores y profesionales
Sin embargo, desde el punto de vista de los administradores de
sistemas y profesionales, tanta automatización y abstracción se
traducen en un menor control, que ya de por sí era bastante
limitado en plataformas Microsoft.
De entrada, tanta actualización automática seguro que pone en alerta
a más de un administrador de sistemas, que ya habrá experimentado
como un simple parche a demanda, o el Service Pack de turno, ha podido
volver inestable ciertos servicios, cuando no a todo un servidor. Con
esta experiencia, no es de extrañar que algunas políticas corporativas
contemplen tests de los parches en equipos de pruebas, durante al
menos un mes, antes de pasarlos a los sistemas de producción.
Con STPP se plantean nuevos problemas, ya que Microsoft está optando
en muchas ocasiones por «macro parches» acumulativos, que resuelven
múltiples vulnerabilidades con una sola actualización. Mientras antes
un administrador de sistemas podía decidir si instalar un parche
específico o retrasarlo, dependiendo de sí afectaba a la configuración
de su servidor o si podía prevenirlo por su cuenta (por ejemplo con
reglas en el firewall o modificando la configuración del sistema),
ahora esa opción es muy limitada, por lo que tendremos que instalar
los «macro parches» aun a sabiendas de que algunas correcciones no las
necesitaba nuestro sistema, con las implicaciones que ello pueda
acarrear en cuanto a estabilidad.
Por otro lado, la tendencia parece que apunta a que cada vez más los
sistemas de Microsoft realizarán operaciones y actualizaciones
automáticas, transparentes al usuario, dependiendo de conexiones
externas vía Internet. Algunas de estas tendencias ya pueden verse en
los sistemas de actualización automáticos actuales o en Windows XP,
sin entrar en otras consideraciones como pueden ser el control que
Microsoft puede establecer a través de estas vías, políticas de
control de licencias o fidelización (sólo permitir actualizar a los
usuarios suscritos) y sus implicaciones en el ámbito de la privacidad.
Si extrapolamos esto a un servidor, los administradores de sistemas
tendrán aun menos control o, dicho de otra forma, contarán con un
«superusuario» por encima de ellos: Microsoft.
Windows NT, crónica de una muerte anunciada
Ante este panorama algunos podrían decidir no migrar hacia los nuevos
sistemas de Microsoft y quedarse con plataformas como por ejemplo
Windows NT, sistemas con años en producción, bien conocidos por los
administradores, con múltiples Service Packs a sus espaldas que han
ido puliendo sus defectos y mejorándolo, que ya se encuentran bien
implantados, cumplen su cometido y no necesitan de las nuevas
funcionalidades que propone Microsoft.
Desgraciadamente Windows NT tiene sus días contados, y eso es fácil
de predecir, bien observando la historia reciente de Microsoft, bien
dejándose llevar por simples reglas de mercado: hay que vender los
nuevos productos. En este apartado la seguridad juega un papel
crítico, incluso como herramienta para forzar a la actualización.
Igual que no hay solución para ciertos problemas de seguridad en
Windows 95 o en Internet Explorer 5.0, obligando al usuario a
actualizar a Windows 98 o IE6.0 si quiere estar seguro. Es sólo
cuestión de tiempo que Microsoft deje de dar soporte a Windows NT.
Posibles mejoras
Desde el punto de vista del administrador de sistemas lo ideal sería
ofrecerles la posibilidad de obtener un mayor control. Aunque las
comparaciones en este ámbito son casi inevitables, evitaré entrar
en el eterno debate entre la comunidad Open Source y Microsoft,
no en vano algunas posturas que se podrían copiar y adoptar pueden
sonar a pura quimera. Así que las peticiones serán escasas y simples.
De entrada sería importante que Microsoft, además de los macro
parches acumulativos, ofreciera la posibilidad de obtener parches
específicos e individuales, de forma que el administrador pudiera
optar por una instalación personalizada de los mismos, según
configuración y necesidades.
Llegados a este punto es vital que se ofrezca información más al
detalle sobre las vulnerabilidades, entrando más en profundidad
en la explotación y opciones de mitigación del ataque, así como
en los parches propuestos (que componentes serán actualizados,
que dependencias crea dicha actualización, si se introducen
modificaciones adicionales, etc.).
Bienvenida sería la opción de desactivar todas las dependencias y
conexiones externas y automáticas, tanto a nivel de servidores como
de estaciones de trabajo. Así como documentar el proceso de
WindowsUpdate y facilitar su personalización, posibilitando a los
administradores establecer sus propias políticas y sistemas internos
de autoactualización según necesidades. Aunque Microsoft ya dispone
de soluciones propietarias para la distribución de parches, su
adopción sólo optimiza recursos y cambia el problema de sitio, pero
no permite corregir la situación de dependencia y falta de control.