protocolo-https


NOTA: El 18 de diciembre de 2015 el PCI SSC extendió las fechas de migración hasta junio de 2018. Más información en el artículo “El PCI SSC amplía la fecha para la migración de SSL y versiones previas de TLS“.


En abril de 2015 el PCI SSC publicó el suplemento informativo “Migrating from SSL and Early TLS” que acompañó a la nueva versión de PCI DSS de aquel entonces (3.1), cuyo cambio fue motivado precisamente por el riesgo en el uso de SSL (Secure Sockets Layer) y versiones antiguas de TLS (Transport Layer Security) debido a una serie de vulnerabilidades graves que afectaban la confidencialidad de los datos transmitidos:

  • BEAST (“Browser Exploit Against SSL/TLS”) – CVE-2011-3389
  • CRIME (“Compression Ratio Info-leak Made Easy”) – CVE-2012-4929
  • BREACH (“Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext”)
  • HEARTBLEED – CVE-2014-0160
  • POODLE (“Padding Oracle On Downgraded Legacy Encryption”) – CVE-2014-3566
  • FREAK (“Factoring Attack on RSA-EXPORT Keys”) – CVE-2015-0204

Algunas de estas vulnerabilidades podían ser corregidas mediante actualizaciones (como en el caso de HEARTBLEED), pero otras (como POODLE) afectan de forma profunda la arquitectura del protocolo afectado, por lo cual la única alternativa es la migración a una versión segura.

Debido a ello, a continuación enumeramos 5 conceptos a tener en cuenta en la planificación de la migración de SSL y versiones antiguas de TLS para gestionar el cumplimiento de PCI DSS y la seguridad de los datos de tarjetas de pago transmitidos.

1. ¿Cuáles versiones de SSL y TLS se pueden usar en un entorno PCI DSS?

De acuerdo con la guía, el protocolo SSL en todas sus versiones debe ser migrado inmediatamente.

Las versiones aceptadas de TLS aceptadas son – como mínimo – las versiones 1.1 y 1.2. Hay que tener presente que no todas las versiones de TLS 1.1 son consideradas seguras, por lo que se recomienda consultar el documento NIST SP 800-52 rev 1 antes de tomar una decisión.

2. ¿Cuáles fueron los requerimientos de PCI DSS afectados por este cambio?

Los requerimientos que fueron afectados por este cambio son:

  • Requerimiento 2.2.3: Implemente funciones de seguridad adicionales para los servicios, protocolos o daemons requeridos que no se consideren seguros.
  • Requerimiento 2.3: Cifre todo el acceso administrativo que no sea de consola utilizando un cifrado sólido.
  • Requerimiento 4.1: Utilice cifrado sólido y protocolos de seguridad para proteger los datos confidenciales del titular de la tarjeta durante la transmisión por redes públicas abiertas.

En general, cualquier requerimiento que hiciera mención explícitamente a SSL o a cifrado sólido/criptografía sólida (“strong cryptography”), ya que SSL y las versiones anteriores de TLS dejan de ser consideradas como tal. Estos conceptos son los que hacen la diferencia – en términos generales – entre las versiones 3.0 y 3.1 de PCI DSS y sus documentos asociados.

Para PCI DSS v3.2, se ha agregado un anexo denominado “Appendix A2: Additional PCI DSS Requirements for Entities using SSL/early TLS” que permite describir con mayor detalle las acciones de mitigación y migración de SSL a TLS.

3. ¿Qué pasa con mi cumplimiento de PCI DSS si tengo SSL y/o versiones anteriores de TLS en mi entorno?

Si en la organización se cuenta con un sistema que usa y/o tiene necesidad de soportar protocolos vulnerables o se implementarán algunos de los siguientes entornos a partir de abril de 2015:

  • Instalación de un sistema en un entorno que actualmente usa y/o tiene necesidad de soportar protocolos vulnerables
  • Instalación de una aplicación en un sistema que actualmente usa y/o tienen necesidad de soportar protocolos vulnerables
  • Desarrollo de un nuevo sistema o red que se comunique con otros sistemas / redes que actualmente usen protocolos vulnerables

Dichas implementaciones serán consideradas como una implementación existente (“existing implementation”) y hay plazo máximo para migrar estos protocolos hasta el 30 de junio de 2016 30 de junio de 2018.

No obstante, las pruebas de penetración y los análisis de vulnerabilidades internos y externos (ASV) detectarán estas vulnerabilidades y las reportarán como incumplimientos. Para gestionar estos hallazgos, la entidad afectada requiere desarrollar los siguientes documentos formales:

  • Plan de mitigación de riesgos: En donde se describa el uso de los protocolos vulnerables, los tipos de datos transmitidos, los canales de pago empleados y la cantidad y el tipo de sistemas afectados, las acciones de monitorización en caso de nuevas vulnerabilidades que se identifiquen, así como los controles implementados para mitigar el riesgo de explotación hasta que se haya finalizado la migración en su totalidad.
  • Plan de migración: En donde se describan los sistemas/entornos que deben ser migrados, las tareas a realizar y las fechas en las cuales se realizará esta tarea, sin sobrepasar el 30 de junio de 2016 30 de junio de 2018.

El uso de SSL y versiones previas de TLS en terminales POI (Point of Interaction) y sus puntos de terminación que puedan verificar que no son susceptibles a exploits conocidos de SSL y versiones previas de TLS y sin riesgo demostrado, pueden seguir siendo usadas más allá de junio de 2018 como una excepción, conforme con lo descrito en PCI DSS v3.2.

3. ¿Qué debo tener en cuenta en la implementación de nuevos entornos?

Si en la organización se implementarán algunos de los siguientes entornos a partir de abril de 2015:

  • Instalación de un sistema en un entorno que actualmente usa únicamente protocolos seguros
  • Instalación de una aplicación en un sistema que actualmente usa únicamente protocolos seguros
  • Desarrollo de un nuevo sistema o red que se comunique con otros sistemas/redes que soportan protocolos seguros

O si la nueva implementación no requiere soportar el uso de instancias pre-existentes de protocolos vulnerables, dichas implementaciones serán consideradas como implementaciones nuevas (“new implementations”). En tales casos, no deberá existir ningún soporte para SSL o versiones anteriores de TLS y se deberán configurar las versiones de TLS con soporte para criptografía robusta.

4. ¿Cuáles controles de mitigación de riesgo puedo usar antes de la fecha de migración si tengo SSL y versiones anteriores de TLS en mi entorno?

Algunos de los controles que se pueden implementar para minimizar el potencial riesgo causado por las vulnerabilidades en los protocolos afectados son:

  • Minimizar los sistemas/servicios que usan versiones vulnerables de estos protocolos.
  • Restringir el uso de sistemas/servicios con protocolos vulnerables únicamente a determinados sistemas/entidades empleando reglas de filtrado de tráfico.
  • Monitorizar de forma activa los controles detectivos (IDS, firewall, FIM, etc.) y optimizar los controles reactivos (IPS, WAF, etc.) para responder ante potenciales intentos de explotación de las vulnerabilidades.
  • Aplicar las recomendaciones de los fabricantes de los productos afectados por estas vulnerabilidades y mantenerse informado si aparecen nuevos problemas.

5. ¿Cuáles opciones de migración existen?

Aparte de la migración y remplazo de las versiones de los protocolos afectados a versiones consideradas seguras, se pueden utilizar otras opciones dentro del programa de migración:

  • Encriptar el dato a nivel de campo (“field level”) o de aplicación (“application level”) ANTES de ser transmitido por un canal que soporte SSL o versiones anteriores de TLS.
  • Emplear conceptos de “tunelización” en los cuales se establece un canal seguro (IPSEC, por ejemplo) ANTES de transmitir los datos por un canal que soporte SSL o versiones anteriores de TLS.
  • Adicionalmente (y para la protección exclusiva de credenciales de autenticación) se puede emplear el uso de doble factor de autenticación.

Como se puede ver en estos controles, se garantiza la confidencialidad del dato de forma previa ANTES del envío por un canal que soporte SSL o versiones anteriores de TLS, gestionando el potencial riesgo de acceso no autorizado a información confidencial

Como siempre, les invitamos a participar en el foro o dejar un comentario en este artículo si se tiene alguna duda, comentario o sugerencia.