martes, 20 de octubre de 2020

LA IMPORTANCIA DE LAS SUITES DE CIFRADO EN LAS COMUNICACIONES EN PCI DSS

 1. Introducción

Desde 1995, SSL (Secure Sockets Layer) se convirtió en uno de los protocolos más utilizados y extendidos a nivel mundial para el cifrado de las comunicaciones. La gran cantidad de vulnerabilidades en SSL hizo que en 1999 se desarrollase Transport Layer Security 1.0 (TLSv1.0), un protocolo que buscaba mejorar la seguridad en las comunicaciones, aunque como ocurrió en SSL, fueron apareciendo vulnerabilidades en dicho protocolo, principalmente ante ataques BEAST, por lo que tuvo que evolucionar y ser sustituido por TLSv1.1 en 2006.

TLSv1.1 mejoró a TLSv1.0 en cuanto a la seguridad ya que añadía protección con el cifrado de bloques, garantizando el intercambio de datos en un entorno securizado y privado entre dos entes (usuario y servidor); su facilidad de implementación y su uso complementando a otros protocolos en expansión como HTTP, SSH o SMTP, permitió su consolidación en los sistemas de hoy día. Actualmente, son muchas las organizaciones y fabricantes que lo consideran obsoleto (poniendo como fecha límite marzo de 2020) y no se aconseja su utilización para aplicaciones comerciales y comunicaciones a través de redes públicas, por lo que la transición a las versiones TLSv1.2 (2008) o TLSv1.3 (2018) es lo más recomendable puesto que son protocolos más actuales y los cuales están menos afectados por vulnerabilidades y que ofrecen comunicaciones seguras.

NOTA: Este artículo no va enfocado a explicar la criptografía, sino que se centra en el uso de los protocolos de comunicaciones seguros y de cómo las suites de cifrado favorecen esa seguridad.

2. Definiciones

  • Secreto Perfecto Hacia Adelante (Perfect Forward Secrecy). Propiedad que garantiza la protección de las claves utilizadas anteriormente ante el descubrimiento de las claves utilizadas actualmente, por lo que se basa en un sistema de claves efímeras. La clave que se utiliza para la transmisión de datos no puede ser utilizada posteriormente para generar ninguna otra.
  • Claves efímeras. Las claves efímeras tienen solamente un uso, por lo que son generadas para utilizarse en una sesión. Una vez que las claves son creadas, se destruyen cuando el secreto compartido se computa.
  • Claves estáticas. Al contrario que las claves efímeras, estas claves se utilizan para más de un uso, por lo que es más fácil que puedan ser comprometidas que las anteriores.
  • Cifrado autenticado (AE). Se trata de una forma de cifrado que proporciona confidencialidad, integridad y autenticidad de forma simultánea a los datos. Su funcionamiento se basa en el cifrado de datos utilizando una clave y proporcionando unos datos cifrados junto con su etiqueta de autenticación.
  • Etiqueta de autenticación o código de autenticación de mensaje (MAC). Es una cadena de bits aleatorios que provee integridad al texto cifrado y/o a los datos asociados autenticando los mensajes.

3. TLS y el handshake

A pesar de que TLSv1.1 cuenta con vulnerabilidades, su utilización para el cifrado de las comunicaciones no está prohibido, aunque sí desaconsejado. TLSv1.1 se encuentra aceptado por el estándar PCI DSS debido a que proporciona un cifrado seguro siempre y cuando se combine con ciertas suites de cifrado, o por guías o estándares referentes en la industria aceptadas por PCI DSS como son las publicadas por el NIST.

El objetivo de TLSv1.1 es el de proporcionar privacidad e integridad a las comunicaciones entre aplicaciones. Se compone de dos capas: el protocolo de autenticación TLS (TLS Record Protocol) y el protocolo del handshake TLS (TLS Handshake Protocol).

  • Protocolo de autenticación. Se encarga de proporcionar una comunicación privada utilizando criptografía simétrica para el cifrado de datos, y fiable utilizando una comprobación de la integridad del mensaje mediante MAC (utiliza como funciones hash MD5 o SHA).
  • Protocolo de Handshake. Se encarga de autenticar al cliente y al servidor, además de permitirles negociar el algoritmo y las claves de cifrado antes de que se produzca la comunicación. Este protocolo se encarga de dotar de seguridad a las comunicaciones mediante tres propiedades:
    • Autenticación usando claves asimétricas o públicas.
    • Negociación de secreto compartido segura.
    • Negociación confiable.

Ilustración 1: Handshake en TLS. Extraído de researchgate.

Durante el handshake, se negocian los algoritmos que proporcionan la autenticación, confidencialidad y la integridad. El conjunto de algoritmos de cifrado negociados es lo que se conoce como suites de cifrado. Estas especifican una colección de algoritmos para el intercambio de información durante una sesión entre dos dispositivos.  Estos parámetros quedan definidos tras el handshake llevado a cabo por el protocolo TLS, en lo que se conoce como el subprotocolo “change cipher spec”, en el cual el cliente propone al servidor las suites de cifrado que soporta, siendo el servidor el encargado de seleccionar una de ellas para llevar a cabo la comunicación de forma segura.

4. Suites de cifrado

Las suites de cifrado se componen de distintos campos.
Para TLSv1.2 o versiones anteriores:

  • Protocolo utilizado. El protocolo que dota de seguridad en la capa de transporte. En este caso, el protocolo utilizado es TLS.
  • Algoritmo para el intercambio de claves. Utilizado para determinar cómo van a ser autenticados el cliente y el servidor durante el handshake. Los algoritmos son asimétricos y son los siguientes: ECDHE_ECDSA, DHE_RSA, ECDHE_RSA, DHE_DSS, DH_DSS o DH_RSA.
    • Si se trata de algoritmos como Diffie-Hellman (DH) o Diffie-Hellman con curva elíptica (ECDH), el siguiente campo, el campo de la firma, indica la clave pública del servidor.
    • Si el algoritmo es efímero, como son los algoritmos Diffie-Hellman Efímero (DHE) o Diffie-Hellman con curva elípitica Efímero (ECDHE), el campo de la firma corresponde al tipo de clave pública del servidor que va a ser utilizado para autenticarlo.
    En caso de no existir un campo de firma definido, el algoritmo de intercambio de claves indica el algoritmo simétrico de claves pre-compartidas como son: DHE_PSK, ECDHE_PSK o PSK.
  • Algoritmo de cifrado. Indica cómo va a ser cifrado el mensaje mediante un algoritmo de cifrado de bloques (AES_128, AES_256, CHACHA20). Estos algoritmos difieren en la longitud de clave (AES_128 con claves de 128 bits, y AES_256 y CHACHA20 con claves de 256 bits). Los algoritmos de cifrado de bloques van acompañados del modo de operación de cifrado de clave (128 bits) de ese bloque (GCM – Galois Counter Mode, CBC – Cipher Block Chaining, CCM – Counter with CBC-MAC). Los modos de operación están formados normalmente por un esquema de cifrado y por un código de autenticación de mensaje (MAC).
  • Algoritmo de autenticación de mensaje. Es un algoritmo opcional y se utiliza para autenticar un mensaje usando HMAC. Genera los hashes y las firmas que aseguran la integridad de los mensajes. Los algoritmos que pueden ser utilizados son: SHA, SHA256, SHA384 o POLY1305.
Los distintos campos que conforman las suites de cifrado para TLSv1.2 quedan representadas en el siguiente ejemplo:

Ilustración 2: Suites de cifrado para TLSv1.2

Para TLSv1.3, estos valores difieren, pues no se especifica el algoritmo de intercambio de claves ni el método de autenticación. Las suites de cifrado de TLSv1.3 solo se pueden utilizar cuando los certificados del servidor son RSA y ECDSA, pero no DSA o DH que fueron eliminadas de TLSv1.3. Los campos de las suites de cifrado son los siguientes:

  • Protocolo utilizado. El protocolo que dota de seguridad en la capa de transporte. En este caso, el protocolo utilizado es TLS.
  • Algoritmo de cifrado. Este algoritmo dota de confidencialidad, integridad y autenticación de mensaje. Los algoritmos para el cifrado de bloques utilizados pueden ser: AES_128, AES_256 o CHACHA20. A estos algoritmos se les añade el modo de operación de cifrado de clave de ese bloque de cifrado: GCM, POLY1305, CCM o CCM_8. Para TLSv1.3 queda CBC obsoleto. Estos modos de operación generan una etiqueta de autenticación de distinto tamaño: GCM, POLY1305 y CCM de 16 bytes, mientras que CCM_8 de 8 bytes.
  • Algoritmo para la autenticación de mensaje. Se utiliza para autenticar los mensajes y dotarlos de integridad. Los algoritmos que se pueden utilizar son: SHA256, SHA384.
Estos campos quedan representados en la siguiente imagen de ejemplo:

Ilustración 3: Suites de cifrado para TLSv1.3

5. Configuraciones para PCI DSS

Algunas consideraciones que deben tenerse en relación a los entornos PCI DSS son las siguientes:

  • Utilizar suites de cifrado cuyo certificado contenga una firma de al menos 112 bits.
  • Elegir claves efímeras antes que claves estáticas puesto que al utilizar la característica de Secreto Perfecto hacia Adelante (Perfect Forward Secrecy) se garantiza la protección de claves en caso de que una actual se vea comprometida. Por tanto, algoritmos como DHE (Diffie-Hellman Ephimeral) o ECDHE (Elliptic-curve Diffie-Hellman Ephimeral) son preferidos a DH o ECDH.
  • Utilizar cifrado autenticado (AE) para añadir integridad y autenticidad. El cifrado autenticado previene diversos ataques sobre la autenticación. Por tanto, es preferible utilizar GMC o CCM antes que el modo CBC.
  • Seleccionar algoritmos que proveen una etiqueta de autenticación lo más larga posible para proporcionar una mayor seguridad en la autenticación debido a que es más complicado alterar la integridad cuanto más larga sea esta etiqueta. En este caso, sería preferible utilizar CCM antes que CCM_8 puesto que utiliza 16 octetos para rellenar la etiqueta de autenticación en vez de 8.

6. Conclusiones

Tras analizar los distintos protocolos y suites de cifrado se puede concluir que las suites de cifrado constituyen un elemento fundamental en la seguridad de las comunicaciones puesto que son las encargadas de establecer los algoritmos de cifrado de datos aportando confidencialidad, integridad y autenticidad. Se trata de un elemento imprescindible dentro de PCI DSS porque permite que los datos de tarjeta no sean transmitidos en claro a través de un canal seguro.

La importancia de elegir protocolos de comunicaciones seguros dificulta que los datos transmitidos puedan verse comprometidos. Por ello, la utilización de protocolos como TLSv1.2 y TLSv1.3 es lo más recomendable para las comunicaciones, aunque TLSv1.1 acompañado de suites de cifrado seguras son todavía válidas igualmente dentro de PCI DSS. 

7. Referencias


Autor: Diego de la Horra
Dpto. Consultoría

lunes, 5 de octubre de 2020

Anonimización y Seudonimización de datos de carácter personal

 1. Introducción

Desde la entrada en escena del nuevo Reglamento General de Protección de Datos personales (en adelante, RGPD) han sido muchas las técnicas estudiadas y utilizadas para cumplir con cada uno de los artículos del mismo y, en particular, para proteger de una manera efectiva los datos de carácter personal que se tratan por parte de una organización, de tal manera que, exista un equilibrio entre seguridad y negocio. Sin embargo, existen una serie de técnicas y/o conceptos que todavía causan bastante confusión en la industria y de los cuales se suelen utilizar indistintamente, cuando en realidad, son totalmente distintos. Estas técnicas de protección de datos personales son las que se conocen con el nombre de Anonimización y Seudonimización de datos de carácter personal. Realmente, el único concepto nuevo que se ha introducido con el RGPD ha sido el de Seudonimización, ya que la Ley de protección de Datos, anterior al reglamento, ya recogía en su cuerpo el proceso de anonimización.


En la actualidad, pocas empresas, debido precisamente a la falta de entendimiento de este tipo de técnicas tan beneficiosas en algunas ocasiones, utilizan la Anonimización y Seudonimización para la protección de los datos personales que tratan en sus procesos de negocio.

2. Riesgos básicos

Estas técnicas de protección sirven para combatir varios riesgos que afectan a la confidencialidad de los datos de carácter personal, principalmente:

  • Singularización: Consiste en la posibilidad de extraer de un conjunto de datos algunos registros (o todos los registros) que identifican a una persona.
  • Vinculabilidad: Consiste en la capacidad de vincular, al menos, dos datos referentes al mismo interesado o grupo de interesados, ya sea a través de una única fuente de datos o varias.
  • Inferencia: Consiste en la posibilidad de deducir, con una probabilidad significativa, el valor de un atributo al que no se debería tener acceso a través de otros, menos críticos, a los que sí se tiene o se puede tener acceso en un conjunto de atributos.

3. Diferencias entre Anonimización y Seudonimización de datos

3.1. Anonimización de datos personales

El proceso o el concepto de anonimización (o disociación de datos personales) consiste en eliminar o reducir al mínimo el riesgo remanente de reidentificación de los datos de carácter personal anonimizados, es decir, se trata de una técnica por la cual se eliminan las posibilidades de identificar al titular de los datos de carácter personal, manteniendo la veracidad y exactitud de los resultados del tratamiento de los mismos, es decir, además, de evitar la identificación de las personas a las cuales pertenecen dichos datos, se debe garantizar que cualquier operación sobre los datos anonimizados no conlleva una desviación en los resultados que se hubieran obtenido con los datos reales antes de ser sometidos al proceso de anonimización. 

En definitiva, la anonimización debería eliminar los datos personales que permiten la identificación de las personas de “forma irreversible”. Es decir, los datos personales se disocian de forma completa, de tal forma que un individuo no pueda ser identificado con el resto de los datos. Una vez que se ha completado el proceso de anonimización, el tratamiento de los datos anonimizados no estaría dentro del ámbito del RGPD.

A partir de este momento, el responsable del tratamiento podrá hacer uso de esta información en la forma y modo que necesite ya que la privacidad de las personas no se encuentra comprometida de ningún modo. 

Por otro lado, para determinar si una persona física o interesado puede ser identificado tras someter sus datos a un proceso de anonimización, el Grupo de Trabajo del Artículo 29 hace referencia a la “razonabilidad de medios usados” como criterio para evaluar si el procedimiento de anonimización es suficientemente sólido y robusto y, por tanto, la identificación de los datos anonimizados es considerada “razonablemente imposible”. Es decir, si los medios que deben o tienen que usarse para “romper” los resultados obtenidos de las técnicas de anonimización empleadas son excesivos o desproporcionados, se considerará que la técnica de anonimización utilizada provee una disociación de los datos “irreversible”.

El avance de la tecnología y la información disponible hacen difícil garantizar el anonimato absoluto, especialmente a lo largo del tiempo, pero, en cualquier caso, la anonimización va a ofrecer mayores garantías de privacidad a las personas. 

3.1.1. Técnicas de Anonimización de datos personales

De forma general, existen dos tipos de anonimización: generalización y aleatorización:

  • Aleatorización: La aleatorización consiste en un conjunto de técnicas que tienen como objetivo modificar la veracidad de un dato con la finalidad de eliminar la conexión existente entre éste y el titular del mismo. Si los datos son lo suficientemente ambiguos o inciertos, se evita que se pueda llegar a identificar a una persona física concreta. De forma particular, podemos encontrar las siguientes técnicas:
    • Adición de ruido: Esta técnica consiste en modificar los atributos de un conjunto de datos para que sean menos precisos o exactos, pero conservar su distribución general. Los datos son veraces hasta determinado punto.
    • Permutación: La técnica de permutación consiste en mezclar los valores de los atributos de un conjunto de datos para que algunos de ellos puedan vincularse artificialmente a distintos interesados, es decir, se intercambian algunos valores contenidos en un conjunto de datos, con los de otro conjunto, teniendo cuidado de no alterar la relación lógica existente.
    • Privacidad diferencial: La privacidad diferencial es diferente del resto de técnicas anteriores, ya que se basa en la recolección de datos del global de usuarios sin saber a quién corresponde cada dato, es decir, el responsable del tratamiento de datos genera vistas anonimizadas del conjunto de datos, pero almacenando, de forma paralela, una copia de los originales.
  • Generalización: La técnica de generalización consiste en generalizar y diluir los atributos de los interesados o personas físicas modificando las respectivas escalas u ordenes de magnitud. La generalización puede ser efectiva para descartar la singularización o el aislamiento, pero no permite obtener una anonimización eficaz para todos los casos; siendo necesario aplicar otros enfoques (cuantitativos y sofisticados) que impidan la vinculabilidad y la inferencia.
    • Agregación y anonimato k: Con esta técnica se pretende impedir que una persona sea aislada al agruparla con al menos un grupo k de personas. Para ello los valores de los atributos se generalizan de modo que cada individuo comparta el mismo valor.
    • Diversidad l / proximidad t: Añade un poco de complejidad a la técnica anteriormente descrita y se amplía el “k-anonymity” asegurándose de que, en cada clase de equivalencia, cada atributo tenga al menos l valores diferentes.
Otras técnicas que pueden utilizarse para llevar a cabo el proceso de anonimización, se indican a continuación:
  • Algoritmos de Hash con clave secreta y borrado de clave: Esta técnica equivale a generar un número aleatorio como seudónimo para cada atributo de una base de datos y, posteriormente, al borrado de la tabla de correspondencia (datos reales).
  • Cifrado Homomórfico: Un algoritmo de cifrado homomórfico permite realizar operaciones con datos cifrados (sin la necesidad de ser descifrado en ningún momento) de tal manera que el resultado de las operaciones no varía con respecto a si las operaciones se hubieran llevado a cabo con los datos en claro (sin cifrar). Los resultados de las operaciones con datos cifrados dan por resultado valores igualmente cifrados. El esquema de cifrado homomórfico abre la posibilidad del tratamiento de datos personales anonimizados garantizando la privacidad del tratamiento y que los resultados de los tratamientos van a ser accesibles únicamente al poseedor de la clave de descifrado, si es que es necesario.

    NOTA: Hay que tener en cuenta que esta tecnología todavía se encuentra en una fase de prueba y debe estabilizarse antes de su uso masivo.

  • Sello de tiempo: Se debe tener en cuenta la posibilidad de utilizar en el proceso de anonimización algoritmos de sello de tiempo con el fin de garantizar la fecha y hora en la que la anonimización ha sido realizada, o incluso algoritmos de firma electrónica que permiten garantizar la identidad electrónica de quien ha realizado la anonimización.

3.2. Seudonimización de datos personales

Según el RGPD el proceso de seudonimización se corresponde al proceso de tratamiento de datos de carácter personal de tal manera que no puedan atribuirse a un individuo sin utilizar información adicional, siempre que dicha información adicional figure por separado y esté sujeta a medidas técnicas y organizativas destinadas a garantizar que los datos personales no se atribuyan a una persona física identificada o identificable


Es decir, consiste en tratar los datos de carácter personal sin los datos que permiten la identificación del interesado, pero sin suprimir la conexión existente entre los datos que permiten determinar la persona propietaria de los mismos. Esto hace que siga existiendo una alta probabilidad de identificar a la persona física propietaria de los datos de carácter personal que se están tratando.


A pesar de que la información que se ha sometido a un proceso de seudonimización no permite la identificación directa del interesado o propietario de los datos, no se debe olvidar que dichos datos siguen siendo de carácter personal (ya que es posible averiguar la identidad del interesado a través de información adicional) y, como tales, objeto de protección de la normativa en materia de protección de datos vigente. Por ello, es muy importante proteger aquellos sistemas que permiten realizar la traducción inversa y obtener la identidad de la persona a la cual pertenecen los datos que han sido sometidos a un proceso de seudonimización.

3.2.1. Técnicas de Seudonimización de datos personales

Las técnicas de seudonimización más relevantes, tal y como se indica en el Dictamen 05/2014 del Grupo de Trabajo del Artículo 29 son las siguientes:

  • Algoritmos de Hash: El uso de algoritmos de Hash (MD5, SHA, etc.) son considerados como una técnica unidireccional o de una sola vía, ya que no son “reversibles”. Se trata de una función matemática que puede recibir como entrada un conjunto infinito de datos y produce como salida un resumen o conjunto finito de datos que identifican inequívocamente al conjunto de caracteres de entrada. Es imposible derivar u obtener la entrada partiendo de su hash. Existe la posibilidad, dado que siempre se obtiene la misma salida para la misma entrada y, conociendo el rango de los valores de entrada y el hash, obtener los datos personales de entrada que fueron sometidos a este proceso.
  • Cifrado con clave secreta: Los datos personales se cifran con una clave de cifrado custodiada por un individuo. El custodio de la clave de cifrado con la cual se han cifrado los datos de carácter personal podrá, de una forma sencilla, descifrar el conjunto de datos de carácter personal identificando así al interesado y propietario de los datos.
  • Función con clave almacenada: Es un tipo de función hash que hace uso de una clave secreta a modo de valor de entrada suplementario (la ejecución de la función se podría reproducir con el valor de entrada y la clave secreta).
  • Descomposición en tokens: Consiste en la sustitución o reemplazo de datos de carácter personal (sensibles) por otros datos o conjunto de caracteres que no lo son, pero que garantizan la misma operatividad. Dado que debe existir una tabla de correspondencia entre el par token – dato personal, se puede identificar a la persona o interesado propietario de los datos de carácter personal, teniendo acceso a dicha tabla.

4. Conclusiones

Como se ha podido apreciar, las técnicas de anonimización y seudonimización actuales no cumplen de forma completa los criterios que permitan obtener una anonimización o seudonimización efectivas; de una u otra forma todas ellas entrañan o suponen algún riesgo en cuanto a la identificación de un individuo a través de datos anonimizados, es por ello que se hace imprescindible estudiar y diseñar de forma cuidadosa cada técnica a emplear atendiendo a varios factores como, la naturaleza de los datos personales y el posterior uso o tratamiento de los datos anonimizados. Como puede observarse en la siguiente tabla extraída del dictamen 05/2014 sobre técnicas de anonimización del GT29, se concluye que ninguna de las técnicas actuales cumple al 100% los criterios de anonimización y seudonimización efectivas:
 

Técnica ¿Existe riesgo de singularizació? ¿Existe riesgo de vinculabilidad? ¿Existe riesgo de inferencia?
Adicción de ruido Puede que no Puede que no
Sustitución Puede que no
Agregación y anonimato k No
Diversidad 1 No Puede que no
Privacidad diferencial Puede que no Puede que no Puede que no
Hash / Token Puede que no
Seudonimización


Al no garantizar completamente la no reidentificación de las personas, es importante que los responsables del tratamiento o, en su defecto, los delegados de protección de datos de carácter personal conozcan bien todas las fortalezas y debilidades de cada una de las técnicas, así como las circunstancias precisas para aplicar una u otra técnica o un conjunto de ellas, de tal forma que se garantice la privacidad de los datos de carácter personal. Para paliar más aún los efectos de estos riesgos residuales que existen tras la aplicación de este tipo de técnicas, los responsables del tratamiento deberán implantar medidas de seguridad compensatorias que ayuden a mitigar dichas debilidades y aumenten así la fortaleza y la privacidad de los datos.


Además, sea cual sea la técnica elegida, no hay que olvidar que este proceso de anonimización y/o seudonimización debe trasladarse a una política interna o procedimiento el cual, debe estar disponible y accesible para todas las partes interesadas en el tratamiento de los datos anonimizados. Esta documentación debe ser correctamente auditada, con una periodicidad lógica que permita garantizar su cumplimiento por parte de todas las partes y detectar posibles desviaciones y/o modificaciones necesarias dado el rápido avance de la tecnología. Es por esto último, que la anonimización o seudonimización debe plasmarse como un proceso continuo y vivo en el cual el responsable del tratamiento evalúa de forma regular los riesgos existentes e incorporando las soluciones y medidas de seguridad necesarias para reducir el nivel de riesgo a una cota aceptable por la organización.

Finalmente, tanto la anonimización como la seudonimización (teniendo en cuenta los riesgos anteriores) son excelentes métodos que ayudan a reducir los riesgos inherentes al tratamiento de datos personales por parte de una organización y ayudan a los responsables y encargados del tratamiento de estás a cumplir con sus obligaciones derivadas de la normativa de protección de datos de carácter personal. Estas técnicas no deben ser vistas como una exención del cumplimiento, sino como herramientas útiles y necesarias para la mitigación de los riesgos asociados al procesamiento, transmisión, almacenamiento o cualquier otro tipo de operación efectuada sobre este tipo de datos, que no son definitivas debido a que son altamente dependientes del avance de la tecnología.

5. Referencias


Autor: Sergio Moreno - CCNA, PCIP, CCSP, CISSP, CDPSE, ISO 27001 L.A.
Dpto. Consultoría

lunes, 21 de septiembre de 2020

ISecAuditors de nuevo en el GEAR 2020-22 del PCI SSC

 El GEAR (Global Executive Assessor Roundtable) se creó el año 2018, fecha desde la cual hemos formado parte de este grupo internacional de asesores, para obtener recomendaciones y aportaciones de los altos directivos de las empresas de asesoría de seguridad de pago acreditadas por el PCI SSC. Esta iniciativa ha permitido a los altos ejecutivos de las empresas asesoras en Normas PCI de todo el mundo proporcionar asesoramiento, retroalimentación y orientación al PCI SSC sobre las cuestiones y preocupaciones relacionadas con las evaluaciones y los programas de evaluación, representando las perspectivas de las regiones y clientes dónde y con los que trabajan.

El hecho de ser la única empresa Iberoamericana con presencia en el GEAR demuestra el posicionamiento y relevancia de Internet Security Auditors en el entorno de Normas PCI y el valor que considera el PCI SSC que tiene la compañía en las regiones donde trabaja desde hace más de 12 años, ayudando a sus clientes en la consecución del cumplimiento de las diferentes Normas PCI como uno de los líderes indiscutibles y reconocimiento por la calidad de su trabajo.

Más información en el microsite de GEAR del PCI SSC:
https://www.pcisecuritystandards.org/get_involved/global_executive_assessor_roundtable

lunes, 17 de agosto de 2020

Charlas, Eventos y Entrevistas

Aún en estos meses de verano nuestro responsable de ciberinteligencia, Carlos Seisdedos, no para ni un momento. Desde Cifal Málaga han publicado el Libro Blanco de Reflexiones y Propuestas para una Nueva Sociedad post Covid19, en el que un centenar de expertos han participado exponiendo sus soluciones a los retos y desafíos a los que se enfrenta el mundo debido a la pandemia.

Entre ellos, Carlos Seisdedos, con un artículo sobre ciberinteligencia frente al cibercrimen en el COVID-19

Carlos también participará como ponente en la DragonJar Security Conference que se celebrará los días del 4 al 6 de septiembre, este año de forma online y gratuita.

Desde reKnowledge, empresa dedicada a la fabricación de software para análisis de inteligencia han publicado un artículo en su blog en el que recomiendan el perfil de Twitter de Carlos cómo uno de los “especialistas” en OSINT a los que seguir.

Y para finalizar, el pasado 13 de agosto la cadena de TV La Sexta Noticias entrevistó a Carlos Seisdedos, dónde estuvo hablando sobre la nueva aplicación del gobierno, Radar, en la investigación y rastreo de personas con covid.

martes, 14 de julio de 2020

SQLi y “Cleans URLs”

Cada vez es más común ver URL menos sofisticadas, entendibles para el usuario, llamadas Search Engine Optimization Friendly URL (SEO-Friendly URL). Si recordamos un tiempo atrás, cuando alguien nos enviaba una URL prácticamente podíamos reconocer el nombre del dominio.

        https://myforo.com/path/doit&post=172356&comment=213

Ahora rara vez encontramos ese tipo de enlace con parámetros en la petición GET, sino que lo encontramos de una forma más entendible y bonita, incluso el propio enlace contiene el título de la página.

        https://mytsite.com/path/172356/213/my-post-title

Este cambio en las URL se debe a los motores de búsqueda y el posicionamiento de las páginas webs, un estudio demostró que cuanto más corta es la URL y más descriptiva del contenido del post es, Google te muestra en mejor posición.

lunes, 29 de junio de 2020

Análisis PCI Contactless Payments on COTS (CPoC™)

El pasado 4 de diciembre de 2019 el PCI SSC publicó en el repositorio de su página web (https://www.pcisecuritystandards.org/document_library) tres nuevos documentos relativos al programa CPoC - Contactless Payments on COTS (Commercial Off-The-ShelfDispositivos de caja cerrada):



jueves, 25 de junio de 2020

Kerberos: El perro de tres cabezas

Un entorno muy común que nos encontramos durante la realización de pentest internos es encontrarnos un Directorio Activo (DA). Es un servicio de directorio para su uso en un entorno de Windows Server. Se trata de una estructura de base de datos distribuida y jerárquica que comparte información de infraestructura para localizar, proteger, administrar y organizar los recursos del equipo y de la red.

Active Directory (AD) o Directorio Activo (DA) utiliza un protocolo llamado Kerberos para la autenticación de los clientes en la red.

lunes, 22 de junio de 2020

Posibles sanciones en caso de incumplir PCI DSS

Nota preliminar

Todo el contenido del artículo se menciona con fines meramente informativos. Las versiones de los documentos referenciados, y los requerimientos exigidos por las marcas de pago, pueden haber cambiado desde la última fecha de revisión del presente artículo. Adicionalmente, hay información que no puede hacerse pública, por lo que pueden existir requerimientos y/o sanciones adicionales a las explicadas en el mismo. Es por este motivo que se recomienda contactar con la entidad financiera prestadora de servicios, con el fin de obtener información vinculante y actualizada.

miércoles, 17 de junio de 2020

Novedades y actualizaciones de PCI DSS 4.0

El pasado día 29 de mayo, el PCI SSC actualizó en su blog la información relativa a la versión 4.0 del estándar PCI DSS.

La actualización de la información coincide con la revisión de los comentarios generados a raíz del ‘Request for Comments’ (RFC) que tuvo lugar entre octubre y diciembre del año pasado. Según indican, aún se encuentran revisando dichos comentarios. Como ya adelantaron el año pasado, habrá 2 rondas de RFC para la versión 4.0 del estándar, estando planeada la segunda a partir de septiembre u octubre del presente año.

De esta forma, también aprovechan para actualizar las fechas de lanzamiento de la versión 4 del estándar, planificándola para mitad del año 2021. Aunque la primera fecha que se indicó fue finales de 2020, ya se dijo que sería el mejor de los escenarios.

Conoce los últimos movimientos de nuestro equipo de ciberinteligencia

El pasado jueves 4 de junio el portal de RTVE publicó un artículo sobre las últimas filtraciones de Anonymous en relación con el homicidio del ciudadano afroamericano George Floyd en EEUU y desde el servicio Verifica de RTVE se pusieron en contacto con Vicente Aguilera para solicitar su participación dando su opinión al respecto. El artículo se puede leer en el siguiente enlace:
https://amp.rtve.es/noticias/20200604/sabemos-filtraciones-anonymous/2015525.shtml

lunes, 15 de junio de 2020

Crónica ISMS Cyber Security & Data Protection Online Forum


Fuente: ISMS Forum


Este año hemos tenido la oportunidad de poder asistir a la primera edición del Foro Digital Cyber Security & Data Protection Online Forum, organizado por ISMS Forum. Carlos A. Saiz, Vicepresidente de la organización, dio inicio a la jornada dando la bienvenida a todos los asistentes y anunciando la presentación de las dos nuevas guías elaboradas por diferentes grupos de trabajo de ISMS Forum: la Guía para la gestión de crisis por ciberincidente en la cadena de suministro y la Guía de Buenas prácticas en Auditorías RGPD. 

jueves, 21 de mayo de 2020

La certificación CISSP reconocida formalmente como Maestría o Posgrado.


El pasado 12 de mayo la UK NARIC, agencia nacional designada por el Reino Unido para el reconocimiento y la comparación de calificaciones y habilidades internacionales anunció que la certificación CISSP es comparable al estándar de maestría RQF Nivel 7 en el Reino Unido.

miércoles, 29 de abril de 2020

Tiempo de vida de los datos de carácter personal

Introducción

Una de las grandes dudas actuales, con respecto al tratamiento de datos de carácter personal, es el tiempo de almacenamiento de los datos personales que una organización recoge y trata.

A veces no se tiene claro cual debe ser el plazo de conservación de este tipo de datos y se opta por aplicar “la ley del por si acaso” la cual dicta que deben almacenarse de forma indefinida, por si son necesarios en algún momento. Como se puede intuir, esto no es solo una mala práctica, sino que aumenta el riesgo ante una fuga de datos (sobre datos que realmente ya no son necesarios) y, además, conlleva un gasto añadido de recursos tanto humanos, técnicos como económicos, que pueden tener un gran impacto en el negocio.

Por ello, es necesario que cada organización realice un análisis de todos los tipos de datos de carácter personal que recaba y/o almacena y analice el plazo de conservación o tiempo de vida necesario para dichos datos, de tal modo que solo se almacenen durante el tiempo mínimo necesario para el negocio y/o cumplir con responsabilidades legales.

Principios del RGPD relacionados con el tiempo de vida de los datos personales

Limitación de la finalidad y proporcionalidad
En la normativa vigente de protección de datos se indica que los tratamientos deben estar limitados en función de su finalidad, que ésta debe estar correctamente determinada y que los datos personales deben de haberse adquirido de una forma explícita, legítima y, además, también deben estar bajo el paraguas de la proporcionalidad:
  • Proporcionalidad:
    • Este principio indica que solo se deben recabar aquellos datos mínimos necesarios para prestar el servicio demandando o necesarios para el negocio; no se deben recabar datos innecesarios, es decir, los datos solo podrán recogerse cuando sean adecuados, pertinentes y no excesivos.
  • Explícito:
    • El interesado debe conocer la finalidad y/o finalidades para la cuales se están recogiendo sus datos de carácter personal.
  • Legítimo:
    • La organización que recaba los datos solo debe utilizarlos para aquellas finalidades o fines para las cuales está autorizada por el interesado.
Por tanto, no se podrán tratar ni conservar (que no deja de ser un tipo de tratamiento sobre un dato de carácter personal), de manera posterior a su recogida, para otros fines distintos para los cuales el interesado y propietario de los datos ha otorgado su consentimiento, excepto para lo que se conoce como fines ulteriores, que son, de forma exclusiva, los siguientes:
  • Con fines de almacenamiento en interés público.
  • Para investigación científica e histórica.
  • Fines estadísticos.
NOTA: Siempre que los datos sean usados para fines ulteriores se deberán utilizar técnicas que no permitan su identificación, tales como la anonimización o seudonimización.

Calidad de los datos

Atendiendo al principio de calidad de los datos de carácter personal, la legislación vigente de protección de datos personales establece que los datos deben:
  • Ser exactos.
  • Estar actualizados.
  • Solo ser usados para las finalidades indicadas al interesado. Si la finalidad cambia, los datos deben cancelarse.

Cancelación de los datos

Es el derecho que tiene todo individuo a solicitar al responsable del tratamiento la supresión definitiva de los datos de carácter personal que le conciernen. Esto puede ser debido a varias circunstancias:
  • Resulten excesivos o inadecuados.
  • Dejen de ser necesarios para la finalidad para la que se recabaron.
  • El interesado a retirado su consentimiento.
  • El interesado haya ejercido su derecho de oposición.
  • Se hayan tratado los datos de forma ilícita.
  • Debido a una obligación legal.

Estrategia de almacenamiento y borrado de datos personales

Una de las muchas estrategias que se pueden implementar para abordar la cuestión de ¿Cuánto tiempo es necesario almacenar los datos de carácter personal? es la siguiente:
  1. Política relativa al periodo de retención de datos y Autorregulación.
    Implementar una política formal para la retención de datos de carácter personal que indique los datos que se deben conservar, el periodo de tiempo por el cual se deben conservar, afectación de alguna legislación, así como el lugar donde residen los datos, de modo que se puedan destruir o eliminar de manera segura cuando ya no sean necesarios.

    Es importante y muy necesario conocer dónde se encuentran los datos de carácter personal (tanto los que se encuentran en soporte físico como los que se encuentran en soporte digital) para poder conservarlos o eliminarlos correctamente cuando ya no sean necesarios. A fin de definir los requisitos de retención apropiados, la organización primero debe entender las necesidades de su negocio, así como cualesquiera obligaciones legales y/o regulatorias que se apliquen en su industria y/o se apliquen al tipo de dato que se retiene.

    Esta política debe ser conocida por todas las partes interesadas, tanto internas (gerencia, empleados, etc.) como externas (proveedores de servicio, etc.) para que sea aplicada de forma correcta en las tareas diarias del día a día e intentar minimizar al máximo los posibles errores que pudieran existir.
  2. Seguridad en los activos de almacenamiento
    La información o datos de carácter personal y, en general, cualquier tipo de información que constituya un valor para una organización debe almacenarse en activos o soportes (servidores, discos duros, etc.) que ofrezcan una gran fiabilidad. Además, se le deberá proveer de las medidas de seguridad oportunas para evitar la pérdida u acceso a la información por terceras partes no autorizadas. Estas medidas de seguridad dependerán, en gran parte, del tipo de soporte sobre el cual se estén al almacenando los datos:
    • Soporte digital:
      • Control de acceso lógico.
      • Software antimalware.
      • Firewall.
      • Data Loss Prevention (DLP).
      • File Integrity Monitor (FIM).
      • Gestión de logs.
      • Etc.
    • Soporte papel:
      • Control de acceso físico.
      • Registro físico de acceso a la información.
      • Sobres anti-tampering.
      • Etc.
  3. Procedimiento de supresión de datos de carácter personal
    El proceso de borrado de los datos de carácter personal que exceden su periodo de retención, en ocasiones, puede ser tedioso y no del todo sencillo, sobre todo, si no se dispone de una buena gestión del ciclo de vida de los datos personales. Para ayudar en esta tarea, se hace necesario el uso de un procedimiento, que puede ser manual o automático, que revise de forma periódica los datos de carácter personal y proceda con el borrado seguro de aquellos que hayan excedido su periodo de retención.

    Por ejemplo, se podría implementar un procedimiento programático (automático, a través de herramienta automatizadas o manual) para encontrar y eliminar los datos personales o una revisión manual de las áreas de almacenamiento de datos revisando el periodo de retención de datos de los mismos y eliminando de forma segura (por ejemplo, a través de una destructora de papel) los datos de carácter personal.

    La implementación de métodos de eliminación segura, deben asegurar que los datos de carácter personal no se puedan recuperar cuando ya no sea necesarios.
  4. Programas de revisiones periódicas.
    Una buena práctica consiste en, de forma periódica (pero con un periodo de tiempo que no se extienda más allá de los 90 días), verificar que no existen en el entorno datos de carácter personal que han excedido su periodo de retención para, en primer lugar, comprobar la fiabilidad y eficacia de los procedimientos implementados y, en segundo lugar, cumplir con la legislación vigente en materia de protección de datos personales.

Periodos legales de prescripción de los datos

A continuación, se muestra una tabla en la cual se recogen los tipos de datos más comunes y sus plazos de almacenamiento según la legislación española vigente a 23 de abril de 2020:


Tipo Descripción Plazo
Contratos y otra documentación laboral
  • Contratos de trabajo, y anexos acuerdos adicionales.
  • Hojas de salarios.
  • Libro de visitas.
  • Actas de reuniones con el Comité de Empresa (en su caso).
  • Comunicaciones de apertura de centro de trabajo.
  • Contratos de puesta disposición formalizados con ETT (si procede).
  • Expedientes disciplinarios.
  • Acuerdos de extinción, y documentos de saldo y finiquito.
Plazo mínimo de 4 años.
Regla general de prescripción de las infracciones laborales a los 3 años (artículo 4.1 del Texto Refundido de la Ley sobe Infracciones y Sancionadores en el Orden Social (LISOS), APROBADO POR EL Real Decreto Legislativo 5/2000, de 4 de agosto.
El artículo 30 del Código de comercio establece un periodo mínimo de 6 años.
La Ley Orgánica 7/2012, de 27 de diciembre, recomienda guardarla durante 10 años
Nóminas
  • Los trabajadores solo deben firmar la nómina cuando se les pague en efectivo o mediante cheque o talón bancario. No es necesario cuando se les paga por transferencia bancaria porque el comprobante bancario del pago la sustituye.
  • La nómina tiene la función de acreditar el pago del salario por lo que la empresa debe guardar una copia, ya sea en papel o digital, en función de los plazos de prescripción.
En relación con el trabajador: las nóminas prescriben pasados 12 meses, que es el tiempo máximo que tiene el trabajador para reclamar una cantidad.
En relación con la Agencia Tributaria: el plazo de prescripción de todos los documentos, incluidas las nóminas, es de 4 años, desde el momento en que se presenta el impuesto.
En relación con la Seguridad Social: las nóminas y los boletines de cotización a la Seguridad deben guardarse durante un periodo mínimo de 5 años para permitir las comprobaciones oportunas.
En relación con la contabilidad: Las nóminas son un justificante de gasto, por lo que deberán conservarse durante seis años, según el Código de Comercio.
Seguridad social
  • Comunicaciones de alta y baja en Seguridad Social.
  • Documentos de cotización (TC1/TC2 Recibos de Liquidación de Cotizaciones) a partir de 2015 substituidos por RNT).
  • Certificados de situación de cotización Actas de infracción o Actas de liquidación.
Plazo mínimo de 4 años.
Las infracciones en materia de Seguridad Social prescriben a los 4 años (artículo 4.2 de la LISOS; Real Decreto Legislativo 5/2000 sobre Infracciones y Sanciones de Orden Social).
No obstante, es recomendable guardarla durante el periodo mínimo de 6 años que establece el artículo 30 del Código de Comercio.
La Ley Orgánica 7/2012, de 27 de diciembre, recomienda guardarla durante 10 años.
Prevención de riesgos laborales
  • Concierto con el Servicio de Prevención (en su caso) Plan de Prevención.
  • Planificación de la Actividad Preventiva o Plan de Riesgos.
  • Emergencia; documentación sobre información y formación a los trabajadores.
  • Evaluación de Riesgos; relación de accidentes de trabajo.
  • Expedientes de accidentes laborales o enfermedades profesionales.
Plazo mínimo de 5 años.
Las infracciones en materia de prevención de riesgos laborales prescriben a los 5 años si son muy graves (artículo 4.3 de la LISOS)
No obstante, es recomendable guardarla durante el periodo mínimo de 6 años que establece el artículo 30 del Código de comercio.
Curriculum Vitae Curriculums Se recomienda 2 años.
El Reglamento europeo de Protección de Datosestablece el límite de 24 meses para guardar CV sin actualizar.
Sanidad Datos de pacientes. Plazo mínimo de 5 años, pero depende de cada Comunidad autónoma.
Puede llegar a ser indefinido para ciertos documentos como altas, bajas o el consentimiento informado, entre otros.
Videovigilancia Datos procedentes de cámaras de videovigilancia. Plazo máximo de 1 mes. Para aquellas imágenes que se vean afectadas por la ley de seguridad ciudadana se podrán conservar durante 3 años.
Fines comerciales
  • Nombre y apellidos
  • Correo electrónico
  • Teléfono
Hasta que el interesado solicita la baja.
Otros documentos N/A Copia de documentos de identidad de ciudadanos extranjeros: un mínimo de 4 años.
Programas de desarrollo de carrera y de gestión de talento: un mínimo de 4 años.
Datos relativos a trabajadores temporales: un mínimo de 4 años.

Conclusiones

Cada empresa u organización es un mundo en sí misma, por lo que es probable que se traten datos de muy distinta índole y no se tenga claro qué periodo de retención se deba aplicar a cada uno de ellos. Esto conduce a que se planteen el tiempo de vida de los datos de carácter personal se sus clientes de una forma errónea utilizando la fórmula mágica del “guardarlo por si acaso” que no es el mejor de los planteamientos ni el más correcto, puesto que llevar acabo estrategias de este tipo puede derivar en multas mayores por parte de las autoridades de control de cada estado miembro.
No existe una regla fija o un plazo fijo para la eliminación de los datos personales como hemos visto anteriormente, sino que dependerá mucho de los tipos de datos que se traten y la normativa legal que les aplique. Por ello, hay que tener claro lo siguiente:
  • Los datos se deberán cancelar una vez hayan dejado de ser necesarios para la finalidad y/o finalidades para las que fueron recabados.
  • Se deberán bloquear aquellos datos que les sea de aplicación una ley o norma con rango de ley de obligado cumplimiento por parte del responsable del tratamiento.
  • Transcurridos dichos plazos, se deberán eliminar definitivamente los datos de carácter personal de todos los soportes donde se encuentren, ya sean digitales y/o en papel.
Lo ideal, es aplicar lo que hoy en día se conoce como “security by design”, es decir, instaurar la seguridad por defecto y, desde el principio, desde el primer momento en el cual se está diseñando un flujo de datos o un nuevo tratamiento de datos de carácter personal. En esta fase deberán contestarse 3 preguntas ¿qué? ¿cuánto tiempo? ¿cómo? También habrá que contestarse otras preguntas como ¿quién? ¿desde dónde se puede acceder? Pero estas preguntas darían para otro artículo.



Autor: Sergio Moreno - CCNA, PCIP, CCSP, CISSP, ISO 27001 L.A.
Dpto. Consultoría

miércoles, 22 de abril de 2020

Cifrado de datos de carácter personal

En la Era de la información global compartida y en un mundo cada vez más digitalizado y conectado, el valor de los datos para una organización y para los propietarios de dichos datos es, actualmente, indiscutible.

Tecnologías como el Big Data, el Knowledge Discovery, el machine learning, el datamining y, la tendencia de la sociedad a la contratación, cada vez más frecuente, de servicios digitales, hace que exista una creciente necesidad de proteger la información adecuadamente, incluyendo, el crecimiento exponencial de datos de carácter personal en las redes y, además, es necesario para salvaguardar los derechos y libertades fundamentales de los individuos que los comparten con terceras empresas a cambio de algún bien y/o servicio. Uno de los instrumentos más importantes y con mayor potencial para la protección de datos es el cifrado.

Además, en numerosas ocasiones, la recogida de datos es de vital interés para la realización de estadísticas, investigaciones, análisis de datos de tráfico o geolocalización, blockchain, etc. En principio, para poder hacer uso de los datos de carácter personal para estas finalidades, se debería recoger el consentimiento explícito de los interesados, aunque en determinadas ocasiones, y la tendencia ante este tipo de tratamientos es utilizar técnicas de anonimización o seudonimización como pueden ser, el token o funciones hash; esto último, se tratará en un futuro artículo.

A continuación, se presentan los fundamentos e importancia de utilizar este tipo de técnicas para la protección de los datos de carácter personal.

Cifrado de datos de carácter personal

El uso de técnicas de cifrado o criptográficas o, simplemente, el uso del cifrado es un elemento básico y fundamental en la política de seguridad de la información de cualquier empresa, ya que ofrece altas garantías de la confidencialidad de los datos que protege y, además, reduce el riesgo asociado por llevar acabo un tratamiento de dichos datos.

Aunque en ocasiones, hablar de cifrado, pueda parecer bastante lejano y complejo, sobre todo para organizaciones cuya actividad principal se encuentra lejos de un ambiente puramente técnico y/o tecnológico, es muy importante asimilar su concepto y aprovechar las ventajas que proporciona a la hora de proteger los datos de carácter personal frente a accesos y manipulaciones no autorizadas, además de respaldar la seguridad de los valores de la empresa y otorgar confianza, en materia de seguridad, a los clientes. Muchas empresas no cifran por miedo o por desconocimiento pero, Cifrar no es complicado, el coste es asequible y, los beneficios y ventajas que ofrece son visibles desde el inicio. 

Entonces empecemos por el principio… ¿Qué es el cifrado de datos?

Cifrar los datos se refiere al proceso por el cual una información pasa de estar en un estado legible a un estado ilegible o secreto, a través de un algoritmo de cifrado informático y una o varias claves de cifrado. Por tanto, cuando un dato es cifrado adquiere una serie de propiedades que lo hacen mucho menos vulnerable frente a accesos no autorizados y reduce el riesgo de divulgación de información confidencial, en este caso, de datos de carácter personal.

Un aspecto muy importante a tener en cuenta es que el uso de cifrado no elimina la naturaleza de dato de carácter personal, por lo que la información cifrada no es información anonimizada, y, por tanto, hay que tratarla como tal.

¿Cuándo, cómo y qué datos son necesarios cifrar?

Aplicar el cifrado para proteger absolutamente todos los datos de una empresa, en principio, puede no ser del todo práctico, sobre todo a la hora de abordar las operaciones necesarias llevar a cabo en el día a día, pero entonces ¿Cuándo y qué datos se deben cifrar? Pues se deberían cifrar todos aquellos datos considerados sensibles o de gran valor para dicha empresa y, centrándonos en los datos de carácter personal, en concreto, los que son considerados pertenecientes a categorías especiales, según recoge el RGPD:
  • Origen étnico o racial.
  • Opiniones políticas.
  • Convicciones religiosas o filosóficas.
  • Afiliación sindical.
  • Datos genéticos.
  • Datos biométricos dirigidos a identificar de manera unívoca a una persona física.
  • Datos relativos a la salud.
  • Datos relativos a la vida sexual o las orientaciones sexuales de una persona física.
Cuando se realice un tratamiento o se esté pensando en llevar a cabo un tratamiento de datos contenidos en la lista anterior, se debe pensar en el cifrado como un método de protección de dichos datos. Es importante, tener en cuenta la seguridad al inicio o en el nacimiento de cada tratamiento de datos, lo que se conoce como, seguridad por defecto y desde el principio, ya que no tener en cuenta la seguridad que se debe aplicar al tratamiento desde el comienzo, además de ser obligatorio por el RGPD, puede incurrir en futuros costes no previstos, cambios en las actividades principales del tratamiento, aumento del riesgo de fuga de datos, etc.

Para el resto de datos, lo ideal sería analizar y evaluar el riesgo, pero aunque el riesgo que obtengamos no sea demasiado alto y, por tanto, no sea obligatorio usar el cifrado, una organización podría utilizar esta herramienta de protección siempre que:
  • No impacte de forma grave en el negocio.
  • Quiera ser proactiva en cuanto a la seguridad.
  • Elemento diferencial, en cuanto a la privacidad se refiere, con respecto a la competencia.
Una vez conocemos los datos que debemos cifrar, ¿Cómo aplico el cifrado a los datos?

La Agencia Española de Protección de Datos (AEPD), en su Informe 494/2009, recuerda cuál es la importancia de emplear un cifrado correcto, de manera que sea legal y suficiente:
"La seguridad en el intercambio de información de carácter personal en la que hay que adoptar medidas de seguridad sobre datos sensibles de carácter personal, en particular los requisitos de cifrado de datos, no es un tema baladí, ni un mero trámite administrativo, ni una cuestión de comodidad. Es el medio técnico por el cual se garantiza la protección de un derecho fundamental y al que hay que dedicar el tiempo y los recursos que sean necesarios para su correcta implementación".
Además, a lo largo del Reglamento General de Protección de Datos (RGPD), también se contempla y se hace referencia, de forma constante, al uso del cifrado como un elemento básico de seguridad, como por ejemplo, en el considerando 83 “A fin de mantener la seguridad y evitar que el tratamiento infrinja lo dispuesto en el presente Reglamento, el responsable o encargado deben evaluar los riesgos inherentes al tratamiento y aplicar medidas para mitigarlos, como el cifrado” o en el artículo 6 “Licitud del Tratamiento”, entre otros.

Por otro lado, se le consultó a la Agencia Española de Protección de Datos si los sistemas de cifrado de ciertas herramientas empleadas de forma masiva en la mayoría de las empresas, como las de compresión de archivos (ZIP) y los sistemas de claves de los PDF, eran suficientes para cumplir la normativa vigente de protección de datos. Ésta, respondió: no son suficientes, debido a que para estos sistemas generales existen vulnerabilidades conocidas y los algoritmos de cifrado de los que hacen uso son manifiestamente vulnerables. Para un uso personal, en ciertos casos, puede ser útil el manejo de estas herramientas generales, pero nunca para un uso profesional.

Entonces hacer uso de un cifrado correcto implica lo siguiente:
  • Que el sistema de cifrado que se emplee no esté comprometido, es decir, que en el momento de utilizarlo no se conozca forma alguna de romperlo.
  • Que se disponga de un sistema de gestión de claves adecuado y robusto, así como de un procedimiento de administración de material criptográfico, en general.
A la hora de seleccionar un método de cifrado, a parte de tener en cuenta los dos puntos anteriores, se deberá tener en cuenta que las opciones disponibles cuentan con distintas características, por lo que será necesario analizar y elegir el sistema de cifrado que más se adecúe al servicio en el que se quiere integrar, es decir, si se va a utilizar para el envío de información a un tercero, si se requiere de cifrado en reposo, si se necesita una baja latencia, por ejemplo, para servicios online o en vivo, consumo de recursos, tiempo de establecimiento, rendimiento, coste, etc.

Si nos centramos en las dos grandes casuísticas dónde pudiera ser necesario el cifrado de datos de carácter personal, debemos tener en cuenta lo siguiente:
  • Transmisión de datos
    • Vía Web:
      • Hacer siempre uso de HTTPS a través de certificados emitidos por una entidad o autoridad confiable (no hacer uso de certificados autofirmados para conexiones públicas) y utilizando protocolos robustos como Transport Layer Security en su versión 1.2 o superior (TLSv1.2) ya que el resto de versiones y protocolos como SSL (en cualquiera de sus versiones) son vulnerables actualmente a ataques como POODLE o BEAST.
    • Vía Correo Electrónico: Hacer uso de criptografía asimétrica o de clave pública. La privacidad se garantiza cifrando desde el cliente de correo los emails con la clave pública del receptor; de este modo, sólo el receptor puede descifrar el contenido haciendo uso de su clave privada. Usando este tipo de criptográfica evitamos el riesgo de compartir una clave simétrica por un canal de comunicación que pudiera ser vulnerable. Ejemplos para correo electrónico de este tipo de criptográfica es el conocido Pretty Good Privacy (PGP) para clientes de correo pesados o Mailvelope para clientes de correo web. Lo importante de utilizar este tipo de soluciones es:
      • Por un lado, seleccionar una clave robusta y un algoritmo de cifrado robusto y recomendado por las buenas prácticas de la industria a través de organizaciones como el NIST.
      • Por otro lado, almacenar la clave secreta o privada en un lugar seguro (almacén de claves criptográficas) y que sea conocida exclusivamente por el propietario de la misma.
      NOTA: Cuando el destinatario del correo electrónico sea un particular, y no sea operativo hacer uso de PGP u otra herramienta similar, se deberán buscar alternativas que permitan enviar los datos sensibles de forma segura y, a la vez práctica, para el fin requerido. Por ejemplo, hacer uso de portales web securizados y, también, como última opción, acudir al cifrado a través de .ZIP seleccionando AES256 y utilizando una contraseña que deberá ser de una longitud 8 o superior y contener caracteres alfanuméricos y caracteres especiales. Importante: nunca se deberá transmitir la información cifrada y la contraseña por el mismo medio, siempre se deberá transmitir la contraseña por un medio distinto, como, por ejemplo, llamada telefónica, SMS, etc.
  • Almacenamiento de datos:
    • Cifrado de dispositivos: Haciendo uso de herramientas como Bitlocker,  VeraCrypt, AESCrypt, TrueCrypt, las cuales permiten un cifrado total o parcial del dispositivo y se basan en criptográfica sólida y robusta.
    • Cifrado a nivel de dato: Para esta casuística dependerá mucho se si los datos son estructurado o no estructurados y dónde residen los datos, por ejemplo, en bases de datos, aplicaciones, archivos, contenedores de almacenamiento. Las soluciones más estandarizadas son las siguientes:
      • Cifrado en bases de datos:  La mayoría de empresas que proporcionan tecnología de bases de datos, permiten configurar un proceso de cifrado nativo en sus bases de datos. Esta opción de seguridad, por lo general, se suele denominar TDE (Transparent Data Encryption). El cifrado de base de datos se puede proporcionar a nivel de archivo o de columna.
        • Cifrado a nivel de columna: En esta solución se elige qué columna o columnas, de qué tabla o tablas se desean cifrar y se aplica el cifrado sobre las columnas elegidas. Cualquier dato que se encuentre dentro de las columnas seleccionadas se cifrará de forma automática.
        • Cifrado a nivel de archivo: Se crea un archivo que contiene el tablespace cifrado y, todos los objetos que se creen o muevan ahí, estarán cifrados.
        Por lo general, el TDE realiza el cifrado y descifrado de datos de entrada y salida en tiempo real sin necesidad de que se produzca ninguna acción por parte del administrador del sistema y/o base de datos, como su nombre indica, la idea es que sea totalmente transparente.
      • Uso de HSMs: Para entornos que requieren mayores niveles de seguridad, los módulos de seguridad hardware (HSM) son la principal solución (también una de las más costosas) en cuanto a la gestión y administración centralizada de claves. Se trata de un procesador criptográfico diseñado para proteger, de forma específica, una clave criptográfica en todo su ciclo de vida. Estos dispositivos, por lo general, cumplen con varias certificaciones de seguridad como, por ejemplo, FIPS (a prueba de manipulación e intrusiones no autorizadas) y las claves se generan y almacenan en su interior.
NOTA: Sea cual sea la solución escogida, para proteger de forma eficaz la confidencialidad e integridad de los datos de una organización, lo importante es elegir una buena clave de cifrado lo suficientemente larga y seleccionar un algoritmo robusto y sin vulnerabilidades conocidas. Que un algoritmo sea robusto, atañe a la característica de fortaleza de un sistema de encriptación que se expresa mediante un valor conocido como “factor de trabajo”. Este factor de trabajo puede ser medido en tiempo computacional o coste económico de los recursos necesarios para romper el cifrado. Cuando el facto de trabajo es lo suficientemente alto, se considera que ese sistema de cifrado es robusto o invulnerable.

Para conocer qué algoritmos se consideran robustos (hay que recordar que el factor de trabajo solamente es válido para un periodo de tiempo determinado, ya que se debe tener en cuenta cómo avanza la tecnología y la capacidad de procesamiento) se puede recurrir a organismos oficiales como el NIST (National Institute of Standards and Technology) que se encarga, entre otras cosas, de catalogar los algoritmos y sus longitudes de clave en la publicación NIST Special Publication 800-57.

A día de hoy, alguno de los algoritmos considerados robustos, son los siguientes:

Algoritmo Longitud de la clave
AES 128 bits,192 bits, 256 bits
TDES/TDEA 112 bits y/o superior
RSA 2048 bits y/o superior
ECC (Elliptic Curve Cryptography) 224 bits y/o superior
DH (Diffie–Hellman) 2048/224 bits y/o superior

Como conclusión, en caso de que el cifrado no se realice de forma correcta y los datos de carácter personal quedaran expuestos a terceras partes no autorizadas, sea cual sea el tratamiento que estas partes hagan de los mismos, se estaría incurriendo en una cesión o comunicación pública de datos de carácter personal, definida en la LOPD como “toda revelación de datos realizada a una persona distinta del interesado” sin consentimiento alguno por parte de los interesados y, por tanto, susceptible de sanción por parte de la autoridad de control pertinente, en este caso la AEPD. Por lo tanto, es muy importante dedicar los esfuerzos y recursos necesarios para elegir una buena estrategia de cifrado que permita a la organización, por un lado, cumplir con la legislación vigente de protección de datos de carácter personal y, por otro lado, proteger sus datos de manera robusta y otorgar la confianza necesaria a sus clientes.

Autor: Sergio Moreno - CCNA, PCIP, CCSP, CISSP, ISO 27001 L.A.
Dpto. Consultoría

viernes, 17 de abril de 2020

RTVE vuelve a contar con Carlos Seisdedos para desmentir los bulos que corren por Internet

Actualmente son muchos los bulos que corren por Internet en relación al COVID-19, cómo por ejemplo la vigilancia de nuestras conversaciones de WhatsApp, o el confinamiento usando la violencia en Hungría o que el antiparasitario ivermectina proteja frente al COVID-19, entre otros.

RTVE ha vuelto a contar con Carlos Seisdedos, nuestro Responsable del Dpto. de Ciberinteligencia, junto con otros expertos en la materia para ayudarles a desmentir todos estos embustes que recibimos casi a diario en nuestro teléfonos móviles.

Podéis leer el artículo completo en el siguiente enlace:
https://www.rtve.es/noticias/20200415/whatsapp-censura/2011988.shtml

miércoles, 8 de abril de 2020

Vicente Aguilera participa en el evento Hackvoid organizado por la Generalitat de Catalunya y la Fundació i2CAT

Esta tarde a las 17:30, Vicente Aguilera participará como ponente en el evento Hackovid, organizado por la Generalitat de Catalunya (Departament de Polítiques Digitals i Administració Pública) y la Fundació i2CAT.

El evento será virtual, abierto y participativo y se ha creado para dar respuesta a las necesidades sociales relacionadas con la situación de confinamiento que estamos viviendo por la crisis de la COVID-19, así como las que surgirán posteriormente a medida que la actividad se vaya normalizando. Ante esta situación inédita, el talento de la comunidad TIC es clave para desarrollar herramientas digitales en tiempo récord y, así, resolver las necesidades sociales que más preocupan a la ciudadanía.

Se ha organizado un hackathon en el que participan más de 100 equipos, con el objetivo de desarrollar herramientas que cubran alguna necesidad social (tras un periodo previo de propuestas y votación, se identificaron 175 necesidades).

La ponencia de Vicente será para todos los grupos del Hackathon, y hablará sobre OWASP y el Top 10.

La Hackovid cuenta, además, con el apoyo de mentores, expertos y entidades de todo el país y promueve el desarrollo de soluciones innovadoras alineadas con los Objetivos de Desarrollo Sostenible de las Naciones Unidas.

Más información:
https://hackovid.cat/

martes, 7 de abril de 2020

Charlas, Entrevistas y Eventos desde el confinamiento

Carlos Seisdedos, del dpto. de ciberinteligencia, sigue participando en tertulias y saraos desde el confinamiento.

Por otro lado, el sábado 4 de abril se celebró el webinar Ronda de OSINT, organizado por Quantika 14 y en el que se habló sobre cómo identificar cuentas anónimas, darknet y terrorismo, y Carlos también participó como ponente.

Más información:
https://www.meetup.com/es-ES/hacking-sevillaQK14/events/269746327/

Carlos también participará en un evento creado especialmente para recaudar fondos para la Cruz Roja en la lucha contra el COVID-19, el c0r0n4con. Se celebrará los días del 9 al 12 de abril y en él habrá charlas técnicas, de concienciación, talleres. Carlos participará con la ponencia “Ciberterrorismo y Ciberinteligencia” el día 10 de abril.

Más información sobre el evento:
https://c0r0n4con.com/

Seguridad SSL/TLS: LUCKY 13

¿Qué es LUCKY 13?

El ataque Lucky Thirteen es un ataque de tiempo criptográfico contra implementaciones del protocolo Transport Layer Security (TLS), explota un problema de diseño de este protocolo y permite obtener información en texto plano a partir de un texto cifrado.

El nombre proviene del hecho de que los paquetes TLS cifrados tienen trece bytes de encabezado que se consumen en uno de los cálculos criptográficos en los que se basa TLS.

El nombre de esta técnica roza la ironía, ya que en cierto sentido, el número trece es de la mala (o buena) suerte. Sin embargo, cuando se pone en práctica el ataque, “Lucky Twelve” sería un nombre más acertado, ya que los encabezados de 12 bytes harían que el ataque sea aún más eficiente.

Características y Conceptos

Este es más un ataque teórico debido a la escrupulosidad de la sincronización diferencial de la respuesta del servidor a través de la red. Sin embargo, los investigadores Nadhem J. AlFardan y Kenny Paterson demostraron el ataque en el laboratorio con resultados fehacientes.

El ataque es aplicable con el modo de cifrado  CBC (Cadena de Cifrado Por Bloques) y con el esquema MAC (Código de Autenticación de Mensaje). El cálculo TLS MAC incluye 13 bytes de información de encabezado (5 bytes de encabezado TLS más 8 bytes de número de secuencia TLS) y es por eso que se llama Lucky 13, el cual explota una falla mencionada en la RFC 5246.
   
Antes de profundizar en el ataque, primero comprendamos los componentes básicos.
  • CBC (Cadena de Cifrado Por Bloques)

    Este modo de operación comienza dividiendo el texto sin formato en bloques de tamaño específico, dependiendo del algoritmo de cifrado simétrico subyacente; 8 para DES y 16 para AES. Cada bloque de texto sin formato realiza primero una operación lógica de disyunción exclusiva (XOR) con el bloque de texto cifrado anterior antes de cifrarse, de esta manera, cada bloque de texto cifrado depende de todos los bloques de texto sin formato procesados hasta ese punto. Para que cada mensaje sea único, se debe utilizar un vector de inicialización en el primer bloque:

    Cadena de Bloques de Cifrado (referencia)

    Si el primer bloque tiene el índice 1, la fórmula matemática para el cifrado CBC es:

    Fórmula Matemática Para Cifrado CBC

  • Ejemplo de Cifrado:
    Cifrado de un Mensaje (referencia)
  • MAC

    El código de autenticación de mensaje (MAC) se utiliza para confirmar que el mensaje proviene del remitente declarado y no ha sido alterado.

    El modus operandi de este algoritmo es el siguiente:
    1. Se calcula el MAC del texto sin formato.
    2. El resultado se agrega al texto plano.
    3. Se añaden bytes de relleno de modo que se convierta en múltiplo integral de la longitud del bloque.

    El último byte del último bloque indica cuánto relleno hay y todo el byte de relleno debe contener el mismo valor numérico. El relleno debe consistir en "p+1" bytes del mismo valor "p". Por ejemplo, si el último byte es 0x00, entonces será solo 1 byte de 0x00 y ese será el byte en sí mismo. Si el byte de relleno es 0x01, entonces serán 2 bytes 0x01 0x01 del mismo valor 0x01.
  • Cifrado TLS

    Para un mensaje "M" (payload), primero se agrega un "HDR||SQN" (encabezado TLS de 13 bytes) y luego se calcula una etiqueta "MAC tag" según el algoritmo negociado (MD5 / SHA1 / SHA256). Después de eso, se agrega relleno para hacerlo múltiplo integral de tamaño de bloque (8 bytes para DES y 16 para AES).

    Cálculo de MAC y relleno TLS (referencia)
  • HMAC

    También se requiere una breve comprensión de HMAC para entender en profundidad el ataque.

    HMAC es un código de autentificación de mensajes en clave-hash (HMAC) es una construcción específica para calcular un código de autentificación de mensaje (MAC) que implica una función hash criptográfica en combinación con una clave  criptográfica secreta.

    Por lo general, HMAC se calcula con un bloque de 64 bytes, con un encabezado de 8 bytes , y al menos 1 byte de relleno , por lo que efectivamente 55 bytes de datos es el tamaño máximo que se puede calcular una etiqueta en 1 bloque:

    64 – 8 – 1 = 55 bytes

    Si los datos son más de 55 bytes, se requieren 2 bloques. La función HMAC usa compresión, lo que significa que, si los datos superan los 440 bits, se necesitaría más tiempo de ejecución y, por lo tanto, la respuesta del servidor también se retrasaría. En general, 64 bytes de datos requieren un ciclo de máquina adicional. El tamaño de la etiqueta MAC es de 16 bytes (HMAC-MD5), 20 bytes (HMAC-SHA-1) o 32 bytes (HMAC-SHA-256).

    Se debe tener en claro lo siguiente:
    • 55 bytes, utilizan 4 ciclos de CPU.
    • 56 o más bytes, utilizan 5 ciclos de CPU.

¿Cómo se realiza el ataque?

Se explicará el ataque para el esquema de cifrado por bloques AES , cuyo tamaño de bloque es de 16 bytes y HMAC-SHA1 , que calcula 20 bytes de etiqueta.

En primer lugar, un atacante modifica y trunca el texto cifrado. Veamos cuánto necesita truncar. Esto depende exclusivamente de cada ítem mencionado anteriormente:
  1. De HMAC, conocemos que el cálculo de MAC de 55 bytes de datos presenta diferencias computacionales certeras respecto a los 56 bytes de datos, ya que 56 bytes (o más) requieren un ciclo adicional completo de máquina. Entonces, nuestro objetivo es encontrar un bloque de cifrado tal que obtengamos estos 55 bytes de datos.
  2. Sabemos que el cálculo de MAC también usa 13 bytes de HDR (5 bytes) y SQN (8 bytes). Dado que el bloque de cifrado no contendrá estos bytes, restemos para obtener bytes reales, el bloque de cifrado debe tener:

    55-13 = 42 bytes

  3. Ahora agregue el tamaño de la etiqueta, ya que estamos usando SHA-1, son 20 bytes:

    42 + 20 = 62 bytes

  4. El tamaño de bloque más cercano (16) múltiplo de 62 es 64 ( 4 bloques de 16 bytes cada uno). Tenemos que sumar 2 bytes adicionales para obtener 64 bytes.

Por lo tanto, para HMAC-SHA1, tenemos que truncar en 4 bloques y modificar 2 bytes.
Estos 2 bytes serán nuestro terreno de juego para recuperar texto sin formato.

Para descifrar el mensaje, el atacante debe enviar lo siguiente:


Envío de Paquete Malicioso

  • HDR es el encabezado TLS.
  • C₀ es el vector de inicialización.
  • C₁ -C₄ son los bloques de cifrado truncado.
Para TLS, SQN no se envía, pero el emisor y el receptor sin embargo lo agregan.

C₄ es el bloque objetivo con texto plano que el atacante desea explotar. El atacante modificará el bloque anterior, es decir, C₃ con un valor de 16 bytes denotado como Δ (delta).

Analicemos el siguiente diagrama de codificación de cifrado de bloque:

Descifrado AES-CBC (referencia)


En circunstancias normales, es decir, sin ninguna modificación del atacante, la fórmula para descifrar el bloque 4 con la información que contiene es:

                                                            P₄ = (C₄) ⊕ (C₃)

La misma se altera cuando comienza el ataque, debido a que C₃ se modifica con Δ:

                                                            P* = (C₄) ⊕ (C₃⊕ Δ)

De las dos ecuaciones anteriores podemos deducir entonces:

                                                            P* = (P₄) ⊕ (Δ)

Esta es una relación importante entre la información modificada y los datos que el atacante desea obtener en texto plano. Entonces, el receptor primero descifra el paquete transmitido, elimina los bytes de relleno y el MAC, y nuevamente calcula el MAC del texto descifrado para compararlo con el MAC recibido.

Los siguientes escenarios se pueden dar en el lado del receptor una vez que finaliza el descifrado:
  • La comprobación de relleno falla: Esto significa que los últimos bytes y los bytes de relleno no coinciden. Por ejemplo, el último byte es 0x75 , lo que significa que todos los bytes de número 0x75 anteriores también deben contener un valor numérico de 0x75, sin embargo el proceso falla.
  • La respuesta (que sería un MAC incorrecto) regresó en menos tiempo: Este es un caso interesante, y significa que el cálculo de MAC utilizó menos de 55 bytes. Dicho escenario solo puede ser posible si los últimos 2 bytes son 0x01 0x01 o incluso 0x02 0x02 0x02, en todos estos casos se utilizan 64 bytes de bloque de cifrado debido a 42 + 13 bytes de HDR||SQN = 55 bytes.
    Descifrado del rendimiento del último bloque 0x01 0x01 (referencia)
  • El relleno es correcto, pero toma más tiempo: Significa que el último byte es 0x00, entonces el último byte se calcula como 64–1 (1 byte de 0x00) - 20 (etiqueta SHA-1) = 43 bytes + 13 bytes de HDR || SQN = 56 bytes.
Por lo tanto, solo el segundo caso toma menos tiempo y eso significa que en P* los últimos 2 bytes son 0x01 0x01 y que poseemos una relación entre P₄ y P*. El atacante puede recuperar los últimos 2 bytes de P₄.
                                                                P* = (P₄) ⊕ (Δ)

En la práctica, el atacante debe realizar una gran cantidad de cálculos, más precisamente 2¹⁶ (2⁸ por cada byte). Tenga en cuenta que cuando falla el cálculo de MAC, la sesión se cerrará. Por lo tanto, el atacante debe implementar un modelo que inicie una conexión múltiple inyectando JavaScript.

Mitigación

  • Escriba el código de tal manera que los casos de éxito y error consuman el mismo tiempo para que un atacante no pueda medir la diferencia de tiempo.
  • Utilice cifrados AEAD como AES-GCM, estos cifrados calculan MAC mientras cifran el mensaje en sí.
  • Cifre el texto sin formato primero, luego genere un MAC basado en el texto cifrado resultante.
  • Utilice versiones no vulnerables de las librerías que implemente en sus sistemas, como por ejemplo, la versión 1.1.1.* de OpenSSL.
  • Para evitar el ataque LUCKY13, use la siguiente configuración de TLS en los siguientes servidores:
    • Apache:
      • Con apache, la configuración SSL/TLS se almacena en:
        "/etc/apache2/mods-enabled/ssl.conf" Si usa "Let's Encrypt", la configuración puede residir en: "/etc/letsencrypt/options-ssl-apache.conf"

        Para habilitar solo los cifrados con cifrado alto y protocolos recientes establecidos utilice la siguiente configuración:
        SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
        SSLCipherSuite ECDHE-ECDSA-
        AES256-GCM-
        SHA384:ECDHE-
        RSA-AES256-GCM-SHA384:ECDHE-
        ECDSA-CHACHA20-
        POLY1305:ECDHE-
        RSA-CHACHA20-
        POLY1305:ECDHE-
        ECDSA-AES128-
        GCM-
        SHA256:ECDHE-
        RSA-AES128-GCM-
        SHA256:ECDHE-
        ECDSA-AES256-
        SHA384:ECDHE-
        RSA-AES256-
        SHA384:ECDHE-
        ECDSA-AES128-
        SHA256:ECDHE-
        RSA-AES128-
        SHA256
        SSLHonorCipherOrder On
        SSLCompression Off

        Luego vuelva a cargar la configuración del servidor Apache.

        Tenga en cuenta que esto limita las suites de cifrado y la versión del protocolo a versiones recientes de SSL/TLS que pueden excluir a los usuarios con navegadores más antiguos.
    • Nginx:
      • Para Nginx, actualice el archivo de configuración que generalmente se encuentra en:
        • /etc/nginx/nginx.conf
        • /etc/nginx/sited-enabled/yoursite.com (Ubuntu/Debian)
        • /etc/nginx/conf.d/nginx. conf (RHEL / CentOS)

          Agregue la siguiente directiva a la sección del servidor:
          SSLProtocol TLSv1.2;
          ssl_ciphers 'ECDHE-ECDSA-
          AES256-GCM-
          SHA384:ECDHE-
          RSA-AES256-
          GCM-
          SHA384:ECDHE-
          ECDSA-
          CHACHA20-
          POLY1305:ECDHE-
          RSA-CHACHA20-
          POLY1305:ECDHE-
          ECDSA-AES128-
          GCM-
          SHA256:ECDHE-
          RSA-AES128-
          GCM-
          SHA256:ECDHE-
          ECDSA-AES256-
          SHA384:ECDHE-
          RSA-AES256-
          SHA384:ECDHE-
          ECDSA-AES128-
          SHA256:ECDHE-
          RSA-AES128-
          SHA256';
          ssl_prefer_server_ciphers On


          Luego reinicie el servidor Nginx.

          Tenga en cuenta que esto limita las suites de cifrado y la versión del protocolo a versiones recientes de SSL/TLS que pueden excluir a los usuarios con navegadores más antiguos.

Referencias


Autor: Pablo Gonzalo Carrasco - CEH
Depto. Auditoría