Close
  • Français
  • English

13/06/2014L’analyse de logs dans le contexte de l’Internet des objets

Introduction

Dans un article[1] précédent, nous avions vu comment les logs permettaient de détecter les signaux faibles de cyberattaques.

La corrélation des divers événements enregistrés dans les logs, l’analyse comportementale de profils utilisateurs donnés, l’enrichissement des logs par des ressources extérieures, la visualisation des analyses résultantes, permettent de détecter des signaux dits « faibles » (car indirects et ne constituant pas des preuves d’incidents, pris indépendamment) de tentatives ou succès d’exploitation de failles.

Nous nous étions concentrés sur l’analyse de logs dans le cas particulier de la détection d’attaques informatiques, mais en mentionnant déjà qu’une multitude d’équipements électroniques générait des logs : stations de travail Windows, Mac, ou Linux, téléphones portables Android, mais aussi équipements domotiques, imminentes voitures connectées…

Dans l’article qui suit, nous proposons de préciser la démarche d’analyse de ces logs dans une ambition plus générale de compréhension syntaxique et sémantique de ces logs, puis de leur visualisation. Et pour illustrer ce « cas plus général », nous traiterons du cas de l’Internet des Objets (Internet of Things)[2], archétype du foisonnement de formats de logs hétérogènes, donc auxquels il est ardu d’appliquer une méthode homogène d’analyse.

Comment en effet traiter la diversité des formats de logs, mais également la diversité du sens des informations ainsi formatées ? Et enfin, comment produire des visualisations lisibles des résultats de corrélation des informations ?

De l’analyse syntaxique des logs

Des formats pour le moins hétérogènes

Si vous avez déjà regardé des logs[3] de firewall Checkpoint, vous savez qu’il est difficile de les déchiffrer, en pratique. Même s’il s’agit d’un équipement largement utilisé, et dont les formats de logs sont documentés (voire publics). Et si vous n’en avez jamais analysé, un excellent exemple du SANS vous permettra d’appréhender la démarche.

Imaginez donc la difficulté d’un analyste ou d’un développeur de système de détection d’intrusion à comprendre des logs produits dans un format binaire propriétaire ! Avec une documentation confidentielle ou partielle, la tâche constitue un défi forensique important.

À chaque format son parser

Il est alors nécessaire de développer, pour chaque type de log, un parser (analyseur syntaxique), capable d’extraire les fameux couples « clé=valeur » de ce log. Ces clés, qui représentent des méta-informations, seront envoyées aux outils de corrélation des analystes afin, par exemple et comme on l’a décrit dans notre dernier article, de détecter les signaux faibles des cyberattaques.

En la matière, peu de solutions existent pour généraliser la conception de parsers, et l’on trouve le plus souvent : soit des parsers développés en interne, adaptés à des types bien particuliers de logs mais par conséquent peu évolutifs ; soit pas de parsers du tout (rappelons que l’analyse de logs est loin d’être une évidence pour les entreprises) !

L’analyse syntaxique des logs demeure ainsi une problématique technique : bien qu’ardue, elle relève plutôt de compétences en développement et en administration de systèmes informatiques. Or, la difficulté d’appréhender l’hétérogénéité des sources ne s’arrête pas à la variété des formes de l’information.

Quand bien même plusieurs informations auraient le même format, rien ne garantit évidemment que leur sens sera le même : le sens d’une information n’est pas entièrement représenté par un tableau de couples (méta, valeur). En d’autres termes, l’analyse syntaxique n’implique pas l’analyse sémantique de l’information, pourtant utile à la production d’indicateurs sur cette même information !

De l’analyse sémantique des logs

Des informations plus ou moins objectives

Dans le contexte de l’Internet des Objets, la diversité du sens des logs est démultipliée. Prenons un exemple de sens « divers » pour une information.

Les événements au format syslog[4]sont plutôt clairs et objectifs, par exemple : « tel utilisateur s’est connecté à telle heure », ou « tel processus a ouvert tel fichier en lecture à telle heure ». Une interprétation peut suivre, mais en soi, l’information formatée n’est pas biaisée par le jugement d’un analyste.

L’affaire se complique si vous recevez des informations sur la réputation d’une IP, par exemple. On peut certes définir un format pour transmettre une structure associée à cette réputation (nous y reviendrons au paragraphe suivant), mais il apparaît bien que la nature de l’information, en l’occurrence le caractère historiquement malveillant ou non d’une adresse IP, n’est pas de la même nature qu’une notification de connexion.

Or, nous voulons pourtant corréler ces informations de natures différentes. Le mécanisme de corrélation est alors une problématique scientifique, en soi.

Comment définir des normes de présentation de l’information ?

Il s’agit d’une problématique ancienne, et pourtant très loin d’être désuète. Dans notre article précédent, nous avions mentionné les très actifs travaux du MITRE[5], notamment pour la conception :

  • D’un langage standardisé pour la représentation structurée de l’information sur les cyber-menaces, STIX[6]. Ce langage est actuellement en cours d’adoption par de nombreux CERT gouvernementaux et transnationaux[7], ainsi que par de nombreuses entreprises[8].
  • D’un langage structuré pour la description des événements « cyber » : CYBOX[9]. Le langage est peu utilisé, puisqu’il s’appuie sur STIX (les éditeurs mentionnés dans la note 8 prévoient de permettre la production de documents au format STIX pour le dernier trimestre 2014, environ[10]).
  • D’un langage pour le codage et la transmission d’informations intègres et détaillées sur les logiciels malveillants : MAEC[11]
  • D’un ensemble de services pour l’échange d’informations sur les cyber-menaces : TAXII[12]

Ces formats seront une avancée fondamentale pour l’échange de données relatives aux cyberattaques. Mais il s’agit d’un cas particulier : le sens que revêt l’information ici communiquée ne concerne que les attaques informatiques… ce n’est pas le cas de l’ensemble des informations communiquées par les objets connectés !

Il y a donc aujourd’hui une problématique pour présenter des informations dont le sens revêt des connotations très différentes.

Imaginons un outil capable d’enrichir des logs émis par divers équipements (de sécurité ou non) à l’aide de données récupérées sur les réseaux sociaux, les forums undergound, divers sites Web, et d’autres sources de renseignement.

Plusieurs questions se posent, qui représentent un enjeu majeur pour les entreprises de business intelligence et de renseignement en sources ouvertes (Open Source Intelligence – OSINT) :

  • Comment corréler ces informations de nature très différentes ? Comment produire des indices pertinents et mesurables systématiquement, à partir d’une telle variété d’information ?
  • Comment pondérer « l’objectivité » des informations à corréler : si l’on décide de corréler des logs systèmes (par exemple : des notifications d’échec de connexion sur le port SSH) avec la provenance des attaques supposées (typiquement, des pays suscitant une méfiance systématique des analystes, comme la Chine ou la Russie), on introduit un biais dans le raisonnement. Ceci peut mener à des faux positifs, voire à des accusations injustifiées.

Or dans le domaine des objets connectés, nous sommes confrontés aux mêmes problèmes.

Prenons l’exemple de la corrélation de logs d’un thermomètre[13], d’un réfrigérateur[14], et d’un compteur intelligent[15] connectés. Trois formats d’information étant définis, corréler les informations véhiculées : typiquement la température, le contenu du réfrigérateur, et la consommation électrique à un instant t, signifie exactement « déterminer à l’avance des lois de corrélation entre les informations véhiculées ».

Une  de ces lois pourrait être : si la température augmente, il fait plus chaud, donc il y aura plus de boissons dans le réfrigérateur, et les habitants du foyer mettront la clim, d’où une augmentation de la consommation électrique de ∆ %.

Mais que dire d’un jour où vous avez oublié d’allumer le radiateur ? Du jour où, faute de place dans le frigo, vous stockez les jus de fruits à la cave ? De la soirée où vous laissez tout allumé parce qu’il y a des amis chez vous et que votre consommation électrique est anormalement haute ?

Tant d’exceptions, de « singularités » dans l’espace des événements observés, où la question « comment corréler différentes informations » est très difficile à résoudre.

De fait, nous pensons humblement qu’à ce jour, seule  une étude détaillée et particulière à un système producteur de log donné, associée à l’expérience et au jugement d’un analyste, peuvent permettre de produire des indicateurs de corrélation pertinents. Toute solution trop générale nous paraît fortement suspecte !

L’asynchronie des informations

La synchronisation du temps sur les réseaux d’objets connectés est bien plus complexe que sur un réseau  de type Internet “classique” : il est notamment difficile de synchroniser les différentes implémentations de NTP fonctionnant sur votre réfrigérateur, votre montre, votre iPhone… Par exemple, il est très difficile de gérer les temps de latence des communications, car ces temps sont spécifiques à chaque équipement central auquel se connecte un groupe d’objets[16]. Par conséquent, une règle de corrélation aussi basique que la date d’occurrence des événements est difficile voire impossible à mettre en place.

Ajoutons enfin que les problématiques de coût des objets connectés justifient, pour nombre de constructeurs, de ne tout simplement pas produire de logs !

De la visualisation des données

Malgré les difficultés d’analyse syntaxique et sémantique des logs, nous sommes, à ce jour, capables d’agréger, puis de corréler certains types de données ! Se pose alors la question très concrète de la visualisation du résultat de ces corrélations.

À ce sujet, nous avions évoqué la nécessité de développements internes, les solutions d’enrichissement de SIEM[17] par des sources extérieures, par exemple, n’étant clairement pas à la hauteur des annonces.

Or, visualiser des données structurées soulève deux problématiques importantes.

Assez trivialement, nous vivons en dimension 3, et visualisons nos données le plus souvent sur un écran en dimension 2 (bien que les implémentations de WebGL dans les navigateurs, produisent des vues en « 3 dimensions » – nous y revenons au paragraphe suivant – et en attendant les outils de « réalité augmentée », mais qui n’ajouteront au mieux qu’une troisième dimension).

  • Il faut donc définir des visualisations que l’œil humain puisse percevoir, et que le cerveau humain puisse traiter !
  • Or, agréger des données, puis les associer à des indicateurs plus ou moins nombreux et complexes, mène à l’obtention de vecteurs à plusieurs dimensions (par exemple, n informations sur un individu). Afficher un graphe en deux dimensions, dont chaque nœud serait un tel vecteur, résulterait inéluctablement en un inextricable fouillis.

En outre, il n’y a pas que la puissance de calcul qui compte : un problème à n dimensions n’est pas nécessairement n fois plus complexe qu’un problème à 1 dimension. Souvent, c’est pire, quand le problème n’est pas insoluble ! D’où des performances très limitées des librairies de navigateurs citées pour la visualisation d’objets en 3 dimensions (et encore pire au-delà). Par conséquent, le problème de la représentation des données passe d’une problématique plutôt technique à des problèmes essentiellement mathématiques. C’est un enjeu auquel s’attaquent quelques dirigeants de PME (françaises, par exemple), passés du monde académique mathématique au développement de logiciels pour les entreprises. Les notions mises en jeu sont de haut niveau, et font essentiellement appel à des connaissances en géométrie algébrique, en topologie, et en analyse différentielle[18], c’est-à-dire (au cas probable où ces termes vous seraient peu clairs) des domaines des mathématiques permettant de découper des éléments dans des espaces à plusieurs dimensions, et d’y effectuer toutes sortes de calculs plus ou moins amusants et permettant de véritables gains de performances dans la vie réelle de votre programme fraîchement compilé !

Conclusion

L’analyse de logs dans le contexte de l’Internet des Objets se heurte à trois difficultés :

  • L’analyse syntaxique de logs dont les formats sont extrêmement variés.
  • L’analyse d’informations dont le sens est d’une subjectivité variable, et pour lesquelles les règles de corrélation sont difficiles à établir.
  • Les difficultés de représentation en 2 ou 3 dimensions d’objets agrégeant une multitude d’informations,  donc rapidement illisibles sur un écran, et pour lesquels les calculs peuvent être impossibles à mener sans astuce mathématique.

Elle suscite donc un grand nombre de sujets de recherche passionnants en mathématiques et en informatique, entre autres, et nécessitera de définir de nouveaux concepts de présentation, manipulation, et transfert de l’information.

Merci Barbara Louis-Sidney et Jérôme Desbonnet pour leur relecture, à Philippe Saadé pour ses avis mathématiques éclairés, et à Guillaume Rossignol pour me permettre d’appliquer les idées de cet article en milieu industriel.

Charles Ibrahim, analyste cybersécurité, Bull.

@Ibrahimous

LinkedIN


[1] https://observatoire-fic.com/detecter-les-signaux-faibles-des-cyberattaques-ou-pourquoi-vous-devriez-analyser-vos-logs-par-charles-ibrahim-bull

[2] Une présentation succinte et parlante du concept d’Internet des Objets est disponible ici

[3] http://ossec-docs.readthedocs.org/en/latest/log_samples/firewalls/checkpoint.html

[4] http://fr.wikipedia.org/wiki/Syslog

[5] Organisation à but non lucratif financée par, et travaillant pour le gouvernement américain. Gère trois centres de recherche et développement : pour le département de la défense (“DOD Command, Control, Communications and Intelligence FFRDC“), pour la Federal Aviation Administration (the Center for Advanced Aviation System Development), et pour l’Internal Revenue Service (the Center for Enterprise Modernization).

[6] http://stix.mitre.org/

[7] Notamment l’US-CERT, le CERT Siemens, l’Advanced Cyber Defence Centre (ACDC)

[8] Par exemple : HP, Microsoft, Bromium, Checkpoint, Malcovery, Vorstack, ThreatConnect, …

[9] http://cybox.mitre.org/

[10] D’après des déclarations lues sur la mailing-list du STIX

[11] http://maec.mitre.org/

[12] http://taxii.mitre.org/

[13] Par exemple : http://connected-objects.fr/2014/06/igrill-thermometre-barbecue/

[14] Voir : http://www.maison-numerique.com/produits.php?id_cat=1

[15] En France, le compteur Linky EDF : https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.erdf.fr%2FLinky%2F&ei=hqCUU4C8IuTD0QWCmoH4Cw&usg=AFQjCNHq5MXUzaG6L_4pFrdcqUJBct-LWg&sig2=oxMM82bwChWrAK-PD4nVKQ&bvm=bv.68445247,d.d2k

[16] Voir par exemple la partie “Discussion” du lien suivant

[17] Security Information and Events Management

[18] Pour ceux qui seraient intéressés : voir http://www.math.ens.fr/~debarre/DEA99.pdf, http://www-fourier.ujf-grenoble.fr/~demailly/L3_topologie_B/topologie_nier_iftimie.pdf, et http://www.math.jussieu.fr/~delabrie/CalcDiff/CalcDiff.pdf