Vicente Aguilera entrevistado en el periódico El Confidencial

El pasado jueves Vicente Aguilera fue entrevistado para el periódico El Confidencial, con motivo del Campeonato de Europa de Ciberseguridad celebrado en Málaga los días 31 de octubre y 1 de noviembre.

Se puede consultar el artículo completo en:
https://www.elconfidencial.com/tecnologia/2017-11-03/hackers-campeonato-europa-ciberseguridad-espana_1471555/

Vicente Aguilera ponente en el evento QurtubaCON que se celebrará en Córdoba

Los próximos días 17 y 18 de noviembre se celebra en Córdoba (España) el congreso de seguridad QurtubaCON en el que Vicente Aguilera participará como ponente con la presentación: “Datos, información, inteligencia y otras guerras”.

En esta ocasión Vicente, tomando como base ejemplos de enfrentamientos históricos, realizará un análisis del papel desempeñado por la información en acontecimientos muy dispares, relacionados con el ámbito militar.

Asimismo, se realiza un énfasis en el uso de la inteligencia para conseguir una ventaja frente a agentes externos, a la vez que se dificulta las labores de inteligencia por parte de dichos agentes.

Más información sobre el evento:
https://qurtuba.es/

¡Nuevo cambio de imagen corporativa!

Cómo ya veníamos anunciando hace unas semanas, el cambio de imagen corporativa, es ya una realidad.

¡A partir de hoy, estrenamos nueva web, y nueva imagen corporativa!

Con este cambio pretendemos reflejar la evolución que ha tenido la compañía y un concepto que creemos que ha de ser uno de los leitmotiv en el mundo de los servicios de ciberseguridad: hacer las cosas complicadas más sencillas.

Nuestro logo era complejo, intrincado y reflejaba como se ve la seguridad en la primera década del siglo XXI. Hemos querido sintetizar estos conceptos haciendo una nueva imagen más sencilla, moderna, y definir un símbolo propio que nos identifique de forma única y particular.

A continuación, os mostramos el proceso de simplificación y el resultado final que hemos obtenido:


Resultado:




Con este cambio cerramos una etapa e iniciamos una nueva que vendrá llena de novedades.





Internet Security Auditors

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

    Se recoge expresamente el deber de confidencialidad.

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

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

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

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

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

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

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

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

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

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

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


Autor: Carmen Areces
Departamento Comercial.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Figura 5. Flujo transaccional de un pago no presencial tradicional

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

Pago recurrente (RP):

Figura 6. Flujo transaccional de un pago recurrente

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

Pago en un clic (OCP):
Primera compra:


Compras posteriores:

Figura 7. Flujo transaccional de un pago en un clic

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

Privacy Shield, considerado inadecuado por el Parlamento Europeo

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

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

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

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

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

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

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

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

Servicios para el cumplimiento de PCI DSS de la mano de Sabre Travel Network y ANATO

El pasado 16 de Agosto, con el apoyo de Sabre Travel Network, uno de los mayores GDS (Sistemas de Distribución Global) del mundo, se realizó en el auditorio de ANATO (Asociación Colombiana de Agencias de Viajes y Turismo) en Bogotá una conferencia enfocada principalmente a concientización del cumplimiento de PCI DSS en las Agencia asociadas a IATA así como a la presentación de los servicios de cumplimiento diseñados específicamente para pequeñas y medianas agencias de viajes.

En la conferencia participó Daniel Fernández, Global Sales Manager de Internet Security Auditors, aclarando los aspectos más relevantes del cumplimiento y  responsabilidades desde el punto de vista de las agencias del sector turístico, donde nuestra gran experiencia marca la diferencia, siendo uno de los sectores con los que se cuentan más referencias en proyectos de cumplimiento de PCI DSS. La conferencia contó con una amplia representación de agencias de viajes en todo el territorio colombiano, participando de forma presencial y virtual.


Sabre Travel Network® es proveedor líder en el mundo de soluciones que optimizan el desempeño del negocio a lo largo de toda la industria de viajes, incluyendo agencias, corporaciones, proveedores, y desarrolladores. Sabre Travel Network® atiende a agentes de viajes, proveedores de viajes, sitios de viajes en línea, corporaciones y gobiernos en todo el mundo. Siendo el proveedor líder de soluciones para viajes y el sistema de distribución global más grande del mundo, teniendo un alcance global con un servicio personalizado y accesible.

ANATO es la mayor asociación colombiana de agencias de Viajes siendo una entidad sin ánimo de lucro y de carácter gremial que representa, defiende y promociona los intereses generales del turismo y de las Agencias de Viajes en Colombia. Creada el 20 de octubre de 1949, está conformada por Agencias Asociadas en todo el territorio nacional con 9 capítulos de representación, consolidando el sector y la agremiación como la entidad de más amplio reconocimiento nacional por el desarrollo de su gestión.

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.