La obsolescencia afecta por igual tanto a sistemas operativos de Microsoft (Windows XP, Windows 2003, Windows 7, Windows 2008 y próximamente Windows 2012 R2) como a sistemas operativos GNU/Linux. Este es el caso de la distribución Community Enterprise Operating System (CentOS).

Red Hat, la empresa patrocinadora del proyecto CentOS (adquirida por IBM en julio de 2019), anunció formalmente a finales del año 2020 las fechas del fin de vida (End of Lifetime – EOL) de la distribución CentOS para focalizarse en una nueva distribución denominada CentOS Stream:

Recordemos que Red Hat mantiene – hasta ahora – tres proyectos de GNU/Linux ubicados en etapas diferentes del proceso de desarrollo de su producto principal Red Hat Enterprise Linux (RHEL):

  • Fedora, un proyecto comunitario soportado por Red Hat en donde se implementan diferentes mejoras y correcciones del sistema que eventualmente pueden hacerlo inestable. Usado principalmente por desarrolladores y beta-testers.
  • Red Hat Enterprise Linux (RHEL), una distribución comercial (soporte por suscripción) que toma los cambios implementados en Fedora para aplicarlos y optimizarlos en un sistema operativo más estable.
  • CentOS, que usa como base la distribución RHEL y cuya principal diferencia con esta distribución es que el soporte no es de pago y es realizado por la comunidad.

Con el anuncio realizado por Red Hat, CentOS dejará de existir y será remplazado por CentOS Stream, una nueva distribución que se ubicará entre el proceso de desarrollo de Fedora y RHEL:

En términos generales, el anuncio de Red Hat implica que:

  • No habrá una versión 9 de CentOS. En su lugar, Red Hat publicará la versión 9 de CentOS Stream durante el año 2021.
  • Las actualizaciones de la distribución CentOS Linux 8 continuarán hasta el 31 de diciembre de 2021
  • Las actualizaciones de la distribución CentOS Linux 7 continuarán hasta el 30 de junio de 2024, coincidiendo con el fin del soporte de RHEL 7
  • La distribución CentOS Linux 6 se encuentra fuera de soporte (obsoleta), ya que sus actualizaciones finalizaron el 30 de noviembre de 2020.

¿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 guía 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 CentOS Stream

Esta es la opción recomendada por Red Hat como camino directo frente a la notificación de finalización de soporte. En este caso, solo se permite la migración directa de CentOS 8 a CentOS Stream 8:

Esto implicará la actualización de paquetes y dependencias del sistema operativo para continuar con las actualizaciones de la rama CentOS Stream 8.

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 HP-UX, AIX, etc. o en otras distribuciones de GNU/Linux:

  • Rocky Linux, una distribución creada por el desarrollador principal y fundador del proyecto CentOS, Gregory Kutser, como respuesta al anuncio de Red Hat respecto a la finalización de CentOS, cuya primera versión fue liberada en junio 21 de 2021.
  • AlmaLinux, otra distribución que surgió como spin-off de CentOS, desarrollada por CloudLinux como predecesor de la versión comercial de su sistema operativo Cloud Linux OS, cuya primera versión fue liberada el 30 de marzo de 2021.
  • Red Hat ofrece la migración a Red Hat Enterprise Linux (RHEL) sin coste hasta 16 sistemas en entornos de producción.
  • Ubuntu, Debian u OpenSuSE también son buenas opciones para sistemas en producción, así como el proyecto ClearOS, patrocinado por HP en sus servidores HPE ProLiant.

Finalmente, otros sistemas operativos Unix como OpenBSD, FreeBSD y NetBSD pueden ser opciones interesantes si la seguridad, el soporte en múltiples plataformas de hardware y el desempeño son elementos a tener en cuenta.

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.


David Acosta

Asesor de Seguridad Calificado (QSA) para PCI DSS, P2PE, PIN, 3DS, TSP y PIN.
CISSP Instructor, CISA, CISM, CRISC, CHFI Trainer, CEH, OPST, BS25999 LA.