En esta cuarta entrega de la serie “Análisis de PCI DSS 4.0” se presenta una revisión a los cambios en los requerimientos 5 y 6 del estándar PCI DSS ocurridos entre las versiones 3.2.1 y 4.0. Estos dos requerimientos están enfocados a la protección a nivel de software para prevenir, detectar y mitigar la explotación de vulnerabilidades en los componentes del sistema dentro del alcance.

En la versión 4.0 de PCI DSS estos requerimientos fueron renombrados para aclarar y ampliar su campo de acción, subsanando algunas de las restricciones identificadas en la versión 3.2.1.

Requerimiento 5: Protect All Systems and Networks from Malicious Software

Desde su primera versión el estándar PCI DSS ha incluido controles para la detección, remoción, bloqueo y contención contra código malicioso (malware). Sin embargo, hasta la versión 3.2.1, dichos controles se referenciaban genéricamente como “software antivirus” (anti-virus software), lo cual era incorrecto desde un punto de vista estrictamente técnico, ya que este tipo de soluciones no solamente protege contra virus (como su nombre lo indica) sino también contra otras variantes de software malicioso conocidas (gusanos (worms), troyanos (trojan horses), ransomware, spyware, rootkits, adware, backdoors, etc.).

Por ello, a partir de la versión 4.0 de PCI DSS se emplea el término “antimalware” para cubrir no solamente los virus sino también todas las demás familias de código malicioso, lo cual es más congruente con el objetivo de este requerimiento.

Diferencia entre «antivirus» y «antimalware»

Otros cambios incorporados en esta nueva versión del estándar fueron:

• Para evitar las ambigüedades vistas en versiones anteriores del estándar acerca de cuáles sistemas operativos deberían tener instalada una solución antimalware y cuáles no, se ha optado por enfoque más operativo: la entidad debe realizar una evaluación periódica para determinar los componentes del sistema que deben requerir una solución antimalware. Todos los demás activos que se determine que no son afectados por malware deben ser incluidos en una lista (req. 5.2.3).
• Las actualizaciones de la solución antimalware deben ser realizadas de forma automática (req. 5.3.1)
• Por fin se incorpora de forma explícita el término “escaneo en tiempo real” para la solución antimalware (este es un tipo de escaneo persistente y continuo en donde se realiza un análisis en búsqueda de riesgos de seguridad cada vez que se recibe, se abre, se descarga, se copia o se modifica un archivo). Anteriormente, se hacía referencia a que los mecanismos antimalware deberían estar ejecutándose activamente (actively running), lo que daba pie a diferentes interpretaciones.
• Se incorpora el análisis continuo de comportamiento de sistemas o procesos como un método de escaneo de la solución antimalware aceptado, como alternativa a los tradicionales escaneos periódicos (programados y bajo demanda) y escaneos en tiempo real (real-time u on-access) – Req. 5.3.2.
• En cuanto a los escaneos programados, su periodicidad debe ser configurada con base en un análisis de riesgos (req. 5.3.2.1).
• Se incorpora la obligatoriedad del escaneo de medios de almacenamiento removibles (req. 5.3.3).
• Se alinea la retención de los logs de la solución antimalware a los criterios generales de gestión de logs (12 meses con disponibilidad de los últimos 3 meses para análisis inmediato – req. 5.3.4).
• Se incorpora la obligatoriedad del uso de mecanismos para detectar y proteger contra ataques de phishing (req. 5.4.1). En este caso, los controles a implementar van más allá de la instalación de un agente antimalware, implicando configuraciones a nivel de servidores de correo electrónico (sin que por ello estos servidores tengan que estar en el alcance).

Requerimiento 6: Develop and Maintain Secure Systems and Software

Al igual que la gran mayoría de requerimientos de PCI DSS, el requerimiento 6 tampoco fue ajeno al cambio de su nombre, que en esta ocasión amplia su alcance para cubrir no solamente aplicaciones sino software en general. En esa línea, se aclara que los controles de este requerimiento aplican a todos los componentes del sistema, con excepción de la sección 6.2 que aplica únicamente a software personalizado o desarrollado internamente.

Los cambios más relevantes en los controles para software personalizado o desarrollado internamente son:

• El orden de los controles en el requerimiento fue cambiado, organizando en la sección 6.2 los controles para software personalizado o desarrollado internamente, la sección 6.3 para la gestión de actualizaciones y vulnerabilidades, la sección 6.4 para la protección de aplicaciones web con acceso público y la sección 6.5 para gestión de cambios.
• Se priorizó la aplicación de controles de seguridad en software personalizado o desarrollado internamente para prevenir vulnerabilidades a lo largo de las fases del ciclo de vida de desarrollo.
• Se incorporaron detalles acerca del contenido de la formación para desarrolladores (req. 6.2.2):
  • Debe ser realizada anualmente
  • Debe cubrir los lenguajes de programación empleados
  • Debe incorporar información acerca de las herramientas empleadas para la detección de vulnerabilidades
• En cuanto a la revisión de código, debe ser realizada de acuerdo con las guías de desarrollo seguro, incluir revisiones de vulnerabilidades existentes y emergentes y aplicar correcciones antes de su puesta en producción (req. 6.3.2).
• Se agruparon algunas de las vulnerabilidades “tradicionales” en desarrollo de software (SQLi, XSS, CSRF, etc.) en un único requerimiento (req. 6.2.4).

Por otro lado, para la gestión de vulnerabilidades de seguridad se agregaron/complementaron los siguientes controles:

• En la versión 4.0 de PCI DSS, req. 6.3.3 (antiguo 6.2), los parches «altos» y «críticos» se deben instalar dentro del primer mes después de su publicación. En PCI DSS v3.2.1 solo se requería la instalación de los parches «críticos».
• La identificación de vulnerabilidades debe cubrir no solo el software “base” (sistemas operativos, bases de datos, aplicaciones, equipos de red) sino también librerías, compiladores, lenguajes de programación
• Se menciona por primera vez el concepto de “bug bounty” como herramienta adicional para que terceras personas puedan reportar vulnerabilidades a la entidad (req. 6.3.1).
• Se requiere la creación de un inventario de software personalizado o desarrollado internamente, incluyendo componentes vinculados como librerías, servicios, frameworks, etc. (req. 6.3.2, que entrará en vigor el 31 de marzo de 2025).
• A partir del 31 de marzo de 2025, será obligatorio el uso de una herramienta técnica automatizada para detectar y prevenir ataques web en tiempo real (como un Web Application Firewall – WAF, por ejemplo). La ejecución periódica de herramientas para el escaneo de aplicaciones web, que se ofrecía como opción para la protección de aplicaciones web con acceso público, dejará de ser válido.
• En el control 6.4.1 (protección de aplicaciones web con acceso público) se menciona la tecnología de Runtime Application Self-Protection (RASP) como herramienta complementaria al Web Application Firewall (WAF).
• Finalmente, se incorporaron en el estándar muchos de los criterios que se habían presentado en el documento Information Supplement: Best Practices for Securing E-commerce, incluyendo la implementación de métodos técnicos para la protección de scripts en páginas de pago cargados y ejecutados en el navegador del usuario, incluyendo:
  • Controles para confirmar que cada script es autorizado
  • Controles para verificar la integridad de cada script
  • Un inventario de todos los scripts empleados con su justificación relacionada.

Este control será válido a partir de marzo 31 de 2025.

Por otro lado, en cuanto a la gestión de cambios:

• Se permitirá el uso de números de PAN reales (live PANs) en entornos de preproducción si estos entornos están incluidos en el CDE y protegidos de acuerdo con PCI DSS.
• En la gestión de cambios se incluyen los cambios realizados a software personalizado o desarrollado internamente.

En el siguiente artículo de esta serie se analizarán los requerimientos 7, 8 y 9 de PCI DSS, focalizados en la gestión del control de acceso físico y lógico al entorno.

Referencias

• Information Supplement – Best Practices for Securing E-commerce https://www.pcisecuritystandards.org/pdfs/best_practices_securing_ecommerce.pdf
• Defending Against Phishing & Social Engineering Attacks – A Resource Guide from the PCI Security Standards Council https://www.pcisecuritystandards.org/documents/PCI_SSC_Phishing_Resource_Guide_-v06.pdf