En los sistemas operativos Windows existen dos aspectos de diseño que condicionan mucho el sistema:

Windows tiene un diseño monolítico

Al tener un diseño monolítico, la mayoría de sus funciones están integradas en una única unidad (kernel). La antítesis de monolítico es aquel en que la funcionalidad está separada en distintas capas, y cada capa tiene un acceso limitado a otras capas (diseño modular).

Mientras algunas deficiencias de Windows son debidas a su diseño inicial monousuario, otras deficiencias son el resultado directo de deliberadas decisiones de diseño, como es el caso de su diseño monolítico. Por ejemplo, al integrar Internet Explorer con el sistema operativo, el uso del navegador Netscape es casi irrelevante y es casi imposible no usarlo (p.e. cuando llamas al sistema de ayuda se llama directamente a Internet Explorer).

Un sistema operativo monolítico tiene dos errores que originan efectos en cascada:

* Un error en un módulo del sistema expone a todos los servicios y aplicaciones que dependen de dicho módulo. Cuando Microsoft integra Internet Explorer en el sistema operativo, se crea un sistema donde un único fallo de Internet Explorer puede exponer a todas las aplicaciones que utilizan el explorador; por lo tanto se expone todo el sistema. Si pensamos en el diseño ideal de un sistema operativo, éste está compuesto por tres capas: una en el centro, otra que envuelve la primera, y la tercera que envuelve a su vez a la anterior. El usuario sólo ve la tercera capa donde se ejecutan las aplicaciones (p.e. procesadores de texto). Las aplicaciones hacen uso de la funcionalidad que le facilita la segunda capa, como puede ser visualizar imágenes, textos, etc. La segunda capa no tiene acceso directo a partes vulnerables del sistema. Y la capa interior es la que hace el trabajo más importante ya que es la que tiene acceso directo a todas las partes vulnerables del sistema (p.e. sistema de memoria, disco,..). La última esfera se llama “kernel� y es el corazón del sistema operativo.

En la arquitectura anterior, un fallo en el sistema gráfico no puede causar un daño general al sistema ya que las funciones gráficas no tienen acceso directo al hardware. De este modo, si un usuario carga una imagen que tiene oculto un virus podemos estar seguros de que el virus no puede hacer nada ya que el sistema gráfico no tiene acceso directo al hardware.

El problema de Windows es que pone demasiado esfuerzo en la funcionalidad de la primera esfera (kernel). Por ejemplo, al integrar el sistema gráfico en el kernel el sistema gráfico puede acceder directamente al hardware (para bien o para mal). Por eso, cuando se encuentra un error en el sistema gráfico, la integración de la arquitectura de Windows, puede causar un error que permita el acceso a todo el sistema.

* Finalmente, un sistema monolítico es inestable por naturaleza. Cuando diseñamos un sistema que tiene muchas interdependencias, introducimos muchos riesgos al modificar un solo módulo. Un único cambio puede producir un efecto en cascada en los servicios y aplicaciones que dependen de él. Por ejemplo, la primera versión de Windows XP service pack 2 provoca que aplicaciones de terceros genera un gran número de fallos. Ésta es una consecuencia natural de un sistema monolítico: cualquier cambio afecta a todo el sistema.

Windows depende demasiado del modelo RPC (Remote Procedure Call)

El estándar RPC permite que un programa envíe un mensaje a una red para indicarle a otro programa que haga algo. Dicho estándar origina grandes riesgos de seguridad porque está diseñado para permitir que una aplicación le pueda indicar a otro ordenador lo que tiene que hacer. Si alguien descubre un error en el módulo RPC, la posibilidad de que utilice el fallo para decirle a un gran número de ordenadores lo que tienen que hacer es muy alta. Desafortunadamente, no siempre se puede desactivar el servicio RPC porque Windows depende de él (sobre todo si nuestro ordenador está conectado a la red).

En algunas ocasiones, se puede bloquear con un cortafuegos el puerto RPC, pero Windows depende demasiado de los mecanismos RPC para funciones básicas. Irónicamente, algunas de las vulnerabilidades más importantes de Windows Server 2003 están producidas por los fallos en el módulo RPC.

Es importante saber cuándo el módulo RPC no es necesario. Por ejemplo, si queremos crear un sitio web utilizando dos servidores: uno como servidor web y el otro como servidor de base de datos. En este caso, es necesario que el servidor de base de datos utilice RPC ya que el servidor web se encuentra en una máquina diferente y debe acceder a la base de datos a través de la red. Sin embargo, en el servidor web si podemos cerrar el puerto RPC.

Un ejemplo de la importancia del módulo RPC lo podemos encontrar en enero del 2003, cuando una vulnerabilidad del módulo RPC permitió al virus W32/SQLSlammer (http://www.vsantivirus.com/sqlslammer.htm) ser el culpable del mayor ataque a Internet (http://www.vsantivirus.com/ataque-puerto1434.htm). Exactamente a las 2.45 AM de Uruguay, según información oficial de los foros militares norteamericanos, se inició un ataque masivo del tipo D.O.S. (Denegación de servicio). En este tipo de ataques actuaron miles de ordenadores al mismo tiempo, contra blancos específicos. A las 6:00 AM de Uruguay, al menos 5 de los 13 servidores de nombres de dominio raíz (DNS) estaban fuera de servicio o con pérdida masiva de paquetes. Y poco después las líneas principales (backbones) de los Estados Unidos se encontraban saturadas por culpa del fallo en el módulo RPC.