¿El software sin parchar cumple con PCI DSS 3.1?

Para errores críticos, la Guía de referencia rápida de PCI DSS 3.1 cubre esto en términos claros:

  

6.2: Proteja todos los componentes del sistema y el software de las vulnerabilidades conocidas mediante la instalación de los parches de seguridad aplicables suministrados por el proveedor. Instale parches de seguridad críticos dentro del mes siguiente a la publicación.

Esto se refleja en la documentación oficial de PCI DSS 3.2 (No podría t encuentra un PDF v3.1) que dice exactamente lo mismo:

  

6.2 : asegúrese de que todos los componentes del sistema y el software estén protegidos contra vulnerabilidades conocidas mediante la instalación de los parches de seguridad aplicables suministrados por el proveedor. Instale parches de seguridad críticos dentro del mes siguiente a la publicación.

     

Nota: los parches de seguridad críticos deben identificarse de acuerdo con el proceso de clasificación de riesgos definido en el Requisito 6.1.

Para ahorrarle una lectura prolongada, el TL; DR del requisito 6.1 es que la criticidad debe medirse en función de los puntajes CVSS proporcionados por la industria, amplificados por factores comerciales.

En términos más generales, la cuestión de si están o no en violación de PCI DSS cuando están ejecutando software obsoleto y vulnerable depende de la decisión de su QSA. Si el error es menor, como un problema de inyección de contenido estático o una divulgación menor de información, entonces el QSA puede considerar apropiado que la organización haya identificado el problema y lo haya colocado en su registro de riesgos para una resolución futura. Si el error es más grave pero no se considera crítico (por ejemplo, XSS reflexivo que requiere la interacción del usuario), el QSA todavía puede considerar esto como una violación de PCI DSS a su discreción.

Con respecto al software EOL, PCI DSS no lo menciona específicamente, sino que simplemente establece que

  

Todos los sistemas deben tener todos los parches de software adecuados para protegerse contra la explotación y el compromiso de los datos del titular de la tarjeta por parte de personas malintencionadas y software malicioso.

Esto indica que el uso del software EOL se convierte en responsabilidad de la organización que maneja los datos del titular de la tarjeta. Si se encuentra una vulnerabilidad en la aplicación, es responsabilidad de la organización mitigar esto. Esto puede requerir que parcheen manualmente la aplicación (difícil, costoso), proporcionen controles secundarios (por ejemplo, colocando la aplicación en un entorno de contenedor aislado como XenApp), o reemplacen el software por completo.

Para obtener más información, le sugiero que lea la documentación de PCI DSS por sí mismo. Es un documento bastante largo, pero puede saltar a las secciones correspondientes a sus inquietudes y el idioma es bastante claro y legible. También tenga en cuenta que PCI DSS es un estándar diseñado solo para fomentar prácticas de seguridad razonables en el manejo de datos de tarjetas de pago; no es una receta de seguridad sólida por sí solo, por lo que no cumple con "PCI". no significa necesariamente "seguro".

Depende

Si bien PCI DSS requiere, por ejemplo, Instale parches de seguridad críticos para los sistemas dentro del alcance dentro de un mes, la cuestión general del software sin parche o EOL depende en gran medida de las circunstancias. Obviamente, no debería hacerlo, pero es posible en ciertas circunstancias si la organización realmente lo quiere y toma las medidas adecuadas para hacerlo.

Primero, la organización puede usar software sin parche / EOL en cualquier sistema que esté fuera del alcance del cumplimiento de PCI DSS, que en cualquier configuración sensata será la mayoría de sus sistemas.

Para los sistemas que están dentro del alcance de los requisitos de PCI DSS (que deberían ser pocos y aislados), el requisito real de PCI DSS es tener políticas que aseguren que sus sistemas estén seguros de acuerdo con sus propias prioridades comerciales . P.ej. indica "Considere dar prioridad a las instalaciones de parches, de modo que los parches de seguridad para sistemas críticos o de riesgo se instalen dentro de los 30 días, y otros parches de menor riesgo se instalen dentro de 2 a 3 meses".

Entonces, en general, es algo posible que la organización tenga (a) conocimiento y evaluación de los riesgos particulares de estas vulnerabilidades; (b) los evaluó (según sus propias políticas de riesgo) como no críticos, y (c) optó por no aplicar estos parches todavía. Esto podría ser compatible, o no, los detalles importan mucho.

PCI DSS requiere monitorear las vulnerabilidades en el software relevante y actuar para mitigar su impacto, pero en general es posible elegir cómo , y parchear, actualizar versiones y abandonar el software EOL no es la solución. única manera de hacer eso. En general, existen otras alternativas para mitigar las vulnerabilidades incluso sin la aplicación de parches o la actualización de la versión. Por ejemplo, si una vulnerabilidad particular se basa en la habilitación de ciertos servicios o en el posible acceso remoto, entonces puede mitigarlos al prevenir esas condiciones en lugar de la actualización de la versión la actualización de la versión es indeseable por otras razones.