Requisitos de PCI DSS 4.0: Un análisis profundo de los últimos cambios y cómo afectan a su organización
Lanzada el 31 de marzo de 2022, la última versión del Estándar de Seguridad de Datos de la Industria de Tarjetas de Pago — PCI DSS 4.0 — está actualmente en vigor. Se convertirá en la única versión activa el 31 de marzo de 2024.
Para el 31 de marzo de 2025, las organizaciones también tendrán que adoptar los requisitos identificados como de fecha futura en la v4.0.
Para cumplir con estos plazos de conformidad, las organizaciones que almacenen, procesen, transmitan o impacten la seguridad de los datos de los titulares de tarjetas deben:
- revisar los cambios en la v4.0.
- implementar nuevos controles para cumplir con los requisitos actualizados y nuevos en la v4.0.
- actualizar sus plantillas y formularios de informes.
- empezar a implementar los requisitos de fecha futura para ser evaluados a más tardar el 31 de marzo de 2025.
Esto puede ser difícil de hacer por su cuenta. Es por eso que Marc Rubbinaccio, un ex QSA y actualmente el experto en la materia de PCI DSS en Secureframe, y Jonathan Smith, un QSA en Moss Adams, organizaron un seminario web de Secureframe Expert Insights el 11 de mayo.
Proporcionaron un análisis en profundidad de los cambios más significativos de PCI DSS 4.0 y orientación sobre cómo puede cumplirlos. Siga leyendo o vea la repetición del video bajo demanda para obtener sus ideas.
Requisitos de PCI DSS 4.0 vs 3.2.1
A medida que la tecnología y el panorama de amenazas evolucionan rápidamente, los marcos de seguridad diseñados para proteger a las organizaciones de incidentes de seguridad y brechas deben mantenerse al día. Es por eso que marcos como PCI DSS se actualizan regularmente.
Aunque mantenerse al día con los últimos cambios en los requisitos de conformidad de PCI DSS puede ser difícil, las organizaciones que se adapten serán las más capaces de proteger los datos de pago.
A continuación se presentan las principales diferencias entre la versión 4.0 y la 3.2.1 de PCI DSS y por qué debe cumplir con la última iteración.
1. Continuar evolucionando
Uno de los principales objetivos de PCI DSS 4.0 es continuar evolucionando el estándar para satisfacer las necesidades cambiantes de la industria de tarjetas de pago y las nuevas tecnologías que se implementan diariamente. Es por eso que PCI DSS 4.0 contiene actualizaciones a los requisitos de autenticación multifactor, contraseñas y concienciación sobre seguridad, así como nuevos requisitos de comercio electrónico.
Autenticación multifactor y requisitos de contraseñas
Un tema principal de discusión en la comunidad de seguridad es cómo asegurar mejor la autenticación sin obstaculizar la capacidad de los usuarios para iniciar sesión en los sistemas y realizar el trabajo real.
Un buen ejemplo de esto es la revisión de los requisitos de contraseñas por parte de NIST hace un par de años para abordar específicamente cómo se estaban hackeando las contraseñas en el mundo real. PCI DSS 4.0 ha mejorado los requisitos de autenticación, forzando la autenticación multifactor para todos los usuarios que acceden al entorno de datos del titular de la tarjeta, no solo a los administradores. Los requisitos de longitud de las contraseñas también se han incrementado de 8 a 12 caracteres. Finalmente, en lugar de tener que rotar todas las contraseñas cada 90 días, PCI DSS ahora da a las organizaciones la opción de usar análisis dinámicos para determinar el acceso a los recursos automáticamente.
Requisitos de conocimiento de seguridad
La ingeniería social, y el phishing en particular, sigue siendo una de las formas más frecuentes en que los atacantes obtienen acceso a los sistemas y roban datos de los titulares de tarjetas. No importa cuán sólidas sean las configuraciones de seguridad de su nube y de las aplicaciones, si un empleado con acceso a datos sensibles cae en un ataque de phishing dirigido, los hackers podrían obtener el mismo acceso y comenzar a filtrar datos de los titulares de tarjetas.
Como resultado, PCI DSS está reforzando su postura sobre la capacitación en concienciación de seguridad al requerir que se incluyan amenazas y vulnerabilidades específicas en los programas de capacitación de las organizaciones. Por ejemplo, si usted es un comerciante de comercio electrónico y ofrece soporte por chat, su personal de soporte debe ser consciente de los tipos específicos de ataques de phishing que podrían ocurrir durante el chat en vivo.
La capacitación en concienciación de seguridad también debe revisarse y actualizarse anualmente en función de los cambios en el entorno o los posibles riesgos.
Otra adición a los requisitos de concienciación de seguridad es la delimitación del uso aceptable de toda la tecnología de usuarios finales, incluidos el acceso y uso de estaciones de trabajo y la comprensión de las consecuencias de no adherirse a estas políticas de uso aceptable.
Requisitos de comercio electrónico
Uno de los cambios más grandes e impactantes en PCI DSS 4.0 gira en torno a la gestión y manejo de scripts dentro de las páginas de pago y las páginas adyacentes al pago.
Antes de PCI DSS 4.0, no había requisitos específicos relacionados con el manejo de scripts que se ejecutan y cargan en los navegadores de los consumidores. Esto llevó a la prevalencia de los ataques de Magecart, que se centraron principalmente en los comerciantes de comercio electrónico. Los hackers inyectaron su propio código en las páginas de pago para secuestrar los formularios de los titulares de tarjetas o redirigir a los consumidores a sitios web maliciosos.
2. Promover la seguridad continua
Otro objetivo de PCI DSS v4.0 es apoyar procesos continuos a largo plazo para proteger los datos de pago.
Un problema común entre las organizaciones que buscan el cumplimiento de PCI es que invierten fuertemente en la implementación de procesos, procedimientos y configuraciones inmediatamente antes de su evaluación, luego reciben su certificación y PCI DSS se convierte en un pensamiento secundario durante los próximos 11 meses. Como resultado, muchas organizaciones que buscan la recertificación pierden revisiones regulares a lo largo del año debido a controles mal organizados. Esto puede llevar a no cumplir con PCI o a que el auditor tenga que redactar un control compensatorio basado en cómo la organización iría más allá para cumplir este control en el año siguiente.
Una gran brecha que PCI DSS 4.0 busca llenar es reforzar la asignación de responsabilidades para los controles de seguridad. Ahora, en lugar de solo declarar que se realizarán escaneos trimestrales de vulnerabilidades, la organización debe declarar quién en la organización es responsable de cumplir con este control y de impulsar todos los demás controles de seguridad de PCI DSS.
Otro aspecto que antes se pasaba por alto es la delimitación del alcance de PCI DSS. Delimitar su entorno de datos de titular de tarjetas es crítico para garantizar que todos los recursos y personal aplicables estén incluidos en el alcance de la auditoría, así como en el alcance de todos los controles de seguridad, configuraciones y revisiones requeridos. Anteriormente, si se realizaban cambios a lo largo del período de auditoría que pudieran afectar su alcance, el auditor descubriría esto solo cuando la auditoría del próximo año estuviera a punto de comenzar. Con PCI DSS 4.0, ahora se requiere que una organización revise y documente su alcance de PCI DSS durante todo el año. Esto asegura que la organización mantenga el cumplimiento de PCI DSS de manera precisa.
3. Permitir flexibilidad
Para ayudar a las organizaciones a priorizar la seguridad como un proceso continuo, PCI DSS 4.0 también proporciona flexibilidad adicional. Esta flexibilidad está destinada a permitir que las organizaciones elijan los controles de seguridad más adecuados para sus necesidades comerciales y de seguridad. Esto se refleja de dos maneras principales en PCI DSS 4.0.
Un cambio significativo en PCI DSS 4.0 incluye cambiar la mentalidad de las organizaciones sobre la gestión de riesgos. Anteriormente, las organizaciones debían realizar una evaluación de riesgos anual completa, así como pruebas en intervalos definidos por el PCI DSS, con algunas tareas diarias, semestrales o trimestrales. Con PCI DSS 4.0, no solo se debe realizar una evaluación de riesgos anual completa, sino que las pruebas en intervalos ahora pueden ser específicamente definidas por la organización según el riesgo. Por ejemplo, las revisiones de acceso ahora pueden realizarse en un intervalo regular que tenga más sentido para la organización según el riesgo definido.
PCI DSS 4.0 también introdujo el enfoque personalizado, un segundo método para que las entidades cumplan con los estrictos requisitos de PCI DSS. El enfoque personalizado proporciona a las organizaciones la flexibilidad de cumplir con los objetivos de seguridad de los requisitos de PCI DSS utilizando nueva tecnología y controles innovadores. El evaluador validará que los controles personalizados cumplan con los requisitos de PCI DSS revisando la documentación del enfoque personalizado de la entidad y desarrollando un procedimiento para validar que los controles se cumplan mediante el enfoque personalizado.
Para ser claros, esto requerirá trabajo adicional y documentación por parte de la organización. En última instancia, será más fácil cumplir con el requisito tal como lo define PCI DSS, pero algunas organizaciones maduras pueden optar por un enfoque personalizado.
4. Validación mejorada
Otro cambio importante realizado por PCI DSS es permitir ahora que las organizaciones completen evaluaciones parciales.
Anteriormente, si algún requisito no era probado por el auditor, la organización se consideraba automáticamente no conforme. Ahora, con PCI DSS 4.0, las organizaciones tienen la flexibilidad de probar solo un cierto aspecto de su servicio según lo solicitado por un cliente y un QSA confirmará que los controles probados cumplían con PCI DSS.
Lecturas recomendadas
Historia de PCI: Cómo surgió el estándar
¿Qué significan estos cambios para su organización y cómo responder?
Ya sea que ya esté certificado por PCI o esté buscando la certificación PCI por primera vez, debe seguir los siguientes pasos para comenzar la transición a PCI DSS v4.0.
1. Comprender los nuevos requisitos y los cambios en los existentes
Para comenzar su viaje hacia PCI DSS v4.0, revise la documentación de PCI DSS 4.0 para obtener una comparación detallada de cada control que está cambiando y es completamente nuevo.
Si es cliente de Secureframe, comuníquese con su gerente de cumplimiento para tener una discusión detallada sobre su entorno y alcance actuales para determinar qué controles son aplicables para usted.
También puede aprovechar la experiencia de su QSA y su experiencia con su entorno. Si actualmente no tiene un QSA, Secureframe tiene una red de socios de auditoría a los que podemos presentarle.
2. Revise el cronograma de implementación
Dado que no todos los requisitos necesitarán estar en su lugar para 2024, es importante priorizar los controles en función de los cronogramas de implementación. Necesita entender qué controles son efectivos de inmediato para las evaluaciones de PCI DSS 4.0 y priorizar esos para estar preparado para 2024. Luego, entienda y priorice los controles para los requisitos con fecha futura en 2025.
3. Establezca un plan
Para asegurar una transición sin problemas a PCI DSS 4.0, elabore un plan sólido, incluida una línea de tiempo de implementación con propietarios asignados para todas las políticas, procesos y cambios de configuración requeridos para PCI DSS 4.0. Priorice los requisitos más impactantes y los requisitos con la fecha de implementación más temprana.
Lecturas Recomendadas
Cumpla rápidamente con PCI DSS con Secureframe
Requisitos de PCI DSS 4.0 y cómo cumplirlos
Con los cambios en PCI DSS 4.0, las organizaciones se enfrentan al desafío de cumplir con cientos de requisitos actualizados o nuevos para marzo de 2024 y requisitos datados para el futuro para marzo de 2025. Para ayudar, hemos proporcionado una visión general de los requisitos más significativos de PCI DSS 4.0 y orientación sobre cómo cumplirlos en las tablas a continuación.
| Must be performed immediately for all 4.0 assessments | What changed? | How to meet this requirement |
|---|---|---|
| All Requirement Sections | Roles and responsibilities for performing activities in each requirement must be documented, assigned, and understood. | Use a responsibility assignment matrix to assign owners. Can be done within a platform like Secureframe. |
| Requirement 8 | Increased the number of invalid authentication attempts before locking out a user ID to ten attempts. | Set threshold for invalid authentication attempts before locking out to ten attempts. |
| Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days. | Use dynamic analysis, a solution that takes multiple data points and determines in real time if an account should gain access. | |
| Requirement 9 | Restrict access to consoles in sensitive areas via locking when not in use. | Lock the login screens of consoles when not in use. |
| Requirement 12 | Added requirement for personnel to formally acknowledge their responsibilities. | Include the security responsibilities of all roles within the organization in your information security policy. |
| Perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. | Implement a controls matrix and risk analysis for controls being met via customized approach (see appendix D/E of PCI 4.0 for more information). | |
| Document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. | Develop a document that contains info related to the storage of CHD (purpose, retention, elements, access, encryption), internal systems and apps consisting of the CDE, and connections to vendors or third parties. | |
| Service providers must support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. | Document a process for obtaining PCI AOC’s from third-party service providers as well as a plan for receiving evidence in case the TPSP is not PCI compliant. |
| Future-dated requirements effective in 2025 | What changed? | How to meet this requirement |
|---|---|---|
| Requirement 3 | Include locations of stored SAD prior to authorization in data retention / disposal policies, procedures and processes. | Inventory SAD data flows to understand where it goes (will involve product/development). |
| Issuers must define business justification for the storage of sensitive authentication data. | In a policy or similar document, state the instances of stored sensitive authentication data, and the justification for the storage of that data. | |
| Encrypt SAD that is stored electronically prior to authorization. | Utilize the same processes to encrypt SAD that is used for PAN (but consider utilizing different keys for SAD vs PAN). | |
| Establish technical controls to prevent copying of PAN when using remote-access technologies. Document a list of personnel allowed to copy or relocate PAN data. | Identify a solution that will help stop the copying of PAN. Can be DLP, PCoIP, blocking of copy/paste functions over RDP, etc. | |
| When hashing is used to render PAN unreadable, ensure all aspects of the hash is documented and the hashing method results in keyed cryptographic hashes of the entire PAN. | When hashing, use cryptographic keys. | |
| If disk level/partition level or transparent encryption is used to render PAN unreadable, it must only be used on removable media devices. | If your cloud solution uses transparent encryption (i.e. the decryption process is tied with user access such that data is automatically encrypted), implement an additional layer of encryption. | |
| Service providers must document the prevention of shared cryptographic keys between production and test environments. | Document how keys are different between production and test environments. | |
| Requirement 4 | Any certificates used to protect PAN data over open / public networks must be confirmed to be valid and not expired. All certificates and trusted keys must be maintained in a documented inventory. | Inventory all card flows over the Internet. Document where you control the encryption (i.e. your website) and where another organization controls encryption (i.e. their website/API). Make sure that your certificates are signed and that you don’t transmit PAN to an organization with an expired certificate. |
| Requirement 5 | Any systems not commonly affected by malware must have a defined periodic risk review. Malware scans must be defined by the organization based on risk. | Perform a risk assessment that can be based upon documented risks - not a knee jerk reaction. |
| Removable media must be reviewed for malware either automatically when attached to systems, or through analysis of those systems when removable media is attached. | Ensure your AV product can support scanning of removable media. | |
| Implement an automated mechanism for detecting and protecting personnel against phishing attacks. | Implement anti-spoofing controls through an email provider and link-scrubbers or anti-malware technology. | |
| Requirement 6 | Maintain an inventory of bespoke and custom software including third-party integrated components. | Utilize tools and/or manual processes to enumerate libraries. (something like Snyk should be able to help). |
| Implement an automated technical solution to detect and prevent web application attacks such as a web application firewall (WAF). Implement methods to determine all payment page scripts are authorized, maintaining integrity, and documented in a script inventory. | The integrity of scripts can be enforced by several different mechanisms including, but not limited to: sub-resource integrity (SRI), a CSP, and proprietary script or tag-management systems, which can prevent malicious script execution. A tool like SourceDefence can help with this. | |
| Requirement 7 | All user accounts and privileges need to be reviewed at least every six months to ensure access is granted based on job function. | Make sure to account for job transfers. Folks who are transferred who don’t need as much access commonly fall through these processes. |
| Application and system accounts must be managed based on least privilege and reviewed periodically based on risk. | Inventory non-user accounts, then ascertain guardrails in how these accounts should be used (limit admin permissions, restricting hours of use, ability to be used for remote access, etc.). | |
| Requirement 8 | Increased minimum password length from seven to 12 characters. | Use passwords with at least 12 characters. |
| If passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or utilize zero trust (Service Providers only). | Analyze if you would like to rotate passwords or implement zero trust (i.e only allowing logon for various parameters, like geolocation, time of day, etc.). | |
| Implement MFA for all access into the cardholder data environment, not just non-console remote access. | The MFA requirements apply for all types of system components, including cloud, hosted systems, and on-premises applications, network security devices, workstations, servers, and endpoints, and includes access directly to an entity’s networks or systems as well as web-based access to an application or function. | |
| Secure the implementation of the MFA system. | Make sure MFA can’t be bypassed and isn’t susceptible to replay attacks. | |
| Manage the use of system / application accounts with interactive login. | Try to disable interactive use of application accounts. If not, there will be five actions that need to be taken: time limited, business justification, approval, user identity is confirmed, and user attribution is tracked. | |
| Do not hard-code passwords/passphrases into files or scripts for any application / system accounts that can be used for interactive login. | Utilize code repository functions to detect accounts/passwords. | |
| Implement practices for protecting passwords for application and system accounts against misuse. | Prepare to rotate system passwords, and make sure their password/rotation mix makes sense. | |
| Requirement 9 | Perform periodic POI device inspections based on risk. | Define how often this review is to be performed. |
| Requirement 10 | Utilize automated mechanisms to perform audit log reviews. | Make sure any systems you were doing manual logs in can ship logs to your SIEM. |
| Implement controls to detect, alert, and address / respond to failures of critical security control systems (new for merchants). | Service providers have been doing this requirement — now merchants will need to. Figure out how you can detect when a security control fails (ie. who watches the watcher). | |
| Requirement 11 | Manage all non-critical and non-high-risk ranked vulnerabilities found during internal vulnerability scans. | Make sure you start focusing on medium/lower risk vulnerability churn. |
| Perform authenticated internal vulnerability scanning. | Make sure your vulnerability scanning tool can do authenticated scans. Inventory all targets to see if they can accept authenticated scans. Set up credentials, and manage credentials in accordance with requirements in section 8. | |
| Multi-tenant service providers must support their customers' need for external penetration testing. | Set up a contracts process to enable this requirement. | |
| Service providers need to implement intrusion-detection and or intrusion-prevention techniques to detect, alert on / prevent, and address covert malware communication channels. | See if your current IDS/IPS can detect covert malware communication channels. Select an IDS/IPS that can do this. | |
| Implement a change-and-tamper detection mechanism on payment pages to monitor and alert for unauthorized modifications. | Mechanisms include but are not limited to: the report-to or report-uri CSP directives can report violations of the Content Security Policy (CSP), Synthetic user monitoring can detect changes to JavaScript in payment pages and alert personnel, Embedded tamper-resistant, tamper-detection script in the payment page can alert and block when malicious script behavior is detected, Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. A tool like SourceDefence can help with this. | |
| Requirement 12 | Perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently the control is performed. | Each of these are documentation/process-related. Simply review the requirements and begin the documentation processes. Contact your Secureframe compliance manager or QSA to help answer questions. |
| Document and review cryptographic cipher suites and protocols in use at least once every 12 months. | ||
| Review hardware and software technologies in use annually. | ||
| Service providers must document and confirm PCI DSS scope at least every 6 months and upon significant change to the in-scope environment. | ||
| Review and update the security awareness program at least once every 12 months. Include threats, vulnerabilities, and acceptable use of end-user technologies in security awareness training. | ||
| Perform periodic incident response training based on risk. Implement an incident response process for detection of stored PAN anywhere it’s not expected. |
Cómo Secureframe puede ayudarlo a cumplir con la versión más actual de PCI DSS
PCI DSS puede ser un marco difícil de organizar, gestionar y mantenerse en cumplimiento año tras año. Aquí es donde entra en juego Secureframe.
Se le asignará un gerente de cumplimiento que lo ayudará a delimitar su entorno PCI DSS anualmente, asegurándose de que comprende cuál es su entorno de datos de titular de tarjeta, cuáles son los sistemas conectados y cuáles redes están aisladas y fuera del alcance. El gerente de cumplimiento ajustará el informe de PCI DSS para reflejar su alcance de PCI DSS, de modo que solo vea los requisitos que le son aplicables.
Durante todo el año, los gerentes de cumplimiento de Secureframe estarán disponibles para ayudarlo con el trabajo de preparación y realizar una evaluación de brechas con usted antes de su auditoría, para que pueda estar seguro de su cumplimiento con PCI DSS antes de que su auditor realice la evaluación real.
Los propietarios y las responsabilidades de los controles son un punto crucial en PCI DSS 4.0. Secureframe le permitirá asignar propietarios a tareas, controles y revisiones, todo dentro de la plataforma, para que pueda cumplir con estos requisitos.
Secureframe también proporciona capacitación en concienciación sobre seguridad y capacitación en código seguro y revisamos la capacitación anualmente para asegurar que estén actualizadas. Puede gestionar la finalización de la capacitación en concienciación sobre seguridad y la aceptación de políticas, incluido el uso aceptable, todo dentro de la plataforma de Secureframe.
Dado que las iteraciones de los controles ahora se basan en riesgos, Secureframe le permitirá gestionar los intervalos para las pruebas basadas en sus riesgos evaluados, por lo que si desea realizar exploraciones de vulnerabilidad mensualmente, tendrá la capacidad de configurar esta prueba para que se active mensualmente.
También contamos con socios preevaluados para cualquier servicio de terceros que Secureframe no pueda completar. Tenemos una red de evaluadores de penetración, socios de escaneo ASV, así como socios de auditoría que estarán encantados de ayudarlo a cumplir con PCI DSS.
Para obtener más información sobre cómo Secureframe puede ayudarlo a lograr y mantener el cumplimiento de PCI, agende una demostración.