PCI DSS VS. GDPR

El 25 de mayo de 2018 entró en aplicación el Reglamento General de Protección de Datos Europeo (o General Data Protection Regulation, de aquí en adelante GDPR),  que remplazó a la Directiva de Protección de Datos 95/46/EC, y que fue diseñado con el objetivo de alinear todas las leyes de protección de datos en países europeos, proteger y darle control de sus datos privados a los ciudadanos europeos y establecer un marco de trabajo homogéneo en términos de privacidad para que las organizaciones e individuos puedan ejercer sus derechos y conozcan sus responsabilidades.

A pesar de que ya existían estándares orientados a la protección de la información de identificación personal (Personally Identifiable Information – PII) como el estándar ISO/IEC 29100:2011 y recomendaciones internacionales en materia de protección de datos provenientes de la OCDE (Organización para la Cooperación y el Desarrollo Económicos), del Foro de Cooperación Económica Asia Pacífico (APEC), de Federal CIO Council, de la Red de Autoridades Francófonas, de la Red Iberoamericana de Protección de Datos y de la Global Privacy Enforcement Network (GPEN), ninguno de ellos había tenido el impacto que ha tenido este reglamento, sobre todo motivado por los altos costes de las multas por incumplimiento (4% de la facturación anual o hasta 20 millones de Euros) y en la obligatoriedad de su implementación por parte de los estados miembro (GDPR es un reglamento, no una directiva, no requiere que los gobiernos nacionales aprueben ninguna legislación habilitante y es directamente vinculante y aplicable).

En términos de aplicabilidad de este reglamento, el elemento clave que lo define es el concepto de datos personales. Según la Comisión Europea, los datos personales son "toda información sobre una persona física identificada o identificable ("el interesado")". Por otro lado, complementa: "se considerará persona física identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador, como por ejemplo un nombre, un número de identificación, datos de localización, un identificador en línea o uno o varios elementos propios de la identidad física, fisiológica, genética, psíquica, económica, cultural o social de dicha persona". Algunos ejemplos de datos personales son:
  • Nombre y apellidos,
  • Domicilio,
  • Dirección de correo electrónico, del tipo nombre.apellido@empresa.com,
  • Número de documento nacional de identidad,
  • Datos de localización (como la función de los datos de localización de un teléfono móvil),
  • Dirección de protocolo de internet (IP),
  • El identificador de una cookie,
  • El identificador de la publicidad del teléfono,
  • Los datos en poder de un hospital o médico, que podrían ser un símbolo que identificara de forma única a una persona.
  • Datos de tarjetas de pago (PAN y nombre del titular).
Precisamente, es en este último punto en el cual GDPR converge con el estándar PCI DSS: La protección de los datos de tarjetas de pago vinculadas con ciudadanos europeos. No obstante, son documentos diferentes pero que pueden ser empleados indistintamente como complemento para lograr el cumplimiento de uno o del otro y no son excluyentes. De hecho, Jeremy King, Director Internacional del PCI SSC para Europa, comentó en una entrevista:

"La gente acude a mí y me dice: '¿Cómo logro el cumplimiento de GDPR?' ... Comience con PCI DSS".

A continuación, se presenta una tabla comparativa entre GDPR y PCI DSS, que le permitirá al lector establecer las pautas básicas para el establecimiento de programas de alineación entre estos dos marcos normativos.

RGPD/GDPR PCI DSS
Tipo Legal/Gubernamental (regulación europea). Industrial (marcas de tarjetas que conforman el PCI SSC: VISA, MasterCard, AMEX, Discover y JCB).
Organismo global encargado del marco normativo Comité Europeo de Protección de Datos (artículo 68). Payment Card Industry Security Standards Council (PCI SSC).
Fecha efectiva de cumplimiento 25 de mayo de 2018 (artículo 99). La primera versión de PCI DSS se publicó el 14 de diciembre de 2004. Se realizan actualizaciones de versiones de forma periódica.
Cuerpo normativo remplazado El RGPD / GDPR remplaza y deroga a la Directiva 95/46/EC del Parlamento Europeo (artículo 94). PCI DSS remplaza (pero no deroga) los estándares de seguridad de cada una de las marcas de pago:
  • American Express – Data Security Operating Policy (DSOP)
  • Discover – Discover Information Security Compliance (DISC)
  • JCB International – Data Security Program (DSP)
  • MasterCard – Site Data Protection (SDP)
  • Visa USA – Cardholder Information Security Program (CISP)
  • Visa International – Account Information Security Program (AIS)
Datos dentro del alcance de cumplimiento Aplica al tratamiento total o parcialmente automatizado de datos personales (información personal de identificación / "Personally Identifiable Information" - PII) relacionados con personas en la Unión Europea (artículo 2). El número de cuenta principal (Primary Account Number - PAN) es el factor que define la aplicabilidad de PCI DSS. Si el nombre del titular de tarjeta, el código de servicio y/o la fecha de vencimiento se almacenan, procesan o transmiten con el PAN o se encuentran presentes de algún otro modo en el entorno de datos del titular de la tarjeta, se deben proteger de conformidad con los requisitos aplicables de PCI DSS.
Operaciones afectadas Aplica a cualquier operación o conjunto de operaciones realizadas sobre datos personales o conjuntos de datos personales, ya sea por procedimientos automatizados o no, como la recogida, registro, organización, estructuración, conservación, adaptación o modificación, extracción, consulta, utilización, comunicación por transmisión, difusión o cualquier otra forma de habilitación de acceso, cotejo o interconexión, limitación, supresión o destrucción; (artículo 4). Aplica a cualquier operación de almacenamiento, procesamiento o transmisión de datos del titular de la tarjeta (CHD) y/o datos confidenciales de autenticación (SAD).
Derechos del interesado Los ciudadanos europeos tienen derecho a lo siguiente (artículo 13):
  • Obtener información sobre el tratamiento de sus datos personales,
  • Obtener acceso a los datos personales que le conciernen,
  • Pedir que los datos personales incorrectos, inexactos o incompletos sean corregidos,
  • Solicitar que los datos personales sean borrados cuando ya no sean necesarios o si el tratamiento es ilícito,
  • Oponerse al tratamiento de sus datos personales con fines de mercadotecnia o por motivos relacionados con su situación particular,
  • Solicitar la limitación del tratamiento de sus datos personales en determinados casos,
  • Recibir sus datos personales en un formato de lectura mecánica y enviarlos a otro responsable del tratamiento («portabilidad de datos»),
  • Solicitar que las decisiones basadas en un tratamiento automatizado que le incumban o le afecten significativamente y basadas en sus datos personales sean tomadas por personas físicas y no solamente por ordenadores; asimismo, tiene derecho, en este caso, a expresar su punto de vista y a impugnar dicha decisión.
No se contemplan derechos específicos de los interesados sobre los datos de tarjetas de pago obtenidos en función del negocio.
Solicitud de consentimiento Una solicitud de consentimiento en el momento de la captura de los datos personales debe presentarse de forma clara y concisa, empleando un lenguaje fácil de entender, y diferenciarse claramente de otras informaciones, como las condiciones de uso. La solicitud debe especificar qué uso se hará de sus datos personales e incluir los datos de contacto de la empresa que trata los datos. El consentimiento debe darse libremente y ser una manifestación específica, informada e inequívoca (artículo 7). No se requiere de una solicitud de consentimiento explícita en el momento de captura de los datos de tarjetas de pago.
Entidades que lo deben cumplir Se definen dos grupos de entidades que deben cumplir con este reglamento, siempre que traten con información personal de identificación de ciudadanos en la Unión Europea, no importa su ubicación (capítulo IV):
  • Responsable del tratamiento ("data controller"): Entidades o individuos que necesitan procesar datos personales para su negocio. Ellos determinan los propósitos y la manera en que se procesan los datos personales.
  • Encargado del tratamiento ("data processor"): Persona física o jurídica, autoridad pública, servicio u otro organismo que trate datos personales por cuenta del responsable del tratamiento.
En función de la cantidad anual de transacciones con tarjetas realizadas y del tipo de entidad (comercio o proveedor de servicio), se requiere:
  • La ejecución de una auditoría anual en sitio realizada por auditores certificados (QSA), o
  • Rellenar un cuestionario de autoevaluación anual (SAQ).
Controles de seguridad a implementar La aplicabilidad de medidas técnicas y organizativas para demostrar la conformidad del tratamiento con el Reglamento son discrecionales (no se describen de forma explícita) y deben ser elegidas por el Responsable o el Encargado del tratamiento (artículos 25 y 32) mediante el concepto de protección de los datos desde el diseño y por defecto. Las medidas técnicas, físicas y administrativas a implementar se describen a lo largo de los 12 requisitos del estándar. Se trata de controles de seguridad a bajo nivel definidos explícitamente. También se incluyen controles alternativos o compensatorios, en caso de que la implementación del control descrito en el estándar no pueda ser cubierta debido a una justificación técnica o de negocio.
Técnicas para la protección de los datos afectados
  • Seudonimización.
  • Encriptación.
    (artículo 32)
  • Valores hash de una vía basados en criptografía sólida.
  • Truncamiento.
  • Tokens y ensambladores de índices.
  • Criptografía sólida con procesos y procedimientos asociados para la administración de claves.
    (requisito 3.4)
Persona encargada de la supervisión del cumplimiento en la organización Se debe designar un delegado de protección de datos (artículo 37) siempre que:
  • el tratamiento lo lleve a cabo una autoridad u organismo público, excepto los tribunales que actúen en ejercicio de su función judicial;
  • las actividades principales del responsable o del encargado consistan en operaciones de tratamiento que, en razón de su naturaleza, alcance y/o fines, requieran una observación habitual y sistemática de interesados a gran escala, o
  • las actividades principales del responsable o del encargado consistan en el tratamiento a gran escala de categorías especiales de datos personales con arreglo al artículo 9 y de datos relativos a condenas e infracciones penales a que se refiere el artículo 10.
Se requiere definir un rol de responsable de cumplimiento de PCI DSS si la entidad afectada es un proveedor de servicio (req. 12.4.1) o una entidad designada (según el anexo A3 – A3.1.1). Para los demás comercios es solo una recomendación.
Entidad encargada de supervisar la aplicación del marco normativo Cada Estado miembro delega la responsabilidad de supervisar la aplicación del marco normativo en una "autoridad de control" ("supervisory authority") o "autoridad nacional de protección de datos" (APD), con el fin de proteger los derechos y las libertades fundamentales de las personas físicas en lo que respecta al tratamiento y de facilitar la libre circulación de datos personales en la Unión (artículo 51). Las marcas de tarjetas de pago gestionan de forma independiente el cumplimiento de los comercios y proveedores de servicio. Pueden delegar la centralización de reportes de cumplimiento en bancos adquirientes.
Realización de evaluaciones de impacto / análisis de riesgos Cuando sea probable que un tipo de tratamiento, en particular si utiliza nuevas tecnologías, por su naturaleza, alcance, contexto o fines, entrañe un alto riesgo para los derechos y libertades de las personas físicas, el responsable del tratamiento realizará, antes del tratamiento, una evaluación del impacto de las operaciones de tratamiento en la protección de datos personales (artículo 35). Para identificar los potenciales riesgos que puedan afectar a los activos del entorno de cumplimiento, PCI DSS requiere la realización anual de un análisis formal de riesgos basado en una metodología aceptada por la industria (req. 12.2).
Umbrales de almacenamiento de los datos protegidos Los datos personales deben ser mantenidos de forma que se permita la identificación de los interesados durante no más tiempo del necesario para los fines del tratamiento de los datos personales ("limitación del plazo de conservación" - artículo 5). No se deben almacenar los datos confidenciales de autenticación después de la autorización, incluso si están cifrados (req. 3.1).
Reporte de brechas de seguridad (incidentes) En caso de violación de la seguridad de los datos personales, el responsable del tratamiento la notificará a la autoridad de control competente de conformidad con el artículo 55 sin dilación indebida y, de ser posible, a más tardar 72 horas después de que haya tenido constancia de ella, a menos que sea improbable que dicha violación de la seguridad constituya un riesgo para los derechos y las libertades de las personas físicas. Si la notificación a la autoridad de control no tiene lugar en el plazo de 72 horas, deberá ir acompañada de indicación de los motivos de la dilación (artículo 33). El requisito 12.10 requiere la definición de un plan de respuesta a incidentes, su revisión y prueba anual, designación de personal y formación al mismo y un plan de mejora contínua. El reporte de incidentes se debe dirigir directamente a las marcas, de acuerdo con los procedimientos y tiempos estipulados por cada una de estas entidades.

Igualmente, incluye la necesidad de realizar un análisis de requisitos legales necesarios para el informe de riesgos, dentro de los cuales se contempla GDPR.
Comunicación de una brecha de seguridad al interesado Cuando sea probable que la violación de la seguridad de los datos personales entrañe un alto riesgo para los derechos y libertades de las personas físicas, el responsable del tratamiento la comunicará al interesado sin dilación indebida (artículo 34). No se requiere de forma explícita una notificación al interesado, pero esta acción puede formar parte de las actividades de prevención, contención y recuperación del incidente a ser establecidas por las marcas posterior a una investigación.
Responsable de la investigación de incidentes Las tareas de investigación de incidentes relacionados con datos personales recaen en la autoridad de control. Dependiendo de la magnitud del incidente, las marcas pueden exigirle a la entidad afectada la contratación de los servicios de un PCI Forensic Investigator (PFI). Los PFI son empresas homologadas y listadas en el sitio web del PCI SSC encargadas de la investigación, generación de reportes y soporte a la entidad afectada en caso de un incidente.
Sanciones por incumplimiento Se sancionará con multas administrativas de 20.000.000 EUR como máximo o, tratándose de una empresa, de una cuantía equivalente al 4 % como máximo del volumen de negocio total anual global del ejercicio financiero anterior, optándose por la de mayor cuantía (artículo 83). Las multas por incumplimiento son establecidas de forma unilateral por las marcas de pago en función del incidente. No existen tablas públicas con estos datos.

Ya sea que se necesite implementar GDPR en un entorno alineado con PCI DSS o viceversa, el primer paso consistirá en la ejecución de un análisis diferencial de cumplimiento ("gap analysis") para detectar incumplimientos y definir acciones correctivas.

Conclusión
Por definición, el dato del PAN (Primary Account Number – Número Primario de Cuenta) y los demás datos vinculados con tarjetas de pago (nombre del titular, datos completos de la banda magnética, etc.) son considerados como información personal de identificación ("Personally Identifiable Information" - PII), ya que que pueden usarse para identificar, contactar o localizar a una persona en concreto, o pueden usarse, junto a otras fuentes de información, para hacerlo.

Por esta razón, aparte de los controles de seguridad exigidos por las marcas de pago para su protección (como es el caso de PCI DSS), también requieren cumplir con las normativas legales de protección de datos exigidas en cada región (como es el caso de GDPR). En este caso, hay que tener presente que PCI DSS no sustituye las leyes locales ni regionales, las regulaciones gubernamentales ni otros requisitos legales.


Autor: David Eduardo Acosta CISSP|I, CISM, CISA, CRISC, C|EH, C|HFI Instructor, OPST, PCI SSC QSA for DSS/P2PE/3DS/TSP Dpto. Consultoría

Firmamos acuerdo con el Capítulo de ISACA Bogotá

Internet Security Auditors y el Capítulo de ISACA en Bogotá han firmado un acuerdo para la colaboración en la promoción de los cursos oficiales y diferentes capacitaciones ofrecidas por ambas organizaciones, rubricado por el Presidente de ISACA Bogotá, Víctor A. Vásquez y el Director Global de Ventas y Alianzas de Internet Security Auditors, Daniel Fernández.

Este Acuerdo incluye el acceso a las capacitaciones de la compañía para los miembros del Capítulo con descuentos para sus asociados y también facilitará el acceso a los clientes de Internet Security Auditors a los cursos de la Asociación en Bogotá.

ISACA, fundada el año 1969, es una de las organizaciones con más reconocimiento a nivel mundial, con más de 140.000 en 180 países y con certificaciones que año tras año se sitúan en el top 5 del reconocimiento mundial en la ciberseguridad.

Con este acuerdo, Internet Security Auditors refuerza su compromiso con la difusión de la formación oficial en alianza con una de las asociaciones de profesionales de la Ciberseguridad y Auditoría con más penetración en el país, demostrando la capacidad y voluntad de facilitar el acceso a las certificaciones y cursos del máximo nivel que ofrece la compañía para los miembros de ISACA.

Tratamiento datos sensibles de autenticación, ¿fuera de PCI DSS?

Recientemente nos hemos encontrado el caso de algunos clientes que nos han preguntado si un entorno donde se almacenan, procesan o trasmiten datos sensibles de autenticación relacionados con las tarjetas de pago, pero no datos PAN, es susceptible de la aplicación del estándar de seguridad PCI DSS.

Para ponernos en situación, lo primero que tenemos que hacer es identificar los distintos datos que conforman una tarjeta de pago bancaria. Dichos datos son los siguientes:
  • PAN (Primary Account Number): Datos identificativos de las tarjetas, formados por el BIN (Bank Identification Number) + otros datos identificativos de las tarjetas en cuestión.
  • Cardholder name: Nombre del titular de la tarjeta, necesario para la mayoría de los pagos online.
  • Expiration date: Fecha de caducidad de la tarjeta.
  • CAV2/CID/CVC2/CVV2: Datos sensibles de autenticación, necesarios para autenticar al dueño de la tarjeta en entornos de pago no presenciales.
  • PIN: Datos sensibles de autenticación, no almacenados de manera directa en la tarjeta de pago, necesarios para autenticar al dueño de la tarjeta en entornos de pago presenciales.



Pues bien, la respuesta a esta duda es sencilla, y está recogida en el propio estándar PCI DSS:


Vemos por lo tanto, que el estándar PCI DSS aplica a las entidades que procesan, transmiten o almacenan datos sensibles de autenticación, aunque dichas entidades no lleguen a “ver” nunca los datos PAN asociados a las transacciones.

Esta respuesta puede parecer confusa, ya que a priori, dichos datos pueden parecer un conjunto de 3-4 dígitos aislados y aleatorios, de los que aparentemente, no se puede sacar un provecho si dichos datos no van acompañados de un dato PAN, pero hay que tener en cuenta que lo que busca el estándar de seguridad PCI DSS, es la protección de los entornos dónde se traten datos de tarjeta en su conjunto, aunque dicho cumplimiento esté formado por la suma de varios cumplimientos individuales.

Un ejemplo podría ser en el caso dónde un comercio externaliza en un proveedor de servicios el tratamiento/almacenamiento de los datos sensibles de autenticación CVV2 cuando se produce una transacción online. En este caso, si pensamos en el riesgo de seguridad de dicho proveedor de manera individual, puede parecer que los datos CVV2 no requieran de protección de seguridad, ya que con dichos datos individuales a priori no es posible conseguir la realización de una transacción económica. No obstante, si pensamos en el riesgo de seguridad de manera conjunta (entorno del comercio + entorno del proveedor), parece evidente que tanto los datos PAN como los datos CVV2 deben ser protegidos, de esta manera evitaremos que un atacante pueda conseguirlos y realizar transacciones económicas con dichos datos.

Este es precisamente el criterio que sigue el PCI SSC en la definición de sus estándares de seguridad, y, por lo tanto, es lo que lleva a los entornos aislados dónde se almacenan, procesan o transmiten datos sensibles de autenticación a estar sujetos al obligado cumplimiento de los requerimiento de seguridad que marca el estándar PCI DSS.


Autor: Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona

Técnicas de truncado de datos de tarjeta en entornos PCI DSS


Con el objetivo de minimizar el esfuerzo de implantación de PCI DSS en un entorno dónde se procesan datos de tarjetas, una de las premisas más importantes que nos planteamos es la reducción de dicho entorno. Para ello, una de las técnicas que podemos utilizar es la del truncado de los datos de tarjeta en su almacenamiento.

Muchas entidades tienen tendencia a almacenar el PAN (Primary Account Number) de las transacciones realizadas para fines históricos, o para mantener una correcta trazabilidad de las mismas. El problema en estos casos es que, al almacenar el PAN entero en una BBDD o sistema de almacenamiento, el entorno PCI DSS de nuestra entidad se expande hasta dicha localización, cuando por justificación de negocio, sería suficiente con almacenar una parte sesgada de dichos datos PAN.

En estos casos, es cuando la opción de utilizar el truncado de los datos de tarjeta destaca como una de las opciones más recomendables. Esta técnica, se basa en almacenar solo una parte del PAN, con fines históricos o de trazabilidad, pero sin permitir al atacante que pueda llegar a deducir el PAN completo de la transacción a través del uso de técnicas computacionales simples.

Para aplicar un correcto truncado del PAN, el formato máximo de dígitos del mismo que es posible almacenar sin que el estándar PCI DSS nos afecte en dicha ubicación, es el de los 6 primeros dígitos (que se corresponden con el BIN (Bank Identification number)) y los 4 últimos dígitos (como ID de la transacción realizada) del mismo.

Puede consultarse más detalle sobre los formatos de truncado de PAN aceptables según los diferentes criterios establecidos por las marcas de tarjetas en la tabla siguiente:






































Podemos ver un ejemplo de dicha técnica en la figura siguiente, dónde a partir de unos datos de entrada con un PAN completo, pasamos a almacenar el PAN truncado, evitando de esta manera la aplicación del estándar PCI DSS en la ubicación dónde se almacenen dichos datos, siempre y cuando que dicha ubicación se encuentre segmentada del entorno de tratamiento del PAN completo, y no se vea “contaminada” por otros aspectos de seguridad secundarios.

Por último, es importante destacar que, aunque dicha técnica permita la reducción de nuestro entorno de cumplimiento PCI DSS, tenemos que garantizar que un atacante no va a ser capaz de deducir información sensible en base a la información almacenada en las BBDD dónde se encuentra el PAN truncado. Esto conlleva a que según el estándar PCI DSS, no sea viable almacenar el PAN truncado y el hash de ese mismo PAN en una misma ubicación, sin que esta esté sujeta el alcance de dicho estándar de seguridad, ya que se considera que, con un mínimo de lógica computacional, un atacante podría llegar a deducir un PAN entero a través de la suma de dichos datos.

Si se tiene en cuenta este aspecto, la técnica de truncado de PAN puede llegar a ser muy útil en nuestra entidad, para minimizar nuestro esfuerzo de cumplimiento con el estándar PCI DSS.

Bibliografía
https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-acceptable-formats-for-truncation-of-primary-account-numbers

Autor: Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona

Rol de la International Trade Administration en el marco Privacy Shield



El marco de seguridad Privacy Shield es administrado por la International Trade Administration (ITA), que forma parte del Departamento de Comercio de los Estados Unidos.

Para comprender los pasos a seguir y los requerimientos solicitados en el caso de querer adherirse al cumplimiento del mismo, es importante conocer el rol de dicho actor en la gestión y mantenimiento de dicho marco de seguridad. Para ello, a continuación veremos las principales acciones llevadas a cabo por ITA en la gestión del marco Privacy Shield:
  • Mantenimiento de los listados de cumplimiento de Privacy Shield: En primer lugar, hay que destacar que ITA mantiene los listados de entidades que se han adherido a los requisitos de seguridad de Privacy Shield, y que se han autoevaluado al respeto.

    Además, en el caso de que una entidad salga del programa Privacy Shield, ITA pone en conocimiento público a través de la web del programa el motivo por el cual ha abandonado el marco.
  • Verificación de los requerimientos de auto-certificación de las entidades: Antes de dar por finalizada la auto-certificación inicial (o las posteriores certificaciones anuales) llevada a cabo por las entidades adheridas a Privacy Shield, ITA comprueba que la organización solicitante ha:
    • Proporcionado toda la información solicitada en el formulario de auto-certificación.
    • Añadido en su política de seguridad corporativa la adherencia a los principios indicados en Privacy Shield.
    • Ha indicado que va a recibir información relacionada con labores de RRHH des de Europa, ésta ha declarado su intención a colaborar con las entidades regulatorias europeas, en la resolución de quejas relacionadas con su trato de los datos personales de los ciudadanos europeos.
  • Realización de revisiones periódicas de cumplimiento: De manera periódica, ITA realiza revisiones de cumplimiento de Privacy Shield, enviando a las entidades participantes en el programa cuestionarios que deben ser rellenados y devueltos al departamento, para la revisión e identificación de posibles aspectos que puedan requerir revisiones adicionales.
    Concretamente, se realizarán revisiones de cumplimiento adicionales del marco normativo cuando:
    • ITA haya recibido quejas relativas al cumplimiento de Privacy Shield por parte de ciudadanos europeos o las autoridades regulatorias europeas pertinentes.
    • La entidad no responda satisfactoriamente a las solicitudes realizadas por el departamento ITA.
    • Existan evidencias de que la entidad no está siguiendo los requerimientos indicados en el marco Privacy Shield.
  • Gestión de quejas recibidas por parte de la Unión Europea: En caso de recibir alguna queja por parte de las autoridades europeas, en el trato de datos personales de ciudadanos de la Unión por parte de alguna empresa adherida al marco Privacy Shield, ITA hará las gestiones necesarias para proveer las explicaciones pertinentes a dichas autoridades. Además, ITA se compromete a informar estas autoridades sobre los avances de la resolución de los casos en un plazo máximo de 90 días des de la recepción de la queja pertinente.

Autor: Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona

Vicente Aguilera entrevistado en el programa Así Estamos de la radio argentina

Vicente Aguilera fue entrevistado el pasado jueves en el programa Así Estamos de la radio argentina Estudio 91.7, dónde habló sobre ciberseguridad y como ésta aplica a nuestra vida cotidiana a través de las redes sociales, la banca online o el voto electrónico entre otros.

Si no pudiste seguir la entrevista, visita el siguiente enlace:
https://www.ciudadanodiario.com.ar/nota/2018-8-31-11-1-13-seguridad-informatica-lo-que-tenes-que-saber-sobre-tinfoleak

Publicada la versión 3.0 del estándar “PCI PIN Security Requirements and Testing Procedures”

En Agosto de 2018 el PCI SSC publicó la versión 3.0 del estándar "PIN Security Requirements and Testing Procedures". Este documento hace parte de la familia de estándares PCI PIN Transaction Security (PTS) en donde también se encuentran PCI HSM (Hardware Security Module) y PCI POI (Point of Interaction), orientados a la protección del PIN (Personal Identification Number) en transacciones presenciales (“card present”) en cajeros electrónicos y terminales de punto de venta (TPV) atendidas y desatendidas. La primera versión de PCI PIN (1.0) fue publicada en el año 2011 y la versión 2.0 fue publicada en 2014, con lo que este estándar ya acumula 7 años de implementaciones a nivel mundial. Para esta nueva versión (3.0), el PCI SSC ha optado por combinar los requerimientos de seguridad (“PIN Security Requirements”) y los procedimientos de prueba (“Test Procedures”) en un único documento, ya que en versiones anteriores se habían mantenido documentos separados.

El listado de cambios entre la versión 2.0 y 3.0 se puede encontrar en el documento "PIN Security Requirements Modifications and Testing Procedures: Summary of Changes".

Los objetivos de este estándar son:
  • Identificar los requerimientos mínimos de seguridad para transacciones de intercambio basadas en PIN.
  • Describir los requisitos mínimos aceptables para asegurar el dato del PIN y las claves de encriptación.
  • Asistir a todos los participantes del sistema de pago minorista en el establecimiento de garantías de que los datos del PIN de los titulares de tarjetas no se vean comprometidos.
El estándar PCI PIN es de obligatorio cumplimiento para todas las instituciones adquirientes y agentes responsables del procesamiento de transacciones con PIN de las tarjetas de las marcas del PCI SSC (VISA, MasterCard, AMEX, Discover y JCB) incluyendo servicios de inyección de claves y gestión de certificados y debe ser usado en conjunción con otros estándares aplicables de la industria (PCI DSS, PCI P2PE, etc.).

Respecto a esta nueva versión, uno de los cambios más representativos está en la reorganización de los requerimientos en tres grandes grupos, cada uno subdividido a su vez en “objetivos de control” (“Control Objective”):
  1. Transaction Processing Operations: Anteriormente denominados “PIN Security Requirements”, este grupo de controles aplican a cualquier entidad relacionada con procesos de adquiriencia y/o procesamiento de transacciones basadas en PIN.
  2. Normative Annex A – Symmetric Key Distribution using Asymmetric Keys: Requerimientos específicos para entidades adquirientes involucradas en la implementación de procesos de distribución de claves simétricas usando claves asimétricas (distribución remota de claves) o para aquellas entidades que ofrecen servicios de operación de autoridades de certificación (Certification Authorities – CA) empleadas para dichos propósitos. Su aplicación depende de las tareas realizadas por la entidad afectada:
    • Si se trata de una entidad adquiriente que también realiza funciones de distribución remota de claves, le aplicarán los controles del grupo “Transaction Processing Operations” y los controles del anexo A.
    • Si se trata de proveedores de servicio o de fabricantes de dispositivos de punto de interacción (POI) o de HSM que operen sistemas de distribución de claves actuando en nombre de una entidad adquiriente, deben cumplir la totalidad de los controles del anexo A.
  3. Normative Annex B – Key-Injection Facilities: Requerimientos para entidades que operan servicios de inyeccion de claves de adquiriente en dispositivos empleados para la captura del dato de PIN.
Dependiendo de las tareas realizadas, cada entidad puede estar sujeta a la aplicabilidad de requerimientos de diferentes secciones o al estándar completo. El apéndice A del estándar incluye una nueva matriz en la cual se indica la aplicabilidad de cada requerimiento en función de las labores desarrolladas.
Figura 1. Aplicabilidad de requerimientos de PCI PIN en función de las labores realizadas

Por otro lado, se han estipulado los siguientes plazos para el uso de claves fijas de 3DES (TDES) empleadas para la encriptación de PIN y el uso del formato 4 de bloque de PIN (ISO PIN block format 4):
  • A partir del 1 de enero de 2023 todas las claves fijas de 3DES (TDES) empleadas para la encriptación de PIN en puntos de interacción (POI) y conexiones host-to-host no serán permitidas.
  • A partir del 1 de enero de 2023 todos los hosts deben soportar la desencriptación del formato 4 de bloque de PIN.
  • A partir del 1 de enero de 2025 todos los hosts deben soportar la encriptación del formato 4 de bloque de PIN.
En este punto, hay que resaltar que el estándar PCI PIN especifica los controles sobre las claves vinculadas a procesos que afecten al PIN. Cualquier clave empleada para la protección de otros datos de la tarjeta (PAN, por ejemplo) o que se use para funcionalidades de MAC está fuera del ámbito del documento.

Finalmente, se han establecido los siguientes criterios adicionales:
  • Todas las entidades afectadas por el estándar deben mantener un inventario de todas las claves criptográficas empleadas en el entorno, incluyendo su nombre, su uso, el algoritmo usado y su longitud. De igual forma, se debe mantener un diagrama de flujo red esquemático que facilite la revisión de los requerimientos de seguridad.
  • En relación con el uso de determinados modelos o actualizaciones de dispositivos POI, serán las propias marcas de pago las que definan los criterios de despliegue y periodos de expiración y remplazo de estos equipos en campo de acuerdo con el estándar PCI PTS.
  • Es importante aclarar que son las marcas (y no el PCI SSC) las responsables de la definición y la gestión de los programas de cumplimiento asociados a este estándar, por lo que cada marca estipulará las fechas de cumplimiento, multas y forma mediante la cual se realizará el reporte de cumplimiento, así como los listados de empresas que pueden auditar.


Autor: David Eduardo Acosta CISSP|I, CISM, CISA, CRISC, C|EH, C|HFI Instructor, OPST, PCI SSC QSA for DSS/P2PE/3DS/TSP Dpto. Consultoría

Breve introducción al estándar PCI 3D-Secure (PCI 3DS)



Introducción
En octubre de 2017, el PCI SSC anunció el PCI 3D-Secure (PCI 3DS), un nuevo estándar de seguridad aplicable en entornos de pago no presencial, dónde se utiliza 3D-Secure, un protocolo que mejora la seguridad en la autenticación de los clientes en las compras online. Dicho protocolo permite a los consumidores autenticarse a través de un valor de un solo uso (one-time password), como puede ser número contenido en una tarjeta de coordenadas, un token criptográfico, una contraseña, un código enviado vía SMS/correo electrónico, etc. Dicho valor debe ser introducido por el cliente en el sitio web del banco emisor, lo cual puede requerir la redirección del browser del usuario (vía iFrame, por ejemplo) desde el sitio web del comercio en el cual se realiza la transacción. Este paso se realiza para garantizar que el comercio no tendrá acceso en ningún momento a este valor de autenticación, optimizando los niveles de protección contra el fraude.

En este artículo revisaremos las características más destacadas de este nuevo estándar de seguridad.

Entorno de aplicación
El estándar PCI 3DS debe ser aplicado por parte de las entidades que realizan o proporcionan alguna de las siguientes funciones en los procesos de autenticación 3DS:
  • Servidor de control de acceso 3DS (ACS): Servidor que contiene las reglas de autenticación (reglas que identifican/autentican a los usuarios en sus accesos al entorno), y que es controlado por la entidad emisora. Dicho servidor comprueba si la autenticación es válida utilizando la tarjeta y el equipo de acceso utilizados por el usuario, y en dicho caso, autentica al usuario en las transacciones bancarias relacionadas.
  • Servidor Directorio Activo 3DS (DS): Servidor que mantiene listados de los rangos de números de tarjeta aplicables, y coordina las comunicaciones entre el 3DSS, que en el siguiente párrafo se explica, y el ACS, para determinar si la autenticación 3D-Secure está disponible para una tarjeta concreta y un dispositivo de acceso concreto.
  • Servidor 3DS (3DSS): Proporciona la interfaz funcional entre el entorno de solicitud de la autenticación 3DS y el DS
Además, dicho estándar aplica también a todos los elementos que proporcionen funcionalidades adicionales a los comentados, como elementos de red, dispositivos de seguridad, aplicaciones, otros elementos secundarios conectados al entorno de cumplimiento, etc.

Requerimientos de seguridad
Los requerimientos de seguridad del estándar PCI 3DS están divididos en dos grupos:
  • Parte 1. Requerimientos de seguridad base: Requerimientos técnicos y procedimentales básicos de seguridad para proteger el entorno 3DS.
  • Parte 2. Requerimientos de seguridad 3DS: Requerimientos de seguridad para la protección de los datos y procesos 3DS.
A continuación, procedemos a comentar los requerimientos más destacados:

Parte 1. Requerimientos de seguridad base:
  1. Mantenimiento de políticas de seguridad para el personal:
    • La entidad debe generar y mantener actualizada una política de seguridad, que tenga en cuenta el tratamiento de los riesgos identificados. El personal debe leer y aceptar dichas políticas en su incorporación y como mínimo de manera anual.
    • Anualmente o ante cambios significativos, se deberán realizar análisis de riesgos sobre el entorno.
    • Deben realizarse formaciones de seguridad para el personal de manera periódica (periodicidad definida según la criticidad de cada usuario en el entorno), que cubran todos los aspectos contenidos en las políticas de seguridad y que deban ser tenidos en cuenta por los empleados.
    • Antes de la de la incorporación del personal en los procesos del entorno de cumplimiento PCI 3DS, deberán realizarse comprobaciones de antecedentes.
  2. Conectividad segura de red:
    • Debe restringirse el tráfico de entrada/salida del entorno PCI 3DS al mínimo imprescindible. Los sistemas del entorno deben segmentarse de manera adecuada de las redes externas, y deben generarse y mantenerse actualizados diagramas de red del entorno, dónde también se incluyan los flujos de datos.
    • Se debe monitorizar el tráfico del entorno, así como establecer procedimientos de respuesta y actuación en caso de que se detecte algún posible ataque de red.
  3. Desarrollo y mantenimiento de sistemas y aplicaciones:
    • En base a las mejores prácticas existentes en la industria se deben definir los procedimientos de desarrollo seguro de aplicaciones. Dichas prácticas de desarrollo seguro deben incluir técnicas para proteger las aplicaciones ante las vulnerabilidades típicas existentes.
    • Los programadores deben recibir formaciones de desarrollo seguro orientadas al lenguaje de programación que utilicen en el desarrollo de las aplicaciones del entorno PCI 3DS.
    • Deben mantenerse inventarios actualizados de todas las tecnologías implicadas en el entorno PCI 3DS, además de definirse (y aplicarse) guías de bastionado o configuración segura para todos los dispositivos implicados en dicho entorno.
    • Se deberán definir procedimientos de gestión de cambios en el entorno, los cuales incluyan revisiones de seguridad, procedimientos de autorización y aprobación de cambios, así como procedimientos de testeo, para verificar que la introducción de los cambios no supone una disminución de la seguridad del entorno.
  4. Gestión de vulnerabilidades:
    • Deben instalarse herramientas antimalware actualizadas en los sistemas y equipos involucrados en el entorno de cumplimiento PCI 3DS, para prevenir posibles ataques de malware, y para responder a ellos en caso de se lleven a cabo.
    • Deben llevarse a cabo escaneos trimestrales internos y externos en el entorno de cumplimiento. Los escaneos externos deben ser realizados por parte de una entidad homologada por el PCI SSC como PCI ASV.
    • Con periodicidad anual se deben llevar a cabo pruebas de penetración, así como definirse estrategias para solucionar las vulnerabilidades críticas identificadas en el plazo máximo de un mes.
  5. Gestión de accesos:
    • Los accesos al entorno de cumplimiento PCI 3DS deben requerir siempre una autenticación por parte de los usuarios, y deben asignarse siguiendo la regla de Need-to-know, en la que los empleados tengan solo los accesos mínimos imprescindibles para su trabajo diario. Además, deben establecerse procedimiento de autorización antes de asignar el acceso de un usuario al entorno de cumplimiento.
    • Deben asignarse ID’s únicas a todos los usuarios con acceso lógico al entorno de cumplimiento, evitándose así el uso de usuarios genéricos o compartidos.
  6. Seguridad física:
    • Deben establecerse procedimientos para garantizar la seguridad física de las instalaciones, sistemas y medios físicos que formen parte del entorno de cumplimiento, aunque el estándar no especifica las medidas de seguridad mínimas que deben ser aplicadas, si no que dependerá de cada entidad las medidas que considere oportunas para conseguir dicha protección óptima.
    • Deben implementarse procedimientos para gestionar de manera adecuada las visitas que se realicen al entorno de cumplimiento del estándar PCI 3DS.
  7. Preparación de respuesta a incidentes:
    • Deben establecerse procedimientos de actuación y respuesta en caso de identificación de incidentes de seguridad, que garanticen una respuesta adecuada por parte de todas las partes implicadas en dichos casos.
    • Además, deben almacenarse durante un año logs o registros de auditoría en las acciones llevadas a cabo por los usuarios en aplicativos y sistemas del entorno PCI 3DS.
Parte 2: Requerimientos de seguridad 3DS:
  1. Validación de entorno de cumplimiento:
    • Es necesario identificar y documentar los límites del entorno de cumplimiento PCI 3DS, especificando las medidas de segmentación necesarias para su separación de otras redes externas. Además, deben identificarse todas las redes y/o entidades conectadas a dicho entorno.
  2. Gobierno de seguridad:
    • Para asegurar que cada empleado es responsable de llevar a cabo las actividades periódicas, se deberán definir de manera clara los roles y responsabilidades en materia de seguridad de la información y gobierno corporativo de la entidad.
    • Además, deben definirse estrategias de gestión de riesgos para mitigar los riesgos identificados en el análisis anual realizado en el entorno de cumplimiento.
    • Deben establecerse procedimientos de gestión de proveedores o terceras partes adecuados, de manera que se identifique con antelación los requisitos de seguridad que es necesario solicitar a los mismos. Además, deben mantenerse acuerdos escritos con dichos proveedores, de manera que queden claras las responsabilidades de cada actor en los procedimientos de seguridad implementados en el entorno de cumplimiento PCI 3DS.
  3. Protección de sistemas y aplicaciones:
    • Se deben proteger los programas/aplicaciones del entorno de cumplimiento ante modificaciones no autorizadas.
    • Para verificar que se encuentran securizadas ante posibles ataques, se deben proteger y probar las API’s de acceso al entorno de cumplimiento.
    • Deben cifrarse todos los canales de comunicación web con protocolos HTTPS, estando prohibido el uso de HTTP para dicho uso.
    • También deben protegerse las interfaces de acceso público de la web ante los ataques más comunes existentes, como son ataques XSS, inyecciones de código o ataques CSRF.
  4. Protección de accesos lógicos:
    • Los accesos del entorno habilitados a los comercios deben restringirse con métodos de autenticación de doble factor, y debe revisarse la asignación de dichos accesos como mínimo de manera trimestral, para verificar que siguen siendo necesarios.
  5. Protección de datos:
    • Deben establecerse periodos de retención de datos en la entidad, que aseguren que la información sensible no será almacenada más tiempo del necesario.
    • Debe implementarse criptografía en todos los envíos de datos en el entorno de cumplimiento PCI 3DS, utilizando por ejemplo versiones actualizadas del protocolo TLS.
    • También debe implementarse criptografía robusta en todos los almacenamientos de datos sensibles del entorno.
  6. Criptografía y gestión de claves:
    • Deben implementarse unos adecuados procedimientos de generación y mantenimiento de claves de cifrado, que aseguren la seguridad de éstas en todo su ciclo de vida.
    • Todas las claves criptográficas utilizadas en la solución deben ser generadas en dispositivos HSM homologados o bien como FIPS 140-2 level3 o como PCI PTS HSM.
  7. Seguridad física:
    • El entorno físico que contenga datos sensibles de autenticación 3DS debe ser protegido mediante medidas de seguridad robustas, como son los controles de acceso electrónicos, las cabinas de acceso (mantrap doors), las barreras o tornos de acceso giratorios o los circuitos de cámaras de videovigilancia.


Autor: Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona

Cumplimiento PCI DSS, consejos básicos del PCI SSC para pequeños comercios


Recientemente, el PCI SSC ha publicado unas “píldoras” formativas, llamadas “Payment data security essentials”, para ayudar a los pequeños comercios online a cumplir con los requerimientos del estándar de seguridad PCI DSS. Dichas píldoras, indican recomendaciones o buenas prácticas de seguridad a cumplir, con los requerimientos que dicta dicho estándar. Además, van acompañadas de material adicional que complementa dichas formaciones, como son guías y videos adicionales explicativos.

En la fecha de elaboración de este artículo, el PCI SSC ha puesto a disposición del público las siguientes píldoras formativas:
Siendo algunas de las características más destacadas de las mismas las siguientes:

Contraseñas robustas
  • Deben generarse contraseñas aleatorias difíciles de deducir por parte de un posible atacante externo en todos los accesos lógicos al entorno de cumplimiento, que contengan al menos caracteres alfabéticos, caracteres especiales y dígitos numéricos. Además, dichas contraseñas no deben ser formadas por palabras comunes, que un atacante podría deducir con un ataque de diccionario.
  • Tanto el ID de los usuarios como las contraseñas de acceso al entorno PCI DSS deben ser únicas e intransferibles, y nunca deben compartirse con otras personas o terceras partes. Deben evitarse también las cuentas/contraseñas compartidas entre varios miembros de un mismo departamento en todos los accesos al entorno, ya san accesos administrativos o accesos a nivel de negocio.
  • Las contraseñas deben ser cambiadas como máximo cada 3 meses (90 días), o antes, si se tienen indicios de que éstas han podido ser comprometidas por parte de un atacante.
Securización de accesos remotos
  • El primer consejo para disminuir el riesgo de recibir un ataque remoto en un comercio es el de minimizar los canales o vías de entrada remotas al entorno. Por lo tanto, será necesario partir de un principio de Need-to-have, en el que solo se deberán habilitar los accesos remotos de los empleados o terceras partes que lo necesiten para el desarrollo de sus tareas diarias.

    Además, deberá revisarse de manera periódica que los accesos remotos habilitados en su día por una necesidad concreta siguen siendo necesarios, de manera que se verifique que la justificación que se dio en su día para la tramitación de dichos accesos sigue siendo vigente. En caso de que se identifique en una de estas revisiones que alguno de estos accesos ha dejado de ser necesario, dicho acceso deberá darse de baja con la mayor celeridad posible.
  • Deben habilitarse credenciales únicas de autenticación en todos los accesos remotos al entorno PCI DSS, tanto los realizados por personal interno como los realizados por terceras partes. Esto incluye tanto ID’s de usuarios como contraseñas de acceso.
  • Por último, hay que tener en cuenta que todos los accesos remotos al entorno PCI DSS deberán realizarse mediante una autenticación de múltiple factor, en la que, típicamente, el usuario se autentique con una contraseña y un factor externo asociado a un dispositivo individual poseído por el usuario, como por ejemplo una tarjeta de coordenadas, un token criptográfico o un SMS recibido en su teléfono móvil, entre otros.
Instalación de parches de seguridad
  • El aspecto más importante a considerar por parte de los comercios para implementar una política correcta de gestión de parches de seguridad en la entidad es la necesidad de identificar las responsabilidades de los proveedores de mantenimiento de tecnologías/aplicaciones en este aspecto, de manera que quede claramente definido quien es el responsable de dicha instalación de parches. Es importante no olvidar los entornos de hosting web en ecommerce, que también deben estar sujetos a una correcta política de gestión de parches por parte de las compañías que hospedan dichas webs.

    En caso de duda sobre las preguntas concretas que deben realizarse a nuestros proveedores de servicio para identificar sus responsabilidades en estos y otros aspectos de seguridad, puede seguirse el cuestionario de evaluación para comercios emitido por el PCI SSC para este fin.
  • Una vez claras las responsabilidades en este sentido, es necesario que los parches críticos de seguridad se instalen en un plazo máximo de un mes des de su emisión. Para otros parches no tan críticos, deberá evaluarse el riesgo tanto por parte de los administradores del entorno como por parte de los responsables de la entidad, para definir la fecha óptima de instalación de los mismos.

Autor: Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona

Internet Security Auditors miembro de grupo de Asesores Ejecutivos Global del PCI SSC


El PCI SSC lanzó hace unos meses una nueva iniciativa para contar con un grupo de expertos a nivel global de empresas abriendo la presentación de candidaturas a todas las empresas que participan como asesores en todo el mundo, que superan las 450. Internet Security Auditors presentó la candidatura con la representación su Director de Consultoría y socio, Miguel A. Domínguez.

Tras dos meses de revisión de las candidaturas, que debían cumplir con amplios requerimientos a nivel de compañía y representante, el PCI SSC confirmó que la nuestra había sido seleccionada para formar parte de un exclusivo grupo de 20 empresas a nivel mundial.

El grupo de Asesores Ejecutivos del PCI SSC pretende servir los próximos dos años como un canal directo para la comunicación entre el liderazgo superior de los asesores de seguridad de pagos y el liderazgo senior de PCI SSC.

Los asesores serán responsables de proporcionar asesoramiento, comentarios y orientación al PCI SSC; proporcionar aportes tanto abiertos como expertos tanto desde el punto de vista comercial como técnico; representar los puntos de vista e intereses del evaluador PCI y las comunidades evaluadas; y estar disponible y dispuesto a participar en proyectos especiales PCI SSC.

Este es un importante hito para Internet Security Auditors porqué nos sitúa con la responsabilidad de ser la única empresa de origen iberoamericana, con el interés de representar a países que representan a más de 800 millones de habitantes, y que nos permitirá aportar la experiencia de la compañía en países que el PCI SSC considera claves en sus iniciativas de la seguridad de los Medios de Pago además de situar a la compañía entre el Top20 de empresas del mundo PCI.