smartphone


NOTA DEL EDITOR: Queremos presentar a nuestro nuevo colaborador  Guillem Fábregas, profesional de la seguridad con amplia experiencia en la implementación de PCI DSS. ¿Quieres saber si es necesario que una aplicación instalada en un smartphone cumpla con PCI DSS? Guillem en este primer artículo responde a esta pregunta y ofrece una serie de recursos para implementar los controles de seguridad necesarios.


Por todo lo que hemos leído sobre PCI DSS, tenemos claro que aplica al entorno en el que se almacenan, procesan y/o transmiten datos de tarjetas de pago. No obstante, hay escenarios específicos con estas características donde el estándar PCI DSS no acaba de encajar y para los que el PCI SSC ha definido otros estándares concretos, como son por ejemplo PA-DSS (que aplica a aplicaciones de pago vendidas como un paquete comercial), P2PE (para soluciones de Point-to-point encryption), PTS (para dispositivos que tratan PINs de tarjetas) o PCI Card Production (para entidades que fabrican tarjetas de pago).

No obstante, existen algunos escenarios en los que se almacenan, procesan y/o transmiten datos de tarjeta, y sobre los cuales todavía no existe ninguna regulación específica del PCI SSC que se ajuste a sus necesidades concretas.

Uno ejemplo de este tipo de escenarios son los entornos con aplicaciones de pago instaladas en dispositivos smartphone de usuarios finales. Estas aplicaciones pueden ser desarrolladas y pertenecer a un comercio o entidad, y ser descargadas desde repositorios oficiales por los propietarios de los teléfonos. Las funciones que permiten realizar dichas aplicaciones varían en cada caso, y pueden ir desde el ofrecimiento o catálogos de productos de comercios, la posibilidad de contratar diferentes tipos de servicios, disfrutar de juegos interactivos, etc. Pero todas tienen un punto en común, y es que ofrecen la posibilidad de realizar transacciones monetarias con la introducción de los datos de tarjeta de pago del usuario.

Así pues, en el momento de la realización de un pago, dichas aplicaciones suelen utilizar una redirección a un TPV Virtual del banco o del centro autorizador asociado a la aplicación, donde el usuario podrá introducir sus datos de tarjeta y formalizar así la transacción.

El esquema funcional de dicho entorno se corresponde al siguiente:

diagrama

Al tratarse de aplicaciones de pago facilitadas como un paquete estándar a los usuarios, todo hace pensar que la entidad propietaria de las mismas estará sujeta al cumplimiento de la PA-DSS. No obstante, el PCI SSC emitió un comunicado donde especificaba que aunque el estándar es de recomendada aplicación, su cumplimiento no es obligatorio en estos casos, hasta tanto no se desarrolle un estándar específico en un futuro:

“In June 2011, PCI SSC agreed (see PA-DSS and Mobile Applications FAQs, 22 June 2011) that mobile payment-acceptance applications that qualify as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance”.

“The PCI SSC recommends that mobile payment acceptance applications that fit into Category 3 and are thus not eligible for PADSS validation at this time but are intended for use in the cardholder data environment are developed using PA DSS as a baseline for protection of payment card data and in support of PCI DSS compliance.”

Otra opción que nos puede venir a la cabeza es que dichos entornos estén sujetos al cumplimiento de los SAQ A o SAQ A-EP, pensados para e-commerce en los que las funciones de pago están externalizadas, en este caso al banco adquiriente o de un centro autorizador, propietario del TPV Virtual asociado a la aplicación en cuestión.

No obstante, dichos SAQ están orientados a entornos de e-commerce donde exista un servidor web público desde el que se realice una redirección a un servidor de pago. En dichos casos, existe el riesgo de que el servidor web sea vulnerado por un atacante y se modifique la redirección hacía un portal web no legítimo, causando que el usuario final ingrese sus datos de tarjetas en él. Por lo tanto, el contenido de dichos SAQ está enfocado sobre todo a la protección y monitorización continua de la seguridad del servidor web del comercio online como tal, más no de la aplicación móvil que lo invoca.

En el caso que nos ocupa, la aplicación se encuentra instalada en el smartphone de un usuario final, sobre el cual la entidad propietaria de la aplicación no puede tener control en términos de seguridad – y por lo tanto – dichos SAQ tampoco encajan en este tipo de escenarios.

Entonces nos preguntaremos: ¿Qué hacemos entonces en estos casos? ¿Qué normativa o medidas de seguridad debemos aplicar?

La respuesta es que por el momento, dichos escenarios no están sujetos al cumplimiento obligatorio de ningún estándar concreto del PCI SSC. No obstante, el Council emitió en Julio de 2014 una guía de recomendaciones de seguridad a aplicar en el desarrollo de este tipo de aplicaciones.

Dicha guía, trata medidas de seguridad específicas para el desarrollo seguro de las aplicaciones de pago en móviles, como son por ejemplo las siguientes:

  • Prevenir los accesos no autorizados a la aplicación.
  • Crear la posibilidad de deshabilitar remotamente la aplicación.
  • Definir e implementar un correcto Cicle de Vida de Desarrollo de Sofware (SDLC).
  • Proteger la aplicación contra malware.
  • Etc.

De las cuales, y según la siguiente FAQ del PCI SSC, se deberán tener en cuenta solo aquellas medidas de la guía que apliquen al desarrollo seguro de las aplicaciones, omitiendo así los requerimientos relativos a la securización del dispositivo final (smartphone):

If a merchant develops an application that runs on a consumer’s device (e.g. smartphone, tablet, or laptop) that is used to accept payment card data, what are the merchant’s obligations regarding PCI DSS and PA-DSS for that application?
    
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.

Even though the consumer’s environment is outside of the merchant’s PCI DSS scope, the development of the application is in scope, as the application is being developed for the purpose of the merchant’s payment acceptance process. The application should therefore be developed in accordance with industry best practices and applicable PCI DSS requirements – for example, Requirements 6.3, 6.4 and 6.5.

It is recommended that applications be developed using PA-DSS as a baseline for the protection of payment card data. Sources of industry guidance for developing mobile applications include ENISA and OWASP, as well as the PCI Mobile Payment Acceptance Security Guidelines for Developers.

Por lo tanto – y hasta que el Council defina las obligaciones de cumplimiento para este tipo de entornos – recomendamos encarecidamente la adopción y cumplimiento de esta guía oficial. Además, recordamos a los usuarios finales de este tipo de aplicaciones, que éstas deben ser siempre descargadas desde repositorios oficiales para tal efecto, evitando las descargas desde repositorios no legítimos y posiblemente fraudulentos.

Agradecimientos especiales a Javier Lorrio por sus comentarios y aportaciones al artículo.