PCI DSS es un estándar en el mundo de pagos, el cual busca garantizar la protección de la información perteneciente al tarjetahabiente, todos los merchants y providers que almacenen, procesen o trasmitan cardholder data deben cumplirlo, básicamente si estás pensando en permitir pagos por los rieles de las tarjetas de credito, este es un estándar al que debes adherirte, claramente hay servicios para e-commerce que buscan quitar la complejidad de obtener la certificación de cumplimiento dada por niveles, como se muestra en la Figura 1, un ejemplo es un facilitador de pago como Payu, el cual almacena y procesa esta información por u8n e-commerce. Recientemente, estuve involucrado en este proceso de certificación desde el momento 0, y quiero resumir 4 pequeños datos o aprendizajes que logre obtener en este camino tan empinado
El producto es importante, pero no es lo único
El estándar certifica un producto, es decir, el producto que va a procesar las transacciones que involucran información de las TDC, sin embargo, este producto tiene infinidad de componentes, tanto tecnológicos como no tecnológicos, en tecnológicos es todo lo que rodea al producto redes, logs, integraciones, y todos son igual de importantes, porque al tener tantos componentes, cualquiera puede incurrir en guardar número de la tarjeta o secuirty code sin un proceso adecuado de tokenizacion (el security code no se puede guardar ni tokenizado), los otros componentes son las personas que van a interactuar con ese producto, administradores de la plataforma, DBA, Devs, personas de Ops, estos involucrados, también van a estar expuestos a evaluaciónes (entrevistas), y finalmente todo esto genera un componente documental, es decir todo lo que involucre un cambio a la plataforma, a la red, o a cualquier componente mencionado anteriormente que están en el alcance de PCI, debe tener una gestión de cambio, los cuales van referenciados en los formatos que se entregaran para la certificación
Entender la interoperabilidad entre componentes
Volviendo a lo tecnológico, generalmente un producto se desarrolla usando librerías o frameworks, los cuales utilizan diferentes métodos de comunicación entre componentes, algunos utilizan invocaciones de APIS, otros llamados a SDK e incluso algunos con métodos asíncronos, todo esto buscando tener una excelente comunicación entre diferentes servicios, esto es normal en una arquitectura general, un ejemplo simplificado se puede ver en la Figura 2, en el caso de la Figura 2, entender que todos componentes por defecto están logueando información a CloudWatch, es clave para el éxito de la certificación, pues estos pueden guardar información en cualquier instante, por lo tanto, deben desarrollarse filtros para procesar antes esta información
Todo gira en torno a la información del tarjetahabiente
La certificación se logra garantizado que la información del tarjetahabiente viaje dentro el producto con algún proceso de tokenizacion, la información de mayor relevancia es el número de tarjeta y el código de seguridad, en consecuencia, la revisión del QSA estará enfocada en estos datos, obviamente al tener otras certificaciones, podría ayudar a que se reutilizan ciertas cosas, métodos y procesos, pero lo importante al final del día para el QSA es que estos datos (card number y secuirty code) viajen pasando primero por un proceso de enmascarado
Los permisos
Ya lo dijo conway con su ley, y es como un sistema es el reflejo de su organización, por eso los permisos y la estructura organizacional debe verse claramente en el sistema, eso quiere decir que cuando el QSA evalúe, los permisos que estén asignados dentro del sistema, deben seguir la mimas lógica del árbol organizacional, por lo tanto, si el QSA encuentra permisos asignados a personas que no deberían tenerlos, esto podría quitar puntos. Para la gestión del riesgo que genera asignar permisos, se manejan diferentes metodologías, con el objetivo de entender como se mitiga ese riesgo, aquí lo importante de los permisos es entender que a mayor flexibilidad de permisos mayor riesgo tendrá, esto no necesariamente es malo, porque si son obligatorios para el buen funcionamiento del sistema, se deben otorgar, lo que se debe hacer es tener documentación de esos registros y dentro de la matriz de riesgos tener esta clasificación alta, todas estas asignaciones van ligados a unos procesos de capacitaciones, para que el equipo entienda la responsabilidad que generan esos permisos.
Conclusiones
Es un proceso que puede ser bastante largo, puede tomar hasta 6, 12 meses (el de nosotros tomo poco más de 2 meses) y algunas empresas no lo logran, para mí hay 2 cosas que son superimportantes en el proceso
- Un equipo multidisciplinario con conocimiento en:
(i) El ecosistema de payments,
(ii) Todo lo relacionado con compliance (documentos, metodologías, etc)
(iii) y con altas capacidades técnicas
- Asignación y seguimiento de tareas de una forma eficiente, si bien son 12 puntos lo que se evalúan, estos generan una gran cantidad de tareas, asignar un responsable y un tiempo estimado de entrega, es la única forma de garantizar que se logren los objetivos
par finalizar como consejo, es relevante que durante la evaluación del sistema por parte del QSA, este involucrado un desarrollador que tenga la visión y claridad del todo el producto en general, y que cualquier pregunta que se haga, la respuesta que sé dé, debe ser clara, concisa y corta.
¿Te gusto el post y quisieras poder aplicar lo aprendido?
