Zero trust, identité et segmentation

Comme direction, oui ; comme produit à acheter, non. Le zero trust consiste à ne pas faire confiance à une connexion simplement parce qu'elle vient de l'intérieur du réseau : chaque utilisateur et chaque appareil prouve qui il est et n'obtient accès qu'à ce dont il a besoin, vérifié encore et encore. Une petite entreprise peut aller loin en quelques étapes : authentification multifacteur sur chaque compte exposé à Internet, réseaux séparés pour les invités, les objets connectés et les serveurs, droits d'administrateur seulement là où ils sont nécessaires et via des comptes d'administration distincts, et un VPN ou une passerelle qui n'atteint que les systèmes utilisés par chaque groupe. Procédez dans cet ordre ; chaque étape est utile à elle seule. La surveillance réseau vérifie le résultat : NetSenX montre quels hôtes communiquent réellement entre eux sur les segments surveillés, sur toutes les offres, si bien qu'un chemin qui ne devrait pas exister devient visible.

Testez-la des deux côtés, puis observez le trafic réel. Depuis un hôte qui ne devrait pas entrer, essayez d'atteindre le segment protégé par un simple test de connexion, et depuis l'intérieur du segment protégé, vérifiez ce qu'il peut atteindre vers l'extérieur. Passez en revue les règles du pare-feu entre segments à la recherche d'autorisations trop larges, de vieilles exceptions et de règles que personne ne sait expliquer. Observez ensuite, car les règles dérivent : chaque demande de changement, chaque nouvelle application et chaque visite d'un prestataire peut ajouter une exception, et la vraie preuve, ce sont les connexions qui franchissent effectivement une frontière. Refaites le test après les modifications du réseau et au moins une fois par an. NetSenX montre sur sa carte réseau les communications d'hôte à hôte des segments surveillés et signale comme mouvement latéral les nouvelles sessions qui ne correspondent pas au comportement normal d'un hôte, sur toutes les offres, si bien qu'un chemin inattendu entre segments apparaît dès sa première utilisation. Un chemin qui existe mais n'est jamais emprunté reste invisible pour tout capteur passif.

Cela signifie planifier comme si un attaquant était déjà à l'intérieur, au lieu de compter uniquement sur le fait de le tenir dehors. La raison est pratique : l'hameçonnage, les mots de passe volés et les accès des prestataires font que le périmètre sera franchi tôt ou tard, et les questions deviennent alors jusqu'où va un intrus et en combien de temps vous le remarquez. Concrètement : limiter ce que chaque compte et chaque hôte peut atteindre, séparer les comptes d'administration des comptes ordinaires, conserver journaux et traces réseau assez longtemps pour enquêter, garder des sauvegardes hors ligne, surveiller les mouvements à l'intérieur du réseau et répéter ce que vous ferez quand une alerte arrive, y compris qui décide de déconnecter une machine. La détection à l'intérieur du réseau en fait partie : NetSenX surveille le trafic d'hôte à hôte pour repérer balayages, mouvements latéraux et beaconing, sur toutes les offres, si bien que les étapes d'un intrus après son entrée deviennent visibles.

Non, ils font des métiers différents. Le contrôle d'accès réseau (NAC) décide quels appareils peuvent rejoindre le réseau et sur quel segment ils arrivent, souvent à l'aide de 802.1X, de certificats d'appareil ou d'une vérification de leur état. Il ne surveille pas ce que fait ensuite un appareil admis, et la plupart des intrusions passent par des appareils et des comptes admis légitimement : un portable hameçonné, le compte d'un prestataire, une imprimante au micrologiciel ancien. Utilisez les deux si vous le pouvez : le NAC pour tenir les appareils inconnus dehors et placer les appareils connus au bon endroit, la surveillance pour voir quand un appareil connu se met à se comporter comme un intrus. Dans une petite entreprise, le NAC peut commencer simplement, avec la sécurité des ports sur les commutateurs et un Wi-Fi par certificat. NetSenX couvre la partie surveillance : il détecte balayage, mouvement latéral et beaconing depuis des appareils admis sur toutes les offres, et sa carte réseau montre les appareils vus sur les segments surveillés.

Un VPN classique l'est sur un point : une fois connecté, l'appareil de l'utilisateur est en général à l'intérieur du réseau avec un large accès, c'est-à-dire dans le modèle « de confiance parce qu'à l'intérieur » dont le zero trust s'éloigne. Cela ne veut pas dire que le VPN doit disparaître demain. Vous pouvez le rapprocher nettement du zero trust : exiger l'authentification multifacteur, ne donner à chaque groupe accès qu'aux systèmes dont il a besoin, vérifier avant la connexion qu'il s'agit d'un portable d'entreprise géré et à jour, et journaliser chaque session. Les produits de zero-trust network access (ZTNA) vont plus loin et connectent un utilisateur à une application à la fois plutôt qu'au réseau. Dans tous les cas, partez du principe qu'une session VPN peut être détournée et observez ce qu'elle fait. Avec un capteur sur un port SPAN ou TAP derrière la passerelle VPN, NetSenX détecte balayage, mouvement latéral et beaconing depuis les appareils des utilisateurs du VPN, sur toutes les offres.

Le ZTNA est une manière de donner aux utilisateurs distants accès à des applications précises plutôt qu'à tout le réseau. L'utilisateur se connecte via un fournisseur d'identité, le service vérifie l'utilisateur, l'appareil et souvent sa localisation et son état, puis ouvre une connexion vers cette seule application ; le reste du réseau reste invisible pour l'utilisateur. Beaucoup de produits le proposent sous forme de service cloud avec un petit connecteur dans votre réseau, si bien que rien n'a besoin d'écouter côté Internet. Dans une petite entreprise, il peut remplacer le VPN pour les applications web et le bureau à distance, et il facilite l'accès d'un prestataire à un seul système sans lui ouvrir le réseau. Il ne dispense pas de surveiller l'intérieur : un serveur d'application compromis peut toujours atteindre ses voisins. NetSenX ne fournit pas de ZTNA ; il détecte mouvement latéral et balayage depuis les hôtes des segments surveillés, sur toutes les offres.

Oui, dans la plupart des bureaux. Le secure access service edge (SASE) déplace le filtrage web, l'accès distant sécurisé et certaines fonctions de pare-feu vers un service cloud, et le zero trust change la façon d'accorder les accès, mais il vous faut toujours quelque chose qui bloque les connexions non sollicitées depuis Internet vers le bureau, sépare les segments réseau les uns des autres et contrôle ce que peuvent atteindre les serveurs et appareils qui ne font jamais tourner le client SASE. Imprimantes, caméras, machines et beaucoup de serveurs n'ont pas d'agent et ne sont protégés que par le réseau qui les entoure. Le rôle du pare-feu se réduit donc sans disparaître : protection entrante, segmentation et règles sortantes pour les appareils non gérés. Gardez ses règles courtes et revues. NetSenX ne remplace ni un pare-feu ni un service SASE et ne bloque rien. Il observe le trafic des segments surveillés et détecte balayage, mouvement latéral, beaconing et volume sortant inhabituel, sur toutes les offres, ce qui vous dit quand l'une ou l'autre couche est contournée.

Ils réduisent ce qu'un intrus peut atteindre depuis le premier appareil qu'il compromet. Le mouvement latéral consiste à sauter de cet appareil vers d'autres, en général par le bureau à distance, les partages de fichiers ou des outils d'administration, avec des mots de passe récupérés en chemin. La segmentation place des pare-feu ou des règles d'accès entre des groupes de systèmes, si bien qu'un portable de bureau compromis ne peut tout simplement pas ouvrir de session vers le serveur de base de données ou le système de sauvegarde. Le moindre privilège garantit que les comptes trouvés sur ce portable ne peuvent pas non plus se connecter aux serveurs, parce que les utilisateurs ordinaires ne sont pas administrateurs locaux partout et que les comptes d'administration ne servent pas à la messagerie. Une liste des hôtes autorisés à utiliser les protocoles d'administration réduit encore la brèche. Rien de tout cela n'est parfait, d'où le besoin de détection. NetSenX signale comme mouvement latéral les nouvelles sessions d'hôte à hôte sur des protocoles d'administration qui ne correspondent pas au comportement normal d'un hôte, sur toutes les offres, et à partir de l'offre Pro les relie entre hôtes en un seul récit.

Par les systèmes dont la perte ferait le plus mal et par les appareils auxquels vous faites le moins confiance. Un ordre pratique pour une petite entreprise : invités et appareils personnels sur un réseau à part avec seulement l'accès Internet ; imprimantes, caméras, écrans et autres objets connectés sur un réseau d'équipements qui ne peut pas ouvrir de connexions vers les PC ; serveurs, en particulier sauvegardes, serveurs de fichiers et contrôleur de domaine, sur un réseau de serveurs que les PC n'atteignent que sur les ports nécessaires ; et un chemin propre pour l'administration. Chaque étape est utile seule, et la plupart des commutateurs administrables et pare-feu savent le faire avec des VLAN et des règles. Avant d'écrire les règles, regardez qui parle réellement à qui, pour ne pas casser une dépendance oubliée, comme un scanner qui enregistre sur un partage de fichiers. La carte réseau de NetSenX montre les hôtes des segments surveillés et qui communique avec qui, sur toutes les offres, ce qui donne ce point de départ puis montre si les nouvelles frontières tiennent.

Utilisez des VLAN pour séparer les réseaux et un pare-feu, pas seulement des listes d'accès de commutateur, pour contrôler ce qui passe de l'un à l'autre. Placez les automates de production, les IHM et les serveurs SCADA dans leurs propres VLAN, installez un pare-feu entre eux et le réseau bureautique et ajoutez une petite DMZ pour les systèmes dont les deux côtés ont besoin, comme une copie de l'historian ou une passerelle d'accès distant. Écrivez les règles sous forme de liste d'autorisations : quel hôte du bureau peut atteindre quel hôte OT, sur quel port, et rien d'autre ; refusez et journalisez le reste. Les listes d'accès des commutateurs servent à une séparation simple à l'intérieur de l'OT, mais elles ne suivent pas l'état des connexions et deviennent vite sources d'erreurs à grande échelle. Préparez le changement avec l'ingénieur OT et une fenêtre de maintenance, car une dépendance oubliée peut arrêter une ligne. Surveillez ensuite la frontière : à partir de l'offre Pro, NetSenX signale le trafic qui franchit les niveaux du réseau de l'usine, depuis un port SPAN ou TAP, sans sonder aucun équipement OT.

La microsegmentation consiste à contrôler le trafic entre serveurs ou charges de travail individuels, et pas seulement entre zones du réseau, de sorte que deux serveurs d'un même segment ne puissent pas communiquer sans règle qui l'autorise. On la met en œuvre avec des pare-feu d'hôte, des groupes de sécurité d'hyperviseur ou de cloud, ou un agent qui applique la politique sur chaque machine. Elle est très efficace contre un intrus qui passe d'un serveur à l'autre, et courante dans les centres de données et le cloud. La plupart des petites entreprises gagnent d'abord davantage avec une segmentation ordinaire : réseaux séparés pour les invités, les équipements, les utilisateurs et les serveurs. Si vous exploitez beaucoup de serveurs, la version économique de la microsegmentation consiste à activer le pare-feu de chaque serveur et à n'autoriser que les connexions dont il a besoin. Quel que soit votre choix, laissez le trafic réel guider les règles. La carte réseau de NetSenX montre quels hôtes communiquent sur les segments surveillés, sur toutes les offres, et les alertes de mouvement latéral montrent les sessions qui ne correspondent pas au comportement normal d'un hôte.

Seulement si le trafic entre VLAN passe par un pare-feu ou des règles d'accès qui imposent quelque chose. Un VLAN seul sépare des domaines de diffusion sur un commutateur ; si le routeur entre VLAN laisse tout passer, la séparation est cosmétique, et c'est un constat fréquent dans les petits réseaux. Des ports de commutateur mal configurés peuvent aussi permettre à un attaquant de sauter d'un VLAN à l'autre, par exemple des ports trunk ouverts aux appareils des utilisateurs ou le VLAN par défaut utilisé pour tout. Pour que les VLAN comptent : routez entre eux via un pare-feu avec liste d'autorisations, configurez les ports utilisateurs sur un seul VLAN d'accès, désactivez les ports inutilisés et gardez les interfaces d'administration dans leur propre VLAN. Vérifiez ensuite avec le trafic réel que les règles tiennent. NetSenX montre les connexions d'hôte à hôte des segments surveillés et détecte balayage et mouvement latéral sur toutes les offres, si bien qu'un hôte qui atteint un autre VLAN sans y être autorisé devient visible, à condition que ce trafic traverse une liaison recopiée.

Connectez-vous au réseau invités avec un téléphone ou un portable et essayez d'atteindre des systèmes internes : ouvrez l'adresse d'un serveur de fichiers, la page web d'une imprimante, la page d'administration du routeur et le serveur de noms interne du bureau. Sur votre propre réseau, un simple test de connexion ou un ping vers les plages d'adresses internes montre si quelque chose répond. Vérifiez ensuite la configuration : isolation des clients activée, réseau invités dans son propre VLAN ou sur un port de routeur dédié, accès Internet uniquement, et interface d'administration du système Wi-Fi inaccessible depuis ce réseau. Recommencez après chaque modification du Wi-Fi, car les mises à jour du micrologiciel et les nouvelles bornes peuvent réinitialiser des réglages. Si le segment invités est surveillé, NetSenX affiche les appareils invités sur la carte réseau et signale toute session de leur part vers des hôtes internes, ainsi que balayage ou mouvement latéral, sur toutes les offres. Un appareil invité qui atteint un serveur interne apparaît comme une connexion qui ne devrait pas exister.

C'est une bonne première étape, mais seulement s'il est vraiment séparé et que ce n'est pas votre seule séparation. Un réseau invités avec son propre nom mais la même plage d'adresses et aucune règle entre lui et le bureau n'est pas séparé du tout ; vérifiez qu'il est isolé et n'offre que l'accès Internet. Il ne protège en outre que contre les visiteurs : téléphones du personnel, téléviseurs connectés et machine à café finissent souvent sur le réseau du bureau à la place. Placez appareils personnels et objets connectés sur le réseau invités ou un réseau d'équipements, gardez les portables de l'entreprise sur un réseau avec authentification par certificat ou par utilisateur, changez régulièrement le mot de passe invités et ne laissez pas le réseau invités atteindre les interfaces d'administration du Wi-Fi lui-même. Confirmez ensuite avec le trafic réel. Si le segment invités est surveillé, NetSenX liste ses appareils sur la carte réseau et signale toute connexion de leur part vers des hôtes internes, tout balayage ou mouvement latéral, sur toutes les offres.

Dans la plupart des petits bureaux, oui : une prise active dans une salle de réunion, à l'accueil ou derrière une imprimante donne à quiconque y branche un appareil le même accès réseau qu'un PC de l'entreprise. Un petit ordinateur caché là peut contacter son propriétaire et servir de porte d'entrée dans le réseau pendant des mois. Fermez-la par des mesures simples : désactivez les ports de commutateur et prises murales inutilisés, placez salles de réunion et accueil sur le réseau invités, utilisez la sécurité des ports pour n'autoriser que des appareils connus sur un port, ou 802.1X pour qu'un appareil doive s'authentifier avant d'obtenir le moindre accès. Faites de temps en temps le tour des bureaux et vérifiez les commutateurs à la recherche d'appareils inconnus. NetSenX aide à trouver ce qui est déjà entré : sa carte réseau liste les appareils vus sur les segments surveillés, y compris ceux sans agent, sur toutes les offres, et un appareil caché qui appelle l'extérieur à intervalles réguliers est signalé comme beaconing. Un appareil muet, ou placé sur un segment non surveillé, n'est pas vu.

802.1X est une norme qui oblige un appareil à prouver son identité avant qu'un port de commutateur ou un réseau Wi-Fi le laisse entrer, en général avec un certificat ou un identifiant et un mot de passe vérifiés par un serveur d'authentification. Un appareil qui échoue n'obtient aucun accès, ou atterrit sur un réseau invités restreint. C'est le moyen le plus efficace d'empêcher des appareils inconnus de simplement se brancher, et pour le Wi-Fi il remplace un mot de passe partagé par des identifiants par utilisateur ou par appareil, si bien que l'accès d'une personne qui part peut être révoqué seul. Il faut des commutateurs et des bornes qui le prennent en charge, un serveur d'authentification, souvent inclus dans les services d'identité cloud ou les pare-feu, et un peu de soin avec les imprimantes et les appareils incapables de s'authentifier. Beaucoup de petits bureaux commencent par 802.1X sur le Wi-Fi seulement et la sécurité des ports sur les prises filaires. NetSenX n'impose pas le contrôle d'accès ; sa carte réseau montre les appareils vus sur les segments surveillés, sur toutes les offres, ce qui aide à trouver ceux que votre contrôle d'accès a manqués.

Elle en arrête la plupart, mais pas toutes. L'authentification multifacteur (MFA) bloque les attaques qui reposent uniquement sur un mot de passe volé ou deviné, c'est pourquoi les assureurs l'exigent et NIS2 la cite parmi ses mesures. Les attaquants se sont adaptés : ils utilisent de fausses pages de connexion qui relaient le code en temps réel, volent le cookie de session après la connexion, inondent l'utilisateur de demandes push jusqu'à ce qu'il en accepte une, ou convainquent le support de réinitialiser un téléphone. Relevez le niveau : préférez des méthodes résistantes à l'hameçonnage comme les clés d'accès (passkeys) ou les clés de sécurité matérielles, surtout pour les administrateurs et la finance ; activez la correspondance de nombres sur les notifications push ; limitez la durée des sessions ; et faites vérifier l'identité par le support avant toute réinitialisation de la MFA. Surveillez les journaux de connexion pour repérer les connexions à risque. Un capteur réseau ne voit pas les connexions. Ce que NetSenX montre, c'est ce que fait ensuite l'appareil d'un compte pris en main sur le réseau, comme un mouvement latéral, un balayage ou de gros envois, sur toutes les offres.

En général pas comme « MFA en place », et une réponse imprécise dans un questionnaire peut poser problème plus tard. Les questionnaires d'assurance et les auditeurs demandent typiquement où la MFA est imposée : messagerie, accès distant, applications cloud, comptes administrateur et sauvegardes. Si la MFA couvre la messagerie mais pas le VPN, ou les utilisateurs mais pas les administrateurs, dites-le précisément, car l'instruction d'un sinistre le vérifiera. Comblez d'abord les lacunes que les attaquants exploitent le plus : accès distant, messagerie, comptes administrateur et console de sauvegarde, puis les autres applications cloud. Supprimez les exceptions devenues inutiles et documentez celles que vous gardez, avec une raison et une date de fin. Les comptes de service qui ne peuvent pas utiliser la MFA doivent être limités à des sources connues et surveillés à la place. NetSenX ne vérifie pas la couverture MFA ; votre fournisseur d'identité en rend compte. NetSenX apporte la part réseau des preuves : un historique d'alertes horodatées pour les segments surveillés, conservé pendant la durée de rétention de votre offre.

Les clés d'accès (passkeys) et les clés de sécurité matérielles basées sur la norme FIDO2, ainsi que les cartes à puce avec certificats. Elles résistent à l'hameçonnage parce que la clé vérifie l'adresse du site avec lequel elle dialogue et ne répond pas à un faux site : il n'y a donc aucun code que l'utilisateur pourrait saisir au mauvais endroit. Les applications d'authentification avec correspondance de nombres sont un bon second choix ; les codes par SMS et les simples notifications push « accepter ou refuser » sont les plus faibles, car une fausse page convaincante ou un utilisateur fatigué peut les livrer. Commencez par les comptes qui comptent le plus : administrateurs, finance, direction et toute personne ayant accès aux sauvegardes ou aux données clients. Prévoyez une clé de secours par personne et une procédure de récupération documentée, pour qu'une clé perdue ne conduise pas à une réinitialisation précipitée et peu sûre. La MFA vit chez votre fournisseur d'identité, pas dans le réseau. NetSenX ne voit pas les connexions ; il montre ce que font les appareils sur les segments surveillés après l'utilisation de n'importe quel compte.

C'est une attaque dans laquelle quelqu'un qui connaît déjà le mot de passe d'un utilisateur déclenche connexion sur connexion, si bien que le téléphone de l'utilisateur se remplit de demandes d'approbation, souvent la nuit, jusqu'à ce qu'il appuie sur « accepter » pour que cela cesse. Parfois l'attaquant appelle ou écrit aussi à l'utilisateur en se faisant passer pour l'informatique. Cela fonctionne contre les simples notifications push « accepter ou refuser ». Les défenses sont côté identité : activez la correspondance de nombres, pour que l'utilisateur doive saisir un nombre affiché sur l'écran de connexion ; affichez le lieu et l'application dans la notification ; limitez le nombre de demandes par minute ; alertez en cas de refus répétés ; et dites au personnel qu'une demande inattendue signifie que son mot de passe est connu, qu'il doit la refuser et appeler l'informatique. Mieux encore, passez les comptes clés aux passkeys ou aux clés matérielles. Un capteur réseau ne voit pas ces demandes. NetSenX montre ce qui se passe si un attaquant entre : sessions inhabituelles, balayages ou envois depuis l'appareil de l'utilisateur sur les segments surveillés, sur toutes les offres.

En général plus de personnes et de comptes que quiconque ne le pense : établissez donc la liste à partir des systèmes eux-mêmes, pas de mémoire. Vérifiez les groupes d'administrateurs de votre annuaire ou de votre fournisseur d'identité cloud, les administrateurs locaux des PC et serveurs, les rôles d'administration de chaque application cloud comme la messagerie, la comptabilité et le partage de fichiers, les comptes d'administration des pare-feu, commutateurs, Wi-Fi et sauvegardes, et les comptes qu'utilise votre prestataire informatique. Cherchez les anciens salariés, les comptes partagés, les comptes inactifs depuis des mois et les comptes de service dotés de droits d'administration. Réduisez ensuite : supprimez ce dont personne n'a besoin, donnez aux administrateurs un compte d'administration distinct, exigez pour tous une MFA résistante à l'hameçonnage et refaites la revue chaque trimestre et à chaque départ. C'est un travail d'identité, et un capteur réseau ne peut pas lister les droits d'administrateur. NetSenX aide de l'autre côté : il signale comme mouvement latéral les protocoles d'administration utilisés entre hôtes d'une manière qui ne correspond pas à leur comportement normal, sur toutes les offres.

Cela signifie que chaque personne, chaque compte et chaque système n'obtient que l'accès dont il a besoin pour sa tâche, aussi longtemps qu'il en a besoin, et rien de plus. Concrètement, dans une petite entreprise : le personnel n'est pas administrateur local de son PC ; les administrateurs utilisent un compte d'administration distinct pour l'administration et un compte ordinaire pour la messagerie et la navigation ; les partages de fichiers sont ouverts aux équipes qui s'en servent, pas à tout le monde ; les prestataires obtiennent l'accès aux systèmes qu'ils maintiennent, activé quand il le faut ; les comptes de service n'ont que les droits nécessaires à leur application ; et les accès sont revus quand quelqu'un change de poste ou part. Le gain : un mot de passe volé ou un portable infecté atteint bien moins de choses. Cela réduit aussi le bruit : un accès inhabituel ressort davantage quand l'accès normal est étroit. NetSenX observe le versant réseau : il signale comme mouvement latéral les nouvelles sessions entre hôtes qui ne correspondent pas à leur comportement normal, sur toutes les offres, ce qui révèle souvent des accès que personne n'avait voulu ouvrir.

Oui, et ce sont souvent les comptes les moins surveillés de l'entreprise. Les comptes de service font tourner sauvegardes, analyses, intégrations et tâches planifiées, souvent avec des droits étendus, des mots de passe qui ne changent jamais et sans authentification multifacteur. Les jetons et clés d'API des services cloud traînent dans des scripts, des fichiers de configuration et des dépôts de code, où un attaquant qui en trouve un peut l'utiliser de n'importe où. Tenez un inventaire avec un responsable pour chacun, ne leur donnez que les droits nécessaires, stockez les secrets dans un coffre plutôt que dans des fichiers, renouvelez-les à intervalles réguliers et immédiatement quand quelqu'un qui y avait accès part, limitez d'où ils peuvent être utilisés, et alertez quand l'un d'eux sert depuis un lieu ou à une heure inhabituels ; vos journaux d'identité et de cloud le montrent. Sur le réseau, un compte de service est toujours utilisé depuis un hôte : NetSenX signale cet hôte quand il ouvre de nouvelles sessions vers d'autres hôtes, balaie ou envoie des volumes inhabituels, sur toutes les offres. Il ne voit pas le jeton lui-même dans le trafic chiffré.

Oui. Quand plusieurs personnes utilisent un même compte d'administration, personne ne peut dire ensuite qui a fait quoi, le mot de passe est rarement changé au départ de quelqu'un, et l'authentification multifacteur est difficile à lier à une personne, si bien que le compte s'en passe souvent. Donnez à chaque administrateur, y compris au personnel de votre prestataire informatique, un compte d'administration nominatif avec une MFA résistante à l'hameçonnage, et supprimez ou désactivez le compte partagé. Lorsqu'un compte intégré ne peut pas être supprimé, comme l'administrateur local des PC ou le compte de secours d'un pare-feu, donnez à chaque machine un mot de passe aléatoire unique géré par un outil, gardez les identifiants de secours sous scellé et alertez lorsqu'ils sont utilisés. Journalisez les actions d'administration par personne et revoyez la liste des comptes d'administration chaque trimestre. Un capteur réseau ne peut pas dire quelle personne a utilisé un compte. NetSenX montre depuis quel hôte partent les sessions d'administration et signale comme mouvement latéral celles qui ne correspondent pas au comportement normal d'un hôte, sur toutes les offres, si bien qu'un compte partagé utilisé depuis une machine inhabituelle se remarque.

Oui, pour la plupart des entreprises ils sont bien plus sûrs que les alternatives : mots de passe réutilisés, tableurs et post-it. Un bon gestionnaire de mots de passe professionnel permet à chacun d'utiliser des mots de passe longs et uniques, partage les identifiants d'équipe sans les envoyer par e-mail et retire l'accès d'une personne qui part en une seule opération. Le coffre devient précieux, protégez-le donc : exigez pour lui une authentification multifacteur résistante à l'hameçonnage, choisissez un fournisseur qui chiffre le coffre de telle sorte qu'il ne puisse pas en lire le contenu, vérifiez où vos données sont stockées, bloquez l'accès au coffre depuis des appareils non gérés si le produit le permet, et documentez la procédure de récupération. Ne conservez pas les identifiants d'administration du gestionnaire de mots de passe uniquement dans celui-ci. Un gestionnaire de mots de passe n'arrête pas l'hameçonnage à lui seul, même s'il aide, car il ne remplit pas un mot de passe sur un faux site. NetSenX ne voit ni mots de passe ni coffres ; il observe ce que font les appareils sur le réseau.

La longueur, l'unicité et l'authentification multifacteur, plutôt que des règles de complexité et des changements mensuels imposés. Les lignes directrices du NIST sur l'identité numérique (SP 800-63B) privilégient les mots de passe longs, la vérification des nouveaux mots de passe contre des listes de mots de passe déjà compromis, et le changement lorsqu'il existe un indice de compromission plutôt que selon un calendrier fixe, car les changements périodiques forcés poussent vers des schémas prévisibles. Concrètement : une longueur minimale qui permet les phrases de passe, aucune réutilisation d'un système à l'autre, un gestionnaire de mots de passe pour tous, le blocage des mots de passe compromis ou courants, un verrouillage ou un ralentissement après des échecs répétés, et la MFA sur tout ce qui est exposé à Internet. Les comptes d'administration et de service méritent des mots de passe plus longs, générés aléatoirement et stockés dans un coffre. Expliquez les raisons au personnel ; une politique comprise est mieux suivie. NetSenX n'impose pas de mots de passe. Sur le réseau, il signale comme attaque par force brute les tentatives de connexion répétées contre les hôtes surveillés, sur toutes les offres, ce qui montre quand quelqu'un essaie de deviner.

L'authentification unique (SSO) permet de se connecter une fois avec un compte d'entreprise auprès d'un fournisseur d'identité, puis d'utiliser de nombreuses applications sans mots de passe séparés, généralement via les normes SAML ou OpenID Connect. Bien mise en place, elle améliore la sécurité : moins de mots de passe à réutiliser ou à voler, un seul endroit pour imposer la MFA et les règles sur les appareils, un seul endroit pour voir les connexions, et un seul interrupteur à couper au départ de quelqu'un, qui ferme d'un coup l'accès à toutes les applications reliées. Le revers est la concentration : le fournisseur d'identité devient la clé de tout, protégez donc ses comptes d'administration par une MFA résistante à l'hameçonnage, gardez un compte d'accès de secours sous scellé et surveillez ses journaux de connexion. Les applications hors SSO gardent leurs propres mots de passe ; listez-les pour que les départs ne les oublient pas. Le SSO est une infrastructure d'identité, pas de la surveillance réseau, et NetSenX ne voit pas les connexions. Il montre ce que font les appareils sur le réseau après que quelqu'un s'est connecté.

Rendez d'abord l'accès étroit et visible, puis surveillez-le. Convenez par écrit des PC que les comptables peuvent atteindre, par quel outil, à quelles heures et avec quels comptes, idéalement un compte nominatif par personne avec authentification multifacteur. Préférez un outil d'accès distant que vous contrôlez, avec journalisation des sessions, à un outil installé par le comptable ; activez-le pour la fenêtre de clôture du mois et désactivez-le ensuite. Gardez les PC de la comptabilité sur un segment qui ne peut pas atteindre le reste du réseau. Demandez au cabinet comment il protège ses propres systèmes, car leur compromission devient la vôtre. Surveillez ensuite le schéma : les sessions distantes apparaissent sur le réseau comme des connexions d'une adresse extérieure vers des hôtes internes précis à des heures précises. NetSenX montre ces connexions et, si une session se met à atteindre d'autres hôtes internes, signale un mouvement latéral, sur toutes les offres ; les contacts réguliers d'un outil distant en dehors de la fenêtre convenue apparaissent comme du beaconing. NetSenX ne gère pas qui a accès.

Son accès devient celui de l'attaquant. Un prestataire informatique détient généralement des droits d'administration sur vos serveurs, des outils de gestion à distance sur chaque PC et des mots de passe de vos comptes cloud ; un cabinet comptable peut avoir un accès distant aux PC de la comptabilité et à votre banque en ligne. Les attaquants le savent, et certains grands incidents se sont propagés d'un prestataire à nombre de ses clients. Préparez-vous avant : listez chaque prestataire disposant d'un accès et ce qu'il peut atteindre, exigez des comptes nominatifs avec authentification multifacteur, limitez ses outils aux systèmes qu'il maintient, demandez comment il protège son propre environnement et comment il vous informera d'un incident, et inscrivez ces obligations dans le contrat, ce que NIS2 attend aussi au titre de la sécurité de la chaîne d'approvisionnement. Convenez de la manière de couper son accès en urgence. NetSenX montre les connexions du prestataire dans votre réseau et détecte mouvement latéral, balayage, beaconing et volume sortant inhabituel depuis les hôtes qu'il utilise, sur toutes les offres. Il ne surveille pas les systèmes du prestataire lui-même.

En croisant l'inventaire logiciel et le trafic réseau. Sur chaque serveur, listez les programmes installés et les services en cours, et cherchez les outils de bureau à distance et d'assistance à distance, les clients VPN et les agents de plateformes de gestion à distance ; demandez à chaque prestataire quels outils il a installés, quand, et s'il s'en sert encore. Sur le réseau, cherchez ce que font ces outils même au repos : des contacts réguliers avec les serveurs relais de l'éditeur, ou des connexions depuis une adresse cloud que personne chez vous ne sait expliquer. Supprimez ce qui n'est plus nécessaire, placez ce qui l'est derrière votre propre chemin d'accès contrôlé, et changez les mots de passe que connaissait le prestataire. NetSenX signale les contacts réguliers comme beaconing sur toutes les offres et place les destinations extérieures situées sur des serveurs cloud loués dans sa file de revue, où vous les confirmez, les marquez comme suspectes ou les gardez pour plus tard. Quand l'agent tourne sur le serveur, l'alerte nomme aussi le programme local.

Avec un chemin contrôlé unique, des comptes nominatifs et une trace de chaque session. Tenez un registre des prestataires disposant d'un accès : qui ils sont, quels systèmes ils atteignent, par quel outil et dans le cadre de quel contrat. Faites passer tout accès de prestataire par une passerelle, un VPN ou un bastion qui vous appartient, avec authentification multifacteur et un compte personnel par technicien ; ouvrez l'accès pour des créneaux convenus et refermez-le ensuite ; journalisez ou enregistrez les sessions. Revoyez le registre chaque trimestre et supprimez les accès qui ne servent plus. Exigez des prestataires qu'ils vous signalent les incidents de leur côté, et testez que vous savez couper leur accès rapidement. Sur le réseau, les sessions des prestataires ne devraient alors partir que de ce chemin unique. NetSenX montre les connexions, détecte mouvement latéral et balayage depuis les hôtes utilisés par les prestataires, sur toutes les offres, et place les destinations extérieures sur des serveurs cloud loués dans sa file de revue, si bien qu'un outil qui contourne votre chemin devient visible.

Cela signifie gérer les risques de cybersécurité venant de vos fournisseurs et prestataires dans le cadre de votre propre gestion des risques. La directive (UE) 2022/2555 cite la sécurité de la chaîne d'approvisionnement parmi les mesures de son article 21, y compris la sécurité des relations avec les fournisseurs et prestataires directs. Concrètement, pour une entité concernée : savoir quels prestataires ont accès à vos systèmes ou données, évaluer le degré de criticité de chacun, exiger dans les contrats des mesures de sécurité de base et la notification des incidents, limiter et contrôler leurs accès, et revoir tout cela régulièrement. Si vous êtes fournisseur d'une entité soumise à NIS2, attendez-vous à ce qu'on vous demande des preuves similaires, même si NIS2 ne s'applique pas directement à vous. Les transpositions nationales peuvent ajouter des précisions : vérifiez la loi de votre pays. NetSenX n'évalue pas les prestataires. Il montre ce que fait leur accès sur votre réseau surveillé : connexions, mouvement latéral, balayage et beaconing depuis les hôtes qu'ils utilisent, sur toutes les offres.

Surtout par les comptes, en partie par le réseau. Côté identité : désactivez les comptes de la personne le dernier jour, révoquez les certificats VPN et les sessions applicatives, retirez ses appareils de la gestion des appareils, changez les mots de passe partagés qu'elle connaissait, et vérifiez les règles de transfert de messagerie et les appareils personnels enregistrés pour la MFA. Surveillez ensuite les journaux de connexion de ce compte et alertez à toute utilisation. Côté réseau, un appareil qui a encore accès, par exemple un téléphone personnel avec le mot de passe du Wi-Fi du bureau ou un PC à la maison avec un profil VPN enregistré, apparaît quand il se connecte : la carte réseau de NetSenX liste les appareils vus sur les segments surveillés avec leurs dates de première et dernière apparition, sur toutes les offres, si bien qu'un appareil que vous pensiez disparu réapparaît, et la vue VPN liste tunnels et sessions de passerelle. Changez le mot de passe du Wi-Fi, ou mieux, utilisez des identifiants Wi-Fi par utilisateur, pour que les appareils d'une personne partie ne puissent pas revenir. NetSenX observe des appareils, pas des personnes, et ne suit pas un ancien salarié.

Surtout grâce aux journaux de connexion, car ils enregistrent qui s'est connecté, d'où et comment. Cherchez des connexions depuis de nouveaux pays, des appareils inconnus ou des hébergeurs, des connexions réussies juste après de nombreux échecs, de nouvelles méthodes MFA enregistrées, de nouvelles règles de transfert de messagerie et des accès à des applications que la personne n'utilise jamais. La plupart des fournisseurs d'identité et des suites bureautiques en cloud savent signaler les connexions à risque ; activez cette fonction et veillez à ce que quelqu'un lise les alertes. Consultez les services publics de notification de fuites pour le domaine de votre entreprise, et agissez sur leurs signalements en réinitialisant le mot de passe et en vérifiant sa réutilisation. Le réseau montre la seconde moitié : ce que l'attaquant fait du compte. NetSenX détecte mouvement latéral, balayage, beaconing et envois inhabituels depuis les appareils des segments surveillés, sur toutes les offres, et c'est souvent ainsi qu'une prise de contrôle de compte devient visible dans l'entreprise. Il ne voit pas la connexion elle-même et ne lit pas les mots de passe.

Oui. Un administrateur qui lit ses e-mails et navigue sur le web avec un compte d'administration expose les clés de tout à chaque message d'hameçonnage et à chaque site malveillant. Avec un compte d'administration distinct, utilisé uniquement pour les tâches d'administration et jamais pour la messagerie ou la navigation, un compte ordinaire compromis rapporte beaucoup moins à l'attaquant. Allez plus loin quand c'est possible : exigez une MFA résistante à l'hameçonnage sur les comptes d'administration, utilisez-les uniquement depuis un poste d'administration dédié ou un bastion, ne donnez à chaque compte d'administration que les droits sur les systèmes qu'il gère, et désactivez les comptes d'administration inutilisés depuis des mois. Cela vaut aussi pour le personnel de votre prestataire informatique. C'est une hygiène d'identité qu'un outil réseau ne peut pas imposer. Elle rend toutefois la surveillance plus précise : quand les sessions d'administration ne sont attendues que depuis un poste ou un bastion, NetSenX signale comme mouvement latéral les protocoles d'administration utilisés depuis d'autres hôtes, sur toutes les offres.

La gestion des accès à privilèges (PAM) est un ensemble d'outils et de pratiques pour contrôler les comptes les plus puissants : administrateurs, root, comptes de service et comptes de secours. Ses fonctions typiques sont un coffre qui stocke et renouvelle les mots de passe d'administration, l'emprunt d'identifiants pour une durée limitée, l'enregistrement des sessions, une approbation avant l'accès et des droits juste-à-temps qui n'existent que le temps d'une tâche. Les produits PAM complets conviennent aux grandes entreprises et aux environnements réglementés. Une petite entreprise peut couvrir l'essentiel sans eux : un inventaire des comptes à privilèges, des comptes d'administration distincts avec une MFA résistante à l'hameçonnage, des mots de passe d'administrateur local uniques gérés par un outil, un bastion pour l'administration à distance et une revue trimestrielle. Choisissez un produit PAM quand le nombre d'administrateurs, de prestataires ou les exigences d'audit rendent ce travail manuel peu fiable. NetSenX n'est pas un outil PAM. Il en est le complément : il montre où ont lieu les sessions à privilèges sur le réseau et signale comme mouvement latéral celles qui ne correspondent pas au comportement normal d'un hôte, sur toutes les offres.

En partie, et NetSenX moins qu'on pourrait le croire. Beaucoup d'attaques d'identité se déroulent dans les systèmes de connexion : pulvérisation de mots de passe contre des comptes cloud, hameçonnage de codes MFA, vol de jetons de session et abus de droits dans l'annuaire. Elles laissent des traces dans les journaux du fournisseur d'identité, de l'annuaire et du cloud, pas sur le réseau du bureau, et ce sont donc les outils qui lisent ces journaux, comme la détection des risques du fournisseur d'identité, un EDR ou un SIEM, qui les repèrent. Certaines attaques contre l'annuaire traversent le réseau, par exemple un poste qui demande soudain de nombreux tickets de service au contrôleur de domaine, et des outils spécialisés surveillent ces protocoles. NetSenX n'émet pas d'alertes sur les événements d'identité. Ce qu'il voit, c'est le comportement des appareils autour : les tentatives de connexion répétées contre les hôtes surveillés comme attaque par force brute, ainsi que le mouvement latéral, le balayage et le beaconing qui suivent la compromission d'un compte, sur toutes les offres. Utilisez-le à côté de vos journaux d'identité, pas à leur place.

Non, NIS2 ne nomme pas le zero trust, mais plusieurs des mesures qu'elle exige vont dans le même sens. L'article 21 de la directive (UE) 2022/2555 demande aux entités concernées des mesures fondées sur les risques qui comprennent notamment des politiques de contrôle d'accès, la gestion des actifs, le recours à l'authentification multifacteur ou à l'authentification continue, des communications sécurisées et la sécurité de la chaîne d'approvisionnement. Les pratiques zero trust, comme la vérification de chaque utilisateur et appareil, le moindre privilège et la segmentation du réseau, sont une manière pratique de mettre en œuvre ces mesures, mais la directive vous laisse le choix de la méthode, et les transpositions et guides nationaux peuvent ajouter des précisions ; vérifiez la loi de votre pays. Les auditeurs recherchent une analyse de risques documentée, des mesures qui y correspondent et la preuve qu'elles fonctionnent. NetSenX apporte des preuves côté réseau : quels hôtes communiquent sur les segments surveillés, et des alertes de mouvement latéral, de balayage et de beaconing, sur toutes les offres. Il ne vous rend pas conforme.

Partez du principe qu'un portable sera compromis et décidez à l'avance du peu qu'il doit pouvoir toucher. Les portables ordinaires ont rarement besoin de communiquer entre eux : bloquez donc le trafic de portable à portable avec le pare-feu du poste ou les réglages des commutateurs ; ne les laissez atteindre les serveurs que sur les ports qu'utilisent leurs applications ; gardez les sauvegardes, les interfaces d'administration et les chemins d'administration du contrôleur de domaine hors de leur portée ; et veillez à ce que l'utilisateur ne soit pas administrateur local, pour qu'un logiciel malveillant ne puisse pas facilement désactiver la protection ou récupérer les mots de passe d'autres comptes. Sur le VPN, ne donnez à chaque groupe accès qu'à ce dont il a besoin. Vérifiez ensuite le résultat avec le trafic réel, car un jeu de règles sur le papier a souvent des failles. NetSenX montre quels hôtes communiquent sur les segments surveillés et signale comme mouvement latéral les nouvelles sessions d'hôte à hôte qui ne correspondent pas au comportement normal d'un portable, ainsi que balayage et beaconing, sur toutes les offres, si bien que vous voyez où un portable compromis pourrait encore aller.

Non. La plupart des serveurs ont besoin d'une courte liste de destinations sortantes, comme les serveurs de mises à jour, une cible de sauvegarde et quelques services partenaires, et de rien d'autre. Un accès sortant illimité est ce qui permet à un logiciel malveillant sur un serveur de contacter son serveur, de télécharger des outils et d'envoyer des données volées. Restreignez-le par un filtrage sortant sur le pare-feu : autorisez les destinations dont chaque serveur a besoin, faites passer l'accès web par un proxy si vous en avez un, et refusez et journalisez le reste. Commencez en mode journalisation pendant quelques semaines pour découvrir ce que les serveurs utilisent vraiment, puis resserrez. Les règles fondées sur des noms de domaine sont plus faciles à maintenir que des listes d'adresses, car les services cloud changent d'adresses. Il en va de même pour les imprimantes, les caméras et les équipements OT. NetSenX montre vers quelles destinations extérieures se connectent les hôtes surveillés, détecte beaconing et volume sortant inhabituel sur toutes les offres et place les destinations sur des serveurs cloud loués dans sa file de revue, ce qui vous donne la liste nécessaire pour écrire les règles.

Fondez-les sur le trafic observé, introduisez-les par étapes et gardez une voie de retour. Commencez par enregistrer pendant quelques semaines qui parle réellement à qui, y compris les tâches rares : sauvegardes, paie, rapports de fin de mois, le scanner qui enregistre sur un partage. Rédigez à partir de là des règles d'autorisation, revoyez-les avec le responsable de chaque système et décidez quelles connexions observées ne devraient pas exister du tout. Réglez ensuite le pare-feu pour qu'il journalise ce que les nouvelles règles bloqueraient, sans bloquer, et examinez chaque occurrence. Seulement après, appliquez, un segment à la fois, avec un plan de retour arrière et quelqu'un sur place. Documentez le jeu de règles, avec une raison et un responsable pour chaque règle. La carte réseau de NetSenX montre les communications d'hôte à hôte des segments surveillés, sur toutes les offres, c'est-à-dire l'image du trafic observé dont cette méthode a besoin, et ses alertes de mouvement latéral montrent ensuite les sessions qui ne correspondent pas à la nouvelle normale.

Oui, chaque fois que vous hébergez quelque chose qu'Internet ou un autre réseau non fiable doit atteindre. Une zone démilitarisée (DMZ) est un segment réseau séparé entre l'extérieur et votre réseau interne, où l'on place les systèmes qui doivent accepter des connexions extérieures, comme un serveur web, un relais de messagerie, une passerelle d'accès distant ou un serveur de transfert de fichiers. Si l'un d'eux est compromis, l'attaquant se trouve dans la DMZ, et les règles du pare-feu l'empêchent d'ouvrir des connexions vers le réseau interne. La même idée sépare réseaux bureautique et de production dans les usines. Beaucoup de petites entreprises n'hébergent plus elles-mêmes de services publics, et la DMZ est alors réduite ou inutile ; mais dès que vous redirigez un port vers un serveur interne, vous avez un problème de DMZ sans DMZ. Gardez les hôtes de la DMZ à jour et minimaux, et n'autorisez vers l'intérieur que les connexions précises dont ils ont besoin. Sur un segment surveillé, NetSenX détecte mouvement latéral et balayage depuis un hôte de la DMZ vers des hôtes internes, sur toutes les offres.

Souvent oui, au moins en partie. Regardez ce que vous avez déjà : beaucoup de routeurs et pare-feu professionnels gèrent les VLAN et les règles entre eux, beaucoup de commutateurs administrables aussi, et la plupart des systèmes Wi-Fi savent faire tourner un réseau invités séparé avec isolation des clients. Si vos commutateurs ne sont pas administrables, commencez par ce qui n'en a pas besoin : un Wi-Fi invités isolé pour les visiteurs et les appareils personnels, le pare-feu de chaque PC et serveur réglé pour n'autoriser que le nécessaire, le trafic de portable à portable bloqué, et les partages de fichiers limités aux groupes qui les utilisent. Remplacez progressivement les commutateurs non administrables, en commençant là où se trouvent serveurs et sauvegardes. Notez ce que vous avez séparé et pourquoi, pour que la personne suivante ne le défasse pas. Vérifiez ensuite que cela fonctionne avec le trafic réel. NetSenX montre quels hôtes communiquent sur les segments surveillés, sur toutes les offres ; un agent sur un port SPAN ou TAP, qui demande un commutateur capable de recopier le trafic ou un TAP, compte pour un seul appareil pour ce segment.

Traitez-le comme le système le plus précieux que vous ayez, car qui le contrôle contrôle chaque compte. Limitez qui peut s'y connecter : seulement quelques comptes d'administration nominatifs avec une MFA résistante à l'hameçonnage, utilisés depuis un poste d'administration dédié et jamais pour la messagerie ou la navigation. Maintenez-le à jour, n'y faites rien tourner d'autre, bloquez son accès Internet sauf pour ce dont il a besoin, et ne laissez les PC ordinaires l'atteindre que sur les ports nécessaires à l'authentification, pas pour le bureau à distance ni les partages d'administration. Gardez une sauvegarde hors ligne et testée de l'annuaire et un plan de restauration documenté, car reconstruire un annuaire sous pression est difficile. Revoyez régulièrement les membres des groupes d'administrateurs, et surveillez les journaux de sécurité de l'annuaire avec un outil qui les lit. Sur le réseau, NetSenX signale comme mouvement latéral les nouvelles sessions vers le contrôleur de domaine qui ne correspondent pas au comportement normal d'un hôte, comme un PC du marketing qui ouvre une session distante en pleine nuit, sur toutes les offres. Il ne lit pas les journaux de l'annuaire.

Non. Le zero trust consiste à ne pas accorder d'accès sur la seule confiance : chaque appareil et chaque compte prouve son identité, n'obtient que ce dont il a besoin, et son accès est vérifié en continu. Cela concerne des appareils, des comptes et des connexions, pas le travail des personnes, et n'exige de lire le contenu de personne. Cela suppose en revanche de journaliser, par exemple les connexions, l'état des appareils et les connexions réseau ; soyez donc transparent : dites au personnel ce qui est journalisé, pourquoi et pour combien de temps, associez les représentants du personnel s'il y en a, et réalisez une analyse d'impact relative à la protection des données lorsque la loi l'exige. Gardez les données minimales et la finalité limitée à la sécurité. NetSenX est conçu ainsi : il observe des appareils et des connexions, pas des personnes, analyse les métadonnées de connexion pour détecter des attaques, ne déchiffre jamais le trafic et ne note ni ne classe les salariés. Ses alertes nomment des hôtes et des adresses ; quand une alerte demande le contexte d'une personne, cette étape reste dans votre propre processus.