TheHive : tout pour enquêter sur les incidents de sécurité

Un vide à combler

Il aura fallu attendre la fin 2013 pour que se trouvent les bonnes personnes et que puisse commencer le développement de TheHive, avec la bienveillance de la Banque de France, lorsque Saâd Kadhi a pris la responsabilité de son Cert.

Tout est alors parti d’une étude de marché, sur la base d’un cahier des charges précis. « Nous avons trouvé des briques éparses », couvrant certains volets fonctionnels, « comme MISP avec lequel TheHive s’intègre pour la collecte, le stockage et le partage d’indicateurs de compromission ». Mais il ne semblait pas y avoir de réponse complète aux besoins, notamment sur le volet collaboratif, « pour permettre à plusieurs personnes de travailler en même temps sur des investigations », ou encore pour « pouvoir collecter facilement des indicateurs auprès de différentes sources », voire traiter des alertes venues directement d’utilisateurs. Il s’agissait aussi de pouvoir étudier facilement un observable « à l’échelle, en sollicitant plusieurs sources, payantes comme gratuites », à l’instar de Virus Total, Passive Total, DomainTools, etc.

Saâd Kadhi, Thomas Franco et Jérôme Léonard ont ainsi commencé à développer la première version de TheHive sur leur temps libre. Pendant deux ans, le projet a été testé et amélioré continuellement « jusqu’à ce que l’on soit suffisamment satisfaits pour se dire qu’il pourrait être utile à une communauté qui nous a beaucoup apporté ».

Une grande exigence

Mais hors de question de rendre public un prototype bâclé : « nous voulions rendre […] un produit léché et aussi professionnel que possible ». Ce n’est donc qu’en novembre 2016 que TheHive a été rendu public. Depuis, Nabil Adouani, Danni Co, et Nils Kuhnert ont rejoint l’équipe projet, partageant le même esprit.

Si l’équipe n’a pas forcément les moyens d’une jeune pousse soutenue par des investisseurs, elle se donne ceux de ses exigences. Et cela porte ses fruits : « la vitesse d’adoption nous a beaucoup étonnés ». Saâd Kadhi indique que « des entreprises ont fait la comparaison, y compris avec des produits commerciaux, et ont retenu TheHive car la plateforme est bien finie, et répond bien à leurs besoins de réponse à incident en équipe, parfois à travers le monde ».

D’ailleurs, si la plateforme est disponible sous la forme d’un conteneur Docker, ce n’est pas un hasard. Cela relève de la même logique : « on ne veut pas que l’utilisateur se dise que c’est de l’open source, donc que c’est moins bien que quelque chose qui va coûter un bras. Nous voulons prouver que le projet est viable et peut être utilisé en toute confiance dans un grand groupe ».

C’est dans cette perspective que le projet est adossé à une association loi 1901, afin d’assurer un support limité et les formations demandées par certains. Mais Saâd Kadhi insiste : « nous voulons proposer des produits de qualité. Et cela signifie que l’on peut les déployer sans passer par des services professionnels exorbitants ».

Une architecture souple…

Concrètement, TheHive s’articule autour d’un moteur central, assurant notamment le suivi en temps réel des tâches réalisées par les analystes, via un flux pouvant rappeler une "timeline" de réseau social – le "live stream" –, un entrepôt de données Elastic Search et une ou plusieurs instances du moteur d’analyse Cortex.

Ce dernier était initialement intégré à TheHive, avant d’être sorti début 2017 pour en permettre l’utilisation dans le cadre de cas d’usage différents, comme la chasse aux menaces, ou encore avec des systèmes de réponse à incident (SIRP) différents de TheHive.

Pour la collecte des incidents à traiter, TheHive s’appuie sur des "alerts feeders externes", avec lesquels la communication est assurée via une API Rest, pour laquelle a été développée une librairie Python. MISP est ainsi supporté, et un connecteur est disponible pour Splunk. Un autre est en développement pour QRadar. Mais ce ne sont que quelques exemples.

TheHive permet aussi de créer des tableaux de bord afin d’aider au reporting ainsi qu’au pilotage de l’activité : « de là, on peut explorer quasiment toutes les données, savoir quels sont analyseurs les plus utilisés, savoir s’il faut étendre les quotas pour certains, les types d’indicateurs de compromission les plus fréquents, suivre les délais de résolution, etc. ».

… et extensible

Pour l’heure, plusieurs « têtes » TheHive peuvent être déployées autour d’une même ressource Elastic Search, mais sans partager leur "live stream". Ce qui limite l’approche à une instance TheHive par équipe. Mais la mutualisation du flux entre instances, autour d’un bus Kafka, est prévue pour la suite. Cet été, la version 3.1 de TheHive apportera autre chose : la gestion de tenants multiples sur une même base.

Il est possible de déployer autant d’analyseurs Cortex que souhaité, pour une même instance TheHive ce qui, outre permettre de répartir la charge, ne manque pas d’intérêt en termes de cloisonnement. Par exemple, il est possible d’en utiliser un sur un réseau isolé, dédié, pour ses bacs à sable internes, tandis qu’une autre instance s’occupe de solliciter les analyseurs externes.

A ce jour, on compte une quarantaine d’analyseurs – développés en Python – pour Cortex, dont certains disponibles en différentes « saveurs », pour un total de « 70 à 80 façons d’analyser un observable ». Mais le moteur ne sollicite pas systématiquement les analyseurs : il intègre un mécanisme de cache qui permet d’accéder aux résultats d’une requête précédente sur un même observable associé au même niveau de sensibilité (TLP)

De nombreuses perspectives

Saâd Kadhi souligne l’importance de la chose : « il s’agit d’optimiser la gestion de quotas de requêtes sur des sources externes ». Mais pas n’importe comment. Car il n’est pas question de partager sur Virus Total un échantillon ultra-sensible, assorti d’un TLP rouge, par exemple. Là, Cortex se contentera de faire une recherche sur la signature de l’échantillon.

La gestion de quotas permet en fait de gérer des organisations, et donc de distribuer un volume de requêtes achetées au niveau d’un grand groupe entre plusieurs équipes, par exemple.

A ce stade, TheHive ne supporte pas l’orchestration entre équipements et logiciels susceptibles de contribuer à la réponse à incident. Mais au fond, rien de l’empêche : les analyseurs ne sont rien d’autre que des modules lançant des actions et collectant leurs résultats. Saâd Kadhi le concède ainsi, c’est une base qui pourrait être utilisée pour l’orchestration, en proposant de soumettre un observable soit pour analyse, soit pour action. Cela fait partie des évolutions à attendre.

En attendant, la version 3.1 de TheHive doit intégrer plusieurs nouveautés, dont le support de la notion de niveau de service pour des incidents ou des tâches, alertant par exemple si un temps de traitement est sur le point d’être dépassé. Cet été, avec la nouvelle mouture, le projet supportera également la préversion de la taxonomie européenne de réponse à incident. De quoi contribuer à faire avancer un projet indispensable à une véritable coordination des efforts de cybersécurité à l’échelle du Vieux Continent.