En este nuevo artículo se presenta una breve introducción al Marco de Seguridad de Software o PCI SSF (Payment Card Industry Software Security Framework), que remplazó al estándar PA-DSS (Payment Applications Data Security Standard) en octubre de 2022.

Introducción

Uno de los objetivos más fáciles de atacar por un ciberdelincuente es una aplicación de pago que esté desactualizada, que no use criptografía fuerte para la protección de datos sensibles o que esté configurada incorrectamente y/o use valores por defecto. Con el fin de definir unos parámetros básicos para la protección de datos de tarjetas en aplicaciones de pago comerciales y facilitar su integración en entornos sujetos al cumplimiento del estándar PCI DSS (Payment Card Industry Data Security Standard), en el año 2004 VISA desarrolló las bases de lo que posteriormente se convertiría en el estándar PA-DSS (Payment Applications Data Security Standard) que fue remplazado completamente por el nuevo marco de trabajo PCI SSF (Payment Card Industry Software Security Framework) en octubre de 2022.

Origen

En el año 2005 VISA USA publicó el documento Payment Application Best Practices (PABP) como parte complementaria de su programa Cardholder Information Security Program (CISP). Este documento contenía once principios de seguridad a ser aplicables tanto en el proceso de desarrollo de software como durante el despliegue, la operación y el mantenimiento de aplicaciones de pago comerciales (vendidas, distribuidas o licenciadas por terceros) involucradas en procesos de autorización o liquidación en transacciones con tarjetas de crédito y débito y utilizadas por comerciantes o por proveedores de servicios.

El uso de estas mejores prácticas era completamente voluntario (no se definía ningún tipo de obligatoriedad en su aplicación ni sanciones si no se usaba) aunque permitía que aquellas empresas interesadas certificaran su software a través de un Asesor Cualificado de Seguridad (QSA) para ser listadas en el sitio web de VISA.

El documento PABP de VISA sentó las bases para que los controles de seguridad en aplicaciones de pago se empezaran a tener en cuenta en dos frentes principales:

• Para aplicaciones desarrolladas internamente, dentro del estándar PCI DSS bajo el requerimiento 6 «Desarrollar y mantener sistemas y aplicaciones seguros«, y
• Para aplicaciones de pago comerciales, dentro del estándar PA-DSS (Payment Applications Data Security Standard).

El 15 de abril de 2008, el PCI Security Standards Council (PCI SSC) publicó el estándar PA-DSS (Payment Applications Data Security Standard) como evolución de PABP de VISA, formalizando el uso de los controles de seguridad en el desarrollo de software para aplicaciones de pago comerciales y definiendo los criterios para su uso como elemento complementario de seguridad en entornos afectados por el cumplimiento de PCI DSS.

Once años más tarde, en enero de 2019, el PCI SSC publica un nuevo marco de trabajo para la seguridad de aplicaciones de pago: PCI SSF (Payment Card Industry Software Security Framework), incorporando nuevos requisitos alineados con el desarrollo de aplicaciones de pago modernas. Este marco de trabajo remplazó completamente el estándar PA-DSS en octubre de 2022.

¿Qué es PA-DSS (Payment Applications Data Security Standard)?

El estándar PA-DSS (Norma de seguridad de datos para las aplicaciones de pago – Payment Applications Data Security Standard) fue publicado por primera vez en 2008 y su versión final fue la 3.2, que se publicó en mayo de 2016. Este estándar fue remplazado por PCI SSF en octubre de 2022.

PA-DSS contaba con catorce requisitos, que iban desde la protección de los datos de tarjeta en el almacenamiento y en la transmisión, como en la gestión de la seguridad en el ciclo de vida de desarrollo del software y el despliegue seguro en el entorno del cliente:

• Requisito 1: No retenga el contenido completo de la pista, el código o valor de verificación de la tarjeta (CAV2, CID, CVC2, CVV2) ni los datos de bloque del PIN
• Requisito 2: Proteger los datos almacenados del titular de la tarjeta
• Requisito 3: Proporcione funciones de autenticación segura
• Requisito 4: Registre la actividad de la aplicación de pago
• Requisito 5: Desarrolle aplicaciones de pago seguras
• Requisito 6: Proteja las transmisiones inalámbricas
• Requisito 7: Evalúe las aplicaciones de pago para corregir las vulnerabilidades y para mantener las actualizaciones de la aplicación
• Requisito 8: Facilite la implementación de una red segura
• Requisito 9: Los datos de titulares de tarjetas nunca se deben almacenar en un servidor conectado a Internet
• Requisito 10: Facilite un acceso remoto seguro a la aplicación de pago
• Requisito 11: Cifre el tráfico sensitivo de las redes públicas
• Requisito 12: Cifre el acceso administrativo que no sea de consola
• Requisito 13: Mantenga una Guía de implementación de las PA-DSS para los clientes, revendedores e integradores
• Requisito 14: Asigne responsabilidades según las PA-DSS al personal y establezca programas de capacitación para el personal, los clientes, los revendedores y los integradores

Uno de los objetivos principales de PA-DSS fue el de optimizar los niveles de seguridad de las aplicaciones de pago comerciales cuando se integran en un entorno que cumple con PCI DSS, minimizando la posibilidad de fallos de seguridad que permitieran el compromiso del PAN (número de cuenta principal), del contenido completo de la pista, de los códigos y valores de verificación de la tarjeta (CAV2, CID, CVC2, CVV2), del dato del PIN y del bloque de PIN, así como del fraude derivado de fallos de seguridad en la aplicación.

Las aplicaciones de pago elegibles para ser analizadas bajo el estándar PA-DSS y ser listadas en el sitio web del PCI SSC debían cumplir con los siguientes criterios:

1. Almacenar, procesar o transmitir datos del titular de tarjeta como parte de los procesos de autorización o liquidación, y
2. Ser vendida, distribuida o licenciada por terceros

En noviembre de 2022 el PCI SSC anunció en su blog oficial la retirada final de PA-DSS y su remplazo por PCI SSF. A partir de ese momento todos los documentos relacionados con este estándar (documentos de soporte, plantillas de reportes, FAQs y el estándar como tal) fueron removidos de la biblioteca de documentos del PCI SSC.

¿Qué es PCI SSF (Payment Card Industry Software Security Framework)?

Debido a los cambios actuales en términos de metodologías de desarrollo, tecnologías, tipos de aplicaciones y de sus vulnerabilidades relacionadas, el estándar PA-DSS empezaba a quedarse anticuado. Como respuesta, el PCI SSC empezó a desarrollar un nuevo enfoque para desarrollar aplicaciones de pago seguras con las necesidades modernas, actualizando, optimizando y extendiendo los criterios de PA-DSS a lo largo del ciclo de vida de desarrollo seguro (Secure Software Development Lifecycle – SSDLC). Este nuevo marco de trabajo recibió el nombre de PCI Software Security Framework y fue publicado por primera vez en enero de 2019.

El marco de trabajo de seguridad de software (PCI Software Security Framework) es un conjunto de estándares de seguridad de software, incluyendo sus programas de validación y de listado de aplicaciones certificadas. Actualmente, hay dos estándares en este marco de trabajo:

• PCI Secure Software Standard – PCI S3  (versión actual: 1.1)
• Secure Software Lifecycle (Secure SLC) Standard (versión actual: 1.1)

La evaluación formal de cumplimiento de los estándares que componen este marco de trabajo está a cargo de empresas homologadas denominadas Secure SLC Assessor Companies y de sus empleados (Secure SLC Assessors).

¿Qué es PCI S3 (Secure Software Standard)?

El Estándar de Software Seguro (PCI Secure Software Standard) o PCI S3 define un conjunto de requerimientos de seguridad y procedimientos asociados de evaluación que ayudan a garantizar que las aplicaciones de pago protegen de forma adecuada la integridad y la confidencialidad tanto de las transacciones de pago como de sus datos relacionados. Su versión actual es la 1.1, publicada en abril de 2021.

PCI S3 incluye un conjunto de requisitos básicos (core) que se aplican a todos los tipos de software de pago, independientemente de la funcionalidad del software o de la tecnología subyacente. Estos requisitos básicos (core) están organizados en cuatro (4) objetivos básicos de seguridad (Security Objectives) que, a su vez, incluyen doce (12) objetivos de control (Control Objectives), como se lista a continuación:

1. Minimización de la superficie de ataque (Minimizing the Attack Surface)
   • Identificación de activos críticos (Critical Asset Identification)
   • Asegurar los valores predeterminados (Secure Defaults)
   • Retención de datos sensitivos (Sensitive Data Retention)
2. Mecanismos de protección de software (Software Protection Mechanisms)
   • Protección de activos críticos (Critical Asset Protection)
   • Autenticación y control de acceso (Authentication and Access Control)
   • Protección de datos sensibles (Sensitive Data Protection)
   • Uso de criptografía (Use of Cryptography)
3. Operaciones de software seguro (Secure Software Operations)
   • Registro de actividades (Activity Tracking)
   • Detección de ataques (Attack Detection)
4. Gestión del ciclo de vida del software seguro (Secure Software Lifecycle Management)
   • Gestión de vulnerabilidades y amenazas (Threat and Vulnerability Management)
   • Actualizaciones de seguridad de software (Secure Software Updates)
   • Guía de seguridad del proveedor (Vendor Security Guidance)

La versión inicial del Estándar de Software Seguro también incluye un «módulo» (Module A) de protección de datos de tarjetas de pago (Account Data Protection) que se aplica al software que almacena, procesa o transmite estos datos. Los módulos son un conjunto de requisitos para abordar un tipo de software específico, un caso de uso o una tecnología. Cuando el software de pago no posee los datos o la funcionalidad específicos, o no utiliza tecnologías que activen los criterios de aplicabilidad de un módulo, los requisitos de ese módulo no se evaluarán como parte de la validación del software. En el futuro, se añadirán módulos adicionales a este estándar para abordar otros tipos de software, casos de uso o tecnologías.

Este módulo también incluye un objetivo de seguridad y dos objetivos de control:

1. Protección de datos de tarjetas de pago (Account Data Protection)
   • Datos sensibles de autenticación (Sensitive Authentication Data)
   • Protección de datos del titular de tarjeta (Cardholder Data Protection)

Este estándar aplica a software de pago que sea vendido, distribuido o licenciado por terceros. Esto incluye software de pago destinado a ser instalado en los sistemas de clientes, así como el software de pago desplegado a los clientes «como servicio» (As-a-Service) a través de Internet. En el momento de la publicación de este estándar, los siguientes criterios deben ser cumplidos para que una aplicación pueda ser evaluada bajo estos requisitos:

1.  Participar en las transacciones de pago o apoyarlas o facilitarlas directamente, y
2.  Almacenar, procesar o transmitir datos de tarjetas en texto claro y, por lo tanto, puede ser validada tanto por el Estándar de Software Seguro (PCI S3) como por el Módulo A – Protección de datos de tarjetas de pago, y
3.  Ser un producto disponible en el mercado desarrollado por el vendedor de software para su venta a múltiples organizaciones.

La validación del estándar PCI S3 no está destinada a:

• Programas informáticos desarrollados internamente para uso exclusivo de la empresa que los desarrolló
• Programas informáticos desarrollados y vendidos a un solo cliente para uso exclusivo de este
• Software de pago que opere en cualquier dispositivo electrónico móvil del cliente que no esté unicamente dedicado a aceptación de pagos para el procesamiento de transacciones
• Productos de software que sean sistemas operativos, bases de datos o plataformas, cinluso si estos pueden almacenar, procesar o transmitir datos de tarjetas.
• Software de pago destinado a ser utilizado en terminales de hardware.

Se prevé la creación de futuros módulos para soportar algunos de estos casos de uso. El software que no es elegible para la validación en el lanzamiento inicial del programa no necesariamente permanecerá inelegible durante toda la vida del programa. Todas las exclusiones serán reevaluadas cada vez que se añada un nuevo módulo al Estándar de Software Seguro (PCI S3) y a medida que el programa evolucione.

Las validaciones de aplicaciones con el Estándar de Software Seguro (PCI S3) tienen un vencimiento de tres años.

Finalmente, es importante resaltar que el hecho de que una entidad tenga que utilizar un software validado según el Estándar de Software Seguro (PCI S3) viene determinado por las directivas de las marcas de pago y no por el PCI SSC.

¿Qué es PCI Secure Software Lifecycle (Secure SLC) Standard?

El Estándar del Ciclo de Vida del Software Seguro (PCI Secure Software Lifecycle (Secure SLC) Standard) define un conjunto de requisitos de seguridad y procedimientos de prueba asociados para que los proveedores de software validen cómo gestionan adecuadamente la seguridad del software de pago a lo largo del ciclo de vida del software. La validación, según el Estándar, demuestra que el vendedor de software tiene prácticas maduras de gestión del ciclo de vida del software seguro para garantizar que su software de pago está diseñado y desarrollado para proteger las transacciones de pago y los datos, minimizar las vulnerabilidades y defenderse contra ataques. Su versión actual es la 1.1, publicada en febrero de 2021.

El estándar PCI Secure SLC está destinado a los vendedores/proveedores de software que desarrollan software para la industria de pagos. Los vendedores de software que tengan validadas sus prácticas de gestión del ciclo de vida del software serán reconocidos en la Lista de Proveedores Calificados de SLC Seguro del PCI SSC.

Al igual que el estándar PCI S3, el estándar PCI Secure SLC está organizado en cuatro (4) objetivos de seguridad que incluyen diez (10) objetivos de control:

1. Gobernanza de la seguridad de los programas informáticos (Software Security Governance)
   • Responsabilidad y recursos de seguridad (Security Responsibility and Resources)
   • Política y estrategia de seguridad de software (Software Security Policy and Strategy)
2. Ingeniería de software segura (Secure Software Engineering)
   • Identificación y mitigación de amenazas (Threat Identification and Mitigation)
   • Detección y mitigación de vulnerabilidades (Vulnerability Detection and Mitigation)
3. Gestión segura de software y datos (Secure Software and Data Management)
   • Gestión del cambio (Change Management)
   • Protección de la integridad del software (Software Integrity Protection)
   • Protección de datos sensibles (Sensitive Data Protection)
4. Comunicación segura (Security Communications)
   • Guía de seguridad del proveedor (Vendor Security Guidance)
   • Comunicaciones con las partes interesadas (Stakeholder Communications)
   • Información de actualización del software (Software Update Information)

¿Cuál es la relación entre el estándar PCI S3 y el estándar PCI Secure SLC?

El estándar PCI S3 y el estándar PCI Secure SLC son dos estándares separados e independientes. Si bien ambos estándares abordan algunos de los mismos conceptos, cada uno de ellos los realiza desde una perspectiva diferente:

• Los procesos de desarrollo de software seguro son cubiertos en el estándar PCI Secure SLC
• La funcionalidad segura y las características de seguridad de una aplicación son cubiertas en el estándar PCI S3

Dicho esto, se proporciona una flexibilidad adicional a los Proveedores Calificados de PCI Secure SLC como parte de la validación de su software de pago al estándar PCI S3. Estos proveedores estarán facultados para realizar y autoatender sus propias evaluaciones «delta» de software (como parte de la validación de sus productos de software de pago con el estándar PCI S3) con una participación o supervisión reducida del asesor cualificado.

¿Cómo se realizará la migración de PA-DSS a PCI SSF?

El Marco de Seguridad de Software (PCI Software Security Framework) tiene un impacto inmediato en las aplicaciones validadas actualmente bajo el programa PA-DSS. Al expirar, todas las aplicaciones de pago validadas bajo PA-DSS serán trasladadas a la lista de «Aceptables sólo para despliegues preexistentes» (Acceptable Only for Pre-Existing Deployments).

Más información en el documento Transitioning from PA-DSS to the PCI Software Security Framework.

Relación entre PCI DSS y los estándares del Marco de Seguridad de Software (PCI S3 y PCI Secure SLC)

En la versión 4.0 de PCI DSS se incluyó una sección  específica en el documento del estándar (Appendix F – Leveraging the PCI Software Security Framework to Support Requirement 6) en donde se describe en detalle cómo se puede usar software validado bajo los controles de los estándares PCI S3 y PCI Secure SLC para cumplir con los requisitos del estándar o cuando se emplea el enfoque personalizado (customized approach):

• Cuando se usa software a medida y personalizado que ha sido desarrollado y mantenido por un proveedor homologado como Secure SLC Qualified Vendor, se facilita el cumplimiento del control 6.2 y se soporta el enfoque personalizado en los controles 6.3 y 6.5. En este caso, se debe validar que el proveedor que desarrolla el software está listado en el inventario de Secure SLC Qualified Vendors, que el software se desarrolla y mantiene como parte de la validación de software de dicho proveedor y que la entidad que debe cumplir con PCI DSS ha seguido las guías de implementación.
• Cuando se usa software a medida y personalizado que ha sido desarrollado de acuerdo con el estándar PCI Secure SLC. La entidad que debe cumplir con PCI DSS también puede usar PCI Secure SLC como referencia para sus desarrollos internos. Para validarlo, un asesor Secure SLC debe revisar el proceso de desarrollo y documentarlo en los reportes relacionados.
• Cuando se usa software provisto por terceros validado bajo PCI S3. En este caso, el uso de software validado bajo PCI S3 puede soportar el cumplimiento con el control 6.2.4 y la implementación del enfoque personalizado para los controles 6.3 y 6.5. Para ello, el asesor QSA debe revisar los reportes de cumplimiento de dicho software (Secure Software Report on Validation (ROV) y Secure Software Attestation of Validation (AOV)) y validar que estos reportes no están expirados.

Otras consideraciones adicionales

Los estándares que componen el Marco de Seguridad de Software (PCI SSF) son totalmente independiente de otros estándares del PCI SSC. El uso de software de pago certificado bajo estos estándares puede ayudar a respaldar la seguridad del entorno de datos de los titulares de tarjetas (Cardholder Data Environment – CDE) de una entidad, pero no hace que una entidad cumpla con PCI DSS, ni implica el cumplimiento o el resultado de la validación de cualquier otro estándar del PCI SSC. Las entidades deben garantizar que todo el software de pago se implementa de forma que cumpla con PCI DSS y que se incluye dentro de su evaluación anual para verificar que el software está configurado correctamente y que cumple con los requisitos aplicables de PCI DSS.

Referencias

How to Successfully Transition Software from PA–DSS to the PCI Secure Software Standard

PCI Software Security Framework FAQS: PA–DSS Impact and Transition

Resource Guide: Transitioning from PA–DSS to the Software Security Framework

Update on PCI Software Security Framework