Este es el primer artículo de una serie dedicada a desglosar el PCI Software Security Framework (SSF). En futuras entregas, profundizaremos en detalles técnicos y casos de uso específicos, pero hoy empezamos por los cimientos.
En el ecosistema de seguridad de pagos, los estándares no son estáticos; evolucionan para responder a amenazas que cambian a diario. Sin embargo, en mi día a día como asesor, he notado una desconexión preocupante. A pesar de que el PCI Software Security Framework (SSF) lleva tiempo vigente, existe un vacío de conocimiento generalizado.
No es solo que los Vendedores (Vendors) o las Entidades (Comercios/Bancos) estén confundidos. Lo más alarmante es que incluso algunos Asesores (QSAs) desconocen cómo evaluar correctamente una aplicación certificada bajo este nuevo marco.
Hoy quiero dejar de lado los tecnicismos profundos para hablar claro sobre qué es este marco y abordar las «malas prácticas» que veo repetirse, auditoría tras auditoría, por parte de todos los actores involucrados.
¿Qué es realmente el PCI SSF?
Para entenderlo fácilmente: el PCI SSF es la evolución natural y necesaria de la seguridad en el desarrollo de software de pagos. A diferencia de su predecesor (PA-DSS), este marco o framework es más flexible y modular. Se divide en dos estándares distintos pero complementarios:
- Secure Software Standard [El Software]: Se centra en la aplicación en sí. Evalúa que el software de pago esté diseñado y construido para proteger las transacciones y los datos sensibles. Es la validación mediante laboratorios que «la aplicación es segura».
- Secure SLC Standard [El Proceso de desarrollo]: Se enfoca en el ciclo de vida de desarrollo del vendedor. Aquí no validamos un software específico, sino la madurez del fabricante para producir software seguro de forma continua. Es la validación de que «la fábrica trabaja de forma segura».
Hasta aquí la teoría suena bien. El problema llega cuando aterrizamos esto a la realidad de las implementaciones y evaluaciones.
Nota aclaratoria: Aunque existen las certificaciones PCI Secure Software Standard (SSS) y PCI Secure Software Lifecycle (SLC), no es correcto afirmar que una organización posee una «certificación en SSF» o que «está certificada en SSF». El PCI Software Security Framework (SSF) no es una certificación en sí, sino un marco que agrupa ambas certificaciones mencionadas.
La muerte del PA-DSS y la trampa de la «Instalación Preexistente»
El estándar PA-DSS expiró. Punto. Sin embargo, el PCI Council permite su uso únicamente para «instalaciones preexistentes«. Muchos se aferran a esta cláusula como un salvavidas, pero aquí viene mi opinión profesional:
Ha pasado demasiado tiempo desde la expiración de PA-DSS. La tecnología avanza muy rápido. Es altamente probable que la infraestructura (hardware, sistema operativo, bases de datos) sobre la que se aprobó esa instalación original ya haya cambiado, se haya actualizado o esté obsoleta.
Si la infraestructura cambió, esa validación de seguridad ya no sirve. Mantener un software PA-DSS en un entorno moderno que no corresponde a su certificación original es vivir con una falsa sensación de seguridad.
El gran error: La Guía de Implementación y la complacencia del Asesor
Todo software validado bajo el Secure Software Standard viene con una Guía de Implementación (Implementation Guide – IG). Esto no es un manual de sugerencias; es una biblia normativa. La aplicación debe ser instalada exactamente en la infraestructura y versiones de Sistema Operativo que indica dicha guía y que aparecen listadas en el portal oficial del PCI Council.
Color Naranja: Versiones y dependencias aprobadas y fecha de vigencia.
Color Verde: Estándar y estatus del software.
Link PCI SSC Validated payment software: https://listings.pcisecuritystandards.org/assessors_and_solutions/payment_software
Link PCI SSC Validated SLC vendors: https://listings.pcisecuritystandards.org/assessors_and_solutions/software_lifecycle
He presenciado en varias ocasiones las siguientes escenas:
- Una entidad instala el software en una versión de Sistema Operativo diferente a la validada o en su defecto, instala una versión del aplicativo distinta a la listada en el portal del PCI Council.
- El Vendedor argumenta: «A otros clientes sí se lo han permitido, tienen esta misma implementación y su QSA se los aceptó como válido».
- El Asesor o QSA que revisa el entorno pasa por alto este detalle, ya sea por desconocimiento de cómo consultar el listado oficial o por falta de rigor al cotejar la guía de implementación.
Esto es una mala práctica que debe terminar.
Como asesores, tenemos la responsabilidad de ser estrictos: si el portal del PCI Council y la Guía de Implementación dicen «Versión X.1», no puede ser «Versión X.2». Si las versiones no coinciden, esa implementación no puede ser considerada como “Validada”, independientemente de lo que diga el vendedor o de que un asesor previo haya cometido el error de «darle el visto bueno».
Validar una aplicación fuera de sus parámetros certificados rompe la cadena de confianza. El sello de PCI SSF garantiza seguridad en un entorno controlado y probado; fuera de ese entorno, no hay garantías.
Conclusión
La transición a PCI SSF no es solo un cambio de siglas; es un cambio de mentalidad y rigor.
- A los Vendedores: mantengan sus validaciones al día con las infraestructuras modernas y ofrecidas a sus clientes, especialmente al personal comercial que complace con tal de vender sin dimensionar el impacto. Involucra al personal que lleva la certificación para confirmar que lo que ofrecen efectivamente es viable.
- A las Entidades: no acepten excusas sobre versiones o compatibilidades «a medias». Asesórese con su QSA previo a instalar, aceptar distintas versiones o cambios en el aplicativo.
- Y a mis colegas Asesores: es hora de estudiar a fondo los lineamientos. Nuestra firma en un reporte debe significar que realmente se verificó la alineación con la Guía de Implementación Oficial.
ES 
EN