En marzo de 2022, el Consejo de Estándares de Seguridad de la Industria de Tarjetas de Pago (PCI SSC por sus siglas en inglés) actualizó el estándar PCI DSS en su versión 4.0. Hoy en día, se encuentran vigente los estándares PCI DSS en su versión 3.2.1 y 4.0, sin embargo, la v3.2.1 será retirado el 31 de marzo de 2024, luego la única versión vigente será la versión 4.0.
Las empresas han tenido un periodo de transición de dos años desde la publicación del estándar PCI DSS v4 para adaptarse a la nueva versión y tendrán uno más, hasta el 31 de marzo del 2025 para implementar nuevos requerimientos que a la fecha son consideradas buenas prácticas de seguridad.
Los OBJETIVOS de la v4.0 son las siguientes:
- Continuar satisfaciendo las necesidades de seguridad que surgen en la industria de pagos. Porque es importante que las prácticas de seguridad evolucionen a medida que las amenazas cambian. Ejemplos:
- Requisito para aumentar la longitud de las contraseñas de siete caracteres a una longitud mínima de 12 caracteres (o si el sistema no admite 12, una longitud mínima de 8 caracteres).
- Nuevo requisito de mecanismos automatizados para detectar y proteger el personal contra los ataques de phishing.
- Fomentar la seguridad como un proceso continuo. Porque es importante que se considere a la seguridad como un proceso continuo, para lo cual se debe evaluar y mejorar la seguridad de manera constante. Ejemplos:
- Se deben asignar claramente los roles y responsabilidades para los 12 requisitos del estándar.
- Se contempla una guía para ayudar a comprender cómo implementar y mantener la seguridad. Se incluye una guía por cada requisito del estándar que contempla secciones como: propósito, buena práctica, definiciones, ejemplos, información adicional.
- Aumentar la Flexibilidad a las organizaciones que utilizan diferentes métodos para alcanzar los objetivos de seguridad. Porque es importante que se considere más opciones para lograr el objetivo de un requisito y apoye a la innovación de la tecnología de pagos. Ejemplos:
- La frecuencia para realizar ciertas actividades queda a discreción de la entidad, siempre que se documente y respalde por el análisis de riesgos.
- Se contempla un nuevo método para implementar y validar los requisitos de PCI DSS denominado “Enfoque Personalizado”. Este enfoque apoya a la innovación en las prácticas de seguridad, permitiendo a las empresas mostrar cómo sus controles de seguridad cumplen con los objetivos de PCI DSS.
- Reforzar los métodos de validación. Es importante que la validación y la presentación de los reportes de cumplimiento apoyen a la transparencia y la granularidad. Ejemplo:
- Mayor alineación entre la información reportada en el Reporte de Cumplimiento (ROC) o el Cuestionario de Autoevaluación de Cumplimiento (SAQ) y la información resumida en la Atestación de Cumplimiento (AOC)
TiPOS de CAMBIOS
- Requisito en Evolución. Cambios para garantizar que el estándar esté al día ante las amenazas y tecnologías emergentes, y con los cambios en la industria de pagos. Ejemplos:
- Se sustituyó «cortafuegos» y «enrutadores» por «controles de seguridad de la red» para dar cabida a una gama más amplia de tecnologías utilizadas para cumplir los objetivos de seguridad que tradicionalmente cumplen los cortafuegos.
- Se cambiaron los parches de seguridad aplicables que se instalarán en el plazo de un mes desde el lanzamiento de «parches de seguridad críticos» a «parches o actualizaciones críticas o de alta seguridad.».
- Aclaración u Orientación. Actualizaciones en la redacción, explicaciones, definiciones, orientaciones adicionales y/o instrucciones para aumentar la comprensión o proporcionar mayor información u orientación sobre un tema en particular. Ejemplos:
- Se actualizó el título principal del requisito 2 para reflejar que la atención se centra en las configuraciones seguras en general, y no sólo en los valores predeterminados proporcionados por el proveedor.
- Sobre el requisito 5.1.2 de la versión 3.2.1 correspondiente a los sistemas que no suelen verse afectados por software malicioso, se lleve a cabo evaluaciones periódicas para identificar y evaluar las amenazas de malware que puedan aparecer. Se aclaró el requisito 5.23 en la versión 4, cambiando el enfoque a “componentes de sistema que no están en riesgo”
- Estructura o formato. Reorganización del contenido, incluyendo la combinación, separación y el volver a enumerar los requisitos para alinear el contenido. Ejemplos:
- Sobre el requisito 9.2 de la versión 3.2.1 correspondiente a desarrollar procedimientos que permitan distinguir fácilmente a los empleados y a los visitantes. En la versión 4.0, se dividió en el requisito 9.3.1 para autorizar y administrar el acceso físico de los empleados y el requisito 9.3.2 para autorizar y administrar el acceso físico de los visitantes.
- Se trasladó el requisito 11.1.2 de la versión 3.21, correspondiente a procedimientos de respuesta a incidentes si se detectan puntos de acceso inalámbricos no autorizados, al requisito 12.10.5 para alinearlos con otros elementos al Plan de respuesta a Incidentes de Seguridad.
Autor : Marco Palomino.
PMP, PCIP, CISM, SCRUM MASTER
