Entretien avec Mathilde Imbert, Margaux Tawil, et Julien Fistre de DarkTrace

Mathilde Imbert, Margaux Tawil, et Julien Fistre de DarkTrace partagent leur expertise ainsi que leur vision du marché.

Pouvez-vous nous expliquer comment fonctionne votre solution ?

Notre solution, l’Entreprise Immune System, analyse les flux réseaux grâce à une sonde physique, ressemblant à un serveur, placée dans le cœur du réseau et va permettre la surveillance de flux au sein du SI, afin de trouver des anomalies et éviter qu’une attaque se propage. Spécifiquement, nous surveillons les flux de partage de fichiers comme SMB, le trafic internet, et même l’ajout nouveau de clefs USB, lorsqu’elles sont branchées sur des systèmes Windows qui envoient par défaut une requête au réseau. Nous pouvons récupérer des métadonnées à différent niveau, ce qui pourra donner des indices lorsqu’un poste est compromis. Les alertes envoyées sont principalement classées selon 3 métriques : le nombre de machines connectées, le volume de données et les échecs de connexion. Aujourd’hui les technologies ne permettent pas encore d’avoir un système autonome à 100% et ce n’est pas notre objectif. Avec le volume de données croissant que l’on utilise, un opérateur a besoin d’avoir des informations contextualisées pour être efficace. Nous voulons guider et simplifier la prise de décision en mettant facilement à la disposition de l’opérateur les informations les plus pertinentes.

Combien d’appliances (de sondes physiques) sont nécessaires pour couvrir un SI ? Couvrent-t-elles tout le réseau même s’il y a plusieurs sites ou en faut-il une par site ?

Tout dépend de l’architecture du SI et s’il y a un point qui centralise l’intégralité du flux réseau comme un Data Center. Dans ces conditions, une seule appliance peut suffire. Au contraire si les différents sites ne sont pas intégralement reliés entre eux et s’ils ont leur propre connexion internet, serveurs DHCP, AD et DNS locaux, il faudra une appliance par site. On peut en revanche, centraliser la remontée d’informations et monitorer l’intégralité des sites qui sont accessibles à la solution depuis l’interface. Notre solution convient aussi très bien pour les réseaux avec IoT, smartphones et tout autre objet qui communiquent via le réseau.

Nous savons que votre solution permet d’étudier les comportements des utilisateurs et de détecter des anomalies. Pouvez-vous nous expliquer comment sont générés les différents modèles mathématiques permettant d’étudier ces comportements ? Plus précisément, est ce que vous partez d’un modèle d’apprentissage pré-entraîné lorsque vous déployez votre solution sur un réseau ou est-ce qu’il est entièrement vierge lors de chaque déploiement ?

Le modèle comportemental n’est pas pré-entraîné, il sera entraîné sur le réseau du client afin d’apprendre de ses habitudes et de son environnement une fois la sonde installée. Pour vous donner un exemple : notre solution ne sait pas qu’une connexion SSH est sur le port TCP 22. Donc lorsqu’elle sera déployée, elle ne lèvera pas d’alerte si le port de connexion SSH sur le SI est différent. Elle apprendra toute seule quel est le port utilisé pour SSH. Par contre, s’il y a une tentative de connexion sur le port 22, à ce moment-là elle lèvera une alerte. Pour entrer plus dans les détails, nous basons notre apprentissage sur 3 classes d’informations :
- Les logs des machines étudiés au cas par cas
- Les informations de type Netflow, forensic réseau accédées via ELK (ElasticSearch, Logstash, Kibana)
- Les captures de paquets et analyses avec des outils de type Wireshark

La durée de vie des données est limitée et varie en fonction de leur volume. Les logs sont gardés entre 8 et 12 mois, les données ELK environ 6 à 8 semaines et les trames réseaux (packet capture) pendant une semaine. Le fait de garder ces informations (qui restent chez le client – pas d’analyse dans le Cloud) permet d’avoir un suivi sur les utilisateurs. L’analyse des logs DHCP permet de suivre une machine, le trafic Kerberos, son utilisateur dans le temps et puis si voulu, nous pouvons aussi personnaliser l’apprentissage. En plus du modèle comportemental, nous intégrons environ 80 modèles de détection pré-entraînés. Ces modèles, qui ressemblent aux modèles de corrélation des SIEM, servent à détecter des attaques ciblées et connues comme les tentatives de brute force de tickets kerberos.

Pouvez-vous nous parler des faux positifs et négatifs lors des détections réalisées par votre solution ?

C’est une question qui est difficile à aborder dans la mesure où nous nous positionnons sur une analyse comportementale. Nous allons détecter les comportements qui sont anormaux et plus ou moins inquiétants en rapport avec une « baseline ». Nous utilisons pour cela tout un arsenal d’algorithmes, notamment de machine learning non supervisé et nous qualifions les symptômes du réseau. Par conséquent, si une connexion est jugée anormale, elle peut être légitime, mais elle reste néanmoins inhabituelle. Notre solution est différente des règles préétablies avec des IOCs et des signatures où le résultat est binaire, soit vrai soit faux. Pour nous, ce n’est jamais binaire et on assigne un score de criticité.

Quel est le temps que met votre solution pour apprendre les comportements et reconnaître les comportements “normaux” ?
On estime en général qu’il faut une semaine à 10 jours d’apprentissage sur le réseau, mais en réalité il est plus juste de dire que la solution est en constant apprentissage. Dès l’instant où elle est connectée au SI elle peut détecter des comportements anormaux. Il est arrivé qu’elle en détecte au bout de quelques minutes, mais nous préférons considérer qu’elle devient vraiment fonctionnelle au bout de 10 jours. Nos clients ont des SI qui changent, avec des nouvelles machines qui arrivent : des fusions-acquisition, des intégrations, etc. Il faut être capable de gérer ça. Grâce à cette approche d’apprentissage non supervisé, le système apprend et analyse en continu ce qui permet un net gain en efficacité, temps et en souplesse.

Concernant l’évolution du SI, que se passe-t-il si une nouvelle machine fait son apparition ? Une nouvelle règle doit-elle être mise en place pour ne pas lever d’alerte, ou est-ce que votre solution va comprendre que cette machine est légitime en analysant son comportement ?

Darktrace va détecter qu’il y a une nouvelle machine sur le réseau et analyser son comportement pour voir par exemple si elle performe un scan réseau ou une autre activité anormale. Si c’est le cas une alerte avec les informations associées sera remontée à l’opérateur. L’intervention humaine reste cependant utile pour juger si la nouvelle machine est légitime sur le réseau. Par exemple si un admin IT scanne le réseau dès lors qu’une machine est ajoutée, la solution risque de considérer ce scan comme malveillant. Cependant, elle permet de mettre en valeur les informations essentielles pour la prise de décision de l’opérateur et lui permet de gagner beaucoup de temps.

Que pouvez-vous nous dire sur votre outil “Threat Visualizer” ?

Le Threat Visualizer, est en fait l’interface principale qui donne de la visibilité totale du réseau en 3D. Le but de cet outil est d’aider à contextualiser quelque chose qui est abstrait. Le machine/deep learning contrairement à ce qu’on pense, n’a pas pour but de remplacer les opérateurs ou la réflexion humaine. On ne peut pas considérer qu’un outil tel que le nôtre puisse actuellement prendre les décisions pour remédier aux attaques. Il peut par contre guider l’opérateur pour prendre les bonnes décisions en lui permettant très rapidement de détecter si un comportement anormal est légitime ou non. Cependant il n’y a pas de considération du contenu, la solution ne sait pas si des fichiers sont critiques ou non et/ou sont transférés. C’est une des limites actuelles des approches comme la nôtre, simplement car tout corps de métiers et leur politique IT sont différents.

Avez-vous des problèmes liés aux données utilisateurs et aux nouvelles normes telles que la RGPD ?
Nous ne nous basons pas uniquement sur les machines utilisateurs, ou le contenu des paquets transitant sur le réseau. De plus, la possibilité d’anonymiser les données, nous ne rencontrons pas de problème à ce niveau. Qui plus est, et contrairement à de nombreuses solutions, les données récoltées par notre solution ne sortent pas du réseau de nos clients. Nous ne les envoyons pas sur nos serveurs pour les analyser. Cela rassure nos clients de savoir que les données restent chez eux.

Comment vous situez vous par rapports à vos concurrents ?

Nous sommes les premiers à avoir développé une solution telle que la nôtre et c’est encore un milieu assez restreint, nous n’avons pas beaucoup de concurrents. Pour l’instant nous avons plus une place de leader sur ce marché.

Que pensez-vous des hackers qui utilisent le deep learning pour apprendre à leur malware à se cacher de ce genre de solutions ?
Les menaces actuelles sont plus basées sur les mauvaises pratiques internes, le shadow IT, les mauvaises habitudes des administrateurs système ou le comportement des utilisateurs. La réalité du marché, c’est déjà ça, il y a peu de clients qui ont des niveaux de sécurité internes qui permettent de se concentrer sur des menaces plus élevées. Quelques une de nos équipes explorent ces sujets, mais ce n’est pas le cœur de notre solution.

Qu’est ce que prévoyez pour l’avenir ?

Les attaques par IA sont quand même dans nos priorités, pas forcément des attaques très évoluées mais qui montrent des potentiels très dangereux.

Dernière publication

Les risk managers mettent le risque cyber en tête de leurs préoccupations. Retour sur les rencontres de l'AMRAE. 

Lire