martes, 10 de marzo de 2020

Análisis PA-DSS Vs PCI SSS y PCI SSLCS

El pasado 16 de enero de 2019 el PCI SSC publicó en el repositorio de su página web cuatro nuevos documentos:



Dichos documentos pertenecen al Marco de Software Seguro (PCI SSF - PCI Software Security Framework) y se componen de dos nuevos estándares;
  • PCI Software Security Standard (PCI SSS)
  • PCI Secure Software Lifecycle Standard (PCI SSLCS)
Estos estándares establecen requisitos de seguridad para el diseño, desarrollo y mantenimiento del software que trata transacciones de pago con datos de tarjeta.

Antes de esta publicación, cualquier software que tratara datos de tarjeta, era susceptible de ser certificable bien por PA-DSS o bien por los requisitos aplicables (principalmente requisito 6) de PCI DSS.

En septiembre de 2019, el PCI SSC ha añadido nuevos documentos entorno al marco PCI SSF, quedando el total formado por 11 documentos disponibles en su página web a través del repositorio anteriormente citado:



¿Qué diferencias hay en el contenido de PA-DSS, PCI SSS y PCI SSLCS?

La estructura de los estándares sigue siendo la misma que PCI DSS o PA-DSS, en los cuales se definen por cada control tres conceptos; objetivo del control, la prueba del requerimiento y la guía. Sin embargo, los controles han sido redistribuidos y agrupados de forma diferente:

# PA-DSS PCI SSS PCI SSLCS
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 bloqueo del PIN. Minimizando la superficie de ataque Identificación de activos críticos Gobernanza de seguridad del software Responsabilidad y recursos de seguridad
2 Proteger los datos almacenados del titular de la tarjeta Valores predeterminados seguros Política y estrategia de seguridad del software
3 Proporcione funciones de autenticación segura Retención de datos sensibles Ingeniería de software seguro Identificación y mitigación de amenazas
4 Registre la actividad de la aplicación de pago Mecanismos de protección de software Protección de activos críticos Detección y mitigación de vulnerabilidades
5 Desarrolle aplicaciones de pago seguras Autenticación y control de acceso Software seguro y gestión de datos Gestión del cambio
6 Proteja las transmisiones inalámbricas Protección de datos sensibles Protección de integridad de software
7 Evalúe las aplicaciones de pago para corregir las vulnerabilidades y para mantener las actualizaciones de la aplicación Uso de la criptografía Protección de datos sensibles
8 Facilite la implementación de una red segura Operaciones de software seguro Seguimiento de la actividad Comunicaciones seguras Guía segura del fabricante
9 Los datos de titulares de tarjetas nunca se deben almacenar en un servidor conectado a Internet Detección de ataque Comunicaciones con las partes interesadas
10 Facilite un acceso remoto seguro a la aplicación de pago Gestión segura del ciclo de vida del software Gestión de amenazas y vulnerabilidad Información de actualización de software
11 Cifre el tráfico sensitivo de las redes públicas Actualizaciones seguras de software - -
12 Cifre el acceso administrativo que no sea de consola Guía segura del fabricante - -
13 Mantenga una Guía de implementación de las PA-DSS para los clientes, revendedores e integradores Módulo A - Protección de datos de la cuenta Datos sensibles de autenticación - -
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 Protección de datos de tarjeta -

 

¿Cuál es el motivo del cambio de estándares?

El nuevo marco de Software Seguro reemplazará PA-DSS con el objetivo de renovar los requisitos del programa PA-DSS por otros más modernos que admitan una gama más amplia de tipos de software de pago con tarjetas, así como diferentes tecnologías y metodologías de desarrollo utilizadas hoy en día. Con este enfoque, el PCI SSC a través del programa SSF proporcionará más agilidad para que los desarrolladores incorporen la seguridad en las aplicaciones de pago con prácticas de desarrollo ágiles y ciclos frecuentes de actualizaciones. El SSF permite un suministro más acelerado de funciones y personalizaciones de las aplicaciones de pago para comercios sin comprometer la seguridad. También mejora la coherencia y la transparencia en las pruebas que se realizan a las aplicaciones de pago, lo que eleva la garantía de validación para comerciantes, proveedores de servicios y compradores que implementan y administran el uso de soluciones de pago.

En resumen, el programa SSF permitirá unos requisitos más flexibles y más opciones de validación que admitirán tecnologías más modernas y una gama más amplia de software de pago.

¿A quién aplica?

El criterio de elegibilidad sigue siendo el mismo que para PA-DSS, por lo que aplican principalmente a software vendido, distribuido o licenciado a terceras partes que esté involucrado en el procesamiento, almacenamiento o transmisión de los datos de tarjeta, no siendo aplicable a desarrollos software internos o a medida.

¿Qué diferencia hay entre los dos nuevos estándares?

El PCI SSS y el PCI SSLCS son dos estándares separados e independientes, sin embargo, abordan conceptos similares, pero desde puntos de vista diferentes:

  • PCI SSLCS se orienta a procesos exclusivos al ciclo de vida del desarrollo o codificación segura de software y está diseñado para certificar empresas de desarrollo de software que quieran certificar su proceso para demostrar su madurez en el diseño y desarrollo de aplicaciones de pago que securicen los datos y las transacciones, así como minimizar las vulnerabilidades y estén protegidas frente a ataques.
  • PCI SSS se enfoca a funcionalidades y funciones seguras (diseño, desarrollo y mantenimiento de las mismas) con el objetivo de proteger la integridad y confidencialidad de los datos de tarjeta. El estándar está diseñado para certificar aplicaciones que estén involucradas, faciliten o directamente soporten transacciones que almacenen, procesen o transmitan datos de tarjeta, siempre y cuando cumplan con el criterio de elegibilidad descrito anteriormente.
Al ser estándares independientes implica que la validación de un software en un estándar (por ejemplo, PCI SSS) no tiene por qué resultar en la validación en el otro estándar (PCI SSLCS o cualquier otro estándar del PCI SSC).

¿Qué ventajas me ofrece cada estándar?

El nuevo marco de software seguro hereda todas las ventajas del programa PA-DSS y añade nuevas características. Podemos resumir todas las principales ventajas en:
  • Aparición en las listas publicadas en la página web oficial del PCI SSC, por lo que cualquier interesado puede consultar de forma ágil y gratuita el estado actualizado de cada aplicación de pago validada (tanto por PCI PA-DSS como por PCI SSF)
  • Al publicar y mantener las listas el PCI SSC de empresas y aplicaciones certificadas, no es necesario solicitar el AoV correspondiente (PCI PA-DSS o PCI SSS) para comprobar que ha sido creado por una empresa utilizando metodología de desarrollo seguro certificada mediante AoC (PCI SSLCS), ya que todo esto estará validado en el proceso de publicación en dichas listas del PCI SSC publicadas en su página web.
  • El nuevo marco PCI SSF, ha sido desarrollado teniendo en cuenta los nuevos avances tecnológicos y las nuevas plataformas de pago emergentes, con el objetivo de validar desarrollos de software modernos con actualizaciones y un ciclo de vida de desarrollo más rápido. De hecho, PCI SSS soportará nuevas actualizaciones con inclusiones de nuevos módulos bajo nuevas versiones del estándar.

 

¿Cambia el tipo de auditorías y certificación que se realizarán respecto a las auditorías de PA-DSS?

No, el proceso de auditoría evaluará de la misma forma la aplicación de pago que como lo haría en una auditoría PA-DSS, dando como resultado dos documentos de certificación; PCI SSS (RoV y AoV) y PCI SSLCS (RoC y AoC). Igualmente se mantiene la lista de software de pago validado en la página web del PCI SSC, que actualmente es la siguiente: https://www.pcisecuritystandards.org/assessors_and_solutions/payment_applications?agree=true

El PCI SSC mantendrá dos listas, una para el estándar PCI SSS y otra para el estándar PCI SSLCS.
Las empresas con certificación PA-DSS, serán candidatas para ser compañías PCI-qualified Secure Software Assessor (SSA) Companies y PCI-qualified Secure Software Lifecycle Assessor (SSLCA) Companies.

Mas información respecto al proceso de auditoría, ya sea auditoría completa o parcial (delta), así como los tipos de cambios y las recertificaciones se puede extraer de los documentos de “Programa” que ha publicado el PCI SSC:
  • Secure-Software-Program-Guide-v1
  • Secure-Software-Life-Cycle-(SLC)-Program-Guide-v1

¿Qué relación tienen los nuevos estándares con otros estándares del PCI SSC?

El marco de software seguro (PCI Software Security Framework) que engloba los dos nuevos estándares ha sido elaborado con elementos de PA-DSS (el cual fue elaborado para validar aplicaciones en entornos PCI DSS), sin embargo, tiene como objetivo dar un nuevo enfoque al desarrollo y distribución de aplicaciones de pago para abarcar diferentes tipos de software, metodologías de desarrollo, más casos de uso y futuras tecnologías.

 ¿Qué transición habrá de PA-DSS al marco PCI Software Security?

En el periodo de transición establecido, coexistirán los dos marcos de validación, PA-DSS y PCI SSF, entre el Q1 de 2020 y el 30 de junio de 2021, en el cual se podrán certificar nuevas aplicaciones por cualquiera de los marcos de validación.

Todas las aplicaciones de pago validadas por PA-DSS se mantendrán actualizadas y continuarán siendo regidas por el programa PA-DSS hasta que se alcance la fecha de vencimiento (28 de octubre 2022 para las aplicaciones de pago validadas según PA-DSS v3.2). Tras dicha fecha de vencimiento, todas las aplicaciones de pago validadas por PA-DSS se moverán a la lista "Solo aceptable para implementaciones preexistentes". En ese momento, las actualizaciones adicionales de las aplicaciones de pago validadas por PA-DSS después del vencimiento del propio estándar PA-DSS deberán evaluarse en el marco de software seguro.

¿Qué debo hacer si estoy próximo o en proceso de certificación de PA-DSS v3.2?

Por el momento se recomienda seguir el programa PA-DSS pues las validaciones de nuevas aplicaciones por PA-DSS v3.2 serán aceptadas hasta el 30 de junio de 2021 y válidas hasta el 28 de octubre de 2022.

Aplicaciones que se quieran validar por el nuevo marco de software seguro podrán iniciar el proceso durante el Q1 de 2020 y seguirán el mismo ciclo de 3 años de validez, al igual que PA-DSS.

¿Cómo me afecta la transición a PCI SSF si ya tengo una aplicación válida y certificada por PA-DSS v3.2?

La aplicación de pago se mantendrá en la “Lista de Aplicaciones de Pago Validadas” hasta su fecha de expiración establecida, y se podrán aplicar cambios según PA-DSS hasta el 28 de octubre de 2022. Tras esta fecha, la aplicación será movida a la lista "Solo aceptable para implementaciones preexistentes" y el programa PA-DSS será clausurado.

Línea de tiempo

CONCLUSIONES

Siguiendo la línea del ciclo de vida de las certificaciones aplicadas por el PCI SSC, era necesaria una renovación de PA-DSS de cara a poder albergar los nuevos desarrollos tecnológicos, por lo que la aparición de PCI SSF viene a cubrir en parte las necesidades en materia de certificación de aplicaciones de pago modernas y diversas. Además, al fraccionar el estándar PA-DSS en dos estándares que se complementan, hace posible que empresas enfocadas única y exclusivamente al desarrollo seguro de código o software, puedan validarse, publicarse y poseer una certificación, en este caso, bajo PCI SSLCS, lo que antes solo con PCI PA-DSS no era posible.
El resto de las empresas que estén cubiertas bajo PA-DSS, seguirán teniendo los mismos beneficios bajo PCI SSF obteniendo una flexibilidad adicional, lo cual, hace que este nuevo cambio de enfoque sea beneficioso para ambas partes, tanto la auditada como para los auditores.

REFERENCIAS

https://www.pcisecuritystandards.org/document_library


Autor: Alberto Villar - CISSP, PCI QSA, PCI PA-QSA, ISO 27001 L.A.
Dpto. Consultoría