Al igual que sucedió con Windows XP y con Windows 2003, Microsoft ya ha anunciado el fin del ciclo de vida («End of Life» – EOL) para dos versiones de su sistema operativo Windows: Windows 7 (todas las versiones incluyendo el Service Pack 1) y Windows Server 2008 (todas las versiones incluyendo R2). Para ambos sistemas operativos, el EOL está programado para el día 14 de enero de 2020.

A partir de ese día, estos sistemas operativos:

  • No recibirán más actualizaciones de seguridad,
  • No recibirán más actualizaciones vinculadas con mejoras o con correcciones funcionales,
  • No tendrán soporte técnico por parte del fabricante (Microsoft), y
  • Todo el contenido de los portales de soporte no será actualizado.

Esto no solamente afectará a estos sistemas operativos sino también a otras aplicaciones como Microsoft SQL 2008, Microsoft Hyper-V Server 2008, Windows HPC Server 2008 R2, Windows Server Update Services 3.0 SP2 y Windows Storage Server 2008.

A la par con esta fecha de obsolescencia, otros fabricantes y desarrolladores de aplicaciones para estas plataformas operativas (como antivirus, firewalls, monitorización, etc.) también empezarán a limitar o finalizar su soporte.

¿Qué implicaciones tiene esta noticia en el cumplimiento de PCI DSS?

El requerimiento 6.2 de PCI DSS v3.2.1 establece lo siguiente:

6.2 Asegúrese de que todo el software y componentes del sistema tengan instalados parches de seguridad proporcionados por los proveedores que ofrecen protección contra vulnerabilidades conocidas. Instale los parches importantes de seguridad dentro de un plazo de un mes de su lanzamiento. Debido a ello, tener dentro del alcance de cumplimiento un equipo con un sistema operativo sin soporte por parte del fabricante puede implicar un incumplimiento del estándar, aparte de los potenciales problemas derivados de las vulnerabilidades de seguridad no corregidas y la consecuente exposición a riesgos por parte del negocio.

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:

Los requisitos 6.1 y 6.2 de PCI DSS abordan la necesidad de mantener los sistemas actualizados con parches de seguridad suministrados por el proveedor para proteger los sistemas de vulnerabilidades conocidas. 
Cuando los sistemas operativos ya no son compatibles con el proveedor, el OEM o el desarrollador, es posible que los parches de seguridad no estén disponibles para proteger los sistemas de exploits conocidos, y estos requisitos no podrían cumplirse. Sin embargo, puede ser posible implementar controles compensatorios para abordar los riesgos planteados mediante el uso de sistemas operativos no compatibles para cumplir con la intención de los requisitos. Para ser efectivos, los controles compensatorios deben proteger el sistema de vulnerabilidades que pueden conducir a la explotación del código no compatible. Por ejemplo, puede ser necesario realizar revisiones exhaustivas con regularidad para garantizar que todos los exploits conocidos para ese sistema operativo se identifiquen continuamente y que las configuraciones del sistema, antivirus, IDS / IPS y las reglas de firewall se actualicen continuamente para abordar esos exploits. Los ejemplos de controles que pueden combinarse para contribuir a un control de compensación general incluyen la supervisión activa de los registros del sistema y el tráfico de la red, la lista blanca de aplicaciones configurada correctamente que solo permite la ejecución de archivos autenticados del sistema, y aislar los sistemas no compatibles de otros sistemas y redes. 
Tenga en cuenta que estos ejemplos pueden complementar un control de compensación general, pero estos ejemplos por sí solos no proporcionarán una mitigación suficiente. Además, si un sistema operativo no compatible está conectado a Internet, un escaneo ASV lo detectará e informará como un error automático. La detección de sistemas operativos no compatibles en un escaneo ASV deberá abordarse de acuerdo con la sección Cómo abordar las vulnerabilidades con controles de compensación de la Guía del programa ASVEl uso de controles compensatorios debe considerarse solo una solución temporal, ya que la solución eventual es actualizar a un sistema operativo compatible, y la entidad debe tener un plan de migración activo para hacerlo.  Para obtener ayuda con los controles de compensación y si tiene preguntas sobre si una implementación específica cumple con los requisitos de PCI DSS, comuníquese con un Asesor de seguridad calificado.

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 Windows 10 (para Windows 7) o a Microsoft Windows Server 2019 (para Windows 2008)

Esta es la opción recomendada por Microsoft como camino directo frente a la notificación de finalización de soporte. 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

(**) Para Windows 2008, si estos sistemas operativos son migrados a Microsoft Azure podrán recibir 3 años adicionales de actualizaciones críticas e importantes.

Así mismo, para Windows 2008 Microsoft ha creado un infográfico denominado «Windows Server 2008 and 2008 R2 EOS brochure» 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)

Invitamos 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.