Cuando una organización requiere almacenar, procesar y/o transmitir cualquier tipo de dato considerado como confidencial, directamente agrega una nueva variable al mapa de riesgos de su entorno. Esto ocurre con datos de carácter personal (PII), con datos clínicos o con datos de tarjetas de pago, por solo enumerar algunos ejemplos. Lamentablemente, muchas de estas organizaciones fallan en la adecuación e implementación de controles para gestionar la seguridad de estos datos, ya sea por desconocimiento o por negligencia, y es aquí cuando empiezan los problemas.

Por ello, actores externos (entidades gubernamentales,  legales o de la industria) tienen que entrar a regular el cumplimiento de una línea base de controles de seguridad con el fin de minimizar el impacto si dichos datos confidenciales llegan a ser comprometidos. Es así como el Reglamento General de Protección de Datos europeo (RGPD), la ley HIPAA (Health Insurance Portability and Accountability Act) estadounidense y el estándar de protección de datos de tarjetas de pago (PCI DSS) se han convertido en elementos clave a la hora de establecer una estrategia de seguridad corporativa (Governance, Risk Management, and ComplianceGRC).

Ahora bien, el verdadero incoveniente empieza cuando se tiene que establecer el ámbito de aplicabilidad de dichos controles. Entre más activos estén involucrados, más tiempo, personal y dinero se requieren para lograr un cumplimiento adecuado, de lo cual se deriva una conclusión obvia: menos activos, menos esfuerzo.

Es por ello que a continuación – y con base en mi experiencia de más de 10 años como asesor QSA – enumero 6 consejos clave para minimizar el entorno de cumplimiento de PCI DSS. Es igualmente importante no olvidar que por más que se empleen estas estrategias, no existe ninguna solución que exima a una entidad afectada del cumplimiento de PCI DSS (así sea residual) si almacena, procesa y/o transmite datos de tarjetas en su entorno.

Consejo 1: Segmentar y aislar el entorno de datos de tarjetas

Divide y vencerás” podría ser la frase perfecta para este consejo. De hecho, el PCI SSC lo describe de forma muy clara en el propio estándar PCI DSS (apartado “Segmentación de red”):

La segmentación de red, o separación (segmentación), del entorno de los datos del titular de la tarjeta del resto de la red de una entidad no constituye un requisito de las PCI DSS. Sin embargo, se recomienda enfáticamente como un método que puede disminuir lo siguiente:

  • El alcance de la evaluación de PCI DSS,
  • El costo de la evaluación de PCI DSS,
  • El costo y la dificultad de la implementación y del mantenimiento de los controles de PCI DSS, y
  • El riesgo de las organizaciones (que, gracias a la consolidación de los datos del titular de la tarjeta en menos y más controladas ubicaciones, se ve reducido).

Sin la adecuada segmentación de red (a veces denominada “red simple”), toda la red se encuentra dentro del alcance de la evaluación de PCI DSS. La segmentación de red se puede alcanzar mediante diversos medios físicos o lógicos, tales como firewalls internos de red, routers con listas de control de acceso robustas u otras tecnologías, con la apropiada configuración que restrinjan el acceso a un segmento particular de la red. Para considerarlo fuera de alcance para PCI DSS, un componente del sistema debe estar correctamente aislado (segmentado) del CDE de manera tal que si el componente del sistema fuera de alcance está en riesgo no afecte la seguridad del CDE

Para la correcta implementación de este consejo es imprescindible emplear la guía (Information Supplement) denominada “Guidance for PCI DSS Scoping and Network Segmentation“. En este documento se categorizan los ativos en tres grandes grupos:

  1. Sistemas del CDE
  2. Sistemas conectados o que puedan impactar la seguridad del CDE
  3. Sistemas fuera del alcance

Como se puede observar, mediante el uso de la segmentación es posible limitar la aplicabilidad de los controles de PCI DSS exclusivamente a los sistemas del CDE y a los sistemas conectados/que pueden impactar la seguridad del CDE:

Categorias para la definición del alcance de cumplimiento de PCI DSS

Más información en el artículo “El PCI SSC publica una guía para la determinación del alcance y segmentación de red para PCI DSS“.

Consejo 2: Delegación de controles en proveedores de servicio certificados

De lejos, este es el mejor consejo que una empresa puede seguir para minimizar su entorno. La delegación de controles de PCI DSS en proveedores de servicio certificados permite que la organización afectada se pueda focalizar en su negocio mientras que un tercero especializado se encarga de asumir el riesgo de una parte de los controles del estándar, en función del servicio ofrecido. Algunos ejemplos son:

  • Uso de proveedores certificados de cloud para servicios IaaS/PaaS como AWS, Microsoft Azure o Google Cloud Platform (GCP).
  • Uso de proveedores certificados de cloud para servicios SaaS como Trend Micro (antivirus), AlienVault (gestión de logs) o Sumologic (servicios de análisis de logs).
  • Proveedores de servicios gestionados (“managed service providers” – MSP) como Armor.
  • Uso de proveedores de servicios de datacenter y/o co-location como Equinix.

Para que este consejo sea efectivo, es imprescindible que se cumpla lo siguiente:

  • Que la empresa a contratar se encuentre listada como proveedor certificado en las listas de las marcas o que proporcione evidencia de su cumplimiento con PCI DSS a traves de su Attestation of Compliance (AoC).
  • Que la empresa a contratar ofrezca una matriz en donde se estipulen las responsabilidades de parte y parte en cada uno de los controles del estándar cubiertos por el servicio contratado.
  • Seguir los criterios estipulados en el “Information Supplement: Third-Party Security Assurance“.
  • El proveedor a contratar entrará dentro del ámbito del requerimiento 12.7 de PCI DSS.

Consejo 3: Emplear integraciones vía iFrame o redirección si se tienen canales de comercio electrónico

La publicación del documento de VISA “Processing e-commerce payments: A guide to security and PCI DSS requirements“ y del “Information Supplement: Best Practices for Securing E-commerce“ del PCI SSC marcaron un hito en la definición de responsabilidades y controles a cumplir en entornos de comercio electrónico. Antes de la publicación de dichos documentos, los controles de PCI DSS a cumplir por parte del entorno de comercio electrónico eran bastante ambiguos y susceptibles a diferentes interpretaciones por parte de los QSA. Con la entrada en operación de los cuestionarios de autoevaluación (SAQ) A y A-EP dichos controles quedaron claramente definidos y estipulados. Es así como en función del tipo de integración realizada y del riesgo asumido se deben asumir más o menos controles de PCI DSS:

Como se puede observar, una integración de comercio electrónico que use iFrame o redirección tendrá que cumplir con menos controles de PCI DSS y – por consiguiente – el riesgo asumido y el esfuerzo en el cumplimiento del estándar será menor.

Consejo 4: Emplear soluciones P2PE si se cuenta con canales de pago presenciales con datáfonos

En términos de transacciones presenciales, una solución P2PE es aquella que combina dispositivos seguros (datáfonos), aplicaciones y procesos que encriptan los datos de la tarjeta de pago desde el punto de interacción (lectura de banda o chip EMV) hasta que dichos datos son recibidos por un entorno seguro para ser descifrados y proceder con su autorización.

Gracias a estas características de seguridad se minimiza la superficie de ataque a transacciones presenciales (RAM scraping, sniffing, etc.) y – por ende – los controles de PCI DSS que se deben cumplir en este entorno son menores en relación con otros escenarios tradicionales con datáfonos, ya que el comercio no tiene acceso a las claves de encriptación ni a datos de tarjetas en texto claro:

Los proveedores de soluciones P2PE se encuentran listados en la página del PCI SSC. Igualmente, los comercios que lo consideren necesario pueden implementar su propia solución de P2PE.

Consejo 5: Usar tokenización

La tokenización es un concepto bastante sencillo pero efectivo. Consiste en el remplazo de un dato confidencial por otro que no lo es, pero que garantiza la misma operatividad. El token es un dato no confidencial (es decir, no representa mayor riesgo a la organización en caso que sea filtrado o comprometido ya que su campo de acción está restringido) y se genera bajo la premisa de que desde él no se puede obtener ni inferir el dato confidencial con el que se relaciona.

Para explicar este concepto, se puede pensar en las fichas de un casino. Para jugar, se debe cambiar dinero real por fichas, las cuales son válidas únicamente en ese casino en particular. Si alguien las roba, su campo de acción estará limitado ya que no las podrá utilizar en otros casinos, restringiendo al atacante y desmotivando su delito ya que la ganancia será menos efectiva que si fuera dinero real.

En el caso de datos de tarjetas de pago, la tokenización reemplaza el dato del PAN por otro dato no confidencial y mantiene una tabla de correspondencia para realizar el proceso inverso (destokenización) en caso de ser necesario (obtener un PAN de su token).

Siguiendo este criterio, un token no es un PAN por lo que los requerimientos de PCI DSS no aplican allí donde se almacene, se procese o se transmita, con lo cual aquellos procesos de la empresa por los que fluya un token (conciliación, liquidación, entornos de pagos recurrentes y pagos en un clic (OCP), soporte a incidencias y reclamaciones, devoluciones, impresión de informes, etc.) no estarían sujetos al cumplimiento del estándar, minimizando de forma significativa el entorno de cumplimiento.

Este tipo de servicios se pueden contratar en formato SaaS (Software as a Service), provisto por un tercero que puede ser una pasarela de pago o una empresa de seguridad. Dicho servicio recibe el nombre de Tokenization as a Service (TaaS).

Consejo 6: Eliminar o remplazar cualquier sistema antiguo y/o no soportado

El uso de sistemas antiguos y/o no soportados (aplicaciones, sistemas operativos, protocolos, hardware, equipos de red) es una de las fuentes más importantes de problemas y brechas de seguridad en un entorno PCI DSS, ya que son estos sistemas los primeros objetivos que intentará atacar un delincuente.

Para mitigar de forma temporal la ausencia de actualizaciones, soporte del fabricante y/o controles de seguridad nativos se opta por implementar controles compensatorios, que, a la larga, añaden más trabajo y complejidad al entorno. Además, su mera existencia implica ya de por sí incumplimientos en los escaneos de vulnerabilidades, pruebas de penetración y demás verificaciones periódicas de seguridad.

Por ello, muchas veces es mejor sopesar los costes involucrados en el mantenimiento a largo plazo de estos sistemas (administración, operación, controles de seguridad adicionales, integración con otros sistemas, etc.) vs. su eliminación y/o migración a una plataforma actualizada o en su delegación a un tercero. Con estas acciones, el entorno de cumplimiento se simplificará notablemente.

Al igual que con cualquier decisión a nivel corporativo, se tienen que analizar los pros y los contras de cada una de estas soluciones, el retorno de inversión (ROI) a largo plazo y la integración con el entorno informático de la organización para que la acción de minimización del ámbito de aplicabilidad del entorno sea efectiva.

Para finalizar, resumimos estos 6 consejos en la siguiente infografía (clic derecho -> “Ver imagen” para ampliarla):