En este penúltimo artículo de la serie “Análisis de PCI DSS v4.0” se presenta un análisis a los cambios del requerimiento 12 – parte del grupo 6 “Maintain an Information Security Policy”- en la versión 4.0 del estándar PCI DSS.

Requerimiento 12: Support Information Security with Organizational Policies and Programs

El último requerimiento del estándar PCI DSS describe los lineamientos administrativos y documentales que deben ser implementados a lo largo del ciclo de vida de los controles físicos y lógicos relacionados con la protección de los datos de tarjetas de pago. En la versión 4.0 el nombre de este requerimiento fue cambiado para hacer énfasis en la necesidad de políticas y programas para soportar las labores de seguridad de la información en la organización, a diferencia del nombre del mismo requerimiento en la versión 3.2.1 que solamente hacía referencia a mantener una política de seguridad de la información para todo el personal.

A la par con los cambios en el nombre del requisito, los siguientes controles fueron actualizados/adicionados:

  • La política de seguridad debe incluir de forma clara los roles y responsabilidades relacionados con la seguridad de la información. Dichas responsabilidades deben ser aceptadas por el personal relacionado (12.3.1).
  • Se requiere que un miembro de la Dirección Ejecutiva de la organización asuma las responsabilidades en seguridad de la información. Este rol puede ser el CISO (Chief Information Security Officer) o cualquier otro rol con conocimientos dentro de la junta directiva (12.1.4).
  • A diferencia de PCI DSS v3.2.1 en donde existían varios controles relacionados con el uso de tecnologías críticas, en PCI DSS v4.0 estos controles han sido unificados, exigiendo solamente la existencia de políticas de uso aceptable para tecnologías de usuario final, la aprobación explícita por las partes autorizadas, los usos aceptables de dichas tecnologías y la lista de productos aprobados por la compañía para el uso de sus empleados, incluyendo hardware y software (12.2.1).

Probablemente, uno de los cambios más representativos en el requerimiento 12 de PCI DSS fue el enfoque en la ejecución del análisis de riesgos. En PCI DSS v4.0, se requiere de la realización de un análisis de riesgos específico y orientado exclusivamente en aquellos controles de PCI DSS en donde se permite que la entidad escoja el periodo de ejecución relacionado y cuando se usa el enfoque personalizado (customized approach).

Este nuevo enfoque se denomina Targeted Risk Analysis, cuyo objetivo es:

  • Determinar la justificación y la frecuencia con la que debe realizarse un control para minimizar la probabilidad de que se materialicen las amenazas identificadas sobre los activos de su alcance. Como mínimo, este análisis de riesgos debe revisarse cada 12 meses (12.3.1). Este control es aplicable a partir del 31 de marzo de 2025.
  • Revisar y documentar la evidencia requerida cuando se usa el enfoque personalizado para cumplir con un control en particular. En este caso, se requiere de la aprobación documentada por parte de la Dirección y su ejecución debe ser cada 12 meses (12.3.2).
  • Debido a las vulnerabilidades identificadas en los algoritmos criptográficos, el PCI SSC ha incluido en la versión 4.0 de PCI DSS un control específico para revisar los niveles de seguridad de los algoritmos criptográficos usados para el entorno (12.3.3). En este sentido, se exige:
    • Un inventario actualizado de todos los conjuntos de cifrado y protocolos en uso, incluyendo su justificación y en dónde es usado.
    • Monitorización de la viabilidad de uso de los algoritmos en uso.
    • Estrategia documentada para responder a cambios en vulnerabilidades criptográficas.
  • En la misma línea, y para prevenir que se sigan usando tecnologías obsoletas en la organización, se requiere realizar una revisión proactiva de las tecnologías de hardware y software que no seguirán siendo soportadas por sus fabricantes (End-of-Life – EOL), incluyendo un plan aprobado por la Dirección para remediar tecnologías obsoletas (12.3.4). Este control es aplicable a partir del 31 de marzo de 2025.

Con ello, la ejecución del análisis de riesgos global de la compañía (como el que se exigía en PCI DSS v3.2.1) ha pasado de ser un requisito a ser una recomendación.

Análisis de riesgos en PCI DSS v3.2.1 y 4.0

  • Para proveedores de servicio, se han centralizado en el control 12.4 todos los requerimientos relacionados con la gestión del cumplimiento de PCI DSS: Responsabilidades (12.4.1), revisión de tareas operativas de seguridad (12.4.2) y documentación de estos resultados (12.4.2.1).
  • El control relacionado con el inventario de componentes del sistema en el alcance de PCI DSS que se encontraba en el control 2.4 de PCI DSS v3.2.1 ha sido reubicado en el control 12.5.1 de PCI DSS v4.0.
  • Para evitar la eterna discusión que existía en PCI DSS v3.2.1 relacionada con la responsabilidad en la definición y actualización del alcance de cumplimiento de PCI DSS, en la versión 4.0 del estándar se ha incluido de forma explícita un nuevo control (12.5.2) en el cual la entidad debe revisar al menos cada 12 meses (en el caso de comercios) y cada 6 meses (en el caso de proveedores de servicios) el alcance de PCI DSS, incluyendo flujos de datos, diagramas, componentes del sistema, controles de segmentación y conexiones con terceros.
  • Para proveedores de servicio, si hay cambios significativos en la estructura organizativa que puedan impactar el cumplimiento con PCI DSS, se requiere documentar su impacto en el alcance y en los controles y que dichos resultados sean comunicados a la Dirección (12.5.3).
  • En cuanto a la formación en seguridad:
    • Se aclara que la formación debe estar alineada con el rol de cada persona en la protección de datos de tarjetas (12.6.1)
    • El material de formación debe ser revisado al menos cada 12 meses y actualizado cuando sea necesario (12.6.2)
    • Se pueden emplear diferentes métodos de comunicación para la formación en seguridad (12.6.3)
    • La formación debe incluir amenazas y vulnerabilidades que puedan impactar la seguridad del CDE (phishing, ingeniería social, etc.). Este control (12.6.3.1) es complementario al control 5.4.1, que define los controles técnicos para detectar y proteger a los usuarios de ataques de phishing. Este control es aplicable a partir del 31 de marzo de 2025.
    • La formación debe incluir la descripción de usos aceptables de tecnologías de usuario final (12.6.3.2). Este control es aplicable a partir del 31 de marzo de 2025.
  • Se aclara que las validaciones de seguridad previas a la contratación de empleados se deben enmarcar dentro de las restricciones legales existentes (12.7.1). Como punto interesante, en la guía de este control se incluye el uso de la revisión de información pública y redes sociales como elemento de criterio en el proceso de selección.
  • En la gestión de terceras partes proveedoras de servicios (third-party service providers – TPSPs) se remplaza el término Service Provider por Third-party Service Providers – TPSPs y se aclara que el hecho de incorporar en el servicio a un TPSP que cumple con PCI DSS no hace que la entidad cliente cumpla de forma directa con el estándar (12.8.1). Igualmente, los proveedores de servicios deben facilitar información acerca de su cumplimiento y de los requerimientos compartidos y bajo su responsabilidad a sus clientes (12.9.2).
  • En el ámbito de la gestión de incidentes, los siguientes son los cambios en la versión 4.0 del estándar:
    • Se ha aclarado que el plan de respuesta a incidentes debe cubrir no solamente los incidentes confirmados sino también los eventos sospechosos (12.10.1).
    • La periodicidad en la formación al personal de respuesta a incidentes debe ser establecida con base en un análisis de riesgos específico, conforme con el control 12.3.1.
    • El plan de respuesta a incidentes debe monitorizar y responder a las alertas de los mecanismos de detección de cambios y manipulación de las páginas de pago (12.10.5). Este control es aplicable a partir del 31 de marzo de 2025.
    • Finalmente, los procedimientos de respuesta a incidentes deben gestionar los eventos en los cuales se detecten datos de PAN almacenados en ubicaciones no autorizadas. Este control debe definir qué hacer con los datos de PAN una vez identificados, revisar si además del PAN también existen datos sensibles de autenticación involucrados, determinar el origen de dichos datos y remediar cualquier fuga de datos existente. Este control es aplicable a partir del 31 de marzo de 2025.

Referencias

 

Deja un comentario

Categoría

Análisis de PCI DSS v4.0

Tags

, , , , , , , , , , ,