Bien que très efficaces, ces différentes solutions sont limitées du point de vue de leur périmètre, et sont inutiles, voire mêmes aveugles dans certains cas : attaque depuis un poste non maîtrisé, détection de shadow IT, appliances ou équipement non couvert par l'EDR, etc. Pour assurer une protection à 360 degrés il est nécessaire d'écouter les événements qui ont lieu sur le réseau interne de l'entreprise, au moyen d'une sonde réseau de type NDR (Network Detection & Response).
Le principe de ces outils est le suivant : à l'aide de sondes, physiques ou virtuelles, installées au sein du réseau interne de l'entreprise, toutes les trames réseau sont récupérées, puis analysées à la recherche de traces d'un potentiel attaquant : indicateurs de compromission, communication avec un serveur de Command & Control, tentatives d'injection sur un serveur web, etc. On comprend donc rapidement que le placement de ces sondes est critique, car il impactera grandement la qualité et la pertinence des données analysées.
Quelles sont les bonnes pratiques pour déployer
un NDR ?
Tout d'abord, il est important d'identifier les grands types de flux dans le SI. Premièrement, les flux Nord / Sud représentent les échanges de données entrants ou sortants du SI, potentiellement avec un lien internet. Pour ceux-ci, la question qui se pose souvent est de savoir s'il est utile de monitorer une potentielle DMZ (De-Militarized Zone). En effet, des assets exposés sur Internet peuvent toujours être soumises à des scanneurs d'IPs publiques ou d’autres tests de vulnérabilités externes. Ces détections doivent donc être mises en exclusion de manière assez fine afin d'éviter du bruit parasite sur le NDR. D’autre part, les flux Est / Ouest, qui concernent les échanges internes au SI, doivent privilégier les flux utilisateur / serveur et entre serveurs.
Une fois que les points de capture sont identifiés, il faut choisir la méthode de capture en elle-même. La plupart des sondes supportent deux méthodes, le TAP et le port mirroring. Le TAP est un équipement physique qui s'installe en coupure du flux et effectue une redirection « en Y ». Le flux original continue vers sa destination initiale mais est aussi recopié vers une autre interface, derrière laquelle on place la sonde réseau. La plupart des TAP sont construits de sorte qu'un défaut d'alimentation électrique ne perturbe pas le flux initial et impacte uniquement le flux recopié. Le TAP est également la seule méthode supportée dans le cas d'un SI soumis aux réglementations de l'ANSSI.
La méthode du port mirroring présente quant à elle l'avantage de ne pas nécessiter d’équipement supplémentaire. Un élément de l'infrastructure réseau (pare-feu ou switch en général) peut être configuré pour effectuer le même type de « Y » qu'un TAP. En revanche, cette configuration peut être assez demandeuse en termes de ressources machine, et la plupart des constructeurs déconseillent d'utiliser du port mirroring sur des équipements déjà bien sollicités.
Comment configurer un NDR ?
Après cette phase de collecte des flux vient celle de la configuration des règles de détection. La plupart des NDR proposent plusieurs moteurs : la détection sur base de règles statiques, celle comportementale, l’analyse des signatures de fichiers transitant sur le réseau, ou encore la recherche de la présence d'indicateurs de compromission (IOC) dans les trames. L'erreur à ne pas commettre avec une solution NDR est d'activer toutes les règles par défaut dès le démarrage. En effet, sans configuration particulière, les détections peuvent être très nombreuses et demander un gros travail de qualification et d’analyse. Il convient donc d'activer les règles par « palier », ou tout du moins avec une pré-configuration de certaines exclusions.Un élément important à garder en tête est qu'une sonde réseau ne déchiffre pas le trafic. Ainsi, des paquets HTTP encapsulés dans une session TLS (donc du trafic HTTPS) apparaîtront chiffrés au niveau de la sonde, et les capacités d'analyse seront assez limitées. Les éléments des couches 3 et 4 (réseau et transport) du modèle OSI (Open Systems Interconnection) pourront tout de même être visibles, et donc les règles s'appliquant sur des adresses IP ou ports resteront utilisables.
Pour contourner ce problème, plusieurs solutions existent. La première est de déchiffrer le flux en amont, par exemple à l'aide d'un proxy avec déchiffrement SSL ou directement via la fonction ad hoc d'un équipement type pare-feu. Cela nécessite cependant des ressources matérielles relativement importantes, à additionner au coût d'un port mirroring.
Une seconde méthode implémentée par la plupart des éditeurs maintenant est de détecter des potentielles compromissions sans avoir besoin du flux chiffré. Par exemple, les comportements de type beaconing sont assez simples à repérer. Dans ce cas de figure, un client va contacter à intervalle régulier un serveur, à la manière d'un « ping ». Cela peut indiquer la présence d'un élément malveillant sur une machine, qui tente de contacter son serveur de Command & Control. De la même manière, dans une communication client / serveur, il est assez rare que le client soit celui qui envoie le plus de données. Ces comportements sont donc à surveiller de près, et peuvent l'être même sans un déchiffrement de la couche applicative.
Enfin, la période d'ajustement des règles doit ensuite être suivie d'une amélioration continue des capacités de détection, tout au long du cycle de vie de la solution. Ainsi, des nouveaux périmètres techniques ou des nouveaux risques métiers doivent être identifiés et traduits en nouvelles règles de détection via le NDR. Il est aussi fortement conseillé de récupérer les logs et/ou alertes provenant du NDR au sein d'un SIEM, pour que des analyses et corrélations puissent être faites par les équipes SOC. En effet, il est important de rappeler que le NDR n'est qu'une brique de la protection du SI, et que seul, il ne peut assurer une défense totale contre les menaces cyber complexes actuelles.
Par Pierre Tabary, consultant Sécurité Opérationnelle chez Synetis
