El estándar de software seguro de PCI (PCI SSS) reemplazará al estándar de seguridad de datos de aplicaciones de pago (PA-DSS) y al programa cuando se cierre oficialmente el 28 de octubre de 2022. La aceptación de presentación de nuevas solicitudes de pago para la validación de las PA-DSS se cerró el pasado 30 de junio de 2021 y, tras el cierre del programa en octubre de 2022, todas las aplicaciones pasarán a estar en “expiradas” y movidas al listado de “Aceptadas únicamente para despliegues preexistentes”.
El nuevo estándar PCI SSS amplía los principios clave de protección de aplicaciones y datos de pago, que se introdujeron por primera vez en PA-DSS, y está diseñado para admitir un conjunto mucho mayor de arquitecturas de software de pago, funciones y metodologías de desarrollo de software.
Desde el pasado 2020 se abrió la aceptación de envíos de evaluaciones para publicación de listados en el programa marco SSF, el cual cuenta con un período de validación de tres años.
Como parte del cierre de PA-DSS en octubre de 2022, el programa PA-QSA también se retirará, por lo que los asesores deberán certificarse en alguno de los estándares del programa Marco de Software Seguro (PCI SSF), bien en PCI SSS (y convertirse en SSA o Secure Software Assessors) o bien en PCI SSLCS (y ser Secure Software Life Cycle Assessors o SSLCA) o ambos. Las empresas con asesores de SSF son organizaciones de seguridad independientes que están calificadas por PCI SSC para realizar evaluaciones según PCI SSS, PCI SSLCS o ambos. Por tanto, cabe destacar, que el estar certificado en un estándar solo se te permite realizar evaluaciones en dicho estándar.
Otra diferencia clara, es que el estándar PCI SSLCS está orientado a empresas fabricantes de software de pago, mientras que el estándar PCI SSS está orientado a evaluar dichas aplicaciones de pago, en línea a lo que se venía definiendo desde PA-DSS. Ambos estándares dentro del marco de Software Seguro (PCI SSF) mantienen listas públicas de validación diferenciadas, las cuales son mantenidas por el PCI SSC.
En cuanto a la relación con PCI DSS, el uso de software de pago validado bajo el marco SSF y usando en un entorno PCI DSS, cuenta con las siguientes características:
Se debe tener en cuenta que el uso de aplicaciones de pago validadas puede contribuir a conseguir el cumplimiento general de PCI DSS de una organización, pero este hecho no reemplaza la necesidad de realizar una auditoría completa de PCI DSS en el entorno.
Lo primero que debemos tener en cuenta a lo hora de relacionar ambos estándares es que PCI SSS se trata de un estándar totalmente nuevo y que no mantiene ninguna dependencia con PA-DSS, si bien, comparten algunos aspectos conceptuales entre ambos (en línea con las normas PCI) de cara a la securización de datos sensibles.
Una de las principales diferencias reside en el glosario (se puede consultar y descargar aquí), el cual es totalmente nuevo y diverge sustancialmente del usado en PA-DSS. Un ejemplo es la definición de “activo crítico” la cual engloba a datos, funciones y recursos “sensibles”. Cada uno de estos tres “elementos” sensibles, tiene su propia definición, pero a muy alto nivel, puede resumirse en datos, funciones y recursos que requieran protección ante ataques de confidencialidad e integridad (lo cual hace que dichas definiciones sean extensibles a la práctica mayoría de los componentes de las aplicaciones de pago). Si nos enfocamos exclusivamente en los “datos sensibles” tal y como los define el glosario, ya no solo tenemos que pensar como en PA-DSS que se tratan de datos de tarjeta, sino que ahora se incluyen en la definición otros tipos de datos como las credenciales de autenticación, información de sistemas internos, tokens, material de claves criptográficas, etc.
En resumen, podemos destacar tres puntos de PA-DSS y PCI SSF en cuanto a su interrelación:
Si nos centramos en el estándar PCI SSLCS, el cual recordemos que está orientado a empresas que son fabricantes de software de pago, encontramos las siguientes características novedosas y que no estaban reflejadas en PA-DSS, en caso de que la organización esté certificada como SSLC cualificada;
Tanto para aplicaciones de pago certificadas bajo PA-DSS v3.2 como para aplicaciones de pago que no hayan sido certificadas, es recomendado abordar la certificación o transición de estándar de la siguiente forma, divida en fases:
Es de vital importancia hacer un análisis diferenciar o “GAP” análisis al alcance del entorno de certificación de la aplicación. En caso de que la aplicación no haya sido certificada anteriormente, es muy probable que se deba hacer un ejercicio previo de definición de alcance. Esta definición de alcance debe ser definida tanto por el Fabricante del Software como por el SSA.
Una vez con el alcance definido, se deben analizar uno a uno todos los requisitos del estándar PCI SSS v1.1 a las personas, procesos y tecnologías que estén afectadas por dicho alcance.
Para una empresa con una aplicación de pago que no haya sido certificada, la experiencia nos demuestra que su grado de cumplimiento normativo respecto a la “antigua” PA-DSS (y por tanto se puede trasladar también para SSS), es prácticamente nulo. En cambio, para una aplicación que venga de superar una certificación PA-DSS anteriormente, parte con una base de cumplimiento de los requisitos asociados al estándar. Teniendo en cuenta un cumplimiento “mínimo” del estándar PA-DSS y que no se haya aumentado la madurez de los controles, se puede extraer el siguiente resultado a alto nivel para el cumplimiento de PCI SSS v1.1 de una aplicación de pago que no esté destinada a datáfonos y, por tanto, no le aplique el Módulo B:
| Figura 1: Gráfico porcentaje de cumplimiento total PCI SSS v1.1 |
| Figura 2: Gráfico porcentaje de cumplimiento total PCI SSS v1.1 por requerimiento |
| Proyectos esenciales en PCI SSS | |
| Título | Descripción |
| Identificación de los activos críticos | Inventariar todos los activos críticos; datos sensibles, funciones sensibles y recursos sensibles. |
| Valores predeterminados seguros | Revisión y/o elaboración de Guías de Bastionado o Guías de Configuración Seguras de las tecnologías dentro del alcance. |
| Retención de datos sensibles | Al haber ampliado la definición de datos sensibles, es necesario revisar los periodos de retención asociados a los mismos. |
| Protección de activos críticos | Identificar los escenarios de ataque y definir los controles de seguridad del software para mitigar dichos ataques. |
| Uso de criptografía | Revisar el uso de criptografía para la protección de los activos críticos, ya que se han establecido nuevos controles sobre las características de los algoritmos de cifrado a utilizar. |
| Seguimiento de la actividad | Revisión del sistema de gestión de logs, el cual ahora como cambio principal debe ser resiliente ante caídas del propio sistema, así como asegurar la integridad de log en todo momento. |
| Detección de ataques | Creación/revisión de los procedimientos y controles implementados para poder detectar ataques contra la confidencialidad y/o la integridad de los activos críticos. La identificación debe realizarse alertando en tiempo y forma. |
| Guía de Implementación | Revisión de la Guía de Implementación para modificar su contenido y alinearlo a la nuevo “Program Guide” y hacer referencia a los nuevos controles y requisitos del estándar. |
| Metodología de versionado | Actualizar la metodología de versionado para adecuarse a lo exigido por el “Program Guide” de PCI SSS. |
Para esta fase, que es la de mayor esfuerzo por parte de fabricante de software, se deben ir priorizado y abordando todos los proyectos que, como mínimo, se habrán identificado en la Fase I de Gap Análisis. Un aspecto clave de esta fase, es la coordinación que debe existir entre diferentes equipos del fabricante para poder asegurar que los proyectos son implementados de forma adecuada y que siguen el alineamiento de PCI SSS. Para este último aspecto, juega un papel fundamental contar con la ayuda de un SSA para ir enfocando o reenfocando dichos proyectos, los impactos en la aplicación y sus esfuerzos asociados.
Una vez se han abordado todos los proyectos identificados como necesarios para cumplir con los controles, la aplicación de pago y el fabricante, están en disposición de abordar una auditoría en la que los desalineamiento respecto a controles y requisitos del estándar, deben ser mínimos.
No es necesario abordar las fases anteriores (Fase I y II) para poder ir a una auditoría de PCI SSS, sin embargo, este hecho hará que el número de no cumplimientos que se identifiquen en la fase de auditoría puede ser muy elevado, con las complicaciones y la mas que probable dilatación de la auditoría que eso conlleva.
Los “pasos” o etapas en la auditoría completa o de certificación de PCI SSS, no han sufrido cambios sustanciales respectos a los que debían ser abordados en una auditoría completa de PA-DSS. Los pasos, que desde nuestra experiencia como auditores, creemos que son los mas adecuados para demostrar el cumplimiento de los controles son:
Estos seis pasos o etapas son los necesarios para poder extraer las evidencias requeridas en el estándar y ser detalladas en los informes de cumplimiento (RoV y AoV).
La transición hacia PCI SSF en su última versión, como hemos visto, se va a componer de dos variantes (una por cada estándar):
Autor: Alberto Villar - PCI SSA, PCI QSA, CISSP, CSSLP, ISO 27001 L.A., CSFPC, SFPC
Dpto. Consultoría
