Hace solo unas semanas, Pomelo renovó PCI-DSS en su última versión, la 4.0, un logro que demuestra nuestro compromiso con el cuidado de la información y nuestra capacidad de adaptarnos a los cada vez más exigentes requisitos de seguridad definidos por la industria de medios de pago.
Como anunciamos en la nota anterior, esta nueva versión del estándar fue lanzada a nivel global en marzo del 2022, y será exigida de forma obligatoria recién en marzo del 2025, ya que se espera que en ese plazo las entidades puedan adaptarse a sus nuevos requerimientos. Veamos a continuación las precisiones técnicas de esta nueva versión de PCI-DSS y cómo logramos ser una de las primeras empresas en Latam en obtenerla.
¿Qué cambia en la versión 4.0 de PCI-DSS?
El mundo ha cambiado mucho desde el lanzamiento de la versión anterior, la denominada 3.2.1, dada a conocer en el año 2018. El crecimiento de las operaciones online impulsado por la pandemia y la expansión de las soluciones cloud, obligaron a endurecer y mejorar los controles de este volumen, en el cual se añadieron 63 nuevos puntos de control, sumando una totalidad de 423 controles, distribuidos en 12 áreas temáticas y 3 anexos. Todos ellos, en conjunto, buscan elevar el nivel general de seguridad de todas las entidades alcanzadas por la normativa.
Esto significa que obtener la certificación, que incluso en su versión anterior ya era compleja, fue aún más difícil. ¡Es por eso que compartimos con ustedes, nuestros lectores, algunos de los desafíos que enfrentamos hasta llegar a la más reciente versión de PCI-DSS!
Los desafíos de la versión PCI-DSS 4.0 que resolvimos
Análisis GAP:
El primer paso antes de poder encarar la certificación fue realizar un exhaustivo análisis a conciencia para evaluar si efectivamente era posible encarar la nueva versión en un tiempo razonable, o si por el esfuerzo que representaba era preferible mantenernos en la 3.2.1 y aprovechar los plazos vigentes.
De esta forma se pudieron identificar aquellos puntos que exigían mayor dedicación, calcular el esfuerzo para cumplirlos, para luego trazar un cronograma distribuido en hitos y sus respectivos entregables, confirmando el resultado final en el período objetivo.
CDE: alcance y pruebas de segmentación
Los ajustes hechos tanto en el requerimiento 1 como al apéndice A1 se abocan a revisar y definir de forma explícita el alcance de la denominada zona “CDE” (por sus siglas en inglés “Card Data Environment”). Es decir, aquel segmento de red donde se concentran los datos de tarjeta, y en consecuencia se consolidan la gran mayoría de los controles y herramientas a desplegar a lo largo de todos los puntos siguientes.
En principio, el equipo de DevSecOps actualizó y documentó en detalle la relación y componentes del CDE. Luego, este alcance fue contrastado por un flujograma desarrollado en conjunto por los equipos de Payment Processor e Issuing, validando que la información afectada fluía de forma exclusiva dentro de las cuentas establecidas.
Una vez definidos los límites de este segmento, el equipo de Platform Solutions desarrolló una extensa serie de pruebas técnicas, demostrando de forma fehaciente que la separación entre los mismos se realiza de forma concreta y robusta, generando evidencia empírica que remarca la solidez de los controles implementados.
Cifrado de “Datos Sensibles de Autenticación” (SAD)
Entre los nuevos requisitos 4.0, el control más complejo quizás sea el definido en el requerimiento 3, donde se amplían las exigencias técnicas a nivel de cifrado, cubriendo la totalidad del ciclo de vida de los datos SAD (Sensitive Authentication Data), tanto en los momentos previos a ser procesados, como al transporte y a su estado posterior en reposo.
Para resolver estos requisitos, el equipo de Platform Solutions (¡una vez más!) implementó una versión mejorada en la puerta de entrada de las peticiones clientes. Se incorporó un cifrado a nivel de payload sustentado por algoritmos RSA, el cual complementado con las implementaciones MTLS (a nivel de transporte) y AES 256 (a nivel de DB) logran el nivel suficiente y necesario que satisface estos puntos.
Antimalware
El requerimiento 5 incorpora nuevos puntos relacionados con políticas antimalware en diversos componentes del entorno, tanto a nivel de workstation, como de prevención de personas (antiphishing), además de un aumento en la frecuencia de los controles.
El equipo de Access Response se puso al hombro el alcance completo, y logró dar cumplimiento adecuando las funcionalidades del motor antiphishing y la solución EDR, además de ajustar el calendario de las revisiones que ya venían haciendo desde el ciclo anterior.
Autenticación reforzada
El octavo requerimiento refuerza varios controles en relación a la autenticación:
- La cantidad mínima de caracteres requeridos para las contraseñas se incrementa de 8 a 12.
- El Doble Factor de Autenticación se vuelve mandatorio para ambientes y acciones críticas.
El modelo de Zero Trust desplegado por el equipo de Access Response fue idóneo para dar por cubierto estos requerimientos. Adicionalmente, la incorporación de una herramienta DAST (Dynamic Application Security Testing) cubre otro nuevo requerimiento muy puntual: asegurarse de que no haya passwords “hardcodeados” a nivel de código.
Análisis de Vulnerabilidades autenticados
El requerimiento 11 exige que los análisis de vulnerabilidades se realicen con usuarios autenticados, una modalidad que no era un requisito en la versión anterior.
Este ajuste fue incorporado de forma inmediata por parte del equipo de Platform Solutions a su calendario y esquema de pruebas, tras una minuciosa evaluación previa de su factibilidad técnica.
¡Y pusimos cuarta a fondo!
Además de los desafíos que mencionamos más arriba, hay novedades importantes a destacar sobre esta nueva versión, que también abordamos para poder dar cumplimiento. Estas son algunas de ellas:
- Inventario de certificados digitales: Una nueva incorporación del requerimiento 4 exige detallar los certificados digitales utilizados en la solución. Para dar cumplimiento, el equipo de Gobernanza, Riesgo y Cumplimiento (GRC) relevó y listó los certificados asociados al entorno CDE, incluyendo su dominio, entidad emisora y fecha de vencimiento.
- Revisiones periódicas de usuarios: Cabe destacar que el requerimiento 7 incrementa el nivel y frecuencia de las revisiones de los permisos y roles de los usuarios asociados al CDE. Nuevamente, el equipo de Access Response desplegó una matriz extendida y mejorada de los roles designados a cada usuario afectado, generando la evidencia necesaria.
- Prevención y Detección de Intrusiones: Un control que antes se planteaba como sugerencia, a partir de esta versión se vuelve mandatorio: la necesidad de contar con una herramienta de prevención y detección de intrusiones. Desde sus inicios, Pomelo cuenta con estas soluciones como parte del set de herramientas gestionadas por el equipo de DevSecOps, con lo cual no fue necesario realizar cambio alguno.
- Formalizar Políticas de Cifrado: Si bien en la anterior se mencionaban diversos controles relacionados al uso de criptografía robusta, la nueva versión del estándar exige en su punto 12 la necesidad de documentarlo de forma detallada, explicitando el alcance, versión y modalidad de los mismos.
Fue tarea del equipo GRC el documentar y consolidar en un solo documento todas las herramientas utilizadas en Pomelo que aportan al uso de soluciones de cifrado, incluyendo a los HSM y los repositorios seguros.
- Awareness & Gestion de Incidentes: Además del cifrado, el requerimiento 12 suma también nuevas especificaciones sobre la capacitación y el entrenamiento del staff involucrado en la gestión operativa del CDE, sobre áreas como la Gestión y el Tratamiento de Incidentes. El equipo de GRC utilizó las funcionalidades de la herramienta de e-learning y documentación de respaldo para dejar evidencia del cumplimiento requerido.
- Análisis de Riesgos focalizado: Por último, el duodécimo requerimiento reformula las condiciones necesarias para realizar el Análisis de Riesgos, poniendo el foco en aquellos inherentes a la operatoria del negocio y en consecuencia que afectan al CDE.
La metodología implementada por el equipo de GRC para realizar este relevamiento se modificó y ajustó para cubrir lo definido en esta nueva versión.
- Seguimiento y control: Complementando al análisis GAP inicial, el equipo de GRC desarrolló un extenso y detallado tablero de control que refleja el estado de cumplimiento de los 423 puntos de la versión 4.0, de forma tal de poder monitorear los avances, evidencias e incluso desvíos, cerrando el circuito de control hasta la próxima instancia de certificación.
Esta es una muestra parcial de algunos puntos de interés del estándar 4.0 y cómo los resolvimos desde Pomelo. Para ver el detalle completo de los cambios introducidos por esta versión, puedes consultar el listado detallado desde este link oficial del PCI Council.