Por qué la SIC sanciona a empresas por incumplimiento de la Protección de Datos

Durante el año pasado, una ferviente inquietud se extendió en Colombia por la proximidad en la fecha límite para la inscripción de bases de datos de carácter personal en el Registro Nacional de Bases de Datos (RNDB) de la SIC.

La mayoría de empresas llevaron a cabo esta labor bajo una interpretación de la consecuencia de no hacerlo: si no registramos nuestras BBDD la SIC verá que no lo hemos hecho y nos inspeccionará.
La realidad no parece ser esta dado que las sanciones siguen produciéndose ante denuncias de ciudadanos y no como resultado de inspecciones de oficio. Es decir, el registro en el RNDB no parece ser una buena razón para creerse fuera de “peligro” para ser sancionado.

Analizando las sanciones del año 2016 y 2017 vemos que entre las que están en trámite o en firme tenemos catorce en el año 2016 y seis en lo que va del año 2017. Estas sanciones recayeron en dieciséis empresas y dos personas naturales expedientadas, es decir, algunas de esas sanciones fueron sobre la misma empresa.

De los dieciocho multados, nueve habían inscrito bases de datos en el RBND (esto no quiere decir que lo hicieran correctamente, pero ya lo comentaremos más adelante). Si descontamos que es más extraño las personas naturales que las declaren e incluso que sea normal que puedan tener bases de datos, siete empresas no habrían declarado sus bases de datos. Pero entonces la cuestión que se estarán haciendo es ¿y por qué fueron sancionadas esas siete empresas que tan diligentemente habían declarado sus bases de datos? Pues veámoslo.

Intentando centrarnos en el incumplimiento que desembocan en las sanciones, debemos prestar atención a cuatro artículos de la Ley 1581/2012 y a uno del Decreto 1074 de 2015 según se muestra en el gráfico siguiente:
Algo que merece especial atención y resulta, cuanto menos, curioso es que, tras cometer alguno de los errores o violaciones en el cumplimiento, quedando éste demostrado, sólo en dos casos de sentencias en firme, el sancionado reconoció la infracción, hecho que implicó la reducción de la sanción en un 25%. En ninguno de los otros se buscó una atenuación de la sanción reconociendo el error.

Para tener una idea de qué han implicado las diferentes sanciones en cantidades dinerarias, el volumen de estas (en SMLMV) el año 2016 ($689.455/SMLMV) sumó un total de 3.775 SMLMV ($2.602.692.625) y una media por sanción de 270 SMLMV aproximadamente, aunque hay que tener presente que las sanciones a personas físicas fueron las menores por lo que, eliminando estas, la media de sanciones a personas jurídicas fue de 340 SMLMV ($234.414.700) aproximadamente; en lo que llevamos de año 2017 ($737.717/SMLMV) suma ya 1.222 SMLMV ($901.490.174) con una media de 135 SMLMV aproximadamente ($100.165.575), con lo que la media de sanciones a razones sociales estos últimos 18 meses ha sido de unos 250 SMLMV ($183.212.017 en SMLMV del 2017). El detalle de la cantidad de las sanciones es el que la siguiente gráfica:

A parte de esto, comentábamos que el declarar bases de datos no quiere decir que esto lo estemos haciendo correctamente, la efervescencia tiene un problema, es llamativa, pero de corta duración, y eso es lo que a veces sucede cuando nos estresamos en ejecutar una tarea sin un estudio adecuado. De las siete empresas que comentábamos que habían declarado sus BBDD, claramente, algunas se han dejado llevar por esa efervescencia: algunas de ellas no tiene registrada ninguna base de datos de empleados por lo que, lógicamente, salta a la vista que ninguna empresa podrá funcionar sin ellos, y no podrá realizar procesos propios de cualquier empresa sin disponer de los datos personales de éstos, por lo tanto su registro de BBDD es claramente defectuoso; alguna otra tiene decenas de bases de datos, claramente asociadas a aplicaciones, no a usos, esto quiere decir que si cambiamos de la aplicación A a la B para gestionar un conjunto de datos personales, deberemos rehacer el trabajo de gestión de las BBDD; incluso, una de las sanciones, es un claro ejemplo de cómo no puede tratarse el cumplimiento de Protección de Datos como un mero asunto legal dado que el grave problema que desembocó en sanción fue debido a una deficiente implementación de medidas técnicas para la protección de la información que derivó en una publicación -cuya magnitud real pudo no haber sido identificada correctamente en el proceso investigativo- en Internet, etc.

Defectos de este tipo suelen estar asociados a no realizar un análisis previo adecuado sobre los repositorios de los datos personales de los que dispone la compañía a fin de definir las bases de datos a declarar de la forma más adecuada, no sólo para un registro, si no para el mantenimiento de la declaración y publicación de estas con una estrategia a largo plazo.

Las conclusiones que podemos extraer de este breve análisis sobre las sanciones (teniendo en cuenta que algunas de ellas todavía están en trámite y podrían sufrir cambios, incluso anularse a favor del demandado, aunque esto no resultaría muy esperable tras la revisión de todas ellas) son que:
  1. La declaración de Bases de Datos no es razón eximente en ninguna de las sanciones firmes o en trámite.
  2. Que la mayoría de sanciones se producen por el envío indiscriminado de comunicaciones comerciales, de forma abrumadora, en un período de tiempo prolongado.
  3. Que, en los casos anteriores, cuando los clientes ejercen sus derechos, las empresas no tiene realmente implantados procesos integrales de respuesta: en algunos casos se atienden las peticiones, se da respuesta tarde o de forma incorrecta, incluso se responde como si se hubiera tramitado pero los procesos internos, al ser incompletos demuestran que el trámite no ha sido realmente llevado a cabo.
  4. Que las empresas no disponían de las políticas de seguridad realmente implementadas y que los controles de seguridad y de protección de la información no eran adecuados.
  5. Que las personas encargadas de mantener la comunicación con los clientes no tienen la capacitación necesaria sobre qué se puede y no se puede hacer con la información personal, cual no debe transmitirse de forma pública o qué medios deben emplearse.
  6. Que las autorizaciones en los procesos de obtención de información (importante cuando esta se utilizara para comunicaciones publicitarias) no se custodian, requieren o notifican a los clientes de forma adecuada sobre el uso de esa información.
Claro está, no todos los errores anteriores se producen en todas las ocasiones. En algunos casos sólo se da uno de ellos, en otros, algunos más. Todo ello muestra que la implementación correcta de los requerimientos exigidos por la Ley 1581/2012, los reglamentos y otras regulaciones relacionadas, necesitan desarrollarse mediante un proceso global, holístico en toda la compañía que aborda un proyecto de este tipo, capacitando a su personal, a todo el que pueda llegar a estar involucrado en el manejo de datos personales, y, además, tener presente que ni la Ley es un asunto puramente de las áreas legales, ni lo es de seguridad de la información.

Revisando los importes medios de las sanciones de este último año y medio, podríamos hacer un ejercicio sencillo y es pensar si realmente no se podría haber realizado un proceso de adecuación y cumplimiento robusto por, digamos, el 50% de lo que supuso la media de sanción a las compañías afectadas, sin tener en cuenta el costo del proceso legal cuando éste puede extender más allá de año. Posiblemente, la respuesta sea en muchos casos afirmativa.


Autor: Daniel Fernández Bleda - CISSP, CISM, CISA, ISO 27001 LA, CHFI, OPST/A
Global Sales Manager, Internet Security Auditors

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

El próximo 30 de Agosto en colaboración con la Asociación Colombiana de Empresas de Contact Centers y BPO se realizará en Bogotá un ciclo de conferencias sobre Ciberseguridad enfocadas principalmente a concienciación de la norma PCI DSS y Ley de Protección de Datos abordando temas como:
  • Protección de Datos y metodologías de implementación de la Ley 1581/2012.
  • PCI DSS, justificación de cumplimiento de la normativa.
  • Problemáticas particulares de cumplimiento de PCI DSS en CC&BPO.
  • Transferencia internacional de datos y cumplimiento de PCI DSS con proveedores Cloud.
En las conferencias participarán nuestros ponentes expertos Daniel Fernández, David A. González y Javier R. Amaya, además de nuestros partners legales de Summa-Consultores, Esteban Jaramillo y Laura Bernal, y como objetivo realizar presentaciones de alto contenido formativo sobre temáticas particulares del sector de CC&BPO en cuanto al cumplimiento de la legislación en Protección de Datos y PCI DSS.

La ACDECC&BPO es la única entidad dedicada exclusivamente al desarrollo de la Industria de BPO y de las empresas asociadas a su cadena de valor en Colombia como: Proveedores de tecnología, proveedores de conocimiento y proveedores de infraestructura, CSC, entre otros y agrupa a más de 50 empresas, siendo el principal referente de la industria a nivel nacional e internacional con la organización del encuentro sectorial más importante en Latinoamérica del sector.

El evento estará abierto a todos los interesados y el registro deberá realizarse a través de la ACDECC&BPO, contando con un aforo limitado a 100 personas, y tendrá lugar en el auditorio del Edificio ADVANCE en la dirección Calle 99 # 7A-77.

Esperamos sea de total éxito, una jornada completamente productiva y llena de grandes proyecciones en Seguridad de Sistemas de Información.

Más informacion y contenido:
https://gallery.mailchimp.com/224eb707621d0bf4e0960cab4/files/7c46d4f1-3082-48ee-b6d9-29b6fdd7148a/brochure_security_2.compressed.pdf

Nueva versión Tinfoleak 2.1 "SHA2017 Edition"

Las redes sociales son una fuente de información imprescindible en procesos de análisis e investigación con distintos propósitos. Entre estas redes, Twitter destaca por la actividad de sus usuarios dada la facilidad de uso y su simplicidad.

Con idea de disponer de una herramienta SOCMINT (Social Media Intelligence) que permita automatizar la extracción de información en Twitter y facilitar el análisis posterior para la generación de inteligencia, Vicente Aguilera Díaz ha desarrollado la herramienta Tinfoleak.

En esta versión 2.1 "SHA2017 Edition", se han incorporado cuatro nuevas funcionalidades:
  • Análisis basado en el timeline global
  • Análisis de followers y friends
  • Análisis de frecuencia de palabras
  • Análisis de likes
También hay cambios “menores”, principalmente:
  • Ligeros cambios en aspectos estéticos del reporte HTML
  • Corrección de bugs


 Tinfoleak v2.0
Información básica sobre el usuario:
  • Imagen del perfil.
  • Fecha de creación de la cuenta.
  • Estado de verificación de la cuenta.
  • Nombre en Twitter.
  • Nombre completo de usuario.
  • Descripción de la cuenta.
  • ID de Twitter.
  • Número de seguidores.
  • Número de usuarios a los que sigue.
  • Número de tweets enviados y promedio de tweets por día.
  • Número de likes.
  • Número de listas.
  • URL extendida.
  • Característica de geolocalización.
  • Ubicación.
  • Zona horaria.
  • Idioma.

Aplicaciones utilizadas por el usuario:
  • Aplicaciones utilizadas por el usuario para publicar tweets.
  • Número de tweets publicados por el usuario desde cada una de las aplicaciones.
  • Porcentaje de uso de cada aplicación respecto el total de aplicaciones.
  • Fecha del primer uso de la aplicación.
  • Primer tweet publicado con cada aplicación.
  • Fecha del último uso de la aplicación.
  • Último tweet publicado con cada aplicación.
  • Número total de aplicaciones identificadas.


Análisis de hahstags:
  • Hashtags utilizados, fecha, hora, número de retweets, número de likes, usuario que publica el hashtag, imagen de perfil del usuario que publica el hashtag, ubicación del usuario que publica el hashtag y consulta de los tweets publicados por el usuario conteniendo hashtags.
  • Para cada hashtag utilizado por el usuario, se muestra el periodo de tiempo en el que fue publicado, el número de retweets, el número de likes, y el número de veces que fue utilizado.
  • Identificación de los diez hashtags más utilizados, incluyendo periodo de tiempo en el que fue publicado, número de retweets, número de likes, y consulta de hashtag.
  • Número de hashtags identificados.
 

Análisis de menciones de usuario:
  • Menciones de usuario, fecha, hora, número de retweets, número de likes, usuario que publica las menciones, imagen del perfil del usuario que publica las menciones, ubicación del usuario que publica las menciones y consulta de los tweets publicados por el usuario conteniendo menciones de usuario.
  • Para cada usuario mencionado, se muestra el periodo de tiempo en el que fue mencionado, el número de retweets, el número de likes, y el número de veces que fue utilizado.
  • Identificación de los diez usuarios más mencionados, incluyendo periodo de tiempo en el que fue mencionado, número de retweets, número de likes, nombre del usuario y consulta del usuario mencionado.
  • Número de menciones identificadas.

 

Análisis de LIKES:
  • Tweets marcados como “like”, incluyendo fecha y hora de la publicación del tweet, usuario que lo publica e imagen del perfil de dicho usuario, contenido multimedia publicado, texto y consulta de cada tweet.

Análisis del contenido de Tweets:
  • Se muestran los tweets publicados por el usuario que cumplen el filtro especificado (búsqueda por palabras clave, retweets y contenido multimedia).
  • Para cada tweet, se muestra la fecha, hora, el usuario que publica el tweet, la imagen del perfil del usuario, el nombre del usuario, la ubicación del usuario, texto y el contenido del tweet.
  • Número de tweets identificados.

Análisis de Metadatos:
  • Se muestran metadatos asociados a las fotografías del perfil, o de las imágenes publicadas por los usuarios.

Análisis de contenido multimedia:
  • Se muestran las imágenes y videos publicados por el usuario, junto a la fecha y hora de su publicación, la aplicación utilizada, el usuario a quien se ofrece respuesta (si la hubiera), el número de retweets y likes, así como la consulta del tweet donde se publica el contenido multimedia asociado.
  • Número de imágenes y videos publicados por el usuario.
  • Descarga de todo el contenido multimedia publicado por el usuario.

Análisis de la geolocalización de un usuario:
  • Fecha y hora de la publicación del tweet.
  • Coordenadas y localización desde las que se publicó el tweet.
  • Información sobre el contenido multimedia (fotografía o video) contenido en el tweet.
  • Acceso al tweet geolocalizable.
  • Aplicación utilizada para la publicación del tweet.
  • Consulta de ubicación asociada a las coordenadas desde las que se publicó el tweet.
  • Ruta seguida por el usuario (incluyendo periodo de tiempo en el que permanece en cada ubicación, y número de tweets que envía desde cada una de ellas).
  • Localizaciones más visitadas por el usuario, incluyendo periodo de tiempo desde el que publica tweets desde cada localización, número de tweets que envía, días de la semana en los que ha publicado tweets desde cada localización, día de la semana que más publicaciones ha realizado, coordenadas de cada localización y nombre de la ubicación.
  • Generación de fichero de salida en formato KML para ser importado desde Google Earth, mostrando los tweets y el contenido multimedia publicado desde cada ubicación.
 

Análisis basado en coordenadas geográficas
  • Identificación de tweets publicados en el área geográfica especificada. Posibilidad de filtrar resultados que cumplen el filtro especificado (búsqueda por palabras clave, retweets y contenido multimedia).
  • Fecha, hora, coordenadas geográficas, contenido multimedia publicado, y aplicación utilizada en la publicación de cada tweet, así como el usuario geolocalizado y consulta del tweet asociado.
  • Identificación de usuarios geolocalizados, incluyendo fotografía del usuario, su identificador en Twitter, así como sus identidades digitales en Instagram, Foursquare y Facebook.
  • Identificación de usuarios etiquetados en el área geográfica especificada. Se incluye el usuario etiquetado, el usuario que lo ha etiquetado, la fecha y hora de publicación del tweet, la fotografía en la que se ha etiquetado al usuario, y las coordenadas geográficas donde se publicó el tweet.
  • Análisis de contenido multimedia publicado en el área geográfica especificada.
  • Análisis de hashtags y menciones realizadas en el área geográfica especificada.
 
 


Análisis basado en el timeline global
  • Identificación de tweets publicados en el timeline global (no asociado a un usuario en particular) y con posibilidad de filtrar resultados que cumplen el filtro especificado
    (búsqueda por palabras clave, retweets y contenido multimedia).
  • Fecha, hora, consulta de tweet publicado, contenido multimedia, aplicación utilizada, así como la imagen de perfil del usuario y su identificador en Twitter.
  • Número de tweets identificados.

Análisis de conversaciones entre usuarios
  • Se muestran las conversaciones que ha mantenido el usuario especificado con el resto de usuarios.
  • Los tweets se agrupan por conversación y se muestran ordenados en base al tiempo, mostrando una apariencia de chat.
  • Las conversaciones pueden ser filtradas en base a usuarios, fechas, o palabras clave.
  • Se muestra el número de conversaciones y el número de mensajes por conversación.

Análisis de Followers:
  • Se genera un fichero CSV con información detallada
    sobre los followers del usuario especificado.
  • Para cada follower, se muestra su identificador de Twitter, nombre de usuario, descripción, URL de la imagen del perfil, URL de la imagen de background, fecha de alta del usuario,
    localización, zona horaria, estado de la geolocalización, número de followers, número de friends, número de likes, número de listas en las que se ha incluido, estado de la verificación de la cuenta e idioma configurado.
  • Posibilidad de limitar los resultados al número de followers especificado.
  • Descarga de la imagen del perfil de cada follower.
 


Análisis de Friends:
  • Se genera un fichero CSV con información detallada sobre los friends del usuario especificado.
  • Para cada friend, se muestra su identificador de Twitter, nombre de usuario, descripción, URL de la imagen del perfil, URL de la imagen de background, fecha de alta del usuario, localización, zona horaria, estado de la geolocalización, número de followers, número de friends, número de likes, número de listas en las que se ha incluido, estado de la verificación de la cuenta e idioma configurado.
  • Posibilidad de limitar los resultados al número de friends especificado.
  • Descarga de la imagen del perfil de cada friend.
 


Análisis de frecuencia de palabras:
  • A partir del timeline de un usuario, o un timeline global, se identifican las palabras que aparecen en cada tweet y se analiza el número de palabras más frecuentes que haya definido el usuario.
  • En el análisis, se descartan menciones de usuario y hashtags, así como “palabras vacías” en inglés y español.
  • Se muestra cada una de las palabras más frecuentes, junto al número de ocurrencias, el porcentaje de ocurrencias, así como la fecha de la primera y última ocurrencia de cada palabra.



Análisis de Identidades Digitales
  • Identificación de la presencia del usuario en otras redes sociales
  • Se muestra la red social en la que se ha identificado al usuario, el identificador en dicha red, nombre y fotografía que utiliza en cada red social, así como información adicional.
  • Se analiza la presencia del usuario en las siguientes redes sociales:
  • Twitter, Instagram, Foursquare, Facebook, LinkedIn, Runkeeper, Flickr, Vine, Periscope, Kindle, Youtube, Google+ y Frontback.



 Autor: Vicente Aguilera - CISA, CISSP, CSSLP, ITILF, PCI ASV, CEH, ECSP, OPST/A OWASP Spain Chapter Leader
Director Departamento de Auditoría.

Programa de seguridad CSP (SWIFT)

Recientemente, la Sociedad para las Comunicaciones Interbancarias y Financieras Mundiales (SWIFT) ha sacado a la luz el programa de seguridad CSP (Customer Security Programme). Este programa es de obligado cumplimiento para todas las entidades financieras que forman parte de dicha organización, y su cumplimiento debe ser reportado de manera formal desde este mismo año. A lo largo de este artículo veremos el origen de dicho programa de seguridad, así como las características más destacadas del mismo.

Orígenes

Fundada en Bruselas en el año 1973, SWIFT (del inglés: Society for Worldwide Interbank Financial Telecommunication, es decir, la Sociedad para las Comunicaciones Interbancarias y Financieras Mundiales), es una organización cooperativa dedicada al fomento y al desarrollo de métodos de interacción globales y estandarizados para las transacciones financieras entre entidades bancarias. Es decir, que el objetivo de dicha organización es el de establecer una red global de comunicaciones para el procesado de datos bancarios, así como un lenguaje común para la realización de dichas transacciones.

Actualmente, SIWFT opera una red internacional de comunicaciones formada por más de 11000 entidades financieras, que a su vez son distribuidas en más de 200 países en todo el mundo.

Con el objetivo de mejorar la seguridad en toda la red de comunicaciones SWIFT, dicha organización inició en mayo de 2016 el programa de seguridad CSP (Customer Security Programme), de obligado cumplimiento por todas las entidades financieras que forman parte de la misma.

En los siguientes meses, se definió la hoja de ruta para el cumplimiento de dicho programa de seguridad, que establece los siguientes hitos:
  • A partir del segundo trimestre de 2017, todas las entidades financieras que forman parte de la red SWIFT deben reportar a la organización informes de validación que demuestren el cumplimiento de dicho programa, resultantes de evaluaciones de seguridad llevadas a cabo de manera interna, o de manera opcional, a través de entidades de auditoría externas. Dichos reportes deben renovarse (y reportarse) de manera anual, a partir de esta fecha inicial de validación.
  • En enero de 2018, todas las entidades financieras deberán haber reportado su cumplimiento con el CSP. Además, la organización SWIFT, seleccionará al azar algunas entidades financieras que formen parte de su red de comunicaciones, para que reporten con más detalle el resultado de las auditorías internas/externas llevadas a cabo para verificar su adecuación con el programa CSP.
Características destacadas
El programa de seguridad CSP establece 27 controles de seguridad, de los cuales 16 son de obligada aplicación por todas las entidades que forman parte de la red de comunicaciones SWFT. Los 11 controles restantes son de carácter opcional.

Dichos controles están agrupados en 8 principios, que a su vez están clasificados en 3 niveles, como puede observarse en la Figura [2].

Figura [2]

Además, el programa de seguridad CSP establece 2 tipos de arquitectura para las entidades financieras que forman parte de su red de comunicaciones:
  • Arquitectura A: Parte o la totalidad de la infraestructura SWIFT utilizada en la entidad forma parte del entorno de la entidad financiera.
  • Arquitectura B: Toda la infraestructura SWIFT utilizada en la entidad es externalizada a proveedores externos, de manera que el entorno de la entidad financiera no incluye en ningún caso parte o la totalidad del entorno SWIFT.
Dicha diferenciación en los tipos de arquitectura es importante, ya que algunos que los 27 controles de seguridad del CSP no aplican a las entidades que dispongan de una arquitectura correspondiente al escenario B.

En la Figura [3], puede observarse una tabla resumen con los 27 controles del programa de seguridad CSP, en la que se diferencian los controles obligatorios y los controles opcionales, y se muestra su aplicabilidad en las 2 posibles arquitecturas anteriormente comentadas.
Figura [3]
A continuación, se describen de manera general los aspectos más destacados de los principios de seguridad del programa CSP:
  1. Restricción de accesos desde internet: Debe limitarse el acceso desde redes públicas a la infraestructura SWIFT al mínimo imprescindible. Para ello, solo se aceptará en el entorno SWIFT tráfico proveniente de conexiones establecidas previamente desde el propio entorno SWIFT (conexiones de salida), nunca conexiones de entrada. Además, las URL’s con las que el entorno SWIFT pueda establecer comunicaciones deberán ser restringidas mediante la aplicación de listas blancas.
  2. Segregación del entorno SWIFT: Debe definirse una zona segura para el hospedaje de los elementos que formarán parte de la infraestructura SWIFT. Dicha zona debe ser segmentada del resto de elementos de la infraestructura de IT de la entidad financiera, mediante firewalls a nivel de red (como mínimo).

    Además, deben restringirse de manera adecuada los accesos a dicha zona segura, mediante una correcta gestión de las ACL de los elementos de filtrado, así como con unos adecuados controles de acceso, con los mecanismos de autenticación situados dentro de la zona segura.

    Por último, los accesos administrativos a los distintos elementos que forman el entorno SWIFT deben ser altamente controlados y monitorizados, permitiendo solo a los usuarios estrictamente necesarios el acceso a la realización de cambios de configuración en dichos elementos.
  3. Reducción de la superficie de ataque y las vulnerabilidades en el entorno: Dicho principio indica, en primer lugar, que todos los flujos de datos realizados entre los usuarios de la entidad financiera y el entorno SWIFT deben realizarse mediante canales que garanticen la Confidencialidad, la Integridad y la correcta Autenticación de dichas comunicaciones (por ejemplo, mediante canales VPN, SSH o similares).

    Además, dicho principio también incluye la necesidad de implementar una correcta gestión de vulnerabilidades y parches de seguridad en el entorno SWIFT, de manera que los parches críticos sean instalados como muy tarde un mes después de su fecha de lanzamiento.

    También se establece que, de manera opcional, las entidades financieras pueden ejecutar escaneos de vulnerabilidad anualmente, así como definir unos SLA’s adecuados con los proveedores de servicio a los cuales se hayan externalizados funciones críticas del propio entorno SWIFT.

    Por último, se establece que todas las tecnologías que forman parte del entorno SWIFT deben ser bastionadas siguiendo las mejoras prácticas de la industria, a través de guías de bastionado reconocidas, como son las de los organismos CIS, SANS o NIST.
  4. Securización física del entorno: En dicho principio se establecen las pautas para lograr una correcta securización del entorno físico de SWIFT. Entre otros, se establece que los dispositivos removibles del entorno (por ejemplo, dispositivos PED (Pin Entry Device), cintas de backup, etc.) deben estar sujetos a un correcto control y monitorización por parte de los empleados responsables de su custodia.

    Además, también se establece que las salas que contengan los servidores y los equipos de red que forman parte de la infraestructura SWIFT, deben estar sujetas a controles de acceso adecuados, como controles biométricos o tarjetas inteligentes identificativas, para restringir que solo los empleados con necesidades de negocio para tal efecto puedan acceder a las mismas.
  5. Prevención de robo de credenciales: Para evitar el robo de credenciales de autenticación en el entorno SWIFT, se debe establecer una política de contraseñas adecuada en todos los elementos de dicho entorno, teniendo en cuenta aspectos como la complejidad de las contraseñas, su longitud, su caducidad, etc.

    Además, y de manera obligatoria, deben definirse mecanismos de autenticación Multi-Factor en todos los accesos a los elementos del entorno SWIFT.
  6. Gestión de identidades y privilegios: Se deben gestionar de manera adecuada los accesos al entorno SWIFT, teniendo en cuenta los principios de la necesidad de conocer (Need-To-Know), la asignación de privilegios mínima (least privilege) y la segregación de funciones (segregation of duties).

    Además, deben gestionarse de manera adecuada los procesos de alta/baja de usuarios, así como los procesos de asignación de tokens físicos a los usuarios relacionados con el entorno SWIFT.
  7. Detección de actividades anómalas en sistemas o transacciones: Dicho principio indica que debe implementarse software antimalware en todos los elementos del entorno SWIFT, para identificar posibles amenazas de seguridad en dichos elementos.

    También debe implementarse software de monitorización de integridad de ficheros (software FIM o File Integrity Monitoring), para monitorizar los cambios en los ficheros críticos del entorno.

    Además, deben monitorizarse los logs o registros de auditoría de los distintos elementos del entorno SWIFT, para lograr una identificación temprana de los eventos no deseados llevados a cabo en el entorno.

    De forma opcional, dicho principio también ofrece la opción de implementar tecnologías de detección/prevención de intrusiones (IDS/IPS) en el entorno SWIFT, de manera que se monitorice la actividad de los usuarios a nivel de red.
  8. Planificación de respuesta a incidentes de seguridad: El último principio de seguridad indica la necesidad de que las entidades financieras dispongan de un plan de respuesta a incidentes de seguridad disponible y actualizado, de manera que los procesos de actuación en estos casos sean lo más ágiles posibles, y cada persona tenga claras sus obligaciones y responsabilidades al respeto.

    Además, dicho principio también indica la necesidad de que todos los usuarios relacionados con el entorno SWIFT reciban formaciones de seguridad con una periodicidad como mínimo anual, así como en el momento de su incorporación al entorno.

    Por último, se ofrece de manera opcional la posibilidad de que la entidad realice Tests de Penetración anuales en el entorno, así como la realización de análisis de gestión de riesgos con una periodicidad también anual.
Mapeo con otros estándares
Para acabar, es importante destacar que para incrementar la convivencia entre el programa de seguridad CSP y otros estándares de seguridad disponibles en la industria, el SWIFT ha realizado un mapeo entre el CSP y los estándares PCI DSS v3.2, ISO 27002:2013 y NIST Cybersecurity Framework v1.0, que puede ser consultado en la Figura [4].

Figura [4]

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

Skimming: en qué consiste esta práctica delincuencial y cómo protegerse


El skimming es una práctica ilegal orientada hacia la captura no autorizada de los datos confidenciales contenidos en el plástico de una tarjeta de pago (banda magnética y/o contactless) con el fin de ser empleados para fines fraudulentos (clonación, uso en transacciones no presenciales, etc.).

Desde el origen de las tarjetas con banda magnética, éste ha sido uno de los principales problemas de seguridad a los que se enfrentan los adquirientes, los comercios y los propios usuarios. En este punto, es importante tener presente que los datos de la banda magnética se encuentran grabados en el plástico en texto claro y que no se cuenta con ningún método de protección asociado, más allá de la seguridad física del plástico.

Esta captura fraudulenta de datos de tarjeta puede ser realizada a través de diferentes dispositivos (denominados skimmers) que emplean las mismas funcionalidades que cualquier lector legítimo y que por lo general son ubicados de forma encubierta para evitar que el usuario detecte su presencia. Igualmente, existen skimmers portátiles que permiten la captura de datos directamente por el delincuente sin la necesidad de estar desplegados en un lector legítimo.

Figura 1. Diferentes dispositivos de tipo skimmer decomisados por la policía alemana
En este artículo se realizará una breve introducción a esta práctica delincuencial y se describirá algunas formas para evitar ser víctima de este tipo de fraude, así como recomendaciones por parte de las marcas de pago para afrontar este riesgo.

Skimming en cajeros electrónicos
Los cajeros automáticos / electrónicos (ATM – Automated Teller Machine) han sido históricamente los dispositivos más afectados por este problema, debido en gran medida a que no requieren de personal del banco, se encuentran ubicados en sitios con niveles de seguridad bajos y expuestos al público en general (centros comerciales, tiendas, supermercados, estaciones de transporte público, gasolineras, etc.), no son monitorizados de forma continua y muchas veces se encuentran en zonas aisladas y con poca visibilidad, facilitando la actividad del delincuente en la instalación, operación y retirada del skimmer.

Los delincuentes aprovechan estas fallas para ubicar el skimmer encima del lector legítimo o en otra ubicación que no ofrezca desconfianza al usuario final. De esta manera, cuando el usuario se dispone a retirar su dinero empleando una tarjeta de pago, es él mismo quien inserta el plástico en el skimmer sin notar ninguna diferencia en la operación normal del cajero. Los datos capturados (datos completos de la banda magnética) son almacenados hasta que el delincuente retira el lector encubierto.

Figura 2. Skimmer superpuesto sobre la parte frontal completa de un lector de tarjeta en un cajero electrónico
Los skimmers se adaptan a los diferentes tipos de cajeros electrónicos y su efectividad depende del camuflaje empleado para evitar ser detectado. Están diseñados para que se puedan colocar sobre la abertura del lector de tarjetas del cajero electrónico, ya sea cubriendo el propio lector o a través de un panel falso que cubre toda la superficie del frente del lector de tarjetas:

Figura 3.  skimmer superpuesto sobre la abertura de un lector de tarjeta en un cajero electrónico
Con el fin de obtener el dato del PIN asociado a los datos de la banda magnética capturada, los delincuentes suelen instalar como complemento al skimmer una microcámara de video (cámara estenopeica) que permite la grabación del PIN del usuario:

Figura 4. Micro-cámara encubierta para la grabación del PIN
En otros escenarios, se emplean teclados superpuestos que registran las teclas oprimidas por la víctima:

Figura 5.  Teclado falso superpuesto para permitir la captura del PIN
También pueden recurrir a métodos menos técnicos, como shoulder surfing (mirar por encima del hombro):

Figura 6.  Delincuente empleando shoulder surfing
Con estos elementos (banda completa de la tarjeta y PIN), el delincuente puede proceder a emplear estos datos con fines delincuenciales (extracción de dinero, compras y pagos abusivos, etc.).

¿Cómo protegerte si eres un usuario?
  • Utiliza solamente cajeros electrónicos localizados en sitios confiables (dentro del propio banco, por ejemplo)
  • Inspecciona siempre la superficie de los lectores de la tarjeta de pago y los teclados de los cajeros electrónicos en busca de cables, paneles falsos o accesorios sueltos o flojos y/o superficies extrañas ANTES de insertar la tarjeta. En caso de identificar cualquier anomalía, no uses el cajero e informa al banco o a la policía de forma inmediata.
  • Si la tarjeta es bloqueada o no es regresada por el cajero electrónico, NO TE RETIRES del cajero. Llama a la policía o al banco para notificar este problema.
  • Nunca recibas ayuda de personas extrañas cuando te encuentres realizando una transacción en un cajero electrónico.
  • Estate atento a personas extrañas que puedan estar a tu alrededor mientras realizas la transacción. Algunos cajeros electrónicos cuentan con pequeños espejos ubicados encima o a los costados del cajero para identificar el entorno:
    Figura 7. Espejos de seguridad para identificar personal extraño alrededor
  • Siempre cubre el teclado durante la digitación del PIN. Esto evitará que cualquier micro-cámara o personas cercanas puedan visualizar este dato mientras es digitado:
    Figura 8. Siempre cubra el teclado en el momento de digitar el PIN
¿Cómo protegerte si eres un banco?
  • El uso de tarjetas de pago con chip EMV disminuye de forma drástica la copia no autorizada de los datos de la tarjeta a través de skimmers. La responsabilidad por los fraudes relacionados con tarjetas falsificadas utilizadas en cajeros automáticos se asignará a la parte – Adquirente o Emisor – que no haya adoptado la tecnología de chip EMV. Si se usa una tarjeta de chip EMV en un cajero que no tenga la capacidad de aceptar tarjetas de chip EMV, el Adquirente del cajero automático asumirá el coste del fraude debido al uso de una tarjeta falsificada.
  • Notificar a los clientes acerca de los riesgos del skimming y las acciones que deben tener presente para auto-defenderse de esta práctica delictiva.
  • Mantener un sistema de CCTV (circuito cerrado de televisión) 7×24 que cubra los alrededores del lugar en donde se encuentra instalado el cajero electrónico.
  • Instalar lectores de tarjetas del tipo Jitter (vibratorio), que dificulta la lectura directa de la banda magnética de la tarjeta.
  • Instalar paneles anti-skimmer, que ayudan a evitar que el delincuente ubique un dispositivo de skimming encima de la ranura donde se inserta la tarjeta en el cajero electrónico.
  • Instalar dispositivos emisores de interferencias de frecuencias radiales que distorsionen el campo electromagnético que rodea al lector de tarjetas.
  • Notificar al usuario a través de mensajes de texto (SMS) acerca del uso de sus datos de tarjetas en transacciones extrañas.
  • Usar dispositivos PED (PIN Entry Devices) que cumplan con el programa PCI PIN (Encrypting PIN PAD – EPP)
  • El PCI SSC publicó en enero de 2013 el documento “Information Supplement: ATM Security Guidelines” que ofrece una serie de mejores prácticas a la hora de configurar y desplegar en producción un cajero electrónico, incluyendo seguridad física, seguridad lógica (software) y procedimientos para evitar la inserción de skimmers, entre otros controles.
    Figura 9. Bloques de componentes de un cajero electrónico cubiertos por la guía del PCI SSC
Skimming en datáfonos / TPV
Otro dispositivo afectado por esta técnica delincuencial es el datafono o TPV (Terminal de Punto de Venta), empleados en supermercados, gasolineras, peajes, etc. Debido a que estos elementos también permiten la lectura de la banda magnética y la digitación del PIN, son empleados por los criminales para la instalación de skimmers. Estos skimmers suelen estar acoplados en una carcasa externa que cubre toda la superficie del datafono o ser pequeñas unidades camufladas que capturan los datos de la tarjeta en el momento en el que el usuario la desliza.

Figura 10. Carcasa externa con skimmer para lectura de banda y captura de PIN

Figura 11. Nótese la diferencia entre la terminal TPV original (derecha) y la carcasa del skimmer (izquierda)
Figura 12. Otro ejemplo de carcaza externa de datáfono para captura de banda y PIN
Skimmers similares suelen ser instalados en terminales de pago desatendidas de gasolineras o peajes, que por lo general no requieren de autorización de la transacción en tiempo real (online), por lo que la detección del fraude es más demorada:
Figura 13. Skimmer en una terminal de pago desatendida

¿Cómo protegerte si eres un usuario?
  • Al igual que con los cajeros electrónicos, revisa siempre la superficie de la terminal de pago en busca de accesorios, pegatinas, cables, carcazas o piezas extrañas
  • Siempre utiliza terminales de comercios reconocidos
  • Si la tarjeta soporta EMV, inserta la tarjeta en el lector EMV en vez de emplear la lectura de la banda magnética
  • Protege el PIN en el momento de la digitación
  • Nunca entregues tu tarjeta a nadie ni la pierdas de vista durante la transacción
¿Cómo protegerte si eres un comercio?
Los comercios que emplean terminales de punto de venta (TPV) atendidas o desatendidas deben cumplir con un conjunto de controles de PCI DSS dependiendo del tipo y características de conexión del TPV (SAQ B, SAQ B-IP o SAQ P2PE). Estos controles incluyen la verificación periódica de la seguridad física del punto de interacción (Point of Interaction – POI) para verificar que no se han instalado componentes extraños, no se encuentran cables o carcazas adicionales y que los controles de seguridad provistos por el fabricante se mantienen íntegros (sellos de seguridad, tornillos, etc.). Adicionalmente, se requiere de formación a los empleados que están al cargo de estas terminales y/o las emplean para recepción de pagos y la creación de un inventario de terminales que incluya información del dispositivo, estado, identificación y ubicación. Algunas recomendaciones generales se pueden encontrar en el documento "PCI DSS v3.0 compliance: A closer look at Requirement 9.9 – Payment Terminal Protection".

¿Cómo protegerte si eres un banco?
Idealmente, el objetivo es emplear terminales de pago que acepten transacciones vía EMV. No obstante – y debido a compatibilidad con tarjetas emitidas en otros lugares – la compatibilidad con tarjetas con banda magnética obliga a aceptar métodos de pago inseguros.

En este caso, informar acerca de la responsabilidad de la seguridad física de las terminales a los comercios en donde se encuentran instaladas y enviar notificaciones periódicas para recordar acerca de estas responsabilidades y de los riesgos asociados.

Skimmers portátiles
Los skimmers no necesariamente deben estar ubicados en cajeros electrónicos y en TPV (datáfonos). También pueden ser portables. En este caso, requieren que el delincuente tenga acceso de alguna forma al plástico y lo deslice por el skimmer para leer la banda magnética, la cual es almacenada en el propio dispositivo para posteriormente ser descargada en un ordenador.
Es importante saber que existen skimmers que capturan los datos de tarjetas de pago que soportan NFC (contactless). En este caso – y dependiendo de la implementación – la cantidad de datos capturados se puede limitar al PAN, la fecha de expiración y el nombre del titular.

¿Cómo protegerte si eres un usuario?
  • Nunca entregues el plástico de la tarjeta a nadie
  • Para realizar pagos, garantiza que tienes acceso directo a la terminal de pagos (TPV o datáfono) y que nadie desliza tu tarjeta en tu nombre
  • En el caso de tarjetas que soportan contactless, se recomienda el uso de un elemento que bloquee la lectura de la tarjeta. Existen billeteras y bolsas de seguridad para estos casos.
  • Si identificas alguna acción sospechosa, notifica al responsable del comercio y a la Policía
¿Cómo protegerte si eres un comercio?
  • Ofrece formación y concienciación a los empleados
  • Notifica a la Policía si se detecta que un empleado está haciendo uso de estas herramientas
  • Garantiza que, en los protocolos de pago con tarjeta, siempre sea el cliente quien inserte su plástico en el lector o lo acerque al lector de contactless.
¿Cómo protegerte si eres un banco?
Aplican las mismas recomendaciones en el uso de skimming en datáfonos / TPV.

Recomendaciones generales
Con el objetivo de concienciar a usuarios y comercios respecto a los riesgos de estas prácticas delincuenciales, el PCI SSC publicó en septiembre de 2014 el documento "Information Supplement – Skimming Prevention: Best Practices for Merchants". Este documento incluye diferentes ejemplos de ataques y acciones para protegerse.

Por otro lado, VISA ha publicado los siguientes documentos, orientados hacia la información y actuación preventiva en casos de skimming:
Finalmente, MasterCard por su parte también ofrece una serie de recomendaciones generales para protegerse de este tipo de ataques:

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

Vicente Aguilera participa en el SHA2017 que se celebrará en Holanda el próximo mes de Agosto

Se acerca la fecha del SHA2017, un evento sin ánimo de lucro que se llevará a cabo en Holanda, del 4 al 8 agosto. Es el sucesor de un conjunto de eventos similares que se realizan cada cuatro años (GHP, HEU, HIP, HAL, WTH, HAR y OHM). La compartición del conocimiento y el hacking son algunos de los valores clave de este evento que reúne a miles de apasionados y profesionales de la seguridad.

Vicente Aguilera participa por partida doble con 2 actuaciones:
  •     Impartición conferencia
  •     Impartición taller
En la conferencia, Vicente presentará una nueva versión de Tinfoleak, y mostrará ejemplos prácticos reales sobre cómo explotar la información existente en redes sociales para tareas de investigación. A demás de mostrar información útil para fuerzas y cuerpos de seguridad, investigadores privados, pentesters, ingenieros sociales, periodistas, analistas de seguridad y cualquier persona interesada en la privacidad o el análisis de redes sociales.

A través de demostraciones en vivo, Vicente pretende mostrar la capacidad de análisis de la que puede disponer cualquier persona. Se recopilará información sobre diversos objetivos y se utilizará para generar inteligencia, de forma que pueda servir en la toma de decisiones.

Más info:
https://sha2017.org/

ISO 27001 y PCI DSS, Un Análisis Comparativo

En abril del 2016 fue emitida la nueva versión de la norma PCI DSS, esta nueva versión (3.2) hace una actualización en algunos controles técnicos y endurece otros, sin embargo, no cambia su enfoque.

La norma PCI DSS v.3.2 y sus diferentes actualizaciones se ha venido orientando el cumplimiento de la misma en un esquema de los negocios como siempre (Business as Usual – BAU), sin embargo este enfoque aunque la acerca un poco más a la norma ISO 27001:2013 en términos de que las tareas deben ejecutarse de manera continua como parte de los procedimientos, la sigue manteniendo separada en su filosofía.

Partamos de la filosofía de los sistemas de gestión planteados por las normas ISO: “mejoramiento continuo”, es decir, se presume un sistema que tiene fallas pero que busca mejorarse continuamente y usa los mecanismos como manejo de incidencias y auditorías para el apoyo en la generación de los cambios. Este sistema parte de los requerimientos de la organización y del apetito de riesgo de la misma, el análisis de riesgos provee los insumos para la definición de los controles que debe implementar la organización.

La norma PCI DSS parte del principio de que los controles definidos cumplen con los requerimientos de seguridad y deben estar funcionando correctamente. Los mecanismos como manejo de incidencias y auditorías son sistemas de monitoreo para asegurar que los controles están operando correctamente, y buscan realinear cualquier desviación con la definición original y no mejorar, o en el mejor de los casos se busca detectar actividad sospechosa no limitada por los controles implementados. El único control que permitiría un espacio para mejorar el sistema es la evaluación de riesgos (Req. 12.2), pero es un control sin dientes, porque lo único que se exige es que se haga una evaluación que identifique las amenazas y vulnerabilidades asociadas en búsqueda de riesgos no mitigados por la norma, sin embargo, aunque el control pide identificar nuevos controles, el mecanismo de verificación no pide que se valide la implementación de dichos controles.

El espíritu con el que se implementan estos dos sistemas que buscan un fin común, asegurar los activos de información, difiere también en el principio que determina su vida dentro de la organización, la norma ISO 27001 requiere de un compromiso de la dirección sin que sea un requerimiento legal o contractual (en la mayoría de los casos), mientras que la norma PCI DSS es mandatoria, ya sea porque para operar, las franquicias de las marcas de pago o el adquiriente lo exigen o porque un cliente lo exige, es importante tener en cuenta que para mantener adecuadamente la implementación de la norma requiere un soporte financiero y esto hace que se involucre la dirección. De hecho, para llegar a la implementación de una norma ISO 27001 se hace de una manera más voluntaria (algunos mercados están exigiendo estar certificado para permitir el acceso a ellos), mientras que la implementación de los controles de la norma PCI DSS son obligados de manera contractual para poder manejar datos de tarjeta habiente. Se puede decir que la diferencia de principios genera una diferencia significativa en la asignación de recursos y en el camino que se sigue para implementar su cumplimiento.

De acuerdo a este espíritu en un sistema que se requiere un compromiso se deberían obtener mejores resultados, mientras que en un sistema de obligatorio cumplimiento se hará lo mínimo necesario para pasar la evaluación. Sin embargo, esta presunción dista mucho de la realidad, ya que en la mayoría de las implementaciones de cualquiera de las dos normas se encuentra que se hace lo mínimo necesario para poder demostrar un estado de cumplimiento, generando en ocasiones controles débilmente implementados.

El alcance de las dos normas tiene dos ramas que también difieren en lo que se busca obtener, en la primera rama vemos que mientras la norma PCI DSS busca proteger la confidencialidad, la norma ISO 27001 tiene un alcance mayor cubriendo no solo la confidencialidad sino la integridad y la disponibilidad. Esta gran diferencia nos muestra que sólo proteger los datos de la organización con los controles que brinda la norma PCI DSS deja dos vectores importantes huérfanos comprometiendo la imagen y la continuidad del negocio.

En la otra rama del alcance de la norma están los activos de información a proteger, mientras que PCI DSS busca proteger los datos de tarjeta-habiente, la norma ISO 27001 busca proteger todos los activos de información de la organización de acuerdo a los niveles que la misma organización defina.

Esta diferencia lo que nos muestra es que PCI DSS tiene pre-definido un conjunto de activos como confidenciales mientras que bajo el criterio de la norma ISO 27001 esta definición puede ser un poco ajustable dependiendo de los requerimientos legales a los que esté sujeta la empresa, las necesidades de proteger sus activos de información y su apetito de riesgo. Sin embargo, al estudiar diferentes implementaciones de la norma ISO 27001, es fácil encontrar la falta de rigurosidad a la hora de clasificar la información y por ende los controles terminan siendo laxos o insuficientes.

Adicionalmente algunas organizaciones certifican tareas que tienen en plan de trabajo, contrario a la exigencia de los controles de la norma PCI DSS que se posicionan de un modo absoluto y estricto, la definición de cumplimiento de estos no da lugar a términos medios y no se pueden validar planes de trabajo, los controles deben estar operando desde el principio para considerar que la organización se encuentra en estado de cumplimiento con la norma PCI DSS.

Otro punto de vista sobre la expectativa de cómo implementar cada una de las normas se obtiene al analizar los requerimientos para poder auditar o verificar el cumplimiento de cada una de las normas, mientras que en términos generales de un auditor líder de ISO 27001 se espera que sea un profesional con deseable experiencia en auditoría interna o en auditoría de calidad (ISO 9001) o en general cualquier auditoría que se rija por los métodos definidos en la ISO 19001, un auditor de PCI DSS debe demostrar experiencia de 5 años en el campo de la seguridad informática y alguna certificación de industria en este campo, lo que hace que una persona certificada para hacer evaluaciones PCI (QSA) lo pueda hacer con conocimientos reales y prácticos sobre la materia y no solamente los conocimientos sobre una norma donde en algunas ocasiones sus argumentos serán sobre la interpretación de una palabra y no sobre el riesgo al que se puede exponer una plataforma por una inadecuada implementación de un control.

En otras palabras, la definición de la norma PCI DSS puede considerarse como el ejercicio que hizo el PCI SSC al definir los controles para un sistema de gestión sobre una empresa genérica con unas premisas definidas, con un alcance limitado, y esto lo podemos ver cuando hacemos un mapeo de las dos normas, al realizar esta tarea encontramos que prácticamente todos los controles de la noma PCI DSS tienen una equivalencia en el Anexo A de la norma ISO 27001, sólo que en la primera los controles son bastante específicos.

Conclusión
En ambientes donde es un requerimiento implementar la norma PCI DSS se deben aprovechar los beneficios que brinda el tener un sistema de gestión de seguridad de la información, al proveer mecanismos de mejora continua y respaldo corporativo sumados con el detalle de los controles que da la norma PCI DSS que han sido probados en diferentes ambientes y son reconocidos por dar resultados adecuados.

En muchos casos la implementación de la norma PCI DSS da una relevancia a controles que eventualmente durante la implementación del sistema de gestión se pudieron haber pasado por alto o no se les dio la suficiente importancia.

Referencias
(1) ISO/IEC 27001:2013 Information technology – Security techniques – Information security management systems – Requirements – 2013-10-01
(2) Payment Card Industry (PCI) Data Security Standard (DSS) – Requirements and Security Assessment Procedures – Version 3.2 – 2016-04

Autor: Javier Roberto Amaya Madrid, ISO 27001 LA, PCI QSA, PCI PCIP
Consultor en Seguridad