Pourquoi le réseau est devenu la dernière ligne de défense pour les technologies opérationnelles (OT), l'Internet des objets (IoT) et les équipements médicaux
Quelque part sur votre réseau, il y a un appareil fonctionnant sous un système d’exploitation dont le support a pris fin avant même que certains de vos collègues aient terminé leurs études. Il peut s’agir d’un échographe, d’un contrôleur de gestion technique du bâtiment, d’un lecteur de badges, d’une IHM de chaîne de production ou d’un analyseur de laboratoire qui a coûté plus cher qu’une voiture de fonction. Vous savez que cela représente un risque. Vous l’avez signalé. Et on vous a répondu, poliment et à plusieurs reprises, qu’il était impossible d’y appliquer un correctif.
Cette réponse est généralement correcte. Le fabricant n’a pas certifié la mise à jour. L’homologation réglementaire porte sur une version logicielle spécifique et sa revalidation pourrait prendre des mois. Le contrat de maintenance devient caduc si vous modifiez l’image. L’appareil fonctionne 24 heures sur 24, 7 jours sur 7, dans un environnement clinique ou de production, où un redémarrage relève davantage d’une opération planifiée que d’un simple clic. Ou bien le fournisseur qui l’a fabriqué n’existe plus.
Le point de départ réaliste pour toute personne chargée aujourd’hui de gérer un réseau d’entreprise est donc le suivant : une part non négligeable des appareils de votre réseau ne bénéficiera jamais de correctifs, n’exécutera jamais d’agent de sécurité sur terminal et ne sera pas remplacée dans le cadre de votre horizon de planification actuel. Chaque mesure de sécurité qui part du principe contraire – couverture EDR, vérifications de l’état de sécurité basées sur des agents, conformité automatisée aux correctifs – présente un angle mort qui touche précisément vos équipements les plus critiques sur le plan opérationnel.
Si le terminal ne peut pas se défendre tout seul, c'est au réseau de le faire à sa place.
Pourquoi la réponse traditionnelle ne fonctionne plus
La solution classique consistait à isoler ces appareils dans un réseau distinct : un VLAN médical, un VLAN dédié aux services techniques du bâtiment, un VLAN pour les caméras. Il suffisait de les isoler du reste du réseau à l'aide d'un pare-feu, et le tour était joué.
Cela fonctionne jusqu'à ce que la mise à l'échelle ne soit plus possible. Trois éléments peuvent entraîner une défaillance :
Le nombre d'appareils. Le classement par catégorie était gérable lorsque l'on comptait quelques centaines d'appareils. Les campus convergents en comptent désormais des milliers, et de nouveaux appareils arrivent sans cesse. Ceux-ci sont souvent installés par un prestataire chargé des installations ou par une équipe d'ingénierie clinique qui, tout à fait naturellement, n'a pas transmis de demande de modification à l'équipe réseau.
Le problème des listes de contrôle d'accès (ACL) statiques. Chaque exception – le tunnel de support du partenaire de service, le serveur de surveillance qui doit accéder à tous les sous-réseaux, la nouvelle intégration avec le système de dossiers médicaux – se traduit par une nouvelle règle. Au bout de quelques années, plus personne n'ose supprimer quoi que ce soit, si bien que la base de règles ne cesse de s'étoffer. La segmentation n'existe que sur le papier, tandis que la politique effective est discrètement devenue « autoriser la plupart du temps ».
L'emplacement physique ne correspond plus à la politique. Un VLAN est lié à l'endroit où un appareil se connecte. Les appareils se déplacent d'un service à l'autre, d'un étage à l'autre et d'un bâtiment à l'autre. Les appareils sans fil se déplacent constamment. Une politique liée à un port de commutateur ou à un SSID perd toute sa pertinence dès que la configuration physique change, et la solution consiste toujours à élargir le VLAN.
Le résultat est bien connu : un réseau segmenté sur le papier, mais plat dans la pratique. Et cette structure plate correspond exactement à ce dont les ransomwares ont besoin.
Le point d'entrée initial est rarement un appareil sur lequel il est impossible d'installer de correctifs ; il s'agit généralement d'un compte utilisateur piraté par hameçonnage. C'est l'appareil sur lequel il est impossible d'installer de correctifs qui fait la différence entre un incident touchant un seul service et un incident touchant l'ensemble de l'hôpital.
Trois compétences qui changent réellement la donne
Sachez en permanence ce qui se trouve sur votre réseau. Il ne s'agit pas d'un simple tableau Excel d'inventaire annuel. Utilisez le profilage passif pour identifier les appareils en fonction de leur comportement sur le réseau (empreintes DHCP, utilisation des protocoles, schémas de trafic et attribution des adresses MAC) et signalez tout élément inattendu.
Dans presque tous les exercices de recensement, le nombre d'appareils connectés dépasse celui enregistré dans la CMDB. C'est dans cet écart que réside le risque.
L'ampleur de ce fossé est systématiquement sous-estimée. Dans une étude de cas publiée par runZero, l'université de York, un campus comptant 54 000 étudiants, a pu recenser 25 000 actifs, soit environ deux fois et demie plus que ce qu'elle avait pu identifier auparavant. L'explication fournie par le RSSI mérite d'être prise en compte : ses outils de gestion de réseau étaient efficaces pour gérer le réseau, mais pas pour détecter les appareils qui y étaient connectés.
Il s'agit là de deux capacités distinctes, et la plupart des organisations ne disposent que de la première.
Déterminez avec quels appareils chaque périphérique est autorisé à communiquer. Une pompe à perfusion doit pouvoir communiquer avec trois serveurs. Une caméra doit pouvoir communiquer avec l'enregistreur vidéo en réseau. Un contrôleur de porte doit pouvoir communiquer avec son serveur de contrôle d'accès. Aucun d'entre eux n'a besoin d'Internet, du serveur de fichiers ni d'aucun autre périphérique.
Commencez par établir une base de référence du trafic réel, puis rédigez la politique en vous basant sur ce que vous observez plutôt que sur ce qu'indique la documentation du fournisseur. L'architecture de référence est presque toujours plus permissive que ne l'exige réellement l'environnement.
Appliquez la politique au point de connexion. C'est ce qui permet au modèle de fonctionner. La politique doit être liée à l'identité de l'appareil et appliquée au niveau de la couche d'accès – c'est-à-dire au niveau du port ou du point d'accès auquel il se connecte – plutôt qu'au niveau d'un pare-feu situé à trois sauts de là.
Lorsque la mise en application suit le périphérique, le fait de le déplacer d'un bâtiment à l'autre ne change rien. Les déplacements latéraux entre deux périphériques connectés au même commutateur sont bloqués, et non pas simplement ignorés.
Comment y parvenir sans mettre l'entreprise à l'arrêt
La raison pour laquelle ces projets sont au point mort, c'est la peur, et cette peur est légitime : personne ne veut être celui ou celle dont la politique de segmentation a interrompu une procédure. Le séquençage résout en grande partie ce problème.
- Commencez par effectuer une analyse passive avant de mettre en place la moindre mesure. Il s'agit de semaines, pas de jours. Aucun changement n'est apporté au réseau pendant cette phase ; il n'y a donc aucun risque à prendre.
- Simulez la politique en mode « monitor ». Appliquez les règles prévues et consignez dans un journal les éléments qui auraient été bloqués. Cela permet de transformer un débat sur les risques en une analyse de rapport et met généralement en évidence deux ou trois flux légitimes que personne n'avait répertoriés.
- Commencez par un groupe d'appareils présentant un risque élevé et une portée latérale faible. Les caméras et les équipements techniques du bâtiment constituent des premiers candidats idéaux : le gain en matière de sécurité est réel et les enjeux opérationnels sont moindres que pour les équipements cliniques ou de production.
- Impliquez les responsables du matériel dès le début : le service d’ingénierie clinique, le service des installations, le service d’ingénierie des salles d’opération. Ils savent des choses que le réseau ne peut pas vous révéler, comme le fait que l’analyseur envoie ses données au fabricant pendant la nuit, ou qu’un fournisseur se connecte tous les trimestres pour effectuer un étalonnage. Ils disposent également d’un droit de veto informel : dès qu’une politique est mise en cause pour un problème opérationnel, elle est suspendue, et une fois suspendue, elle est rarement rétablie. Une politique que vous imposez sans eux ne tiendra que jusqu’au premier incident. Celle que vous convenez avec eux y survivra.
- Déployer par groupe, avec une procédure de restauration pour chaque groupe. Chaque étape doit pouvoir être annulée indépendamment.
Il vaut mieux se mettre d'accord sur des indicateurs dès le départ, car l'argument « on est plus en sécurité » ne tient pas la route lors des discussions budgétaires. Voici quelques indicateurs utiles : le temps nécessaire pour identifier un appareil inconnu sur le réseau, le pourcentage de ports d'accès soumis à une politique dynamique, et le nombre de destinations qu'un appareil compromis dans chaque groupe pourrait atteindre – c'est-à-dire son « rayon d'action » ; et le fait de voir ce nombre diminuer est la preuve la plus évidente que le programme fonctionne.
L'aspect de la conformité, en bref
Si vous exercez vos activités en tant qu’entité essentielle ou importante au sens de la directive NIS 2, il est difficile de respecter efficacement les exigences en matière de gestion des actifs, de contrôle d’accès et de détection des incidents sans disposer de cette fonctionnalité. Vous ne pouvez pas signaler un incident dans les délais impartis s’il faut plusieurs jours pour déterminer de quel appareil il s’agit, à quel réseau il est connecté et avec quels systèmes il a communiqué.
La norme ISO/IEC 27001 et les recommandations techniques de l’ENISA soulignent l’importance de ces capacités, tandis que les cadres nationaux mettant en œuvre la directive NIS2 dans les États membres les traduisent en exigences locales. Pour de nombreuses organisations, cela signifie que les travaux de segmentation des réseaux qu’elles avaient reportés pour des raisons de sécurité deviennent désormais également une priorité en matière de conformité. D’un point de vue pragmatique, c’est souvent ce qui permet finalement de débloquer le budget.
Le rôle de Damovo
Nous concevons et exploitons des réseaux de campus où ce modèle est la norme et non une solution de rattrapage : le profilage des appareils et l’application des politiques sont intégrés à la couche d’accès à l’aide des plateformes que nos clients utilisent déjà, notamment Cisco Identity Services Engine, la structure d’Extreme Networks et la politique Universal ZTNA, avec runZero pour la découverte des actifs sans agent dans les environnements IT, OT et IoT. Nous menons les phases de découverte et de surveillance dans le cadre d’une mission structurée afin que vous puissiez visualiser votre inventaire réel de périphériques et votre niveau de trafic de référence avant de vous engager dans l’application des politiques ; nous pouvons également gérer le cycle de vie des politiques sous forme de service géré lorsque votre équipe interne ne dispose pas des capacités nécessaires pour s’en charger.
Si vous souhaitez savoir combien d'appareils sont réellement connectés à votre réseau, c'est par là qu'il faut commencer.