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!