Captura

El cambio es constante y ha llegado el momento de dejar atrás a un sistema operativo cuyo lanzamiento data de 12 años atrás: Windows Server 2003 (WS2K3).

Continuando con los EOL (End of Life), Microsoft ha anunciado el fin del soporte técnico inminente de su sistema operativo Windows Server 2003 el día 14 de julio de 2015. A partir de esa fecha, Windows Server 2003 dejará de recibir soporte técnico y actualizaciones (incluyendo actualizaciones de seguridad), lo cual significa un riesgo notable dentro de la infraestructura informática de múltiples empresas.

Según un estudio realizado por la empresa estadounidense Bit9, aproximadamente 9 millones de servidores ejecutan actualmente Windows Server 2003. Cerca de 2.7 millones de servidores quedarán desprotegidos tras la implementación de esta medida. De las empresas encuestadas, más de la mitad no saben que el soporte técnico de Microsoft finalizará en julio de 2015 y por lo menos el 14%  no cuenta con un plan de migración a una nueva versión del sistema operativo.

Tal como lo comentábamos en PCI Hispano en Abril del 2014 cuando Microsoft anunció el EOL de Windows XP (“Fin del soporte de Windows XP y su impacto en PCI DSS“), el hecho de tener un sistema operativo sin soporte por parte del fabricante implica un incumplimiento de PCI DSS:

Requisito 6.2: Asegúrese de que todos los software y componentes del sistema tengan instalados parches de seguridad proporcionados por los proveedores que ofrecen protección contra vulnerabilidades conocidas.

Igualmente, organizaciones como el US-CERT (en su Alert TA14-310A) ya venían anunciando desde el 2014 la necesidad de empezar a planificar alternativas para minimizar los problemas en cuanto llegara la fecha del EOL de Windows Server 2003.

¿Qué alternativas se tienen para gestionar el riesgo frente a esta plataforma no soportada?

Con el fin de servir de guia a comercios y proveedores de servicio que deben cumplir con PCI DSS y se encuentran frente al inconveniente de contar dentro de su entorno con una plataforma operativa no soportada, la posición del PCI SSC fue descrita en la siguiente FAQ:

Are operating systems that are no longer supported by the vendor non-compliant with the PCI DSS?

PCI DSS Requirements 6.1 and 6.2 address the need to keep systems up to date with vendor-supplied security patches in order to protect systems from known vulnerabilities. Where operating systems are no longer supported by the vendor, OEM or developer, security patches might not be available to protect the systems from known exploits, and these requirements would not be able to be met.

However, it may be possible to implement compensating controls to address risks posed by using unsupported operating systems in order to meet the intent of the requirements. To be effective, the compensating controls must protect the system from vulnerabilities that may lead to exploit of the unsupported code. For example, exhaustive reviews may need to be regularly performed to ensure that all known exploits for that operating system are continually identified and that system configurations, anti-virus, IDS/IPS, and firewall rules are continually updated to address those exploits. Examples of controls that may be combined to contribute to an overall compensating control include active monitoring of system logs and network traffic, properly-configured application whitelisting that only permits authenticated system files to execute, and isolating the unsupported systems from other systems and networks. Note that these examples may complement an overall compensating control, but these examples alone would not provide sufficient mitigation.

Additionally, if an unsupported operating system is Internet-facing, it will be detected and reported as an automatic failure by an ASV scan. Detection of unsupported operating systems in an ASV scan will need to be addressed according to Addressing Vulnerabilities with Compensating Controls section of the ASV Program Guide.

The use of compensating controls should be considered a temporary solution only, as the eventual solution is to upgrade to a supported operating system, and the entity should have an active migration plan for doing so. For assistance with compensating controls, and for questions about whether a specific implementation meets PCI DSS requirements, please contact a Qualified Security Assessor.

Bajo este criterio, a continuación se enumeran las alternativas para la gestión de este inconveniente y que se pueden implementar para cumplir con PCI DSS:

Migración/actualización a Microsoft Windows Server 2012 R2

Esta es la opción recomendada por Microsoft como camino directo frente a la notificación de finalización de soporte de Windows Server 2003. Para ello, se ha creado una herramienta web  que ofrece las siguientes alternativas:

  • Migrar a servidores en la nube (cloud) provistos por Microsoft Azure o cualquier otro proveedor (*)
  • Migrar a servidores en la nube (cloud) provistos por cualquiera de los miembros del Cloud OS Network (*)
  • Migrar a servidores virtualizados
  • Instalar el nuevo sistema operativo en un hardware independiente

 (*) Tener presente que para servidores dentro del ámbito de cumplimiento de PCI DSS,  la gestión de servicios de cloud en formato IaaS está cubierta por el requerimiento 12.8

Así mismo, Microsoft ha creado un infográfico denominado “Windows Server 2003 Roles Migration Process” en el cual analiza los procesos de migración en función del rol del servidor en la red (Directorio Activo, servidor web, servidor de archivos, servidor de base de datos, etc.)

Migración a una nueva plataforma operativa

Otra alternativa es la migración a una nueva plataforma operativa. En función de las necesidades, la plataforma completa se puede migrar o se puede delegar determinados servicios en otros sistemas operativos, como GNU/Linux, HP-UX, AIX, etc.

Uso de controles compensatorios

Si se requiere de un plan temporal mientras que se procede con una migración definitiva, el uso de controles compensatorios puede ser una opción. Estos controles alternativos deben ser consultados con un QSA previo a su implementación para validar que efectivamente el riesgo es gestionado conforme con los criterios de PCI DSS.

Algunos controles compensatorios que se pueden analizar son:

  • Uso de listas blancas de aplicación (application whitelisting)
  • Uso de controles complementarios para el aislamiento del servidor (usando firewalls personales, por ejemplo)
  • Empleando soluciones de HIDS/HIPS (Host IDS/IPS)

Desde PCI Hispano invitamos a todos nuestros lectores a adelantarse a este evento y a planificar y desplegar de forma inmediata los controles necesarios para la gestión de los potenciales riesgos asociados con un sistema operativo no soportado por el fabricante. Microsoft estima en 150 días (mínimo) el tiempo necesario para la migración de un sistema operativo a una nueva versión, por lo que es hora de ponerse manos a la obra.