Recherche et déploiement d’une solution de

détection et réponse à incident

Luisa Bouteille
DGD-SI UGA
43 rue des Mathématiques
38 400 Saint-Martin-d’Hères

Sylvain Thomas
DGD-SI UGA
43 rue des Mathématiques
38 400 Saint-Martin-d’Hères

Résumé

Depuis un peu plus d’un an la DGD-SI de l’université Grenoble Alpes a mis en place un NDR
(Node Detection & Response). Nous nous proposons de faire un retour sur les raisons qui nous ont
amené à chercher à mettre en place un tel outil, comment nous avons fait le choix de Detect de
Vectra et enfin de partager notre premier retour d’expérience.

Mots-clefs
SIEM, EDR, NDR, compromission, attaque

1 Introduction
L’Université Grenoble Alpes (UGA) réunit 56 000 étudiants et 6 800 personnels. Ce qui représente
environ 10 000 postes de travail, 80 000 comptes informatiques et 26 000 adresses IP. Le tout
génère un trafic moyen de 15 Gbit/s de données en entrée/sortie de datacentre et de 5 Gbit/s en
entrée/sortie de campus. Étant donné la mixité des périmètres (laboratoires, composantes, services
centraux…) et de leurs fonctionnements ainsi que les flux de données générés, il serait illusoire de
croire que l’on a une parfaite maîtrise de l’usage de chacun de nos réseaux.
C’est fort de ce constat que le service Réseaux, Télécoms et Datacentres de la Direction Générale
Déléguée aux Systèmes d’Informations (DGD-SI) a cherché à se doter d’un outil qui permettra la
détection et la réponse d’usages abusifs de nos réseaux. Nous espérons ainsi pouvoir détecter
d’éventuelles compromissions de postes ou de comptes, attaques, accès illégitimes au sein de notre
système ou tout autre comportement anormal. Autant de détection qu’il nous est actuellement
difficile de détecter rapidement.

2 Recherche de la solution

2.1 Cahier des attentes

Pour atteindre l’objectif énoncé en introduction (détection et réponse des usages abusifs sur notre
réseau) nous sommes donc en recherche d’une solution capable de :
− Collecter et corréler des flux réseaux ;

JRES 2021 – Marseille 1/19

 − Générer des rapports ;
− Permettre une recherche d’événement le plus efficacement possible ;
− Avoir des graphiques offrant une vision globale sur les flux réseaux ;
− S’intégrer facilement avec nos équipements existants ;
− Être multi-constructeur ;
− Générer des alertes en fonction du niveau de criticité et ce en temps réel ;
− Permettre d’authentifier les personnes accédant à la solution ;
− Être maniable et maintenable facilement ;
− Être clef en main.

L’aisance de la maintenabilité et de son exploitation sont des critères importants pour que la
solution soit pérenne dans le temps. L’étude de solutions et la mise en place sont possibles grâce à
l’alternance de Luisa mais l’équipe n’aura pas de renfort humain pour gérer ce nouvel outil.

2.2 Recherche des solutions

Étant donné l’objectif de la mission, nous nous sommes ensuite rapidement orientés sur les
solutions SIEM (Security Information and Event Management / Gestion de l'information et des
évènements de sécurité) qui paraissaient pertinentes pour répondre à nos différents besoins. Pour
des raisons budgétaires, nous nous sommes intéressés dans un premier temps aux logiciels SIEM
open source existants.
Les solutions SIEM permettent, entre autre, de collecter et corréler les flux réseau. En effectuant des
analyses, grâce au machine learning par exemple, elles peuvent remonter des incidents ainsi que les
évènements pertinents que l’on pourrait rechercher dans le cadre de la sécurité, par exemple des
connexions suspectes. Elles donnent généralement accès à des graphiques liés aux informations
récoltées ce qui permet un meilleur aperçu de la situation. L’opérateur a la possibilité d’utiliser un
système de notifications par mail. Il pourra le configurer pour l’alerter en cas de détections
d’évènements qu’il aura jugées pertinentes.
2.2.1 Recherches sur les solutions SIEM open source

Il existe de nombreuses solutions SIEM open source. Pour réaliser un premier tri, nous avons
regardé les avis d’utilisateurs et leur classement des logiciels. Ce tri nous a permis d’isoler cinq
solutions qui paraissaient intéressantes. Une recherche plus poussée a été menée sur chacune de ces
solutions pour voir celle qui correspondait le plus de nos critères et qui avait le plus d’avantages
(cf : Annexe 1 - Comparaison solutions SIEM open-source).
Deux de ces solutions sont sorties du lot, il s’agissait de Wazuh[1] et ELK (Suite Elastic :
Elasticsearch, Kibana, Beats et Logstash). Elles présentaient plus de fonctionnalités et leurs
communautés d’utilisateurs semblaient investies, ce qui signifie en général qu’il est possible de
trouver de la documentation et de l’aide en cas de besoin. Un déploiement sur une infrastructure de
test a été mené pour la solution Wazuh, pour avoir un meilleur aperçu des possibilités, du
fonctionnement et des paramétrages qu’il y aurait à effectuer. Assez rapidement, des problématiques
sur le paramétrage de la solution et la récupération de log sont arrivées. Les possibilités de la
solution étaient vastes, pas des plus intuitives, et sans formation adaptée, la prise en main risquait
d’être longue.

JRES 2021 – Marseille 2/19

À la suite de ces recherches nous avons décidé de regarder du côté des solutions commerciales « clé
en main ». Le but étant de pouvoir bénéficier d’accompagnement pour la mise en place de la
solution et d’un support pour l’exploitation voire d’un service d’infogérance.
2.2.2 Recherches sur les solutions SIEM commerciales

Comme précédemment une analyse des offres a été faites mais sur les solutions SIEM
commerciales. Nous avons également consulté nos différents intégrateurs présents au marché. Nous
avons ainsi pu affiner nos recherches sur 9 solutions (cf : Annexe 2 - Comparaison solutions
commerciales).
C’est lors de ces échanges avec nos intégrateurs que nous avons constaté que le SIEM n’était pas la
solution la plus adaptée car il s’agit de solutions qui demandent beaucoup de gestion en amont,
avant de pouvoir obtenir des résultats pertinents et fidèles à nos besoins. Notre besoin étant plutôt
ciblé sur un outil effectuant ce travail en amont sans nécessiter un investissement humain à temps
plein.
2.2.3 Recherches sur d’autres solutions

On nous a donc présenté un NDR (Network Detection & Response / Détection et Réponse à
Incident). Il s’agissait de Detect proposé par la société Vectra. Cette solution semblait répondre à
tous nos critères de base et apporter des fonctionnalités supplémentaires très intéressantes comme la
réponse automatique à incident. Les retours utilisateurs sur cette technologie sont très positifs. Cette
solution analyse tout le flux réseau et utilise de l’intelligence artificielle pour détecter les attaques
en faisant appel à de la corrélation d’évènement. Des réponses à incidents peuvent également être
paramétrées pour avoir une réaction automatisée à certaines attaques ou tentatives.
Cette présentation nous ayant particulièrement intéressés, nous avons décidé de rechercher des
technologies similaires pour avoir une comparaison. Nous avons donc trouvé deux technologies
similaires à comparer, Darktrace[3] et Cisco SecureX Threat Response. Darktrace[2] est le principal
concurrent de Detect et possède une plus grande communauté d’utilisateurs ; cependant Detect est
plus utilisé par les universités. Après quelques recherches sur ces deux technologies et les
comparaisons de leurs utilisateurs, nous en avons conclu que Detect correspondait mieux à nos
critères et nous avons pris la décision de réaliser un POC (Proof Of Concept / Preuve de concept) de
leur solution.

2.3 Choix de la solution

Le POC avec la solution Detect de Vectra a duré un mois. Pendant ce mois, nous avons pu tester en
condition réelle la solution puisque nous dupliquions vers les sondes les trafic nord/sud entre les
datacentres et le réseau fédérateur ainsi qu’en sortie de campus.
Tout au long de ce mois, nous avons été très bien accompagnés par l’équipe de Vectra qui organisait
des points hebdomadaires pour répondre à nos questions et nous montrer les bonnes pratiques
d’utilisation.
Nous avons ainsi pu tester son fonctionnement et apprécier la capacité à détecter des incidents.
L’une de nos principales craintes était le taux d’incidents et de faux positifs remontés dû à des
politiques de détection trop légères. Nous avons été agréablement surpris de constater que les
évènements remontés étaient pertinents. Nous avons ainsi pu détecter du minage de crypto-monnaie
sur notre réseau, des scans de reconnaissance et du brute-force. De plus, il est possible de
catégoriser les évènements que l’on considère comme légitimes comme tels pour éviter d’avoir ce
que l’on considérerait comme des faux positifs.

JRES 2021 – Marseille 3/19

Une fois ce POC terminé, nous avons pris un peu de recul, revu nos attentes énoncées
précédemment et pris en compte les points qui avaient évolué au cours de cette recherche. Cela
nous a permis de conclure que la solution proposée par Vectra était la plus pertinente pour nos
besoins.

3 Fonctionnement et utilisation de la solution

La solution repose sur un équipement physique appelé cerveau. Il ne s’agit pas d’un simple logiciel
que l’on peut déployer sur un serveur mais d’un équipement physique qui sera la partie centrale de
la solution. Le cerveau a pour fonction de réaliser toute l’analyse des données ainsi que son
stockage. La solution dispose également d’une interface web qui est hébergée par le cerveau. De
plus, cet équipement dispose de sondes, ports réseaux adaptés à la récupération de flux. En fonction
des besoins plusieurs modèles de cerveau existent permettant de traiter des flux de 1 Gb/s à 40 Gb/s.
Il est possible également d’avoir des sondes physiques ou virtuelles externes à cet équipement. On
peut entre autre implémenter des sondes virtuelles sur des ESX pour en récupérer le trafic.

Figure 1 - Schéma logique du réseau et vu des flux monitorés

3.1 Fonctionnement
L’interface graphique de Detect est très ergonomique. Elle permet d’avoir une vision large et rapide
sur toutes les fonctionnalités. Le menu est facile d’accès avec des catégories simples de

JRES 2021 – Marseille 4/19

compréhension (Figure 2 - Menu de l'interface graphique). Nous pouvons observer une division en
deux parties des onglets.
La première étant liée aux détections et à leur affichage, la seconde à la gestion.

Figure 2 - Menu de
l'interface graphique

Lors de la connexion à l’interface, nous arrivons sur le tableau de bord (Figure 3 - Tableau de bord).
Ce tableau de bord répond bien à sa fonctionnalité de rassembler la majorité des informations sur
des graphiques. Nous avons un aperçu sur les détections en fonction de leur criticité des postes
potentiellement compromis ainsi que sur les campagnes d’attaques en cours. Nous pouvons
visualiser les détections réparties par catégories et par type. Le second menu du tableau de bord
donne accès à la santé du système, par exemple l’état des capteurs et des interfaces, l’état du disque
et de la mémoire ainsi que la version actuelle du système.

JRES 2021 – Marseille 5/19

 Figure 3 - Tableau de bord

Lorsque nous allons sur l’onglet Host nous pouvons avoir un aperçu des détections actives (Figure 4
- Graphique de détection des postes). Les postes sont placés en fonction de la menace et de la
certitude de l’évènement. Nous pouvons filtrer les éléments que nous souhaitons afficher.

JRES 2021 – Marseille 6/19

 Figure 4 - Graphique de détection des postes

Chaque élément présent sur ce graphique est ensuite listé. Il suffit de cliquer sur l’un d’entre eux
pour obtenir plus d’informations (Figure 5 - Information sur le poste). Outre le nom de la machine,
nous pouvons connaître la dernière adresse affectée à ce poste. Ces deux éléments permettent de
continuer à détecter tout évènement lié à ce poste même si un changement d’adresse IP a lieu. Le
compte du probable détenteur du poste, donc de celui qui se connecte sur celui-ci, est également
donné. De plus, grâce à l’intelligence artificielle et après un certain temps, Detect est capable
d’attribuer un niveau de privilège en fonction des connexions faites par l’utilisateur du poste. Plus
précisément, en fonction du nombre de services auxquels l’utilisateur se connecte et si ces services-
là sont accessibles par beaucoup d’autres utilisateurs ou non. Ce niveau va de 1 à 10, 10 étant le
niveau de privilège le plus élevé.

Figure 5 - Information sur le

poste

Au-delà des informations liées au poste, nous pouvons visualiser les détections faites concernant
celui-ci. Ici par exemple (Figure 6 - Informations sur les détections du poste) un évènement a été
retenu par Detect. Cette détection a été mise dans la catégorie Lateral, avec le type Ransomware
File Activity (Activité de type chiffrement malicieux de fichier), avec un niveau de menace évalué à
60/100 et de certitude à 95/100.

JRES 2021 – Marseille 7/19

 Figure 6 - Informations sur les détections du poste

Les catégories, quant à elles, permettent de déterminer quelle est la phase d’attaque (Figure 7 -
Phases d'attaque). Il en existe cinq :

Figure 7 - Phases d'attaque

- L’exfiltration (Exfil) : exfiltration de données ;

- Les latérales (Lateral) : actions menées sur d’autres postes internes ;
- La reconnaissance (Recon) : reconnaissances menées sur le réseau interne ;
- Le contrôle et commandement (C&C) : prise de contrôle ;
- Le botnet (Botnet) : postes effectuant des actions similaires à un bot.
Ces catégories aident à déterminer lorsqu’une attaque de plus grande envergure a lieu. Certains
postes ont des détections liées à une seule catégorie, tandis que d’autres ont des détections qui se
situent dans plusieurs catégories, ce qui peut être un indicateur de menace plus élevé.
Les types, il en existe une multitude. Ils permettent d’identifier plus précisément l’évènement qui a
été détecté. Chaque catégorie contient ses propres types, certains pouvant se retrouver dans
plusieurs catégories. Par exemple, le type « tunnels HTTPS cachés » peut se retrouver dans la
catégorie exfiltration mais également dans le contrôle et commandement. Ces types nous
permettront par la suite de créer des filtres qui identifieront les trafics que l’on juge légitimes.
Après l’onglet Hosts, nous avons l’onglet Accounts, dont les contenus sont très similaires. Comme
son nom l’indique, la différence vient du fait qu’ici nous avons accès aux données du compte
utilisateur et pas du poste. Les informations de compte peuvent être récupérées comme celles des
machines, via les informations transitant sur le réseau. Cependant peu de comptes sont récupérés de
cette façon. La façon la plus efficace et qui permet d’obtenir le plus d’informations est de lier
Detect à l’Active Directory, de cette manière tous les comptes présents dans l’Active Directory sont
récupérés ainsi que leurs potentiels privilèges.

JRES 2021 – Marseille 8/19

L’onglet suivant est Campaigns. Il affiche toutes les campagnes d’attaques en cours. Une campagne
est formée lorsqu’il y a au moins une détection de contrôle et commandement avancée et que
plusieurs autres postes communiquent avec la même adresse. Une campagne peut donc impliquer
deux machines tout comme des centaines. Sur la Figure 8 - Exemple de campagne, nous avons un
aperçu d’une campagne. Brièvement nous obtenons : les informations de la machine cible
responsable de la campagne, un schéma des postes impliqués, la date de la dernière activité
détectée, depuis quand la campagne est active, le nombre de machines internes concernées et le
nombre de détections de contrôle et commandement aillant mené à l’ouverture de la campagne. En
accédant à la campagne, nous obtenons le détail des postes concernées et des détections faites. Nous
pouvons également visualiser une chronologie des évènements avec les postes concernées et la date.

Figure 8 - Exemple de campagne

Le dernier onglet de la première partie du menu se nomme Detections. Ici nous allons retrouver
toutes les détections organisées en fonction de leur catégorie. Nous pouvons visualiser un graphique
des nouvelles détections, par jour, semaine ou mois, (Figure 9 - Graphique des détections) réparties
par catégorie. Cela permet, si nous le souhaitons, de nous focaliser sur une catégorie de détection en
particulier. Par exemple si l’on souhaite éliminer tout type de botnet sur notre réseau nous pouvons
ainsi visualiser tous les évènements de ce type. Grâce à cet onglet, nous pouvons également
observer toutes les détections catégorisées comme custom. C’est-à-dire, toutes les détections
correspondantes à un filtre personnalisé, nous verrons ces filtres par la suite.

JRES 2021 – Marseille 9/19

 Figure 9 - Graphique des détections

Les onglets suivants permettent de gérer les détections et l’outil. Nous pouvons :
- créer des rapports personnalisés ;
- observer les statistiques du réseau (le trafic sur les interfaces, le nombre d’adresses IP) ;
- manager (gestion filtres, groupes d’adresses, sondes, utilisateurs, authentification) ;
- configurer (adresses internes, notifications, services, autres licences Detect) ;
- accéder aux documentations ;
- gérer notre compte utilisateur.

3.2 Exploitation
À présent que l’interface a été présentée, nous allons voir comment l’exploiter.
Lorsqu’une détection est faite sur une machine, nous obtenons son niveau de sévérité. Il est établi
en fonction du niveau de certitude et de menace. Il y a quatre niveaux, low, medium, high et critical.
Nous pouvons observer le détail de toutes les détections, chacune a son propre niveau de certitude
et de menace. Cependant, Detect fournit la liste des détections en cause de la sévérité (Figure 10 -
Liste des détections). En effet, une machine peut avoir plusieurs détections mais celles-ci ne sont
pas nécessairement toutes responsables du niveau de sévérité élevé. Ainsi nous savons sur quelles
détections se concentrer en priorité.

Figure 10 - Liste des détections

Si l’on va sur l’une des détections, nous pourrons avoir plus d’informations sur celle-ci. Nous
pourrons connaître l’adresse IP et le DNS de la machine concernée, les scores de certitude et de

JRES 2021 – Marseille 10/19

menace de la détection ainsi qu’un résumé, une infographie pour avoir un aperçu visuel, quelle est
la phase d’attaque, une ligne temporelle des évènements et le détail des activités. Ici par exemple
(Figure 11- Résumé d'une détection de type "External Remote Access"), nous regardons le résumé
d’une détection de type External Remote Access. Nous accédons brièvement aux informations clés,
l’adresse interne et externe impliquées, le nombre de sessions ouvertes, la durée de l’accès ainsi que
la quantité de données reçues et envoyées.

Figure 11- Résumé d'une détection de type

"External Remote Access"

Pour aider dans la communication il est possible d’envoyer un fichier PCAP (fichier de capture de
paquets) ou encore de partager une vue sur la page des détails de la détection comme on peut le voir
sur la Figure 12- Actions possibles. Pour faciliter la gestion, plusieurs outils sont en place. Tout
d’abord le Tag qui permettra d’étiqueter la détection, par exemple pour indiquer qu’une
investigation est en cours ou pour indiquer qu’elle fait partie d’un groupe. Il est possible de
rechercher les détections ainsi que les machines en fonction de leur tag. Ensuite il y a la partie Note
qui permet de réaliser des annotations, elles peuvent être utiles pour soi-même pour rajouter des
détails ou bien pour mettre des informations qui seront visibles par les autres utilisateurs de Detect
ce qui peut éviter de réaliser du travail en double. Enfin, Assign, celui-ci sert à assigner une
détection ou une machine à un utilisateur en particulier, cela peut être utile pour indiquer que
quelqu’un est déjà en train de travailler sur cette détection. Il est possible de générer une
notification mail lorsqu’une assignation a été faite.

Figure 12- Actions possibles

Une fois l’investigation faite, une décision sur l’action menée devra être prise. Cinq actions sont
possibles, nous les retrouvons dans l’onglet Triage (Figure 13- Triage). S’il s’agissait d’une
compromission, d’un comportement anormal qui a été résolu nous choisirions l’option Mark as
Fixed. Cette option permet d’indiquer que le problème a été résolu, cela remettra les scores de la
détection à zéro. En revanche, si cette détection redevient active alors nous en serons informés et les
scores de détection se mettront à jour en conséquence. Mark as custom permet de l’associer à un
filtre existant. Cette action est prise si l’on considère le comportement de la machine comme
légitime, puisque cette détection précise ne sera plus prise en compte pour le calcul du score de la
machine. Create Whitelist Filter va cacher la détection et celle-ci ne sera plus prise en compte pour

JRES 2021 – Marseille 11/19

le calcul du score de la machine. Cette option n’est pas à privilégier puisque nous n’aurions plus
aucune visibilité sur cette détection et les futures détections identiques, il n’y aura plus aucun
élément indiquant leur existence.

Figure 13- Triage

Finalement, l’option sûrement la plus utilisée au début de l’utilisation de Detect est Create Custom
Filter, puisqu’il s’agit de la création de filtre. Cela identifiera la détection comme un comportement
légitime et n’impactera plus le score de la machine concernée. Lorsque l’on crée un filtre, nous
avons accès à un formulaire à remplir, qui est spécifique pour chaque type et catégorie de détection,
hormis la partie nommage et description du filtre. Pour un type External Remote Access par
exemple, nous devrons renseigner l’adresse IP ou DNS source qui devra correspondre (ou au
contraire celle(s) que l’on exclut). Il est également possible de filtrer en fonction de la sonde source.
S’il s’agit de scan de port, il faudra indiquer le port concerné, s’il s’agit d’anomalie de privilège on
pourra renseigner le compte utilisateur ou l’adresse IP source avec le service concerné... La création
de ces filtres permettra d’éviter ce que l’on pourrait considérer comme un faux positif, puisqu’un
comportement légitime à notre sens. Il s’agit donc d’une partie importante de l’outil. À noter qu’il
est possible de créer des filtres dans l’onglet Manage, il n’est pas nécessaire d’attendre une
détection pour créer un filtre personnalisé. Si l’on connaît un comportement spécifique légitime qui
déclenchera une détection par Detect, il est possible d’anticiper la détection de ce comportement en
appliquant un filtre.
La dernière action possible est lorsqu’il existe déjà un filtre qui pourrait s’appliquer, à une
exception près. Dans ce cas, par exemple une adresse IP destination supplémentaire, Detect
suggérera ce filtre en indiquant la modification à appliquer (l’ajout de l’adresse IP destination si
l’on reprend le même exemple).

Le travail sur chaque détection va commencer au moment de la réception d’une notification de

détection par mail ou lors d’un contrôle régulier de l’interface. Pour investiguer nous allons tout
d’abord regarder quel est le niveau de sévérité de la machine. Nous nous concentrons sur les
détections de sévérité élevée et critique avec une priorité sur ces dernières puisqu’elles ont un score
de plus de cinquante sur cent en certitude et menace.

JRES 2021 – Marseille 12/19

La première étape est de regarder les détections faites sur cette machine, celles qui sont en cause de
la sévérité. Nous utiliserons l’outil Assign pour indiquer qui travaille sur cette détection et les outils
Tag et Note pour faciliter le traitement. Ensuite, on prend contact avec les personnes responsables
de la machine (généralement des informaticiens) pour établir avec eux la légitimité de ces
détections ou les informer d’une compromission. C’est à ce moment que l’on pourra utiliser
l’exportation du fichier PCAP (fichier de capture de paquets) ou partager la vue sur la page des
détails de la détection. Une fois toutes les informations nécessaires recueillis nous pouvons décider
quelles actions mener. Ces actions peuvent être menées sur la machine ou même sur nos pare-feux
en fonction des conclusions de la détection. L’une de ces actions se fera également sur Detect, il
faudra choisir de considérer la détection comme résolue, de l’ignorer, ou de la considérer comme
légitime en appliquant un filtre.

3.3 Cas d’usage

Voici quelques cas d’usage auxquels nous avons été confrontés jusqu’à présent et comment nous
avons géré ces incidents.
Premier cas : du minage de monnaie virtuelle. Une détection a été remontée sur un poste ayant une
activité qui s’y apparentait ; l’action était répétée de façon journalière et la détection a été
considérée comme critique. Nous avons pu récupérer l’adresse IP de la machine, son nom DNS,
l’utilisateur supposé de la machine (compte AD) ainsi que les jours et horaires liés à l’activité
suspicieuse. Nous avons pris contact avec l’informaticien responsable de ce poste et lui avons
transmis toutes les données que nous avions en notre possession. Il a pu trouver l’origine, un
logiciel malveillant installé en même temps qu’un logiciel non officiel. Cela nous a permis de
supprimer ce logiciel malveillant et de constater qu’un poste n’avait pas une installation conforme à
notre politique. Après nettoyage de la machine, nous avons considéré l’évènement comme résolu
Mark as Fixed, le poste n’était plus considéré comme critique mais si l’évènement venait à se
reproduire, nous serons notifié.
Second cas, une activité DNS depuis un réseau de non confiance (identifié par Detect). Des requêtes
DNS ont été détectés depuis l’une de nos adresses VPN avec pour information njRAT. NjRaT étant
un cheval de Troie qui permet la prise de contrôle à distance. Nous avons regardé les logs du VPN
pour retrouver quel utilisateur était connecté au moment de l’envoi des requêtes DNS puisque nous
utilisons un adressage dynamique. Après recherche dans les logs, nous avons retrouvé l’utilisateur
et avons constaté que la connexion VPN était établie depuis l’étranger. Nous nous sommes
renseignés auprès de l’informaticien local concerné pour savoir si l’utilisateur en question se situait
actuellement à l’étranger. Suite à son retour négatif, nous en avons déduit qu’une usurpation de
compte avait été faite. Nous avons renvoyé l’utilisateur auprès de notre assistance pour modifier ses
accès et nous avons informé notre RSSI de l’usurpation de compte. Suite à cela, nous avons indiqué
l’évènement comme résolu.

3.4 Modules complémentaires

Cognito Stream
Ces dernières semaines, nous avons pu bénéficier d’une licence d’évaluation pour le module
Stream[4]. Il s’agit d’un module qui permet d’exporter toutes les données récupérées et traitées par
Vectra vers un SIEM, par exemple la Suite ELK. Vectra propose ce système en tant que service
hébergé chez eux mais nous avons aussi la possibilité de rediriger ces données vers nos services
hébergés (ELK, splunk…) . Nous préférons nous tourner vers un hébergement en local en nous
appuyant sur l’ELK en cours de déploiement au sein de l’équipe système de la DGDSI.

JRES 2021 – Marseille 13/19

Le but étant de pouvoir exporter toutes les données brutes et enrichies par Vectra. Cela nous
permettra d’effectuer des recherches fines sur certains éléments et de réaliser des investigations
supplémentaires post-incident si nécessaire.
Ces semaines de tests, n’ont pas été très concluantes. L’intégration à l’infrastructure ELK de
l’équipe système s’est révélée plus complexe que prévue et surtout le volume de données transmis
par Vectra est beaucoup trop important. Nous avons été obligé de filtrer fortement ce qui était
transmis au cluster ELK pour ne pas le saturer mais cela limitait fortement la pertinence des
informations récupérées.
Nous avons donc décidé de ne pas approfondir plus, pour le moment, l’utilisation de ce module.
Son utilisation impose la mise en œuvre de trop gros moyen, humain et matériel ainsi qu’en licence
supplémentaire, au vu de l’intérêt aperçu du module.
Active Directory
Nous avons également relié Detect à l’Active Directory (AD)[5] géré par la DGD-SI pour avoir une
meilleure visibilité sur les privilèges des comptes. Nous pouvons ainsi voir les groupes AD
auxquels appartient la machine ainsi que ceux de son utilisateur. Ceci permettant d’avoir une
meilleur appréciation de la criticité de l’incident. Nous sommes actuellement en attente d’une mise
à jour qui devrait arriver cet été permettant de lier Detect à plusieurs AD. Il ne faut pas perdre de
vue que nous sommes dans un environnement hétérogène et que l’ensemble des machines observées
ne sont pas toutes intégrées à l’AD de la DGD-SI, voir pas en domaine.
L’étape suivante sera d’analyser la pertinence de la mise en place du verrouillage automatique d’un
compte en cas de compromission.

3.5 Avantages
Après quelques mois d’utilisation, nous pouvons d’ores et déjà constater les différents avantages de
la solution nous concernant. Le premier élément est la simplicité de la mise en place. Il a suffi
d’envoyer le trafic que l’on souhaitait analyser au cerveau et de renseigner nos réseaux internes
pour avoir les premières données. Le fait que Detect puisse récupérer le trafic réseau
indépendamment du constructeur des équipements est également un point fort.
Nous constatons peu de faux positifs, d’autant qu’une certaine partie de ces faux positifs ne le sont
que pour nous. Il s’agit de machines particulières qui ont des comportements spécifiques étant
considérés comme anormaux en temps normal mais légitime pour nous. Par exemple, des outils de
supervision, de déploiement de paquets, des serveurs de stockages ou des postes de recherche qui
réalisent des expérimentations.
Pour traiter ces faux positifs qui sont des comportements légitimes dans notre cas, nous avons la
possibilité de définir des filtres, comme présenté dans le fonctionnement de la solution. Les filtres
peuvent être très fins, comme par exemple sur un protocole précis d’une machine en particulier.
Cette finesse dans le filtrage permet de ne pas légitimer plus d’éléments que nécessaire et ainsi
risquer de passer à côté d’un comportement anormal. Cette partie requiert de la gestion mais cela
permet par la suite de se focaliser sur les vrais positifs. De plus, même si ces détections sont
légitimes, nous avons ainsi une meilleure vision sur des usages particuliers de notre réseau.
Pour aider dans le traitement des détections, nous exploitons les tags, les annotations et la
possibilité d’assigner une détection à une personne. Grâce à cela, il y a un gain de temps sur la
gestion. On évite ainsi que plusieurs personnes travaillent sur la même détection sans s’en rendre
compte. De plus, les tags et annotations permettent un meilleur suivi de l’incident.

JRES 2021 – Marseille 14/19

Comme voulu dans notre cahier des charges, nous avons la génération d’alertes mails et de rapports.
Il est possible de les personnaliser pour avoir seulement les éléments qui nous semblent pertinents à
recevoir par mail.
Un élément supplémentaire intéressant, est l’accès aux données virus total et whois d’une machine.
Les requêtes ne sont pas réalisées directement par nous, mais sont transmises par Vectra. De cette
manière nous avons un premier aperçu du potentiel niveau de menace de la machine et de son
appartenance.
Detect de Vectra nous apporte un réel avantage pour détecter les usages abusifs de notre réseau. La
charge de travail apportée semble légitime en vue des avantages obtenus.

3.6 Limitations
Malgré les points positifs de la solution, nous avons constaté quelques limitations. Detect, de
Vectra, est payant mais cela ne nous donne pas pour autant accès à tous ses outils. Certains modules
supplémentaires sont sous licence qu’il faut payer indépendamment. Par exemple le module Stream
évoqué précédemment. De plus la licence générale est calculée par rapport au nombre d’IP
observées ce qui nous oblige à faire des choix dans les réseaux que l’on souhaite surveiller.
De par son fonctionnement, il s’agit d’une boîte noire sur laquelle nous avons peu de maîtrise. En
cas de problématique, il est difficile de réaliser du débogue par nous-mêmes puisque nous n’avons
pas accès aux logs du système. Pour les détections, nous ne connaissons pas de façon précise ce qui
les déclenche et comment les scores sont attribués. En effet, si ces données étaient connues cela
pourrait permettre à une personne malveillante de passer à travers les détections. Mais, en
contrepartie, nous n’avons pas non plus accès à ces données.

On a également pu constater que l’IA n’est pas forcément mise à jour lors de nouvelles failles (ex :
print nightmare) ce qui impliquerait de recourir au module stream pour pouvoir chercher les postes
atteints. A noter que les postes atteints remonteront dans un second temps lorsqu’ils commenceront
à explorer leur environnement.

4 Conclusion
Cela fait maintenant plusieurs mois que Detect de Vectra est en exploitation dans nos murs. De
l’avis général de l’équipe, il s’agit d’un très bon produit qui répond à ce que l’on recherchait.
L’accompagnement de Vectra ne s’est pas arrêté après le POC et ils sont toujours prêt à répondre à
nos questions.
Le cerveau, sur l’ensemble des sondes qui lui sont connectées, encaisse en moyenne plus 20 Gb/s de
trafic et ce sans broncher.
La période de nettoyage des faux positifs avec création de règles pour les gérer s’est passée
relativement facilement et l’outil permet de très bien le gérer. Nous sommes donc maintenant dans
une phase d’exploitation et cela se gère sans accaparer un temps plein parmi les membres de
l’équipe.
À notre grande satisfaction, nous n’avons pas découvert de catastrophe sur le réseau. Les
principales alertes sont liées à du minage de crypto-monnaie et des mauvaises configurations.
Nous pensons qu’il peut être intéressant d’approfondir l’utilisation de ce type d’outil pour avoir des
réseaux plus ouvert mais restant sur surveillance et ainsi passer moins de temps à gérer des
demandes d’ouverture d’accès. La plupart des tentatives sont encapsulées dans du 443, limitant

JRES 2021 – Marseille 15/19

l’intérêt des pare-feux classique, et sur des grands environnements une gestion fines des accès est
quasi impossible.
Malgré nos recherches sur les outils libres dans un premier temps, nous avons dû nous rendre à
l’évidence que ceux-ci nécessitaient beaucoup d’investissement humain et ceci en permanence. La
création de filtres pour obtenir les détections voulues est une opération très fastidieuse tandis
qu’avec cette solution propriétaire cette partie est confiée à Vectra.. De plus, cela évite de saturer
des serveurs avec des données qui se révéleraient non pertinentes. En résumé, malgré un coup
financier, cela nous permet d’obtenir des résultats pertinents tout en économisant un temps de
travail important pour l’équipe.

JRES 2021 – Marseille 16/19

Annexe
Annexe I

Annexe 1 - Comparaison solutions SIEM open-source

JRES 2021 – Marseille 17/19

Annexe II

Annexe 2 - Comparaison solutions commerciales

JRES 2021 – Marseille 18/19

Bibliographie
[1] https://wazuh.com
[2] https://www.cisco.com/c/fr_fr/products/security/threat-response.html
[3] https://www.darktrace.com/fr
[4] https://content.vectra.ai/rs/748-MCE-447/images/Datasheet_CognitoStream.pdf
[5] https://support.vectra.ai/s/article/KB-VS-1210

JRES 2021 – Marseille 19/19