Select Page
Ciber predicciones 2020

Ciber predicciones 2020

Para finalizar el año, les dejo este análisis de diferentes predicciones en ciber seguridad para el 2020 hechas por distintos sitios especializados en el tema.
Se acerca el fin de año (bueno, hoy es fin de año) y todos hacen sus balances del año que pasó y sus proyecciones de lo que puede venir. Hace algunas años hice algún balance. Este año quise dejarles un análisis de sus predicciones hecho a unos 20 sitos de ciber seguridad. En cada sitio se utilizan diferentes criterios para evaluar y proyectar qué es lo que puede pasar en materia de ciber seguridad en el año que comienza mañana.
Esta vez, mi trabajo fue recopilar todas esas proyecciones, extraer los temas que cada uno trata como destacado y darles un puntaje a cada tema. Ese puntaje fue dado arbitrariamente por mí en función de la cantidad de veces que se repetía un tema en los diferentes sitios y de la importancia que cada uno le da a cada tema.
El puntaje entonces, correspondería al interés que se le asigna a cada tema.
El resultado fue un score sobre 23 temas extraídos de los diferentes sitios.

 

Los sitios con los que me quedé fueron los siguientes:

Helpnetsecurity, Circadence, CheckpointTheHackerNewsCyberSecurityMag, Information edgeTechrepublic, SdxcentralCyberscoop, ScmagazineWatchGuardForbes y Forescout.

Y el resultado fue el que se ve en la figura a continuación:

El gráfico está ordenado de mayor a menor interés. En los temas de las predicciones se mezclan varias categorías. El tema de interés puede ser:

  • un ataque
  • un blanco
  • un vector de ataque
  • una contramedida

Brevemente, los temas de interés se definen de la siguiente forma:

Phishing + Awareness: Se refiere específicamente a ataques de phishing (que se verían muy incrementados en 2020) y a su principal contramedida: la concientización.

Cloud: Según los especialistas, la gran adopción que se hizo de la nube en 2019 y la que se proyecta para 2020, servirá de vector de ataque en muchos de sus servicios. El que más se destaca por sus vulnerabilidades es Office365.

Inteligencia artificial: Ya se vienen utilizando técnicas de Inteligencia Artificial y Machine Learning en sistemas de ciber defensa. Se había proyectado de la misma forma que se empezarían a utilizar estas técnicas como ataques, sin embargo no se tiene registro que ese tipo de ataques se hubiese producido todavía. Pero se prevé para 2020…

Ransomware: En los primeros lugares en las predicciones siguen estando los ataques de ransomware. Es realmente incomprensible que existiendo tecnologías que permiten bloquear Ransomware con 100% de efectividad, sea ésta una de las principales amenazas para 2020.

IoT: El enorme crecimiento de la base instalada de dispositivos de Internet de las Cosas y sus múltiples vulnerabilidades, hacen prever un incremento en los ataques durante el próximo año.

Deepfakes: De estos ataques se habla muchísimo en los Estados Unidos debido a que 2020 es año de elecciones. Las noticias e información falsa se considera un arma muy poderosa a la hora de tratar de modificar las intenciones de los votantes.

5G/WiFi: El advenimiento de la tecnología 5G, sus vulnerabilidades o las asociadas a los dispositivos móviles y las propias de WiFi hacen prever una gran actividad de ataques utilizando algunos de estos mecanismos.

Gobiernos: Existe gran preocupación por la intervención de gobiernos o estados en la generación de ciber ataques.

Widen attack surface: El incremento en el tamaño de la superficie de ataque global es un hecho para 2020. Esto se deberá a diversos factores como ser: el incremento en la cantidad de vulnerabilidades, la utilización masiva de la nube con sus vulnerabilidades propias o la incorporación de millones de dispositivos IoT vulnerables.

Robots: Se prevé un gran incremento de la utilización de técnicas de automatización en procesos para el año próximo. Si bien estas técnicas ayudan mucho a los administradores de seguridad, también lo hacen (y lo harán) a los atacantes…

Skill Gap: Ya se viene hablando hace un tiempo de un aspecto en el mundo de la ciber seguridad que es realmente preocupante. Es la brecha de conocimientos que existe entre quienes atacan y quienes defienden. Los atacantes tienen más conocimientos que los defensores. La brecha viene en aumento y se prevé que para 2020 seguirá en aumento.

Servicios financieros: Otro blanco de ciber ataques que sigue en aumento son los servicios financieros y bancarios. Se dice que esto seguirá en aumento en 2020.

Reuso de passwords: Una falla que hoy por hoy no debería existir, inconcebiblemente parecería que en 2020 irá en aumento.

Infrastructuras Críticas: Lo que comenzó con Stuxnet hace ya 10 años, es una carrera que no se ha detenido. Cada vez más las Infraestructuras Críticas serán blanco de ataques.

Sector de Salud: Otro sector, por cierto muy descuidado desde el punto de vista de ciber seguridad, sería blanco de ciber ataques durante 2020 mucho más en en años anteriores.

Zero trust: Este nuevo concepto se visualiza como una tendencia a implementar durante 2020 para evitar ser blanco de ciber ataques.

Móviles: Las vulnerabilidades en las aplicaciones móviles harán que haya muchos más ataques de este tipo el año próximo.

PyMEs: Un ámbito que hace unos años parecía no atractivo para ciber atacantes, lo es cada vez más y parecería que las PyMEs serán blanco de ciber ataques mucho más que en años anteriores.

Computación cuántica: Varios especialistas hablan de cómo la computación cuántica será un ante y un después en la ciber seguridad.

Detección de amenazas: Los sistemas SIEM son cada vez más complejos pero a su vez conllevan un incremento en la fatiga del analista. Se dice que durante 2020 mejorarán las técnicas para utilizar estas tecnologías en la detección de amenazas. Veremos…

Ciber Seguros: Un rubro que viene creciendo silenciosa pero inexorablemente parece tener previsiones de mejoras en sus mecanismos y en su adopción.

Privacidad: Del mismo modo que varios países intentan poner límites a la privacidad del uso de las redes, existen muchas iniciativas para saltear esos límites. Al parecer, esta guerra se intensificaría en 2020.

DevSecOps: Dado  que hoy en día, el software es una de las mayores fuente de vulnerabilidades, la adopción de esta metodología se incrementaría considerablemente durante el próximo año.

 

Al final del 2020 haremos el ejercicio de ver cuánto se cumplieron estas predicciones.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Cayendo en la trampa del Fallback…

Cayendo en la trampa del Fallback…

La empresa china eyeDisk desarrolló lo que prometía ser un pendrive “inhackeable“[1] y terminó siendo tan inseguro como cualquiera, por el inocente agregado de un fallback.

Todos los que estamos en este negocio, conocemos las dimensiones de seguridad de la información. Las 3 principales son: confidencialidad, disponibilidad e integridad. Nuestra tarea desde seguridad, es la de definir el esfuero y los recursos para protegerlas adecuadamente. Pero dependiendo del contexto y del negocio o la misión particular, a veces no todas las dimensiones se deben proteger de la misma forma.

 

Un caso extremo:

En el caso de las redes OT, a través de las que se controlan procesos industriales, la dimensión más importante a proteger es la disponibilidad. Muy especialmente en infraestructuras críticas. La interrupción de un servicio o proceso industrial no sólo puede llegar a costar muchísimo dinero, sino que además puede provocar gravísimos daños en el equipamiento o hasta en el medio ambiente. Es por esto que todas las medidas de protección van a estar enfocadas en que la disponibilidad sea lo más invulnerable posible. Integridad y confidencialidad se dejan en segundo plano.

 

Un caso intermedio:

Al desarrollar sistemas de protección, muchas veces se establecen, diseñan e implementan estrategias de vías o caminos alternativos para el caso que algún componente falle. Es el esquema de “fallback” o “plan B” en el que a veces se deben establecer relaciones de compromiso en las que se pierden o degradan algunas características de seguridad para mantener otras.

Un ejemplo de esto es el sistema de cifrado de la telefonía celular. Cuando se establece una comunicación entre teléfonos celulares, la información viaja cifrada. Esto se hace para que nadie que tenga un receptor de radio en la frecuencia de emisión de la comunicación, pueda interceptar fácilmente las conversaciones. El sistema de cifrado que se usa en GSM es la familia A5. Sin entrar en la discusión de las vulnerabilidades particulares de estos algoritmos (tanto A5/1 como A5/2 fueron rotos), es importante mencionar que la familia está compuesta por 5 miembros: A5/0, A5/1, A5/2, A5/3 y A5/4.

Cada algoritmo posee mayores fortalezas de cifrado que el anterior y, como consecuencia, de consumo de recursos. A pesar de que muchas veces no lo notamos por las deficiencias de las redes, en realidad los sistemas celulares están diseñados para que las comunicaciones nunca se interrumpan. Entonces, el uso de algoritmos de cifrado más fuertes, está íntimamente relacionado con contar con muy buena señal en los dispositivos. ¿Qué pasa entonces si estamos en una condición de baja señal? El sistema tiene varias instancias de fallback, en las que los algoritmos de cifrado se van degradando para no perder la comunicación. En el caso de tener muy baja señal, nuestros celulares bajan hasta el modo A5/0 en el que la comunicación no se cifra en absoluto. En este caso, alguien podría escuchar nuestras conversaciones.

Pero el negocio manda. Es decir, en telefonía celular, si bien no es tan crítico como en el caso de sistemas industriales, la dimensión que más se preserva es la de disponibilidad. ¿La razón? es más que obvia: segundo que el sistema no funciona, segundo que no se factura…

El fallback que implica la degradación de la privacidad está incorporado por diseño con toda la intención de que sea así.

 

Un caso erróneo:

Ahora bien, cuando se diseña un dispositivo cuyo principal objetivo es preservar la confidencialidad. Cuando se anuncia con bombos y platillos que el sistema es absolutamente “inhackeable“, se deben tomar ciertos recaudos. La firma china eyeDisk desarrolló por la modalidad de crowdfunding un pendrive que incorpora la sofisticada tecnología de lectura de iris para asegurar la confidencialidad de los datos que él se almacenen.

Según sus especificaciones, el acceso a los datos sólo puede hacerse mediante la lectura de iris del dueño. Teniendo en cuenta que el sistema de lectura de iris es resistente a la lectura de imágenes o fotografías, la empresa parecía haber creado el perfecto “for your eyes only“…

Sin embargo, David Lodge, de PenTestPartners, descubrió recientemente que si bien la resistencia a ataques de lectura de iris es real, el fallback del sistema compromete completamente la confidencialidad tan promocionada. Si la lectura de iris falla, se puede desbloquear el contenido del pendrive con una contraseña provista por el usuario al momento de la configuración.

Resulta que investigando la manera en la que se transfieren los datos, el investigador descubrió que internamente, la contraseña almacenada se transfiere via USB desde el dispositivo a la PC antes de la validación y en texto plano!!! Por esta razón, con sólo un poco de conocimientos y esfuerzo, es posible obtenerla y usarla…

 

Usando fallbacks

Hay veces que sinceramente no entiendo la forma en la que se diseñan los sistemas. En el caso de eyeDisk “el” argumento de venta del producto es la imposibilidad de que sea hackeado. El usuario debería quedarse 100% tranquilo de que si pierde un pendrive con información valiosa, nadie tendría forma de recuperarla mientras el pendrive no vuelva a encontrarse con el ojo del dueño. El concepto es muy bueno…!!! ¿qué necesidad hay entonces de crear un fallback que permita al usuario desbloquear el pendrive haciendo un bypass de la principal protección del sistema, la lectura del iris? ¿para qué dar esa vuelta más innecesaria cuando al hacerlo se destruye por completo el concepto inicial?

Al pensar, diseñar y construir dispositivos o sistemas, se los dota a éstos de un objetivo. Si se hacen bien las cosas, ese sistema deberia cumplir perfectamente con su objetivo y hacer sólamente eso, la razón para la cual fue diseñado. Esto es lo que diferencia a un producto líder de uno del montón, el hacer muy bien su trabajo. El error se comete cuando se intentan agregar objetivos o funciones extra, y es en esa diversificación innecesaria, cuando lo que se hacía muy bien en principio bien, se termina diluyendo.

En sistemas muy complejos, con muchos componentes y escenarios posibles, en los que se debe tener siempre una respuesta válida, son necesarios los fallbacks. Pero éstos deben estar bien pensados. Porque sino, podríamos sin darnos cuenta, caer en la trampa del fallback, instalando por ejemplo un botón que abra la puerta de calle de nuestras casas desde el exterior, por si nos olvidamos el token de la cerradura electrónica que acabamos de instalar en nuestra nueva puerta blindada…

 

[1] Perdón por el término, pero fue lo mejor que pude traducir la palabra original del fabricante, es decir: “Unhackable”…

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.

Configuración > Normativas > GDPR > Activar

Configuración > Normativas > GDPR > Activar

Y llegó el día. Después de tantos anuncios, polémicas e interpretaciones, el pasado viernes 25 de mayo entró en vigencia la famosa regulación General de Protección de Datos, o GDPR, para toda la Unión Europea. No pasaron unas horas de su entrada en vigencia, y ya cuatro gigantes tecnológicos fueron acusados de quebrantar esa norma.

El grupo NOYB (None Of Your Business o “No es asunto tuyo”) acusó a Google, Facebook, Instagram y WhastApp de incumplir la norma y les reclama varios miles de millones de Euros en concepto de multas. NOYB fue fundada por el conocido activista Max Schrems, que lucha a favor de la privacidad de los datos en Internet y que se volvió conocido por haber presentado 22 denuncias por diferentes violaciones en ese sentido a Facebook.

Si bien GDPR es una ley aprobada por el Parlamento Europeo y cuyo propósito es el de proteger los datos personales de los miembros de la UE, su espectro de acción sobrepasa las fronteras de la Unión. Por este motivo intentaremos explicar brevemente los aspectos más significativos de esta ley que ya está entre nosotros:

Datos que se protegen:

Si bien la ley efectúa 26 definiciones en su Artículo 4, cabe destacar que extiende el concepto de “datos personales” respecto a legislaciones anteriores, incluyendo los siguientes parámetros:

Identificadores:

– nombre,

– número de identificación,

– datos de localización,

– identificador en línea

Uno o varios elementos propios de:

– la identidad física,

– fisiológica,

– genética,

– psíquica,

– económica,

– cultural o

– social

Pero además, va más allá aún. Dado que hoy en día, con los sistemas de inteligencia artificial, es posible analizar enormes cantidades de datos relacionados con las actividades de las personas y generar perfiles de comportamiento, la ley prevé que asimismo se deben proteger dichos perfiles relacionados particularmente con:

– rendimiento profesional,

– situación económica,

– salud,

– preferencias personales,

– intereses,

– fiabilidad,

– comportamiento,

– ubicación

– movimientos de dicha persona física

De hecho la ley genera una delgada línea entre el registro de los eventos de seguridad y la privacidad de dichos datos. En cualquier organización de cierta magnitud, se cuentan con sistemas de monitoreo que analizan y alertan en función de actividades sospechosas en sus sistemas tanto desde el exterior de la organización como en su interior. Si bien estos datos son fundamentales para prevenir ataques o incidentes de seguridad, un abuso en el manejo de dichos datos podría estar violando la GDPR. Es por esto que a los responsables actuales de ciber seguridad de las empresas les aguarda un enorme desafío en determinar la forma de tratar esos datos definiendo qué datos se almacenan, por cuánto tiempo, en qué condiciones, qué se hace con ellos luego, entre otras.

Ámbito de aplicación:

La ley se aplica a las empresas o entidades que manejen datos personales como parte de las actividades de una de sus oficinas establecidas en la Unión Europea (UE), independientemente del lugar donde sean tratados los datos, o si la empresa está establecida fuera de la UE y ofrece productos o servicios (tanto pagos como gratuitos) u observa el comportamiento de las personas en la UE.

Actores:

Existen dos actores definidos quienes son responsables de aplicar todas las medidas de protección que se definen más adelante. Estos actores son los “responsables de tratamiento” (en inglés “controller”) cuya responsabilidad es la de determinar los propósitos y medios para el tratamiento de los datos; y los “encargados de tratamiento” (en inglés: “processors”) que efectivamente efectúen el tratamiento  de los datos personales por cuenta del responsable del tratamiento. Las actividades de los responsables se encuentran reglamentadas en el Artículo 24 y las de los encargados en el Artículo 28.

En el caso de empresas que manejen datos de gran cantidad de personas, la GDPR sugiere la incorporación de un tercer actor denominado “delegado de protección de datos” (en inglés: DPO ó Data Protection Officer) cuyas responsabilidades y atribuciones se detallan en los artículos 37, 38 y 39.

Medidas:

Las empresas que trabajen con datos personales de personas residentes en la Unión Europea deberán efectuar una serie de tareas, cambios, rediseños, adaptaciones de sus sistemas de forma de cumplir con la ley y evitar las enormes multas que pueden llegar hasta los 20 millones de Euros. A continuación se efectúa una breve descripción las medidas más importantes:

1- Análisis de aplicabilidad

Inicialmente, la empresa que trabaje con datos que puedan caer dentro de la ley, debe efectuar un análisis de si los dueños de los datos y los tipos de datos son alcanzados por la norma. En el caso de que lo sea, deberán determinar su rol (responsable o encargado) y adecuar la organización de su empresa para incorporar los nuevos procesos de Tratamiento de la Información a los que los obliga la ley.

2- Evaluación de Riesgos

El Artículo 32 de la norma (Seguridad del Tratamiento) es absolutamente claro que las medidas de tratamiento deben efectuarse basado en el nivel de Riesgo. Es por esto que es fundamental efectuar una evaluación inicial del Riesgo que permita luego ser gestionado e ir aplicando las medidas de tratamiento basadas en el Riesgo obtenido.

3- Análisis de Impacto

La norma es muy estricta en su Artículo 35 respecto a que tanto responsables como encargados tienen la responsabilidad de efectuar análisis de impacto referidos a la privacidad de los datos. Estas evaluaciones son muy similares a la metodología BIA (Business Impact Analysis) pero enfocadas en la posible pérdida de privacidad de los datos. La información exigible y resultante de este análisis está perfectamente detallada en dicho artículo y la autoridad de aplicación de la ley tiene previsto publicar qué operaciones específicas deberán ser objeto de un análisis de impacto.

4- Rediseño de las medidas de protección de datos

El Artículo 25 (Protección de datos desde el diseño y por defecto) establece que el responsable del tratamiento deberá aplicar tanto las medidas técnicas como organizativas que permitan hacer foco en los datos personales que requieran de dicho tratamiento.

Por este motivo, se deberá revisar toda la infraestructura de seguridad de la empresa con el objetivo de corregir todas las medidas de tratamiento que no cumplan con la norma y efectuar una tarea de rediseño de la misma. A partir de dicho rediseño, se muestran las medidas específicas que nombra la ley en su Artículo 32 en los siguientes 3 puntos:

5- Pseudonimización y cifrado de los datos

Se deberán implementar medidas que efectúen el tratamiento de los datos personales de manera tal que ya no puedan atribuirse a un interesado sin utilizar información adicional. Por otra parte, esa información adicional debe estar separada de la anterior y sujeta a medidas de seguridad específicas. Esto podrá realizarse a través de la pseudonimización o del cifrado de datos según sea más adecuado.

6- Recuperación ante desastres

Como extensión a los proyectos de BIA, se deberán también establecer planes de Recuperación ante Desastres (DRP) de modo de contar con la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidentes tanto físicos como técnicos.

7- Evaluaciones periódicas de seguridad

Una vez tomadas las medidas técnicas de tratamiento que correspondan, se deberá verificar, evaluar y valorar periódicamente la eficiencia de dichas medidas para garantizar la seguridad en el tratamiento de los datos. Esta tarea se suele denominar en inglés como Vulnerability Assessment.

Para mejorar, asegurar y mantener las medidas de seguridad efectivas a lo largo del tiempo, las autoridades de la UE promoverán su certificación mediante mecanismos y organismos específicamente designados para dicha función como se menciona en los artículos 42 y 43.

8- Concientización

Las empresas que administran datos personales, corren dos riesgos muy grandes a la hora de cumplir con GDPR. Uno de ellos es que no tengan las medidas de seguridad suficiente y que algún atacante externo pueda robar u obtener de algún modo esos datos. El otro gran riesgo es que el propio personal que no esté suficientemente compenetrado con la norma, pueda en su tarea diaria, tratar esos datos descuidadamente y estos puedan perderse o exfiltrarse. Es por esto que en varios artículos de la ley, se insta a las autoridades a promover tareas de concientización entre los empleados de las empresas responsables y encargadas de forma de minimizar este riesgo.

9- Requisitos legales 

Las empresas que manejen el tipo de datos personales que están contemplados en la ley, deberán adecuar sus procesos internos para cumplir con una gran cantidad de requisitos sobre los datos y los usuarios. La ley especifica gran cantidad de condiciones en los primeros artículos.

Por ejemplo, en el Artículo 5, se define que los datos personales deberán ser tratados de manera lícita, leal y transparente en relación con el interesado. El Artículo 6 enuncia las condiciones en las que el tratamiento de los datos personales será lícito. Fundamentalmente se basa en el consentimiento del usuario en que sus datos sean utilizados y cuyas condiciones define en los Artículos 7 y 8. Los Artículos 9, 10 y 11 definen condiciones especiales de los datos a ser tratados.

Finalmente, en los artículos 12 al 23 se detalla cuidadosamente la información que se debe proveer al interesado en caso de que no haya sido obtenida de forma directa, los derechos de éste en eliminarla, evitar que sea utilizada, sea esta información personal específica o creada mediante los mecanismos automáticos de perfilado.

Es por esto que las empresas deberán llevar a cabo proyectos de ajuste de sus procesos o más aún, la creación misma de procesos nuevos, que permitan contemplar todos estos requisitos.

10- Comunicación

Si a pesar de todas las medidas tomadas para evitar el mal uso de la información, se llegara a producir un incidente o violación de la privacidad de la misma, los responsables tienen la obligación de comunicar tanto al interesado como a las autoridades de la situación. Las condiciones, formas, plazos, descripción y detalles de dichas comunicaciones están establecidas en los artículos 31, 33 y 34. Las empresas deberán por lo tanto, establecer los procesos formales para llevar a cabo esta tarea ajustados para cumplir con la GDPR.

Nota por Carlos Benitez

Cómo entrenar a tu dragón

Cómo entrenar a tu dragón

Y ya están entre nosotros.


A pesar de las predicciones y especulaciones de su inminencia tanto en la literatura fantástica como en el cine de ciencia ficción, le tomó unos 30 años a la Inteligencia Artificial (IA) salir de los laboratorios y llegar a nuestro mundo cotidiano. Pasó por Redes Semánticas, Procesamiento de Lenguaje Natural, Sistemas Expertos, Sistemas Cognitivos, Agentes Inteligentes y, finalmente, Inteligencia Artificial. A medida que fue creciendo, algunos logros nos asombraron como cuando a fines del siglo pasado Deep Blue
 le ganaba varias partidas a Kasparov. Aunque eso ni se compara con la forma en la que DeepMind de Google viene destrozando a varios jugadores expertos y campeones mundiales de Go en los últimos años. Estos resultados espectaculares por ahora siguen siendo de laboratorio. Aunque Siri, Google Now y Cortana no lo son.

Cada vez que consultamos a nuestros smartphones y les preguntamos cómo llegar a cierta dirección, o si nos puede dar la mejor receta de la Musaka griega o si le pedimos que cante, quien nos está respondiendo es el sistema de IA que Apple, Google y Microsoft desarrollaron para sus productos.
Al consultar el pronóstico del tiempo en el Weather Channel, ir de compras virtuales por Macey’s o hacer consultas de salud en el sitio de la American Cancer Society, veremos el logo de “With Watson” que significa que esas organizaciones están usando el sistema de IA de IBM: Watson para analizar sus datos. El mismísimo Elon Musk, a pesar de mostrar públicamente su preocupación por el desarrollo de la IA, formó la compañía OpenAI para fomentar su desarrollo.

Antes de la IA, usábamos nuestros programas, aplicaciones y sistemas para que nos agilicen nuestros procesos de negocio, aunque las decisiones intermedias las seguían tomando los expertos que interpretaban los resultados.  ¿Pero qué pasa si entrenamos a un sistema de IA para que tenga las mismas habilidades del experto? Eso es lo que están haciendo hoy los sistemas de IA. Reemplazan la intervención humana en la toma de decisiones de forma mucho más rápida, eficiente y con menor tasa de error. Y esto se logra por medio de dos claves: la primera es la elección correcta del tipo de herramienta de IA (hoy en día la más difundida por su eficiencia es la de Deep Learning); la segunda es cómo la entrenamos. En particular con Deep Learning, se deben usar millones de datos tomados de expertos, pre-procesarlos adecuadamente para alimentar al sistema para que aprenda y se entrene.

Vayamos a un ejemplo concreto en el ámbito de la ciber-seguridad. Un sistema SIEM (Administrador de Eventos e Información de Ciberseguridad) es un sistema extremadamente complejo. Su misión es la de recolectar información de sensores a través de las redes y sistemas, correlacionarlos y dar alertas ante la evidencia de un ciberataque.
Blog – Como entrenar a tu dragón

Si bien algunos fabricantes prometen que con un “Next> Next> Next>” es posible tener un SIEM activo y funcionando en minutos, la realidad es que estos sistemas son muy complejos que requieren de la intervención de un experto. Inicialmente para el diseño mismo del sistema, analizando la red, los nodos, los sistemas instalados, las comunicaciones, los activos críticos, los puntos de entrada y de salida. Y posteriormente para  analizar enormes cantidades de datos que permitan dar como resultado información realmente útil.
Si bien las herramientas SIEM actuales son bastante completas y funcionan para la mayoría de las instalaciones de forma convencional, en redes muy grandes esto es casi imposible. Por esto algunos vendors están empezando a agregar componentes de IA para reemplazar la intervención humana y hasta para generar acciones por sí mismos, como bloquear conexiones o borrar archivos potencialmente peligrosos.

Ahora bien, una herramienta es sólo una herramienta. Dependiendo de en qué manos caiga, es lo que se va a hacer con ella. Resulta que un ciberataque también es un proceso muy complejo y de varios ciclos de análisis, toma de decisiones y acciones para llegar a un objetivo. Y también es necesario un experto para llevarlo a cabo; ¿o lo era? ¿Se podrá entrenar un sistema de IA para generar ciber-ataques? La respuesta es sí. El mismísimo DARPA (Defense Advanced Research Projects Agency) está fomentando esta actividad. Pero además, las herramientas que están a disposición de la comunidad ya se están entrenando para planificar cómo causar daños en el ciberespacio.

Pero hay un problema extra. Dijimos que especialmente en Deep Learning se necesitan muchísimos datos (muy bien pre-procesados) para que los sistemas de IA aprendan correctamente. Si hacemos esto incorrectamente o a las apuradas o con datos insuficientes, podemos hacer que los sistemas de IA aprendan, pero mal. Que por ejemplo en el caso del SIEM, no sólo no detecten los ataques, sino que abran puertas a los atacantes o borren archivos válidos e importantes o bloqueen un sistema por haber errado en un análisis. Y en ese caso, ¿qué tipo de error sería? ¿Un error humano producido por una máquina?

Los sistemas de IA serán lo que hagamos de ellos. Si los entrenamos bien, podrían convertirse en nuestros aliados como tantas otras tecnologías que utilizamos a diario en nuestras vidas; pero si los entrenamos mal, por error o con malas intenciones, sin que lleguen necesariamente a convertirse en Skynet, pueden llegar a causarnos a los humanos que quedemos, serios dolores de cabeza…

 
Nota por Carlos Benitez
Un golpe de suerte, o de cómo Mark Zuckerberg creó conciencia para la implementación de GDPR

Un golpe de suerte, o de cómo Mark Zuckerberg creó conciencia para la implementación de GDPR

En una nota anterior, contamos cómo la Unión Europea está trabajando fuertemente desde hace 4 años en una nueva normativa de protección de datos personales, la hoy ya famosa GDPR o Reglamentación General de Protección de Datos de la Unión Europea. Esta iniciativa se crea dadas las enormes falencias que existen en las empresas de la Unión, en las que se fueron detectando faltas inaceptables en las capacidades de ciberprotección.
La norma será de aplicación obligatoria para todas las empresas de la UE a partir del 25 de mayo de este año. Sin embargo, el hecho de la obligatoriedad, no necesariamente implica que la curva de implementación de las contramedidas sea rápida o eficiente. La misma motivación que hace que las empresas a veces tengan áreas enteras dedicadas a analizar de qué forma pueden pagar menos impuestos, es probable que las hagan analizar de qué forma cumplir con GDPR con el menor esfuerzo e inversión posibles. 
¿Por qué se da esto? Por la misma razón por la que hoy en día sus medidas de ciberprotección son inaceptables: la falta de conciencia.
El convencimiento de que lo que uno está haciendo es importante o necesario es lo que dispara los procesos para que efectivamente se lleve a cabo. Y en este caso, muchas empresas de la UE no están convencidas ni creen que es importante – o por lo menos no lo estaban.
El vuelco que dio en la aceptación sobre la implementación de la nueva norma, se dio gracias al escándalo de Facebook y Cambridge Analytica. La comisionada por los asuntos de los consumidores de la UE, Vera Jourlova, quien se reunió con Mark Zuckerberg a raiz del escándalo, le dió a Zuckerberg las gracias públicamente por haber aceptado cumplir con GDPR ni bien esté en vigencia. Es difícil saber si la declaración del CEO de Facebookaceptando sin objeciones las nuevas contramedidas de seguridad para preservar la privacidad de los datos de los usuarios, hubiese sido la misma sin el escándalo de Cambridge Analytica. Pero la verdad es que a los promotores de la medida les vino como anillo al dedo, y justo antes de la entrada en vigencia de la medida.
Veremos el 26 de mayo cuáles habrán sido finalmente los resultados.
 
Nota por Carlos Benitez

 

Microkernels, ¿el futuro de la Ciberseguridad?

Microkernels, ¿el futuro de la Ciberseguridad?

El kernel de un sistema operativo es el componente principal o núcleo, donde se encuentra la parte central de su funcionalidad.

Un kernel “monolítico”, el más utilizado en los sistemas operativos actuales, se construye para contener la mayor cantidad de funciones, servicios y soporte para dispositivos posibles. De esta forma, el usuario cuenta con toda la funcionalidad que necesita en el momento que la precisa. No es necesario  cargar o instalar componentes o drivers cada vez que se deba usar un dispositivo nuevo; simplemente el kernel contiene todo lo que el usuario requiere para correr sus aplicaciones.
La utilización de kernels monolíticos se viene dando desde hace años. Y como cada vez se agrega más funcionalidad, cada versión del kernel tiene un tamaño mayor a la anterior. Esto ha llevado a que, por ejemplo, las últimas versiones del kernel del sistema operativo Linux, estén construidas a partir de aproximadamente unas 18 millones de líneas de código fuente.
Está claro que un kernel de tal tamaño posee indudablemente una inmensa funcionalidad, pero del mismo modo la casi absoluta imposibilidad de una revisión completa. En especial de posibles defectos de seguridad debidos a errores de programación.

En el otro extremo del espectro, un “microkernel” es un kernel que contiene la mínima cantidad de funciones necesarias para que un sistema operativo funcione. Su objetivo principal es que las funciones incluidas sólo permitan administrar el resto de los subsistemas. Contrastando con los kernels monolíticos, el código fuente de los microkernels tienen solo algunas decenas de miles de líneas de código. Esta característica hace que sean más fácilmente auditables y de esta forma, mantenerlos en un muy elevado nivel de seguridad.
Si bien existen algunos sistemas que vienen utilizando microkernels desde hace mucho tiempo (como el sistema operativo de tiempo real QNX), sólo se utilizan para propósitos muy específicos en sistemas embebidos.

Hoy en día se han y vienen desarrollando una pequeña variedad de microkernels cada uno con sus particularidades.  Los grupos que los desarrollan vienen trabajando desde hace años en aplicaciones prácticas de microkernels que permitan construir sistemas con altísimos grados de seguridad.

Pero entre ellos, existe un proyecto al que se le debe prestar particular atención, nos referimos a Genode.
Este proyecto toma los elementos básicos de los microkernels y de hecho utiliza microkernels existentes (como seL4, Fiasco.OC o Pistachio), como un microkernel propio directamente asociado al hardware (base-hw) para componer un concepto novedoso.
Genode propone un administrador de microkernels que lo convierte en un framework completo de sistemas operativos pero con características de seguridad muy superiores. Uno de los conceptos desarrollados en Genode, consiste en iniciar el sistema operativo con un proceso madre o raíz del microkernel al solo efecto de administrar a sus procesos hijos. Luego, se disparan diferentes instancias del mismo proceso para manejar cada una de las funciones del sistema, como por ejemplo el acceso al sistema de archivos, el manejo de la red, manejo de dispositivos de entrada/salida, funciones criptográficas, etc. Cada una de estas instancias del microkernel corre en un dominio separado, es independiente del resto y sus permisos son manejados exclusivamente por su proceso madre. De esta forma, si un atacante se adueñara de alguno de estos procesos, su proceso madre podría reiniciarlo sin interrumpir la ejecución para el usuario, eliminando la conexión que generó el atacante y cortando el vínculo con él.
Este complejo mecanismo de seguridad, junto con esquemas de virtualización basados en librerías de Virtualbox, hacen que mediante Genode se puedan instalar sistemas operativos completos pero basados en la tremenda fortaleza de los microkernels.

De hecho Genode Labs, la empresa que está detrás del sistema, tiene planeado liberar durante este año la primer versión estable de su propio sistema operativo completo, el Sculpt; además de sistemas de administración de paquetes, interfaces gráficas, etc. que permitan la utilización de estos sistemas tan seguros, ya no para propósitos específicos sino para casi cualquier aplicación.

Disponer de esta tecnología permitirá, en un futuro cercano, poder instalar desde servicios específicos en pequeños dispositivos hasta sistemas de escritorio y servidores con altísimos grados de seguridad basados en microkernels. Es por esto que tal vez, éste sea el primer paso de un cambio profundo en la mejora de ciberseguridad de nuestros sistemas.

Nota por Carlos Benitez