Analytics

jueves, 27 de septiembre de 2018

Gestión del Cambio Significativo PCI DSS v3.2

Para todo el que se haya visto involucrado o haya tenido que trabajar con el estándar PCI DSS y, especialmente, aquellos que hayan tenido que “sufrir” su implantación y mantenimiento en cualquier de sus alcances, sabrán que dicho estándar deja bastantes ambigüedades y conceptos de los que no termina del todo de definir con exactitud. Esta posición es entendible si tenemos en mente la gran variedad de tipos de entornos, tecnologías y necesidades de negocio que nos podemos encontrar en la vida real que traten datos de tarjetas de pago.

Para mitigar este hecho, el SSC viene publicando con cada versión del estándar, un documento (aquí su enlace en su última versión) a modo de glosario, en el cual recopila diversos conceptos, términos, abreviaciones y acrónimos. Uno de estos términos, y sobre el que trata este artículo, es el Cambio Significativo, con la particularidad de que este concepto no viene recogido ni detallado en el glosario anteriormente mencionado.

Si recopilamos y extraemos del propio estándar todas las menciones que se hacen a cambio significativo, nos encontramos con:
  • En el requisito 11.2.3, se hace referencia a este término como “la determinación de qué constituye un cambio significativo depende totalmente de la configuración de cada entorno.”
  • En el requisito 12.2, sin embargo, pone el ejemplo de “adquisiciones, fusiones o reubicaciones, etc.” relacionado con los componentes del entorno.
  • Por último, en el requisito 11.2 se expone el ejemplo de “la instalación de nuevos componentes del sistema, cambios en la topología de la red, modificaciones en las reglas de firewall, actualizaciones de productos”.
Como se puede observar, es imposible extraer una definición clara y concisa de este término. En cambio, si se puede extraer claramente las implicaciones que conlleva considerar un cambio como “cambio significativo”, y dichas implicaciones suponen en la mayoría de los casos un gran esfuerzo económico y dedicación de personal. Las implicaciones y los requisitos que comúnmente se llegan a aplicar se resumen en:
  • Documentar dicho cambio, aplicar todos los requisitos del estándar y actualizar los documentos correspondientes (Req. 6.4.6)
  • Análisis de vulnerabilidades externo e interno (Req. 11.2)
  • Test de intrusión interno y externo (Req. 11.3)
  • Análisis de Riesgos (Req. 12.2)
Partiendo de esta base y si se analiza desde un enfoque práctico, ejemplos de dichos cambios significativos pueden ser:
  • Cambios de reglas de firewall/router en accesos públicos
  • Cambios sobre los controles de segmentación
  • Cambios de infraestructura, nuevos equipos, nuevo software o protocolos
  • Cambios sobre la aplicación de pago o servicios
  • Nuevos proveedores de servicios o cambio en el servicio de proveedores (intercambio de datos)
Las reglas de firewall son uno de los puntos más críticos, y debe tenerse en cuenta si se están abriendo nuevas interfaces externas o se están poniendo zonas adicionales, o el cambio de reglas implica un cambio de varias reglas de manera simultánea que puedan afectar de algún modo la segmentación. En estos casos es muy probable que se considere como un cambio significativo. Por otro lado, si el cambio es porque a un servidor se le cambió la dirección IP o porque se cambió el puerto por el que se maneja un servicio, en esos casos debe ser estudiando con detalle, para evaluar el riesgo y comprobar si efectivamente estamos ante un cambio significativo o no.

Sobre las nuevas versiones que sean desplegadas de las aplicaciones de pago, típicamente se consideran como cambio significativo, pero su actuación sería parcial, es decir, el análisis de riesgos se debería ejecutar solo en caso de que se activen nuevos servicios, pero el análisis de vulnerabilidades si debería ejecutarse en este caso. Nunca hay que olvidar que todo cambio independiente de si es más o menos crítico debe documentarse, tal y como se especifica en el requisito 6.4.6.

Para finalizar, es necesario enfatizar que la organización tiene la responsabilidad de tratar, a través de los criterios definidos en el documento relativos al procedimiento interno de gestión de cambios, el hecho de clasificar el cambio como significativo o no. Por otro lado, esta acción será objeto de revisión durante una auditoría, en la que un QSA comprobará a través de las evidencias correspondientes, que se han aplicado los criterios correctos acorde al estándar.

Autor: Alberto Villar - CISSP, PCI QSA
Dpto. de Consultoría

miércoles, 19 de septiembre de 2018

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

lunes, 17 de septiembre de 2018

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.

lunes, 10 de septiembre de 2018

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

viernes, 7 de septiembre de 2018

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

martes, 4 de septiembre de 2018

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