Analytics

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

viernes, 3 de abril de 2020

Participamos en el webinar Gestión de crisis del COVID 19: experiencias prácticas en Iberoamérica, organizado por UNITAR

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

Ayer día 2 participó como experto en ciberseguridad y ciberinteligencia en el Webinar: Gestión de crisis del COVID 19: experiencias prácticas en Iberoamérica, organizado por el Instituto de Naciones Unidas para la Formación e Investigaciones (UNITAR) y los diversos centros CIFAL de Iberoamérica.

El webinar consistió en un diálogo constructivo y divulgativo entre profesionales de varias disciplinas localizados en España y varios países de América Latina, quienes hablaron sobre las políticas públicas y la reacción de la sociedad, observadas en la lucha global contra la pandemia del COVID-19 en Iberoamérica.

Desde el periódico La Vanguardia se hicieron eco de este evento, hacen mención de Carlos: https://www.lavanguardia.com/local/sevilla/20200403/48282096404/coronavirus--cifal-reune-a-expertos-para-analizar-la-gestion-de-la-crisis-en-el-ambito-iberoamericano.html

jueves, 2 de abril de 2020

Crónica MundoHackerDay 2020


Como ya es costumbre, otro año más volvemos a Mundohakerday. Esta edición se realizó de manera diferente, tuvo lugar en el Ifema y se realizó en dos días jueves 27 y viernes 28 de febrero.

En primer lugar empezamos directamente con una charla, la cual fue impartida por el futurista destacado Ian Khan, sobre la “Era de la confianza artificial”. En la cual nos comentaba que en apenas dentro de pocos años los ordenadores tendrán la misma capacidad que los humanos y podrán hacer lo mismo que nosotros.

Continuamos con la segunda charla del evento “El nombre es Ciberseguridad. Pero las consecuencias son físicas. Siempre” que fue impartida por Ramsés Gallego y hacía referencia a la falta de seguridad y al impacto que pueden llegar a crear los ataques informáticos. Mencionaba que hoy en día un atacante con  conocimientos informáticos es capaz de conseguir y vulnerar muchos de sus objetivos. 
La siguiente  pero no menos importante, fue impartida por Jaime Andrés Restrepo con “Lo que nadie te dijo antes de dedicarte al Bugbounty”  en la que con su experiencia nos relataba los casos más destacados y algunos de sus trucos a la hora de dedicarse al BugBounty. Nos daba recomendaciones sobre las dificultades con las que nos podemos encontrar y casos reales que le han pasado a él para intentar de alguna manera evitarlos y ser más astutos  a la hora de repórtalos una vez que hemos detectado el Bug.

Luego continuamos con la charla Pablo Teijeira con “Seguridad: del departamento del NO al departamento del "sí, ¡por favor!"” en la que nos ponía ejemplos sobre sucesos que ocurrían y ocurren por la falta de seguridad desde la antigüedad hasta la actualidad. Y una frase muy buena y que recomienda que más vale prevenir que luego intentar remediar. Que el tiempo que dediquemos a intentar prevenir problemas vale mucho más que luego intentar solventarlos cuando ocurran.
Para seguir tuvimos con nosotros a Gabriel Lazo cuyo nombre de la charla fue “Nuevos paradigmas tecnológicos, de la ciberseguridad y el cibercrimen” hablaba sobre la tecnología que se aplica actualmente en las empresas y como estas han cambiado gracias a ella. Hablaba también sobre el cibercrimen y la ciberseguridad lo importante que es hoy en día y donde entra el cibercrimen lo fácil que puede llegar a ser obtener datos o vulnerar nuestro objetivo omitiendo todas esas fases de un ataque y obtener todo esto haciendo búsquedas en el mercado negro.

Posteriormente hicimos una pequeña pausa.
Este año echamos en falta la participación de algunas de las comunidades.



Después del parón continuamos con Alberto Cartier con “Lee la mente” nos enseñaba como conocer mejor a una persona con el lenguaje no verbal.  Ponía ejemplos de cómo ese lenguaje nos puede dar pistas para conocer mejor a la persona con la que estamos hablando mediante expresiones corporales, micro expresiones faciales, gestos adaptadores e ilustradores.

Joel Serna Moreno con “Bypass of Air Gap environments”  nos hablaba de cómo es posible hacer un bypass de air gap y conseguir así una ex filtración de datos. Nos explicaba el concepto de Air gap, una medida de seguridad de red para garantizar el aislamiento de equipos físicamente usada en sistemas militares, controles industriales, centrales nucleares, aviación...

Otro año más, contamos con la presencia de Deepak Daswani cuya charla fue “Smart Things Hacking” que nos mostró las inseguridades de las cosas conectadas a Internet. Como siempre mostrando ejemplos en tiempo real, en este caso un ejemplo de cómo es posible hackear y obtener datos en un Smart TV de la marca Samsung e indicando que también es posible incluso hackear otras marcas de televisores.

Y como no, seguimos con Antonio Ramos con “Big little lies in Social Networks”  trata sobre como un estafador con las habilidades suficientes puede llegar a ser nuestro jefe, nos explica a través de Linkedin a ser un profesional de la estafa, sabiendo rellenar un falso perfil que no suele analizar nadie, pudiendo con esto saltarte toda una plataforma digital  y conseguir tu objetivo sin tener los valores que dices tener. Nos pone un ejemplo que realizo el mismo, creándose un falso perfil y consiguiendo con este una llamada para ocupar el puesto que decía poder ocupar.

Después de la charla de Antonio, realizamos otro descanso y proseguimos con Sara G. Antúnez que nos explicaba los ciberdelitos que se comenten en Internet, como las amenazas, relevación de secretos, estafas, usurpación de identidad, etc... y las consecuencias de los mismos. A su vez nos informaba de como estos se acogen a nuestra legislación. También nos indicaba como poder garantizar nuestra seguridad desde un punto legal.

Más tarde se dio paso a Daniel López Jiménez en cuya presentación nos demuestra que hay una gran parte manual a la hora de atacar un directorio activo y a no depender tanto de las herramientas manuales. Hacía hincapié en que es importante conocer en sí bien la información, del porque es importante esa información, obtener esa información como los usuarios del dominio, los equipos del dominio, los grupos, las OU y GPO, los Bosques o dominios de confianza y ACLS.

Para finalizar y terminar el día, acabamos con Leonardo Nve que nos mostraba un caso de una explotación real de vulnerabilidades de las cuales seguimos teniendo y que han sido detectadas desde hace varios años.

Al día siguiente se dieron lugar diferentes talleres, los cuales tenían un aforo máximo de 100 personas por taller. Estos fueron divididos en 3 salas:

En el primer taller contamos con Carolina Gómez y Marta Barrio con “Phishing to 2FA”. En su taller explicaban como analizar el contenido de un correo de phishing una vez que se ha recibido. Recomendaban el uso de un segundo factor de autenticación para proteger nuestras cuentas y por tanto, estar protegidos ante un phishing pero, que se mostrará cómo no es un método infalible con ejemplos en tiempo real.

Después nos acompañó Rafael Cerrato con la charla de  “La WiFi sin control no sirve de nada. Lo que deberías saber sobre seguridad WiFi”, en su taller nos fue mostrando el tipo de seguridad que se aplica en las Wifis y algunos ejemplos de cómo se puede vulnerar su seguridad y soluciones que se aplican para hacerlas más seguras.

Antonio Navas Casado y Víctor Flores continuaron con una interesante charla sobre, “Hackers Vs Skynet, la revolución del pentesting” en la que hablaban de los distintos entornos que podemos encontrarnos hoy en día. Nos comentaban ejemplos de las metodologías de defensa para descubrir y prevenir ante incidentes, Las maneras ofensivas que podemos tener como un pentesting o test de intrusión. Luego por otro lado dos ejemplos prácticos basados en casos reales, en el que era posible realizar una suplantación de identidad y otro ejemplo de ingeniería inversa de una apk y cómo es posible la escalación  de privilegios .

Seguimos con Pedro Candel  y su “Descubrimiento y explotación práctica de vulnerabilidades en dispositivos IoT”. El taller lo realizó de manera práctica aplicando la metodología OWASP del TOP 10 en IoT (Internet de las Cosas) en la que se trababa de descubrir y explotar las vulnerabilidades analizando las amenazas que estás suponen con los  riesgos y con los correspondientes escenarios de ataque.

Luego se dio paso al descanso, en la que se podía aprovechar para ver los stands de algunos de los patrocinadores y/o aprovechar el CTF que nos proponía la compañía de IMMUNE.

El CTF (Respuesta ante incidentes en las puertas de Mordor) para participar, lo primero que te daban es una serie de recomendaciones y seguido era necesario que trajeras tu equipo para participar. El CTF se trataba de realizar un análisis a raíz de una intrusión realizada por un atacante.  Y la misión era averiguar qué había pasado, como y donde había sucedido el ataque y proponer soluciones para que no vuelva a ocurrir.

Después de la pausa continuamos con los últimos tres talleres para terminar y seguimos ahora con Carlos Loureiro y su ponencia de “DefCon: “Machine Learning para Jack Bauer”. En ella nos mostraba el uso de técnicas de Machine Learning y como se pueden llegar a aplicar a la Global Terrorist Database (que es una base de datos mundial sobre terrorismo), con la finalidad de generar predicciones a nivel de Inteligencia que permitan identificar diferentes características de un atentado terrorista. Identificando así si es por una sola persona o un grupo, si se trababa de una acción o múltiples y si era un grupo terrorista el que comente la acción.

Al mismo tiempo y en otro taller vimos a David Conde con la presentación “DFIR – Real crime scene”, (Digital Forensics and Incident Response) Nos enseño como funcionan los escenarios de investigación dentro de un entorno tras un incidente de seguridad con casos prácticos y que tipos de acciones podemos llevar a cabo.

En otro taller paralelo seguimos con Manuel Blanco Parajón con “Hunting the wild” que en su charla nos contaba los incidentes  reales de un sample de un ransomware que secuestraba los datos y que actualmente seguía activo.Ya que no había muestras reales ni ninguna documentación que explicase como actúa y como se pueden descifrar estos archivos cifrados. En ella mostraba el proceso de ingeniería inversa que se aplicaba a esta familia de ransomware FLKR y mostrando como a partir de un volcado de memoria el poder recuperar todos los archivos cifrados.

David Marugán y su charla de “Introducción la radioescucha y SDR”: En su taller nos enseñaba que es un SDR, como realizar la configuración básica de un SDR  y posteriormente así poder usarlo para realizar escuchas y decodificaciones de señales. Nos mostraba también algunos de sus conocimientos sobre radioescucha y el espectro radioeléctrico y las herramientas utilizadas tanto software como hardware que se pueden utilizar.

Autor: Héctor Berrocal - CEH, MCP, CCNA, ITIL
Dpto. Auditoría