Sophos NDR : choisir la plateforme et dimensionner correctement le capteur

Sophos NDR peut fonctionner sous forme d’appliance virtuelle sur VMware ESXi, Microsoft Hyper-V, AWS ou Nutanix, ou sur du matériel Dell, NUC ou OnLogic certifié. La plateforme doit être choisie avant le déploiement : les capteurs virtuels et cloud sont dimensionnés en fonction de la bande passante, des paquets et des flux ; pour le matériel, seuls les modèles certifiés et leurs niveaux de capacité s’appliquent.

Décision rapide : pour un capteur NDR virtuel dédié traitant jusqu’à 500 Mbit/s, 70'000 paquets par seconde et 1'200 flux par seconde, la configuration standard suffit. Jusqu’à 1 Gbit/s, 300'000 paquets par seconde et 4'500 flux par seconde, prévoyez 8 vCPUs. Si une seule de ces valeurs est dépassée, plusieurs appliances virtuelles réparties sur le réseau sont nécessaires. Pour une bande passante supérieure ou un capteur physique, choisissez du matériel certifié en fonction des charges continues et de pointe réellement mesurées.

Licence et principes de planification

L’intégration nécessite le Sophos Network Detection and Response integration license pack. Sophos dimensionne la licence NDR selon le nombre total d’utilisateurs et de serveurs de l’organisation. Le logiciel des appliances virtuelles est inclus et la licence permet de déployer autant de capteurs NDR que nécessaire. Ce point est important lorsqu’un environnement de grande taille doit être réparti entre plusieurs capteurs en raison des limites documentées des VM.

Avant de choisir la plateforme, relevez les valeurs suivantes :

• bande passante maximale et continue du trafic qui sera effectivement mis en miroir,
• paquets par seconde et flux par seconde sur la même période,
• capacité du commutateur ou du port miroir depuis lequel le capteur reçoit le trafic,
• nombre et emplacement prévus des capteurs,
• autres intégrations Log Collector qui doivent s’exécuter sur la même appliance,
• microarchitecture du processeur, indicateurs CPU, mémoire vive et stockage disponibles,
• plateforme de virtualisation prise en charge ou modèle matériel certifié exact.

La seule capacité de la liaison Internet ne constitue pas une base de dimensionnement suffisante. Le capteur traite le trafic qui lui est mis en miroir. Les valeurs doivent donc être mesurées au point de mise en miroir prévu et consignées en tant que charge continue et charge de pointe.

Choisir la plateforme

Appliance virtuelle ou cloud

Une appliance virtuelle convient lorsqu’une des plateformes testées est déjà disponible et que la charge reste dans les limites des VM ou peut être judicieusement répartie entre plusieurs capteurs. Les plateformes prises en charge sont les suivantes :

• VMware ESXi,
• Microsoft Hyper-V,
• Amazon Web Services (AWS),
• Nutanix.

Pour AWS, les spécifications techniques de Sophos NDR indiquent le type d’instance c5n.2xlarge. Les mécanismes de déploiement concrets, les interfaces réseau et les paramètres de mise en miroir du trafic figurent dans le guide de déploiement correspondant et ne découlent pas de la décision de dimensionnement.

VMware Cloud n’est pas pris en charge. ESXi et Hyper-V doivent en outre respecter les prérequis de version et de processeur décrits ci-dessous. En revanche, les exigences disponibles ne contiennent pas de matrice de versions commune pour AWS et Nutanix ; les prérequis de déploiement doivent donc être vérifiés dans la section propre à chaque plateforme.

Matériel certifié

Le matériel constitue une option lorsqu’un capteur physique dédié est nécessaire ou qu’un niveau de capacité certifié correspond à la charge mesurée. Sophos ne prend en charge NDR sur du matériel qu’avec des systèmes certifiés. Il ne faut pas en déduire que les serveurs x86 génériques, des variantes de modèles similaires ou des systèmes assemblés sur mesure sont pris en charge.

Les systèmes certifiés appartiennent aux familles suivantes :

• Dell,
• NUC,
• OnLogic.

Le nom du fabricant ne suffit pas. Avant l’achat, le modèle exact doit être comparé aux Certified hardware specifications for NDR actuelles. L’installation, l’image disque et les étapes propres au fabricant ne viennent qu’après cette décision concernant le modèle.

Dimensionner les capteurs virtuels et cloud

Ressources minimales

Les ressources minimales suivantes sont requises pour ESXi et Hyper-V :

• 4 CPU,
• 16 GB RAM,
• 160 GB de stockage.

L’OVA VMware pour Sophos NDR et les intégrations Log Collector est déjà préconfigurée avec ces valeurs minimales. AWS utilise le type d’instance indiqué ci-dessus. Pour Nutanix, la source des exigences utilisée n’indique ici aucune ressource minimale distincte. Les ressources minimales ne constituent toutefois pas encore un engagement de capacité. Les trois mesures de trafic doivent être prises en compte pour choisir entre la configuration standard, 8 vCPUs et plusieurs appliances.

Les valeurs limites définissent ensemble une classe de charge. Un capteur traitant 400 Mbit/s, mais 100'000 paquets par seconde, ne relève plus entièrement de la classe Moyenne. Si les valeurs dépassent celles de la classe Élevée, Sophos préconise plusieurs appliances virtuelles réparties sur le réseau ; les sources ne permettent pas de conclure qu’une VM unique plus puissante peut être utilisée au-delà de cette limite.

Les spécifications techniques limitent un capteur NDR virtuel à 1 Gbit/s au maximum. Cette valeur n’annule pas les limites plus strictes relatives aux paquets et aux flux.

Vérifier le processeur et l’hyperviseur

Les exigences suivantes concernant la microarchitecture et les indicateurs s’appliquent au système qui héberge la VM. Sur ESXi, Hyper-V et les autres hôtes de VM autogérés, les indicateurs CPU pdpe1gb et avx2 doivent être exposés à la VM. pdpe1gb est nécessaire à la capture des paquets et avx2 aux fonctions d’apprentissage automatique. L’ajout de vCPUs ne compense pas l’absence de ces indicateurs.

Pour AWS, vérifiez plutôt le type d’instance pris en charge et les exigences de déploiement AWS ; les appliances physiques sont validées à partir du modèle certifié exact et de sa configuration approuvée. Il ne faut en déduire aucune obligation supplémentaire de vérification manuelle des indicateurs pour AWS ou le matériel certifié.

Sophos documente les microarchitectures de processeur suivantes :

• Intel : Skylake Generation 6, Kaby Lake Generation 7, Coffee Lake Generation 8, Coffee Lake Refresh et Cascade Lake Generation 9, Comet Lake Generation 10, Cannon Lake/Palm Cove Generation 10, Ice Lake/Sunny Cove Generation 10, Rocket Lake/Cypress Cove Generation 11, Alder Lake/Golden Cove Generation 12 et Raptor Lake/Raptor Cove Generation 13.
• AMD : Naples et Great Horned Owl avec Zen 1, Rome avec Zen 2, Milan avec Zen 3 ainsi que Genoa avec Zen 4.

Des processeurs plus récents peuvent également être utilisés à condition que les deux indicateurs requis soient disponibles. Sophos précise que les processeurs commercialisés depuis le premier trimestre 2015 devraient fonctionner ; la validation nécessite néanmoins de vérifier concrètement la présence des deux indicateurs sur la VM prévue.

Les versions minimales et les limites suivantes s’appliquent aux hyperviseurs :

• VMware ESXi : version 6.7 Update 3 ou ultérieure et VM Hardware Version 11 ou supérieure. Dans un cluster EVC, Skylake generation or later doit être sélectionné. VMware Cloud n’est pas pris en charge.
• Microsoft Hyper-V : version 6.0.6001.18016 sur Windows Server 2016 ou une version ultérieure. Processor Compatibility Mode n’est pas pris en charge.

Appliance commune avec des Log Collectors

Les valeurs de VM des classes Moyenne et Élevée s’appliquent à une appliance exécutant uniquement Sophos NDR. Si des intégrations Log Collector sont hébergées sur la même appliance, commencez la planification par le dimensionnement de NDR, puis ajoutez leur charge. Les limites et incidences suivantes sont documentées :

• L’ensemble des intégrations Log Collector d’une VM peut accepter au maximum 8'000 événements par seconde.
• Une intégration Log Collector requiert environ 400 MB RAM sous forte charge.
• Avec 4 CPU, NDR utilise 2 CPU ; avec 8 CPU, NDR en utilise 3. D’autres intégrations peuvent néanmoins utiliser ces CPU et ainsi influer sur le volume de trafic que NDR peut traiter.
• Avec 16 GB RAM, les intégrations Log Collector peuvent utiliser au maximum 2 GB au total afin de laisser suffisamment de mémoire à NDR.
• Sur une VM équipée des 4 CPU standard, un Log Collector fonctionnant au débit maximal d’événements requiert approximativement la même puissance de calcul que NDR sous une charge modérément élevée.

Il n’existe pas de dimensionnement universel pour les charges mixtes. Prévoyez des appliances supplémentaires si les limites de NDR ou les ressources disponibles risquent d’être dépassées. Utilisez plusieurs VM lorsque plusieurs intégrations Log Collector dépassent ensemble 8'000 événements par seconde. Si, en revanche, une seule intégration dépasse cette limite, tentez d’abord de réduire le volume d’événements à l’aide des paramètres Syslog du système source. Les valeurs approximatives documentées ne justifient aucune surallocation arbitraire.

Dimensionner le matériel certifié

Sophos détermine le niveau matériel d’après la capacité du commutateur qui assure la mise en miroir ainsi que d’après les charges continues et de pointe. Le capteur NDR doit offrir la même capacité que le commutateur depuis lequel provient le trafic mis en miroir. Les recommandations suivantes reposent sur une organisation type composée de 20 % d’utilisateurs intensifs, 60 % d’utilisateurs typiques et 20 % d’utilisateurs occasionnels. Elles supposent également l’utilisation de la VoIP, un certain volume de streaming vidéo, des chargements et téléchargements volumineux ainsi que des serveurs d’applications et des serveurs web.

Ces noms et niveaux de performances servent uniquement à la présélection. L’achat n’est approuvé que si le modèle exact et la configuration exacte figurent dans les Certified hardware specifications for NDR actuelles.

Pour chaque ligne, Sophos documente une charge de pointe possible équivalente à deux ou trois fois la charge typique. Cette indication de pointe ne remplace pas une mesure et ne doit pas être confondue avec le niveau de capacité. Une utilisation intensive supplémentaire du streaming vidéo et musical peut nécessiter le niveau immédiatement supérieur ; la décision repose sur les charges continues et de pointe mesurées ainsi que sur les limites certifiées actuelles. Si l’utilisation porte essentiellement sur les e-mails, un niveau inférieur peut convenir, à condition que les charges continues et de pointe ainsi que le nombre d’utilisateurs mesurés restent dans ses limites.

La bande passante et le nombre d’utilisateurs ne suffisent pas à sélectionner le matériel. Il faut également vérifier, dans la certification actuelle, le nombre maximal de connexions par seconde ainsi que la configuration approuvée du processeur, de la mémoire et, le cas échéant, des sockets. Ce point est particulièrement important pour le trafic générant de nombreuses connexions. La fiche technique de Sophos NDR du 19 décembre 2024 indique par exemple le même débit nominal pour deux configurations R660, mais des limites différentes en matière de connexions et de ressources :

Détail des configurations de la fiche technique en date du 19.12.2024 :

Dell R660, 2 sockets

• Débit max. : 40 Gbit/s
• Connexions max./s : 120'000
• CPU : 64
• RAM : 128 GB

Dell R660, 1 socket

• Débit max. : 40 Gbit/s
• Connexions max./s : 80'000
• CPU : 32
• RAM : 64 GB

Dell R650

• Débit max. : 20 Gbit/s
• Connexions max./s : 40'000
• CPU : 24
• RAM : 64 GB

Dell R450

• Débit max. : 10 Gbit/s
• Connexions max./s : 20'000
• CPU : 16
• RAM : 32 GB

Dell R350

• Débit max. : 4 Gbit/s
• Connexions max./s : 8'000
• CPU : 8
• RAM : 32 GB

Intel NUC 13th Gen

• Débit max. : 2,5 Gbit/s
• Connexions max./s : 4'000
• CPU : 12
• RAM : 32 GB

Ces valeurs datées illustrent toutes les dimensions techniques du dimensionnement et l’importance de la configuration exacte, mais ne constituent pas une matrice actuelle d’achat ou de certification. Pour R360, R660xs, OnLogic et toute autre variante, les valeurs manquantes ne doivent pas être déduites de modèles similaires, mais reprises exclusivement des spécifications certifiées actuelles.

Les recommandations matérielles constituent un modèle de charge et non une garantie valable pour toute répartition du trafic. Le streaming et les flux de sauvegarde volumineux génèrent beaucoup de volume ; Sophos NDR est optimisé pour ces trafics de streaming et « Elephant Flow », tandis que de nombreuses menaces sont détectées dans le trafic normal de navigation et d’applications. Le profil utilisateur et les valeurs réelles du réseau doivent donc être évalués conjointement.

Prérequis réseau avant le déploiement

L’appliance nécessite des connexions sortantes pour démarrer et effectuer les mises à jour. Si le pare-feu prend en charge les caractères génériques, Sophos documente les autorisations suivantes :

yum.oracle.com est facultatif ; sans accès, l’appliance utilise le miroir Sophos du dépôt JFrog. Si le pare-feu ne prend pas en charge les caractères génériques, ne convertissez pas cette courte liste en une liste d’hôtes individuels supposés. Utilisez plutôt la liste régionale à jour disponible sur la page Sophos Appliance requirements.

N’installez ni Sophos Agent ni aucun autre agent antimalware sur l’Integration Appliance. N’installez pas non plus manuellement les mises à jour du système d’exploitation ou de sécurité ; Sophos gère ces mises à jour.

Valider et transmettre la décision

Avant le déploiement, le protocole de planification doit contenir au minimum les éléments suivants :

1. Plateforme : ESXi, Hyper-V, AWS, Nutanix ou modèle matériel certifié exact.
2. Fenêtre de mesure : date, heure et durée de la mesure, ainsi que les valeurs continues et de pointe de la bande passante, des paquets et des flux au point de mise en miroir prévu.
3. Dimensionnement : classe de charge ou niveau matériel retenu et valeur limite la plus proche dans chaque cas ; pour le matériel, comparez également le nombre maximal mesuré de connexions par seconde à la limite certifiée actuelle.
4. Ressources selon la plateforme :
   • ESXi, Hyper-V et autres hôtes de VM autogérés : vCPUs, RAM, stockage, modèle de processeur ainsi que les indicateurs pdpe1gb et avx2 visibles dans la VM.
   • AWS : type d’instance pris en charge c5n.2xlarge et exigences de la section de déploiement AWS.
   • Matériel certifié : modèle certifié exact et configuration approuvée du processeur, de la mémoire et des sockets.
5. Charge supplémentaire : noms et nombre attendu d’événements par seconde de toutes les intégrations Log Collector hébergées sur la même appliance.
6. Réseau : connexions de gestion et de mise en miroir prévues ainsi que confirmation des autorisations sortantes requises pour les ports et domaines.
7. Mise à l’échelle : nombre et emplacement des capteurs supplémentaires lorsqu’un capteur virtuel risque de dépasser les limites de la classe Élevée.

La décision est solide lorsque chaque valeur mesurée respecte les limites du niveau choisi et que les prérequis propres à la plateforme sont satisfaits. Pour les hôtes de VM autogérés, ces prérequis comprennent l’hyperviseur, le processeur et les indicateurs visibles dans la VM. Pour AWS, le type d’instance pris en charge et les exigences de déploiement s’appliquent. Pour le matériel, le modèle exact, la configuration du processeur, de la mémoire et des sockets, le débit et le nombre maximal de connexions par seconde doivent correspondre à la certification actuelle. Pour une appliance commune, il faut également tenir compte du débit d’événements, de la mémoire et de l’incidence des Log Collectors sur le processeur.

La création de l’image, l’installation, l’enregistrement, le Traffic Mirroring et la première détection relèvent des étapes ultérieures de déploiement et de validation. Un état ultérieur Connected ou un état d’appliance vert ne confirme que l’état de l’intégration ; il ne prouve ni la couverture complète de la mise en miroir ni le bon fonctionnement de la détection de bout en bout.

Limites de la planification documentée

Les sources ne fournissent aucune formule permettant de calculer une taille personnalisée arbitraire du processeur et de la mémoire, supérieure aux niveaux de VM indiqués, à partir du nombre d’utilisateurs, de la bande passante ou des événements. Au-delà des limites de la classe Élevée, la décision documentée consiste donc à utiliser plusieurs appliances virtuelles, et non une VM unique plus puissante dimensionnée de manière spéculative.

De même, les tableaux de matériel ne remplacent pas les spécifications de certification actuelles. Ils fournissent des valeurs de présélection ou des valeurs datées issues de fiches techniques, mais n’approuvent pas des serveurs aux noms similaires, des composants différents ou des systèmes x86 personnalisés. Si le modèle matériel exact et la configuration approuvée font défaut, ou en l’absence de mesures fiables du trafic et des connexions, la plateforme n’est pas encore approuvée pour le déploiement. Il en va de même pour un hôte de VM autogéré si les indicateurs CPU requis ne sont pas disponibles dans la VM.