Capture

Tal y como se tenía previsto, el 07 de Noviembre de 2013 el PCI Security Standards Council publicó las nuevas versiones de los estándares PCI Data Security Standard (PCI DSS) y PCI Payment Application Data Security Standard (PA DSS). Dichos documentos se encuentran disponibles para descarga en la sección “Documents Library” del sitio web del PCI SSC.

A continuación se hará una breve referencia a los nuevos requerimientos y apartados de cada estándar, que han seguido la categorización de cambios “Aclaración” (Clarification), “Guía adicional” (Additional Guidance) y “Evolución del requisito” (Evolving Requirement) descritas en el artículo “Adelanto de los cambios en la versión 3.0 de PCI y PA DSS”:

Novedades PCI Data Security Standard (PCI DSS)

Para esta nueva edición, el estándar PCI DSS cuenta con las siguientes novedades:

  • El documento “Navigating PCI DSS” que solía ser publicado independientemente al estándar y cuya labor era proveer mayor detalle de cada requerimiento ha sido integrado dentro de la nueva versión del estándar. De esta manera, las antiguas columnas “In Place”, “Not in Place” y “Target Date/Comments” que acompañaban cada requerimiento para seguimiento de cumplimiento han sido remplazadas por la columna “Guidance” en donde se detalla el objetivo por cada control.
  • Se han desarrollado una serie de recomendaciones y buenas prácticas para la implementación e integración de los controles del estándar en la operación diaria dentro del apartado “Best Practices for Implementing PCI DSS into Business-as-Usual Processes (BAU)”.
  • Se ha ampliado el apartado “Procedimientos de Prueba” (Testing Procedures) con aclaraciones adicionales para la evaluación de cada requerimiento.
  • De igual manera, la publicación de esta nueva versión de PCI DSS viene acompañada por el infográfico Why PCI DSS v.3.0?”, donde se presentan de una manera gráfica las mejoras del estándar.

Los requerimientos nuevos y evolucionados del estándar son:

  • Req. 1.1.3 – Mantener un diagrama de red actualizado que indique el flujo de datos de tarjetas de pago a través de sistemas y redes en la infraestructura de la organización.
  • Req. 2.4 –  Mantener un inventario actualizado de todos los activos pertenecientes al entorno de cumplimiento (ver “CardHolder Data Matrix (CHDM): ¿Qué es y para qué se utiliza?”).
  • Req. 5.1.2 – Para aquellos sistemas que son considerados como no afectados comúnmente por software malicioso, se deben realizar evaluaciones periódicas para identificar y evaluar potenciales amenazas de malware con el fin de confirmar si dicho sistema requiere o no software antivirus.
  • Req. 5.3 –  Validación que la solución antivirus se encuentra en ejecución y que no puede ser deshabilitada o alterada por usuarios a menos que exista una autorización administrativa.
  • Req. 6.5.10 – Dentro de los controles de desarrollo seguro incluir validaciones específicas para evitar vulnerabilidades en autenticación y gestión de sesiones (“cookies” seguras, evitar la exposición de identificadores de sesión en las URLs y rotación y expiración de identificadores de sesión). Este requerimiento es una recomendación hasta Junio 30 de 2015, en cuya fecha pasa a ser obligatorio.
  • Req. 8.2.3 – Los controles relacionados con longitud y complejidad de contraseñas han sido combinados en uno solo.
  • Req. 8.5.1 – Nuevo requerimiento que obliga a que los proveedores de servicio que cuentan con acceso remoto a los sistemas de sus clientes utilicen credenciales de autenticación diferentes para cada cliente.
  • Req. 8.5.6 – Si se emplean otros mecanismos de autenticación (como tokens físicos o lógicos, tarjetas inteligentes, certificados digitales, etc.), estos deben ser asignados a una cuenta individual y no compartido entre múltiples cuentas y se deben implementar controles lógicos y/o físicos para garantizar que únicamente la cuenta autorizada puede usar dicho mecanismo para autenticarse.
  • Req. 9.3 – Los controles de acceso físico para el personal con acceso a áreas sensitivas debe ser autorizado con base en su función de trabajo y el acceso ha de ser revocado en el momento de la finalización del contrato y todos los mecanismos de acceso (llaves, tarjetas de acceso, etc.) deben ser retornados o deshabilitados.
  • Req. 9.9.x – Nuevos requerimientos para la protección de dispositivos empleados para la captura de datos de tarjeta  mediante interacción física con la tarjeta para evitar manipulación y sustitución. Estos controles serán efectivos a partir de Julio 1 de 2015.
  • Req. 10.2.5 – Se requiere la generación de registro de eventos (logs) en cualquier uso o cambio de mecanismos de autenticación, incluyendo la creación de nuevas cuentas y elevación de privilegios y todos los cambios, adiciones o eliminaciones de cuentas con privilegios administrativos.
  • Req. 10.2.6 – Se requiere la generación de registro de eventos (logs) en la inicialización, detención o pausa de dichos registros.
  • Req. 11.1.x – Se requiere mantener un inventario actualizado de cualquier dispositivo inalambrico dentro del entorno y su justificación de uso, así como implementar procedimientos de respuesta a incidentes en el caso que un dispositivo inalámbrico no autorizado sea detectado.
  • Req. 11.3 – Se requiere la definición e implementación de una metodología para la ejecución de pruebas de penetración (penetration testing). Este requerimiento es una buena práctica hasta Junio 30 de 2015, cuando se convertirá en un requerimiento.
  • Req. 11.3.4 – Si se emplea segmentación para el aislamiento del entorno de cumplimiento (Cardholder Data Environment – CDE), se requiere la ejecución anual o posterior a cualquier cambio para validar que los métodos de segmentación son operacionales y efectivos y aislan los equipos fuera del entorno de aquellos que se encuentran dentro del entorno.
  • Req. 11.5.1 – Implementación de un proceso para responder frente a cualquier alerta proveniente de cambios en la solución de detección de cambios (FIM, por ejemplo).
  • Req. 12.2 – Ejecución de un proceso de análisis de riesgos de forma anual y ante cualquier cambio significativo del entorno.
  • Req. 12.5.8 – La organización debe mantener información acerca de cuáles requerimientos de PCI DSS que son gestionados por cada proveedor de servicios y cuáles son gestionados por la empresa.
  • Req. 12.9 – Cada proveedor de servicio debe reconocer de forma escrita ante sus clientes que es responsable de la seguridad de los datos de tarjetas de pago que almacena, procesa o transmite en nombre de sus clientes. Este requerimiento es una buena práctica hasta Junio 30 de 2015, cuando se convertirá en un requerimiento.

Finalmente, los requerimientos 12.1.1 y 12.2 relacionados con las políticas de seguridad y los procedimientos operativos diarios han sido re-numerados y distribuidos como nuevos controles en los requerimientos 1 al 11.

El listado completo de todos los cambios se puede encontrar en el documento PCI DSS Summary of Changes v2.0 to v3.0″.

Novedades PCI Payment Application Data Security Standard (PA DSS)

Para esta nueva versión de PA DSS, los requerimientos nuevos y evolucionados son los siguientes:

  • Req. 2.x – Se adiciona información del documento “PA-DSS Implementation Guide” a los procedimientos de prueba en toda la sección.
  • El requerimiento 2.4 relacionado con el uso de soluciones de cifrado completo de disco ha sido removido del estándar.
  • Req. 3.3.1 – 3.3.2 – El requerimiento 3.3 de PA DSS v2.0 ha sido dividido en dos requerimientos separados (Req. 3.3.1 focalizado en contraseñas transmitidas y Req. 3.3.2. focalizado en contraseñas almacenadas). En el almacenamiento de contraseñas se requiere el uso de algoritmos criptográficos de una sola vía (one-way) con una variable de entrada única (salt).
  • Req. 3.4 – Se requiere limitar el acceso con base en funciones/recursos y reforzamiento de la implementación del concepto de “menor privilegio” para cuentas de aplicación integradas.
  • Req. 5.1 – Mejora en los requerimientos orientados a la inclusión de revisiones de seguridad en el proceso de desarrollo.
  • Req. 5.1.5 – Se requiere el uso de prácticas de control sobre el código fuente para la validación de integridad de dicho código durante el proceso de desarrollo.
  • Req. 5.1.6 – Se requiere el uso de mejores prácticas de la industria en el desarrollo de código.
  • Req. 5.2.10 – Dentro de los controles de desarrollo seguro incluir validaciones específicas para evitar vulnerabilidades en autenticación y gestión de sesiones.
  • Req. 5.4 – Se requiere definir e implementar una metodología de gestión de versiones de acuerdo con el documento “PA-DSS Program Guide”.
  • Req. 5.5 – Se requiere incorporar técnicas de análisis de riesgos en los procesos de desarrollo de software.
  • Req. 5.6 – Se requiere la implementación de un proceso de autorización formal previo a la publicación de la versión final del software.
  • Req. 7.3 – Se requiere proveer de un documento de “release notes” con detalles de todas las actualizaciones de la aplicación, incluyendo impactos y cambios en los números de versión.
  • Req. 10.2.2 – Se requiere que aquellos fabricantes que ofrecen servicios de soporte o de mantenimiento a la aplicación utilicen credenciales de autenticación diferentes por cada cliente.
  • Req. 14.1 – Se requiere que el personal reciba formación de seguridad y de PA DSS al menos anualmente.
  • Req. 14.2 – Se requiere la asignación de roles y responsabilidades relacionados con PA DSS al personal.

Al igual que con PCI DSS, el listado completo de todos los cambios realizados en esta nueva versión del estándar se encuentra en el documento Summary of Changes from PA-DSS Version 2.0 to 3.0“.

Con base en estas nuevas versiones, ¿considera que los cambios fueron apropiados para cubrir las nuevas amenazas a los datos de tarjetas de pago? ¿echa de menos algún control o mejora?. La discusión está abierta, todos los comentarios son bienvenidos.