20 controles adicionales para optimizar los niveles de seguridad provistos por PCI DSS

Desde el 2006, el PCI SSC ha realizado un trabajo muy importante en cuanto a la estandarización de controles de seguridad para la protección de datos de tarjetas de pago. Sin embargo, esta labor es una carrera contra el tiempo: cada día aparecen nuevas vulnerabilidades y los controles de seguridad se quedan cortos si no se actualizan para gestionarlas. Prueba de ello fue la publicación adelantada (fuera del ciclo tradicional de 3 años ) de la versión 3.1 de PCI DSS en abril de 2015 para cubrir los problemas derivados de la masificación en la explotación de las vulnerabilidades CVE-2014-0160 (HEARTBLEED) y CVE-2014-3566 (POODLE).

Figura 1. Ciclo de vida de los estándares PCI DSS y PA DSS
Por otro lado, el impacto que implica un cambio en el estándar PCI DSS al agregar un nuevo control o modificar uno ya existente, deriva en inversión de tiempo y dinero en comercios y proveedores de servicio afectados, lo cual añade una capa adicional de complejidad para lograr que exista una protección efectiva en un corto plazo. Es por ello que cada cambio viene acompañado de un periodo de gracia para permitir la alineación del entorno con este nuevo cambio, tiempo que – a la larga – es una ventana de exposición en la cual se debe asumir el potencial riesgo al que esté expuesta la organización mientras que la aplicabilidad del control entra en vigencia.

Siendo así, son múltiples las variables que se deben tener en cuenta en el momento de actualizar estos estándares: complejidad técnica o física del nuevo control, impacto en la operación, cobertura generalista de los entornos afectados, compatibilidad con las plataformas de hardware y software, cambios en la cultura y el día a día del mantenimiento de los controles del estándar, resistencia al cambio por parte de las entidades afectadas, costes vinculados, etc.

Más allá de la seguridad provista actualmente en los entornos certificados en PCI DSS y sin ánimo de desmeritar el gran esfuerzo que el PCI SSC ha realizado todos estos años, a continuación se enumeran 20 controles de seguridad adicionales que minimizarían aún más el riesgo residual posterior a una implementación correcta del estándar. Esta lista ha sido elaborada con la experiencia de años de despliegue y auditoría de múltiples entornos de PCI DSS y se ofrecen como una guía de recomendaciones para aquellas empresas que quieren optimizar sus niveles de seguridad más allá de los estipulados en el estándar o incluso quieran emplear estos controles adicionales como parte de sus controles compensatorios en el caso de requerirlos.
  1. Búsqueda periódica de datos de tarjeta de pago almacenados en texto claro en medios de almacenamiento

    Uno de los objetivos principales de PCI DSS es la protección de los datos almacenados, gestionado en el requisito 3. Sin embargo, el estándar carece de un control que permita validar la efectividad de implementación de dichos controles, lo cual es una verdadera lástima ya que se permitiría la identificación preventiva y la activación de acciones correctivas del potencial problema, evitando la exposición a una exfiltración no controlada.

    En este caso, la idea sería que existiera un control que exigiera ejecutar de forma periódica una búsqueda de datos de tarjetas de pago que puedan estar almacenados de forma insegura en los medios de almacenamiento del entorno. En caso de identificarse alguno, significaría que los controles desplegados no son suficientes o no se encuentran correctamente implementados.

    A pesar de que este control no se encuentra en el estándar PCI DSS, sí que se encuentra en el Anexo A3: “Validación suplementaria de las entidades designadas (DES)”, solamente requerido para aquellas entidades designadas por una marca de pago o adquirente a la que le exigen una validación adicional de los requisitos de PCI DSS existentes.
  2. Uso de soluciones de prevención de pérdida de datos (“Data Loss Prevention” - DLP) para minimizar la exfiltración de datos por canales no autorizados

    Las soluciones de prevención de pérdida de datos permiten la monitorización, detección y bloqueo de información confidencial almacenada, procesada y/o transmitida, permitiendo controlar una potencial exfiltración causada por errores no intencionales o por acciones intencionales maliciosas. Este software se puede instalar a nivel perimetral o en estaciones de trabajo y servidores (“endpoint”).

    Con una instalación de solución de este estilo se reforzarían los controles procedimentales descritos en el req. 4.2 para evitar el envío de PAN no cifrados por medios de mensajería de usuario final (correo electrónico, mensajería instantánea, etc.) y el req. 12.3.10 para evitar que personal que tiene acceso remoto al entorno pueda copiar, mover y/o almacenar los datos del titular de la tarjeta en unidades de disco locales y/o en dispositivos electrónicos extraíbles y permitiría la identificación temprana de datos de tarjeta en canales no autorizados.
  3. Integración con otros estándares como PA y PTS (POI/HSM) para que los activos afectados dentro del alcance estén obligatoriamente certificados

    El PCI SSC ha publicado una serie de estándares adicionales a PCI DSS para cubrir otros elementos potencialmente susceptibles a incidentes con datos de tarjetas de pago:
    • PA DSS (Payment Application Data Security Standard), para aplicaciones de pago desarrolladas y licenciadas por terceros
    • PCI PTS (PIN Transaction Security) – POI (Point of Interaction), para la protección de datos de tarjetas en dispositivos de punto de interacción
    • PCI PTS (PIN Transaction Security) – PIN, para la protección del número de identificación personal (Personal Identification Number – PIN)
    • PCI HSM, para definir controles lógicos y físicos de seguridad para módulos de seguridad de hardware (Hardware Security Module – HSM), empleados para la protección de claves y procesos de encriptación.

    Cada uno de estos estándares es certificable para el elemento afectado.

    No obstante, al día de hoy no se exige explícitamente en el estándar PCI DSS que si dentro de un entorno existen terminales de pago (datafonos), dispositivos HSM o aplicaciones de pago de terceros, éstos tengan que estar certificados u homologados, lo cual desvirtúa de cierta manera la existencia de ese ecosistema de estándares.

    En términos ideales, cualquier componente que pueda ser afectado por un estándar del PCI SSC y que esté presente en un entorno de PCI DSS debería estar certificado u homologado para garantizar su correcta integración y el mantenimiento con los mismos niveles de riesgo de forma trasversal. El solo hecho de permitir la interacción con un componente ajeno a estos estándares puede abrir una brecha en la seguridad del entorno, implicando mayor esfuerzo por parte del comercio o proveedor de servicios afectado para mantener un nivel de riesgo aceptable. 
  4. Requerir escaneo antimalware a nivel perimetral

    El requerimiento 5 de PCI DSS exige que se implemente un software antimalware en todos los sistemas que se puedan ver afectados por software malicioso. Esto quiere decir que el control antimalware se realizará en el potencial elemento afectado. Sin embargo, este es un control tardío.

    En el mercado existen soluciones que permiten implementar las mismas técnicas antimalware en tráfico HTTP, SMTP, FTP e inclusive integrar las firmas y patrones heurísticos para la monitorización de tráfico de red como complemento a los sistemas de detección y prevención de intrusiones (IDS/IPS) descritos en el req. 11.4. Si esto se implementa, se lograría detectar y bloquear el software malicioso antes de que llegue a las estaciones de trabajo y/o servidores, complementando la seguridad antimalware en términos generales.
  5. Complementar los controles antimalware a nivel de sistema operativo agregando nuevas funcionalidades tales como DEP, ASRL, etc.

    A pesar de que muy seguramente este punto puede ser cubierto por la implementación correcta del req. 2.2 en el proceso de configuración segura de sistemas operativos, estaría muy bien que PCI DSS exigiera el despliegue de controles de seguridad adicionales, tales como Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR) y Structured Exception Handling Overwrite Protection (SEHOP), entre otros, dentro de las actividades de securización de plataformas operativas.

    De esta manera se complementaría la seguridad provista por la protección antimalware con configuraciones adicionales a nivel de sistema operativo para prevenir ataques de desbordamiento de buffer (buffer overflow) y ejecución de código arbitrario empleados por exploits.
  6. Definición de controles de protección en redes virtuales y/o definidas por software (SDN)

    El requisito 1 de PCI DSS describe los controles a ser implementados para la protección del entorno de red, haciendo énfasis en el uso de firewalls y enrutadores. Sin embargo, este requisito está muy orientado a su implementación en redes y arquitecturas tradicionales.

    Sin embargo, con la llegada de la virtualización, los equipos activos de red también han sido afectados, siendo remplazados por sus contrapartes virtuales (virtual switch, virtual firewall, etc.), tecnologías que suelen ser olvidadas en el proceso de despliegue de controles de PCI DSS al no estar citadas de forma explícita.

    Siendo así, una revisión del requisito 1 complementándolo con acciones de securización de elementos de red virtualizados sería una muy buena opción y alinearía dichos controles con estas tecnologías.
  7. Requerir de soluciones de filtrado de paquetes a nivel de host

    Siguiendo con el requisito 1, PCI DSS establece controles de filtrado a nivel de red entre diferentes segmentos. Solamente se exige un filtrado de paquetes a nivel de host (firewall personal) en aquellas estaciones que se conectan de forma remota al entorno (req. 1.4).

    No obstante, una muy buena alternativa para complementar la seguridad de filtrado a nivel perimetral sería la de requerir el despliegue de una solución de filtrado de paquetes a nivel de host. De esta forma, se reforzarían los controles de securización del requisito 2.2.2 en servicios, protocolos y daemons y se limitaría el potencial impacto en el caso de un error en las reglas de filtrado perimetral revisadas únicamente cada seis meses (req. 1.1.7), aplicando el concepto de defensa en profundidad. 
  8. Requerir cifrado a nivel de canal dentro del entorno de cumplimiento

    Uno de los controles más controvertidos de PCI DSS es el del cifrado de los canales de comunicación dentro del entorno de cumplimiento. Solamente se exige en el caso de acceso administrativo que no sea de consola (req. 2.3), permitiendo que tráfico que pueda contener datos de tarjetas de pago pueda ser transmitido sin cifrar dentro del entorno.

    La implementación del cifrado de comunicaciones dentro del entorno permitiría que toda la comunicación interna fuese punto a punto, eliminando potenciales riesgos derivados de la interceptación no autorizada de tráfico y previniendo que los equipos activos de red a nivel interno tengan acceso a los datos en claro evitando su almacenamiento en ficheros de log, depuración, etc. Esto se puede lograr de una manera muy fácil empleando los componentes nativos de IPSEC en sistemas operativos, empleando los controles de cifrado de tráfico de las propias aplicaciones (bases de datos, por ejemplo) o a través de técnicas de tunelización de tráfico vía TLS o SSH, por ejemplo. El impacto sería mínimo y la ganancia en términos de seguridad sería tangible inmediatamente.

  9. Definir controles para la gestión de nombres de dominio (DNS) tanto a nivel externo como interno

    Uno de los elementos “huérfanos” en PCI DSS es el sistema de resolución de nombres (Domain Name System – DNS). Lo ideal sería que existiese un control específico - al igual que sucede con la sincronización de tiempo descrita en el req. 10.4 - en el cual se describan los controles que se deben aplicar a este servicio en un entorno PCI DSS, incluyendo la definición de un servidor DNS central interno, la gestión de consultas con DNS raíz externos “confiables” y las consideraciones de seguridad adicionales (como DNSSEC) que podrían desplegarse para robustecer la seguridad de este servicio y evitar ataques de tipo “pharming”.

    Actualmente, este servicio estaría cubierto de forma general por el req. 2, aunque – como se puede ver – la necesidad de un control específico estaría más que justificada.

    Igualmente, tampoco se especifican controles de seguridad de resolución de nombres a nivel externo. Por ejemplo: Una empresa de comercio electrónico que cuenta con un sitio web y ha registrado un dominio a su nombre. Ese dominio (que directamente redirecciona todo el tráfico de la transacción de un cliente a una dirección IP en particular) puede estar registrado en una empresa (registrador de dominios) con un nivel de seguridad deficiente, con lo cual un atacante no tendría que vulnerar los sistemas del entorno PCI DSS sino simplemente focalizarse en atacar a ese proveedor, cambiar el registro DNS a otra dirección IP bajo su control y hacerse a todo el tráfico de tarjetas de ese comercio electrónico. Es por ello que al igual que otros proveedores de servicio, los proveedores de registro de nombres de dominio deberían cumplir y estar certificados por PCI DSS para garantizar una seguridad en toda la cadena transaccional.
  10. Establecer controles de seguridad para DHCP

    Otro “huérfano” en términos de controles de PCI DSS es el servicio de configuración dinámica de host (Dynamic Host Configuration Protocol – DHCP). Al igual que como se sucede con NTP y como se justificó con DNS, en el caso que se emplee DHCP en la red de PCI DSS se deberían establecer los patrones de configuración y sus limitaciones de ámbito para evitar que equipos no autorizados puedan obtener toda la información de direccionamiento y enrutamiento del entorno al conectarse.

    Igualmente, estaría cubierto actualmente por el req. 2 pero un control específico no estaría mal.

  11. Definir controles para la gestión de certificados digitales empleados en comunicaciones HTTPS (y otros elementos en los cuales pudieran usarse)

    El requerimiento 4 de PCI DSS establece la necesidad de asegurar los canales de comunicación con redes públicas abiertas, exigiendo que si se usa TLS los certificados digitales empleados sean “de confianza”.

    Sin embargo, no se cuenta con ningún control para la protección de dichos certificados. No se indica cómo se deben almacenar, si deben ser protegidos con un passphrase, los roles y responsabilidades de quienes puedan gestionarlos, los controles en su ciclo de vida, etc. Es decir: se cuenta con controles para garantizar la seguridad del tráfico empleando certificados digitales, pero no del proceso para implementar dicha securización.

    Por otro lado, si se emplean certificados digitales en otros flujos dentro del entorno PCI DSS, tampoco se indica cómo se gestionarán, lo cual puede exponer a la organización a un potencial problema al no estar formalizado este proceso.
  12. Controles adicionales a estaciones con conexión remota y uso de servidores de salto

    Las estaciones que cuentan con acceso remoto al entorno de PCI DSS deben cumplir con varios controles: Tener un firewall personal (req. 1.4) y usar autenticación multifactor (req. 8.3). Sin embargo, no se indica cómo se puede garantizar que la estación que se conecta cumpla con los niveles de seguridad del entorno en términos de actualizaciones de seguridad, actualización de patrones antivirus, controles de acceso, etc. exponiendo al entorno a que, si una estación remota está infectada o comprometida, dicho compromiso podría ampliarse al resto del entorno si la conexión se autoriza. Esto aplica no solamente a ordenadores sino también a dispositivos móviles que se permitan en el entorno.

    De acuerdo con esto, una estrategia sería el uso de control de acceso a la red (Network Access Control – NAC). Mediante la implementación de una tecnología de estas características se permitiría garantizar que los equipos que se conecten cumplan con las políticas del resto del entorno, estén actualizadas y que la estación en sí sea autenticada. Si no, la estación afectada se aísla o se limita su conexión hasta que no esté alineada con los requerimientos de la red.

    Igualmente, se debería requerir de forma obligatoria el uso de un servidor bastión o de salto (jump station) para conexiones remotas administrativas. Este servidor recibiría y centralizaría todo este tráfico hacia el entorno de cumplimiento, evitando exponer las diferentes consolas administrativas, registrando con detalle todos los saltos a equipos internos y aplicando controles de acceso puntuales posteriores a la autenticación del usuario.
  13. Requerir obligatoriamente el uso de salts en operaciones de hash para la protección de datos de tarjeta de pago almacenados

    Ya es bien sabido por todo el personal de seguridad de la información que uno de los principales ataques contra las funciones hash es el uso de “tablas arcoíris” (rainbow tables), que permiten identificar el dato que generó determinado hash mediante la comparación con tablas de valores precomputados. Teniendo presente que el formato del PAN es conocido de antemano (entre 13 y 16 dígitos con los 6 primeros dígitos en claro (BIN/IIN) y el último dígito determinista), cuesta muy poco esfuerzo con la capacidad de cómputo actual generar una tabla precomputada para tales valores. Con este riesgo en mente, se hace obligatorio el uso de valores de tipo salt (valor pseudoaleatorio que se concatena al dato a proteger antes de obtener su hash) que compliquen aún más la obtención de un PAN desde su hash si se emplea esta técnica para la protección de los datos almacenados (req. 3.4).

    Actualmente, el uso de salts es solamente una recomendación y su uso es discrecional.
  14. Complementar los controles de diagramas de red requiriendo la descripción de direcciones IP / hostnames

    Los requisitos 1.1.2 y 1.1.3 de PCI DSS especifican la necesidad de mantener un diagrama de red y un diagrama de flujo actualizados. Sin embargo, no se exige mayor detalle en estos diagramas, lo cual puede dejar incompleto el objetivo de los requisitos, que es el de identificar de forma clara la ubicación de los componentes del entorno.

    Si dichos requisitos se complementan exigiendo el detalle de direccionamiento IP y hostnames, el entendimiento y comprensión de los diagramas será más fácil y se podrá integrar de una forma más sencilla con el inventario de activos del requisito 2.4.
  15. Complementar el detalle requerido en el inventario de activos del entorno

    El requisito 2.4 pide mantener un inventario de activos del entorno. Sin embargo, no entra en mayor detalle de lo que debe contener más allá del hardware y software y una descripción de la función/uso de cada componente. Como tal, este requisito se queda corto en la cantidad de información y la utilidad que proporciona.

    Una alternativa sería exigir una “Cardholder Data Matrix” (CHDM) en toda regla.  El concepto de CHDM va mucho más allá de un simple listado y permite centralizar en un único documento toda la información de los activos del entorno, proporcionando una visión completa del alcance.

    Esta CHDM debería contener la siguiente información detallada (que de por sí ya se requiere en diferentes partes del estándar):
    • Personal vinculado con el entorno
    • Aplicaciones
    • Servidores y estaciones de trabajo
    • Equipos de red y seguridad perimetral
    • Soportes (CD, papel, etc.)- Req. 9.7.1
    • Canales de comunicación y redes
    • Instalaciones físicas
    • Listado de terceros (Proveedores) – Req. 12.8.1
    • Ubicación datos PCI DSS – Req. 3.1
    • Claves de cifrado – Req. 3.5.1 (actualmente sólo requerido para proveedores de servicio)
    • Documentación
  16. Protección a nivel de memoria física, virtual y swap

    El gran talón de Aquiles de las técnicas de criptografía simétrica y asimétrica es el uso de memoria intermedia para el almacenamiento temporal de claves, datos a encriptar en claro, contraseñas, passphrases, etc. mientras que se realizan las operaciones de encriptación y desencriptación. El requerimiento 3 de PCI DSS describe los controles de encriptación en el almacenamiento de datos, mientras que el requerimiento 4 hace lo propio con los controles en la transmisión de datos.

    Si se parte de la premisa que PCI DSS se debe aplicar en el almacenamiento, transmisión y procesamiento de datos, ¿qué pasa con los controles orientados a la protección de los datos en memoria intermedia (RAM, memoria virtual y swap), empleada en el procesamiento? A hoy, no hay ninguna referencia en el estándar. No obstante, existe una FAQ (1042)  que habla de ello:
    .. If the cardholder data is stored in non-persistent memory (e.g. RAM), encryption of cardholder data is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. For example, if the memory is being written to a file, then appropriate PCI DSS requirements are applicable to that file. Where appropriate, this data should be securely purged as soon as possible - for example, from swap files and temporary folders…
    Actualmente, existen diferentes herramientas nativas en la gran mayoría de sistemas operativos que permiten realizar encriptación de las áreas de paginación (swap) y de ficheros de hibernación/suspensión, así como controles de acceso restrictivos a nivel de memoria RAM para prevenir volcados de la misma y ataques con malware del tipo “RAM scraping” , que deberían ser contemplados en el estándar.
  17. Requerir una formación específica para operadores y administradores de la plataforma

    El requisito 12.6 de PCI DSS exige una formación general de concienciación sobre seguridad en el momento de la contratación y por lo menos de forma anual para los empleados del entorno. Yendo más allá, el requisito 6.5 pide una formación específica anual para desarrolladores y el requisito 12.10.4 para el personal vinculado al proceso de respuesta a incidentes. Siendo así, ¿por qué no exigir una formación específica en PCI DSS para operadores y administradores de la plataforma? Para este personal, no es suficiente una formación general, es indispensable una formación focalizada que permita garantizar que existe un conocimiento pleno del estándar en las labores del día a día.
  18. Definición de controles para la gestión de autenticación de aplicaciones

    El requisito 8 de PCI DSS contiene una serie de controles para la gestión del proceso de autenticación de usuarios interactivos (es decir: que tienen a un humano por detrás). Sin embargo, ¿cómo se debe proceder con las cuentas de aplicación (aquellas cuentas que permiten que dos o más aplicaciones se autentiquen mutuamente sin interacción humana)? La ausencia de un control específico para la gestión de este tipo de cuentas – que por lo general cuentan con altos privilegios - podría permitir que un potencial atacante acceda de forma no autorizada al entorno, ya que sus niveles de seguridad no suelen ser tan robustos como en cuentas interactivas.

    En este caso, se requeriría definir una persona o rol responsable de esas cuentas, establecer controles de seguridad apropiados a las mismas (teniendo presente que si se usan contraseñas éstas no se pueden cambiar de forma periódica, que no se puede agregar autenticación multifactor, que un bloqueo de esta cuenta por accesos erróneos puede implicar una parada crítica en la operación del entorno, que la credencial de autenticación debe estar almacenada y disponible en algún lugar por la aplicación y que no se puede cambiar después del primer uso) y hacerles seguimiento de forma continua.
  19. Nombramiento de un responsable de PCI DSS en la organización

    La implementación y mantenimiento de PCI DSS en una empresa es un proyecto en sí, con sus restricciones en términos de tiempo, alcance y costes. Además, se trata de un proyecto trasversal a las áreas afectadas, que requiere para su correcta gestión un responsable que asuma el cargo de similar al de un gestor de proyecto (“Project Manager”).

    Los requisitos 12.4 y 12.5 requieren la asignación de responsabilidades para ciertas acciones (políticas, monitorización de alertas, respuesta a incidentes, gestión de cuentas y acceso a datos). Sin embargo, la asignación de un rol para la gestión general de PCI DSS solamente se exige a proveedores de servicio (req. 12.4.1) y a entidades designadas (A3.1.1).

    En este caso, la idea sería que el mismo requisito cubriera también a los comercios, lo que permitiría que estas entidades contaran con un responsable de PCI DSS a nivel general, el cual velaría por el soporte de la Dirección y el seguimiento general del cumplimiento del estándar.

  20. Alineación de PCI DSS con otras normativas de protección de datos de carácter personal

    De acuerdo con la ISO/IEC 29100:2011 (Information technology -- Security techniques -- Privacy framework), el Número Primario de Cuenta (PAN – Primary Account Number) se puede catalogar como Información de Identificación Personal (PII – Personally Identifiable Information), ya que se trata de un identificador que se puede relacionar con una persona natural. De acuerdo con ello, se deberían generar políticas orientadas al usuario final (al titular de tarjeta) para que cuente con toda la información necesaria para ejercer control sobre sus propios datos, delegados al comercio o al proveedor de servicio para la ejecución de la transacción.
Figura 2. Principios de protección de privacidad de ISO/IEC 29100:2011

Este nuevo conjunto de controles entraría a complementar los acuerdos contractuales de la organización con sus proveedores de servicio (req. 12.8.2) y de los proveedores con sus clientes (req. 12.9), agregando responsabilidades entre la entidad y los titulares de tarjetas.

Conclusión
El estándar PCI DSS (en su versión 3.2 en el momento de la publicación de este artículo) ha permitido que los comercios y los proveedores de servicio que hacen uso de datos de tarjetas de pago puedan gestionar de una forma tolerable el riesgo derivado del almacenamiento, procesamiento y transmisión de esta información. Al tener que ser implementado en diferentes entornos tecnológicos y arquitecturas, la definición y redacción de sus controles ha sido bastante generalista, lo cual implica que el riesgo residual puede llegar a ser bastante significativo en función del escenario en el que se aplique.

Para complementar los controles “base” incluidos en PCI DSS se pueden usar controles adicionales como los descritos en este artículo. Si bien se trata de meras recomendaciones, si se incluyeran dentro de PCI DSS harían de este estándar una versión “con esteroides”.

Obviamente, la lista de estos controles adicionales no es exhaustiva, ya que la seguridad no es perfecta y siempre habrá cabida a mejoras. Siendo así, ¿se te ocurren otros controles que puedan mejorar los niveles de seguridad provistos por PCI DSS?


Autor: David Eduardo Acosta - CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L. A. 
Departamento de Consultoría 

Sobre el Anteproyecto de Ley de Protección de Datos para adaptarla al Reglamento Europeo de Protección de Datos, Reglamento UE 2016/679

El pasado 23 de junio, el Gobierno informó que el Consejo de Ministros había recibido un informe del Ministro de Justicia sobre el Anteproyecto de Ley Orgánica de Protección de Datos que tiene previsto entrar en vigor (al igual que el nuevo Reglamento Europeo de Protección de Datos, Reglamento UE 2016/679) el próximo 25 de mayo de 2018, (según establece el artículo 99 del citado Reglamento) quedando derogada la actual Ley Orgánica 15/1999 (LOPD).

El Anteproyecto (que consta de 78 artículos estructurados en 8 títulos, 10 disposiciones adicionales, 5 disposiciones transitorias, 1 disposición derogatoria única y 7 disposiciones finales), cumple con dos aspectos principales:
  • La necesidad de cumplir con las obligaciones derivadas de la pertenencia de España a la Unión Europea, adaptando previsiones de la normativa comunitaria.
  • Desarrollar algunos puntos que quedan en manos de los legisladores locales.
Entre los aspectos desarrollados, destacamos:
  • Título I, Regulación de los datos referidos a las personas fallecidas, (No eran objeto en la anterior LOPD) que permite que los herederos puedan solicitar el acceso a los mismos, así como su rectificación o supresión, en su caso con sujeción a las instrucciones del fallecido.
  • Título II, “Principios de protección de datos”, se presumen exactos y actualizados los datos obtenidos directamente del propio afectado.

    Se recoge expresamente el deber de confidencialidad.

    El consentimiento, ha de proceder de una declaración afirmativa excluyendo por tanto el “consentimiento tácito”,

    Se fija en trece años (antes catorce) la edad a partir de la cual el menor puede prestar su consentimiento.
  • Título III, Derechos de las personas. Regula el derecho de los afectados a ser informados acerca del tratamiento (derecho de transparencia), se recoge la denominada “información por capas” ya generalmente aceptada en ámbitos como el de la videovigilancia o la instalación de dispositivos de almacenamiento masivo de datos (tales como las “cookies”) y se especifican las circunstancias que permiten que la información se pueda facilitar a través de una dirección electrónica.

    Se prevé el ejercicio de los derechos por medio de un representante voluntario.

    Se contempla los derechos de acceso, rectificación, supresión, derecho a la limitación del tratamiento, derecho a la portabilidad y derecho de oposición.

    Se introduce la obligación de bloqueo que garantiza que los datos queden a disposición de un Tribunal u otras autoridades competentes para la exigencia de posibles responsabilidades derivadas de su tratamiento, y así evitar la ocultación de un incumplimiento.
  • Título IV, Responsable y encargado del tratamiento. Es preciso tener en cuenta que la mayor novedad que presenta el Reglamento (UE) 2016/679 es, la evolución de un modelo basado, fundamentalmente, en el control del cumplimiento a otro que descansa en el principio de responsabilidad activa, lo que exige una previa valoración por el responsable o por el encargado del tratamiento el riesgo que pudiera generar el tratamiento de los datos de carácter personal para, a partir de dicha valoración, adoptar las medidas que procedan.

    Con el fin de aclarar estas novedades la Ley mantiene la misma denominación del Capítulo IV del Reglamento, dividiendo el articulado en cuatro capítulos dedicados, respectivamente, a las disposiciones generales y medidas de responsabilidad activa, el régimen del encargado del tratamiento, la figura del delegado de protección de datos (que adquiere una destacada importancia en el Reglamento (UE) 2016/679 y así lo recoge la ley orgánica) y los códigos de conducta y certificación.

    La Agencia creará un Registro de Delegados, manteniendo una relación pública y actualizada de los delegados de protección de datos, accesible por cualquier persona.

    El responsable o el encargado, deberá dotar al delegado de medios materiales y personales suficientes y no podrá removerlo, salvo en los supuestos de dolo o negligencia grave.
  • Título V, Transferencias internacionales de datos, procede a la adaptación de lo previsto en el Reglamento (UE) 2016/679 y se refiere a las especialidades relacionadas con los procedimientos a través de los cuales las autoridades de protección de datos pueden aprobar modelos contractuales o normas corporativas vinculantes, supuestos de autorización de una determinada transferencia, o información previa.
  • Título VI. Autoridades de Protección de Datos.
  • Título VII Procedimiento en caso de reclamaciones tramitadas por la Agencia Española de Protección de Datos. Se establece un sistema novedoso y complejo, evolucionando hacia un modelo de “ventanilla única” en el que existe una autoridad de control principal y otras autoridades interesadas.

    También se establece un procedimiento de cooperación entre autoridades de los Estados miembros y, en caso de discrepancia, se prevé la decisión vinculante del Comité Europeo de Protección de Datos.
  • Título VIII, El Reglamento (UE) 2016/679 que establece un sistema de sanciones o actuaciones correctivas sumamente genérico, en el que no se tipifican las conductas ni se establecen las reacciones concretas ante su comisión. Las sanciones impuestas son especialmente elevadas yendo desde los 10 millones de euros (o el 2% como máximo del volumen de negocio total anual global) hasta los 20 millones de euros (o el 4% como máximo del volumen de negocio total anual global).

El anteproyecto armoniza el procedimiento sancionador adecuándolo a la legislación estatal en esta materia: conductas típicas, graduación de infracciones y, en función de éstas, la cuantía de la sanción, recursos, prescripción, etc.

  • Disposición Adicional Primera se refiere a las medidas de seguridad en el ámbito del sector público. En la actualidad, las medidas establecidas en el Esquema Nacional de Seguridad (ENS) para garantizar la protección de los datos de carácter personal, lo son por remisión al Título VIII del Reglamento de desarrollo de la Ley Orgánica 15/1999, dado que esta norma va a quedar derogada, será preciso que el ENS amplíe el ámbito de las medidas que considere oportuno adoptar en relación con la seguridad de los datos a partir del enfoque de riesgo exigido por el Reglamento General de Protección de Datos.
  • Disposición Adicional Segunda, sobre protección de datos y transparencia y acceso a la información pública.
  • Disposición Adicional Tercera, normas sobre el cómputo de los plazos, para tratar de establecer un régimen uniforme para los sectores público y privado. Como peculiaridad, se establece el modo de cómputo del plazo por semanas.
  • Disposición adicional cuarta, referida al procedimiento en relación con las competencias atribuidas a la Agencia Española de Protección de Datos por otras leyes.
  • Disposición Adicional Quinta, se refiere a la autorización judicial en materia de transferencias internacionales de datos y prevé que la AEPD, cuando considere fundada la reclamación de un afectado, deberá solicitar de la Sala de lo contencioso-administrativo de la Audiencia Nacional autorización para declarar contraria a Derecho la transferencia internacional de datos sobre la que versa dicha reclamación.
  • Disposición Adicional Sexta, reconoce expresamente el régimen regulador de los registros de apoyo a la Administración de Justicia, recogido actualmente en el Real Decreto 95/2009, de 6 de febrero, como base legal para el tratamiento de datos relacionados con infracciones penales y condenas y medidas de seguridad.
  • Disposición Adicional Séptima, acceso a contenidos de personas fallecidas. El interesado podrá incorporar en un documento de instrucciones su manifestación de voluntad en lo que respecta al uso y destino de sus datos, documentos o ficheros, si opta por su conservación, destrucción o portabilidad, así como por el mantenimiento o cancelación de sus cuentas, pudiendo designar a una persona para que ejecute sus instrucciones. Las instrucciones se podrán incorporar a un registro, para cuya creación y regulación se habilita al Gobierno y que sólo será accesible por terceros en caso de fallecimiento. Además, sólo el designado y, en su defecto, los herederos del difunto podrán acceder al contenido mismo de las instrucciones para poder dar cumplimiento a la voluntad del fallecido y ejercer por él los derechos que le otorga el ordenamiento jurídico.
  • Disposición Adicional Octava, establece qué deudas pueden incorporarse a los sistemas de información crediticia.
  • Disposición Adicional Novena, condiciones adicionales para el tratamiento de categorías especiales de datos.
  • Disposición Adicional Décima, especialidades del régimen jurídico de la Agencia Española de Protección de Datos.
  • Disposición Adicional Undécima, identificación de los interesados en las notificaciones por medio de anuncios y publicaciones de actos administrativos.
  • Disposición Adicional Duodécima, potestad de verificación de las Administraciones Públicas.
  • Disposición Adicional Decimotercera, no incremento de gasto.
Es necesario recordar que estamos hablando de un Anteproyecto por lo que tendremos que ver cómo se va desarrollando o retocando de aquí a mayo de 2018 esa futura LOPD.


Autor: Carmen Areces
Departamento Comercial.

Participamos en la XI Semana de la Ingeniería de la Universidad Uniminuto

El próximo día 27 de septiembre participaremos invitados por la Universidad Uniminuto de Colombia en su XI Semana de la Ingeniería, cuando la universidad está celebrando su 25 aniversario.

En nuestra participación ante el foro de estudiantes de la Facultad de Ingeniería pretendemos mostrar como la Ciberseguridad es una de las carreras profesionales con más futuro dentro del sector TIC.

Explicaremos las diferentes áreas de especialización que tiene el sector, demostraremos actividades de trabajo que se pueden desarrollar dentro de la ciberseguridad, desde aspectos técnicos relativos a actividades de hacking, auditorías de seguridad en software, aspectos relativos con la protección de datos y el análisis de redes sociales.

El objetivo es demostrar a los ingenieros y tecnólogos que están enfocando su carrera profesional a que vean el altísimo potencial de la ciberseguridad en cualquiera de las áreas de la tecnología de hoy en día.

La agenda completa en:
http://www.uniminuto.edu/web/ingenieriasp/agenda

Se avecinan cambios en Internet Security Auditors ¿Te los vas a perder?

Después de más de 15 años, hemos decidido dar un giro de 180º y actualizar nuestra imagen corporativa.

Se avecinan grandes cambios en nuestra web e imagen corporativa que esperamos poder compartir con vosotros dentro de poco…ya sabéis, ¡lo bueno se hace esperar! Estad atentos!

Pagos recurrentes y pagos en un clic: ¿Qué son, qué beneficios aportan, qué riesgos implican y cómo se pueden gestionar de forma segura?

Uno de los principales retos a los que se enfrenta cualquier comercio que cuenta con presencia en internet es el de retener a nuevos clientes y fidelizar a aquellos que ya han hecho uso de sus servicios, tratando de minimizar los esfuerzos y optimizando las ganancias. De acuerdo con Adobe, los visitantes a un sitio web de comercio electrónico se pueden catalogar en tres grupos:
  • Compradores de primera vez o visitantes que no compran (“shoppers”)
  • Clientes que regresan: compradores que tienen una compra previa (“returning purchasers”)
  • Clientes que repiten: compradores que han realizado múltiples compras (“repeat purchasers”)
Los clientes que repiten generan entre tres y siete veces más ingresos por visita que los clientes que visitan por primera vez el sitio web.

Figura 1. Tasas de conversión por tipo de visitante (fuente: Adobe)
Es en este punto en donde generalmente los conceptos tradicionales de mercadotecnia son empleados para lograr la retención de compradores (uso de descuentos, entrega de obsequios, envíos gratuitos, programas de fidelidad, acceso a eventos exclusivos, notificaciones de promociones por adelantado, campañas por perfiles, etc.), aplicando las estrategias conocidas como “Customer Retention Marketing” .

Sin embargo, en el mundo actual estas estrategias por sí solas ya no son suficientes. La información de productos y servicios proviene cada vez menos de medios tradicionales (periódicos, radio, revistas, etc.) y los clientes actuales se orientan hacia el comercio electrónico debido a la simplicidad en los pagos (pagos no presenciales - “Card Not Present” o CNP), facilidades para acceder a realizar sus compras a través de múltiples dispositivos (teléfono móvil, tabletas, televisión y relojes inteligentes, billeteras electrónicas, consolas de videojuegos, ordenadores, etc.)  e inmediatez para la realización de sus pedidos.

Figura 2. Análisis del impacto del uso de dispositivos en compras online (Fuente: Google)
De acuerdo con MasterCard , los compradores también buscan seguridad y comodidad en sus compras como valores diferenciales al momento de escoger un comercio electrónico u otro.

Figura 3. Factores determinantes de la preferencia de pago de los consumidores en línea (Fuente: MasterCard)

Por otro lado, un diferencial importante es el análisis del comportamiento del cliente en términos de hábitos de compra. Esto le permite al comercio focalizar su estrategia de mercadotecnia, analizar los segmentos de compradores en comparación con diferentes variables (edad, cantidad de dinero gastado, tipos de productos adquiridos, etc.), efectuar análisis predictivo de inventarios y mantener un historial de compras. El cliente obtiene a su vez mejoras en los productos recomendados, focalización en sus gustos y segmentación de productos de acuerdo con sus preferencias en compras anteriores.

La pantalla de “checkout”: La decisión entre continuar o quedarse
Uno de los elementos más críticos en cualquier estrategia de mercadotecnia está en mantener el entusiasmo e interés del cliente igual que cuando llegó al sitio web y que no se diluya a lo largo del proceso de compra. Por lo general, el punto álgido de este flujo se presenta en la pantalla del pago final (“checkout“). De acuerdo con el Baymart Institute , la creación de cuentas, los procesos de pago engorrosos, la existencia de pocos métodos de pago aceptados y los problemas de pago con tarjetas se suman a temas como costes adicionales y demoras en los envíos dentro de las causas por las cuales la compra no se finaliza y el cliente opta por abandonar.

Figura 4. Razones por las cuales los clientes declinan finalizar una compra online (Fuente:Baymart Institute)

Una potencial solución: El uso de pagos recurrentes y pagos en un clic
Una estrategia que puede ayudar a una tienda de comercio electrónico para garantizar la retención de los clientes en el momento del pago y ampliar la cantidad de “clientes que regresan” y “clientes que repiten” es la aceptación de pagos recurrentes (“Recurring Payments” – RP) o pagos en un clic (“One-Click Payments”) para el pago de productos y/o servicios.

Antes de continuar, a continuación, se describen las diferencias entre cada modelo:
Pago no presencial (CNP) tradicional:

Figura 5. Flujo transaccional de un pago no presencial tradicional

Pago no presencial (CNP) Tradicional
Definición El pago es iniciado por el titular de tarjeta y cada transacción es independiente
Uso Compras esporádicas
Ventajas No se almacena ningún dato de tarjeta de pago
Desventajas Cada vez que el cliente quiera pagar debe rellenar el formulario de pago con los datos de la tarjeta de pago
Datos de tarjeta almacenados Ninguno
Riesgo Bajo

Pago recurrente (RP):

Figura 6. Flujo transaccional de un pago recurrente

Pago recurrente (RP)
Definición El pago es iniciado directamente por el comercio con una pre-autorización del titular de la tarjeta y ejecutado de forma repetitiva en periodos de tiempo específicos.
Uso
  • Pago de facturas
  • Pago de servicios basados en suscripción
  • Pago de servicios por uso
Ventajas
  • No requiere que el usuario ingrese nuevamente los datos de la tarjeta en cada transacción
  • Automatización basada en eventos
Desventajas Requiere almacenamiento de datos de tarjetas por parte del comercio
Datos de tarjeta almacenados
  • PAN
  • Fecha de expiración
  • Nombre del titular
NOTA: El CVV2 solamente se pide en la primera transacción y no se almacena. En las transacciones subsiguientes con el mismo PAN y provenientes del mismo comercio, el CVV2 no suele solicitarse para permitir la automatización del proceso.
Riesgo Alto

Pago en un clic (OCP):
Primera compra:


Compras posteriores:

Figura 7. Flujo transaccional de un pago en un clic

Pago en un clic (OCP)
Definición El pago es iniciado por el titular de tarjeta empleando los datos de una tarjeta perteneciente a una compra anterior. Cada transacción es independiente.
Método patentado por Amazon en USA en 1999.
Uso Pagos en sitios en los que ya se ha realizado una compra previa.
Ventajas No requiere que el usuario ingrese nuevamente los datos de la tarjeta en cada transacción
Desventajas Requiere almacenamiento de datos de tarjetas por parte del comercio
Datos de tarjeta almacenados
  • PAN
  • Fecha de expiración
  • Nombre del titular
NOTA: El CVV2 solamente se pide en la primera transacción y no se almacena. En las transacciones subsiguientes con el mismo PAN y provenientes del mismo comercio, el CVV2 no suele solicitarse para permitir la automatización del proceso.
Riesgo Alto

El almacenamiento de datos de tarjeta, el principal problema de pagos recurrentes y en un solo clic
Como se puede observar, las transacciones vinculadas a procesos de recurrencia y de pago en un clic tienen un elemento en común: requieren que el comercio almacene los datos de las tarjetas de pago de sus clientes (PAN, fecha de expiración y nombre del titular). En términos de seguridad, el hecho de almacenar datos de tarjeta de pago implica que el comercio que implemente estos servicios requerirán del cumplimiento de todos los requerimientos del Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (Payment Card Industry Data Security Standard) o PCI DSS.
Figura 8. Información de aplicabilidad de PCI DSS
El cumplimiento de este estándar requiere el despliegue de múltiples controles de seguridad lógica, física y procedimientos operativos en los activos que procesen, almacenen o transmitan datos de tarjetas de pago.

Figura 8. Información de aplicabilidad de PCI DSS
La implementación de estos requerimientos conlleva una inversión significativa en tiempo, dinero y personal, razón por la cual no suele ser una alternativa viable en términos de coste-beneficio para un comercio pequeño o mediano.

Tokenización: la alternativa al almacenamiento de datos de tarjeta para pagos recurrentes y en un solo clic
Sin embargo, no todo son malas noticias. Para evitar que el comercio que desee implementar estas funcionalidades en su sitio web tenga que almacenar los datos de las tarjetas de pago de sus clientes, la gran mayoría de proveedores de servicios de pago (“Payment Service Provider” – PSP) ofrecen servicios de tokenización. La tokenización permite que el dato de la tarjeta de pago del cliente sea remplazado por un dato no confidencial denominado “token” que, en términos operativos, ofrece exactamente las mismas funcionalidades de los datos de la tarjeta originales, sin el riesgo que conlleva su almacenamiento, procesamiento y transmisión.

Figura 9. Flujo transaccional de una operación de pago con tokens
En este escenario, el comercio NUNCA almacena los datos de la tarjeta de pago de sus clientes y se puede permitir la realización de transacciones de pago recurrentes y pagos con un clic, minimizando los riesgos y la necesidad de cumplimiento de todos los controles de PCI DSS. El almacenamiento de datos de tarjeta es derivado al PSP quien, en el momento de recibir el pago, está en la capacidad de obtener el PAN original y realizar la autorización de la transacción normalmente.

Para que la tokenización sea efectiva, se necesita el cumplimiento de una serie de variables:
  1. Que el PSP ofrezca servicios de tokenización, pagos con un clic y pagos recurrentes
  2. Que el cliente acepte los términos de los pagos con un clic y pagos recurrentes si desea hacer uso de estos servicios
  3. Que se realice una primera transacción exitosa que involucre la totalidad de los datos de tarjeta requeridos para un pago no presencial (PAN, fecha de expiración, nombre del titular y CVV2)
Desventajas de la tokenización
A pesar de las evidentes ventajas en la minimización del riesgo y el cumplimiento de PCI DSS por parte del comercio, una de las desventajas de la tokenización es que solamente el PSP que ha generado el token está en capacidad de obtener su PAN vinculado. Esta característica tácita del funcionamiento del modelo de tokenización (y en la que también radica su seguridad y las capacidades de minimización del entorno de riesgo) es a la vez uno de sus talones de Aquiles, debido a que el comercio que use este servicio estará vinculado de forma irrestricta a procesar todas las transacciones con tokens con el mismo PSP que los ha generado. Esto limita la capacidad que puede tener un comercio para enrutar sus pagos a diferentes PSP dependiendo de variables como los costes por transacción, el lugar geográfico de emisión de la tarjeta, etc.

En este caso, cabe la alternativa de que sea el propio comercio ejecute internamente sus procesos de tokenización. Si se opta por esta opción, se minimiza el entorno de cumplimiento de PCI DSS del comercio, haciendo que la totalidad de controles apliquen únicamente en el entorno en el cual se tokeniza/des-tokeniza y se guarda la referencia PAN/Token.  De esta manera, se puede trabajar con múltiples PSP sin ninguna dependencia a la hora de procesar la autorización de transacciones.

Conclusión
Conociendo que uno de los elementos diferenciales que permiten que un cliente se fidelice en un comercio electrónico es la facilidad en el momento de pagar, alternativas como los pagos recurrentes y los pagos con un clic se vislumbran como las claves en este proceso facilitador. No obstante, el principal problema al que se enfrentan los despliegues de estas técnicas es el almacenamiento de los datos de tarjeta de pago del cliente, que implican un mayor riesgo y, por ende, la necesidad de la implementación de controles de seguridad (PCI DSS).

Con la ayuda de la tokenización, el comercio (soportado en los servicios de su proveedor de servicios de pago (PSP) o con una implementación propia) puede minimizar este riesgo, mediante la conversión de los datos de la tarjeta de pago (datos confidenciales) en datos no confidenciales que ofrecen exactamente la misma operatividad, pero sin riesgo.

Referencias
1. Adobe: “The ROI from Marketing to Existing Online Customers” https://success.adobe.com/assets/en/downloads/whitepaper/13926.digital_index_loyal_shoppers_report.pdf
2. Ometria: “A Quick Guide to Customer Retention Marketing for Ecommerce” https://www.ometria.com/topic-guides/customer-retention
3. Google: “The New Multi-screen World: Understanding Cross-platform Consumer Behavior” https://services.google.com/fh/files/misc/multiscreenworld_final.pdf
4. MasterCard: “The New world of retail - New Challenges and Opportunities for the retail industry in the digital era” https://newsroom.mastercard.com/wp-content/uploads/2015/05/INNOV_025_White_Paper_Mastercard_4b.pdf
5. Baymart Institute: “37 Cart Abandonment Rate Statistics” https://baymard.com/lists/cart-abandonment-rate 
6. Payment Card Industry Data Security Standard https://www.pcisecuritystandards.org/


Autor: David Eduardo Acosta - CISSP Instructor, CISM, CISA, CRISC, CHFI Instructor, CEH, PCI QSA, OPST, BS25999 L. A. 
Departamento de Consultoría

Normatividad PCI DSS y Protección de Datos con la Asociación Colombiana de Empresas de Contact Center y BPO

El pasado 30 de agosto, en colaboración con la Asociación Colombiana de Empresas de Contact Centers y BPO (ACDECC&BPO), se realizó en Bogotá una jornada de conferencias sobre Ciberseguridad enfocadas principalmente a concienciación de la norma PCI DSS y Ley de Protección de Datos tratando la siguiente temática:

Inicialmente, intervinieron Esteban Jaramillo y Laura Bernal y, de Summa Consultores, despacho de abogados especialistas, entre otras áreas, en Protección de Datos, con el que Internet Security Auditors colabora intensamente en los proyectos de Implementación del cumplimiento de la Ley 1581/2012 y sus reglamentaciones. Laura Bernal presentó los aspectos clave de la regulación en Protección de Datos, haciendo hincapié en los aspectos que más afectan a las empresas prestadoras de servicios de Contact Center y BPO, como responsables del tratamiento, destacando sus responsabilidades. Por su parte, Esteban Jaramillo presentó dos casos de empresas sancionadas, una de ellas del sector, analizando las razones que desembocaron en la sanción con el objetivo de mostrar qué errores se cometieron en cada caso desde el punto de vista del cumplimiento de la legislación en Protección de Datos. Por último, Javier R. Amaya desgranó la metodología que siguen Internet Security Auditors y Summa Consultores en los proyectos de Adecuación de sus clientes en el cumplimiento de la regulación en Protección de Datos para alcanzar el cumplimiento integral legal y técnico.

Posteriormente, Daniel Fernández, Socio y Director Comercial de Internet Security Auditors repaso los aspectos relevantes de las diferentes normas PCI, profundizando en la norma PCI DSS, los aspectos más relevantes de esta y revisando los conceptos más importantes en un proceso de Implementación de la norma. También glosó los puntos más importantes en el proceso de reporte del cumplimiento mediante los Cuestionarios de Auto-Evaluación, mostrando la importancia de identificar y documentar el cumplimiento con el SAQ correcto y los errores más comunes que se producen, así como sus consecuencias, con el objeto de concientizar a la audiencia sobre su responsabilidad en el cumplimiento adecuado de PCI DSS.

En seguida inicio David A. González, QSA del equipo de Consultoría de Internet Security Auditors en Colombia, hablando de Problemáticas particulares de cumplimiento de PCI DSS en CC&BPO, presentando ejemplos de incidentes y compromisos de datos, así como las vulnerabilidades o defectos que fueron explotados o que desembocaron en cada caso, incluyendo algún caso real de empresas del sector. También listó las diferentes problemáticas que, como él dijo, aportan “esos interesantes retos a los QSA que deben asesorarles” detallando las situaciones comúnmente más difíciles de superar en los procesos de implementación de PCI DSS. El cierre de su presentación concluyó especificando las posibles vías de remediación de estas problemáticas y que tienen como objetivo el cumplimiento y evitar las brechas de seguridad de los casos presentados, aparte de simplificar el cumplimiento de PCI DSS para las empresas de tercerización de servicios como las que asistían a las conferencias.

Y finalizando, Javier R. Amaya, QSA y responsable del equipo de Consultoría de Internet Security Auditors en Colombia, expuso la temática de Transferencia internacional de datos y cumplimiento de PCI DSS con proveedores Cloud, enlazando y relacionando PCI DSS y protección de datos con el fin de mostrar la relación de responsabilidades de cumplimiento que tienen los usuarios de las diferentes modalidades de servicios en la nube, dependiendo de la modalidad *aaS contratada, desglosando los diferentes aspectos que cada una de las opciones implican en cuanto a las obligaciones de cumplimiento tanto de PCI DSS como de la regulación en protección de datos. Además, dado el hecho que la mayoría de proveedores comúnmente utilizados en los servicios cloud se encuentran en países extranjeros, se mostraron todos los aspectos que en cuanto a la reciente Circular Externa sobre transferencia de datos al extranjero, se han de tener en consideración. El objetivo de su presentación fue el de mostrar la relación tan importante que se produce entre las diferentes normativas y en uso de terceros proveedores de servicios en la nube.

Sin duda, estas conferencias fueron un éxito por la cantidad y relevancia de las empresas que asistieron y demuestra el interés que hay permanentemente en los diferentes sectores productivos del país tanto en los aspectos relacionados con la protección de datos como con las normas de seguridad de datos de pago.

Seguro que este será el primero de muchos eventos de capacitación continua en los que Internet Security Auditors colaborará con la Asociación de Contact Center y BPO en la difusión de la Ciberseguridad dando respuesta a todas las inquietudes de los asistentes que se enriquecieron en el conocimiento en Seguridad de Sistemas de Información dentro del espacio brindado para este fin.

Para ver todas las presentaciones de la jornada pueden dirigirse a nuestra web.


Autora: Paola Andrea Pirabán Rozo
Sales Manager, Internet Security Auditors

Privacy Shield, considerado inadecuado por el Parlamento Europeo

Cuando hace aproximadamente un año os contábamos que Privacy Shield, el nuevo marco internacional de transferencia de datos personales de ciudadanos entre la Unión Europea y los Estados Unidos que substituye a Safe Harbour, se había aprobado oficialmente, poco nos imaginábamos que unos meses más tarde os daríamos la noticia de que el Parlamento Europeo, o más concretamente la Comisión de Libertades Civiles, Justicia y Asuntos de Interior (LIBE), consideraría dicho programa como inadecuado.

Al parecer, dicho organismo ha detectado las siguientes deficiencias en la aplicación del programa a lo largo de este año:
  • Falta de reglas específicas en la toma de decisiones automatizada y en el derecho general a objetar sobre dichas decisiones, y falta de claridad sobre cómo los principios de Privacy Shield se aplican a los procesadores de datos existentes.
  • Sigue siendo posible una vigilancia a gran escala de los datos de los ciudadanos de la UE, si las autoridades de los EEUU lo consideran justificado en base a sus estados de seguridad y vigilancia.
  • Ni los principios de protección de la privacidad ni las cartas de la administración de los Estados Unidos demuestran la existencia de unos derechos judiciales eficaces para los individuos en la UE cuyos datos personales se transfieren a los EEUU.
  • El mecanismo del “Defensor del Pueblo” establecido por el Departamento de Estado de los Estados Unidos no es suficientemente independiente, y no está dotado de poderes efectivos y suficientes para llevar a cabo sus funciones acordadas.
 Además, dicha comisión también se ha expresado alarmada por las revelaciones recientes sobre las actividades de monitorización y vigilancia en datos personales de ciudadanos, llevadas a cabo por proveedores de servicios de comunicaciones electrónicas estadounidenses hasta el año 2015, bajo petición de la NSA y el FBI, y solicita a las autoridades de los EEUU una clarificación oficial sobre este tema.

Según ha confirmado la Comisión Europea, en septiembre de este mismo año se realizará una revisión conjunta de dicho marco en Washington, que contará con la presencia de representantes de las autoridades de protección de datos de la Unión Europea y de los Estados Unidos, y dónde se pretende ajustar dicho programa para solventar las deficiencias detectadas.

Es importante recordar no obstante, que des de la llegada de Donald Trump a la presidencia de los Estados Unidos, la política de protección de datos de dicho país ha experimentado grandes cambios, siendo uno de los más destacados la orden ejecutiva de 25 de Enero de este año, donde entre otras cosas, se detalla que “las agencias deberán, de manera compatible con la legislación aplicable, garantizar que sus políticas de privacidad excluyen a las personas que no sean ciudadanas de los Estados Unidos o residentes permanentes legales”.

Por lo tanto, parece evidente que las autoridades europeas no lo tendrán nada sencillo para ajustar Privacy Shield a sus intereses en la revisión de septiembre, y no hay que descartar que no se lleguen a acuerdos satisfactorios entre los representantes de la UE y los EEUU, cosa que podría significar que se vuelva a repetir una situación similar a la de octubre de 2015, cuando el marco Safe Harbour fue declarado inválido por parte de la Unión Europea, y anulado en todos sus efectos.

Desde Internet Security Auditors estaremos atentos a las novedades al respeto, para analizarlas en profundidad en este blog.

Referencias
http://blog.isecauditors.com/2016/02/privacy-shield-nuevo-marco-internacional-de-transferencia-datos.html
http://blog.isecauditors.com/2016/09/aprobacion-oficial-del-marco-privacy-shield.html
http://blog.isecauditors.com/2016/03/primer-borrador-de-privacy-shield.html
http://www.europarl.europa.eu/news/en/press-room/20170321IPR67934/privacy-shield-key-deficiencies-urgently-need-to-be-resolved-meps-say
http://europa.eu/rapid/press-release_SPEECH-17-826_en.htm
https://www.whitehouse.gov/the-press-office/2017/01/25/presidential-executive-order-enhancing-public-safety-interior-united

Autor: Guillem Fàbregas - PCI QSA, PCIP, CISSP, CISA, CISM, CRISC, ISO 27001 L.A.
Departamento de Consultoría