Flat Site-to-Site Trust Extends the Blast Radius

Des sites distincts sont reliés par des tunnels permanents et traités comme un seul réseau de confiance. Les règles autorisent de larges plages, de nombreux protocoles ou un trafic bidirectionnel qui dépasse largement les besoins réels.

À cette connectivité s’ajoutent souvent les mêmes comptes administratifs, les mêmes outils de gestion ou les mêmes secrets locaux. Chaque site possède peut-être son pare-feu, mais la frontière existe surtout sur le diagramme. Une compromission locale obtient alors un chemin réseau et des moyens d’authentification vers les autres sites.

Un poste compromis dans une petite succursale peut devenir le point de départ d’un incident à l’échelle de l’organisation. Les tunnels fournissent la portée; les identifiants communs fournissent le passage.

Le confinement devient brutal. Couper un site peut aussi couper des applications, de la téléphonie, des sauvegardes ou des services centralisés dont personne n’avait documenté la dépendance. Cette peur de l’impact retarde l’isolement et laisse à l’attaquant le temps d’utiliser l’architecture comme réseau de distribution.

Dans un contexte infogéré ou multi-environnement, le même défaut peut propager le risque au-delà d’une seule entité.

• Obtenir la matrice réelle des flux inter-sites, pas seulement un dessin des tunnels.
• Repérer les règles de type « any-any », les grands sous-réseaux autorisés, le trafic initiable dans les deux directions et les exceptions sans propriétaire.
• Vérifier si des comptes, mots de passe locaux, comptes de service ou outils d’administration sont communs à plusieurs sites.
• Tester si un poste utilisateur d’un site peut atteindre les ports d’administration, annuaires, hyperviseurs, sauvegardes ou contrôleurs d’un autre.
• Demander quels flux seraient perdus si un site devait être isolé immédiatement. L’absence de réponse documentée indique que la segmentation n’est probablement pas opérable.

• Limiter les tunnels aux flux explicitement requis, avec source, destination, protocole, justification et propriétaire.
• Séparer les plans utilisateur, serveur, sauvegarde et administration; interdire l’administration inter-sites depuis les réseaux utilisateurs.
• Éliminer les secrets et comptes privilégiés partagés; utiliser des identités distinctes et des mots de passe locaux uniques.
• Journaliser et surveiller les flux latéraux entre sites, particulièrement les protocoles d’administration.
• Préparer et tester un mode d’isolement par site qui conserve, lorsque possible, les services essentiels.

• Cartographier rapidement tous les tunnels et toutes les routes depuis le site initialement touché.
• Réduire ou suspendre les flux inter-sites non essentiels; ne pas attendre la preuve d’un déplacement latéral pour limiter sa possibilité.
• Faire une rotation des secrets communs depuis une infrastructure saine et traiter tout site partageant ces secrets comme exposé.
• Rechercher les authentifications et connexions administratives inter-sites depuis le début probable de la compromission.
• Ne reconnecter les sites que par étapes, avec règles minimales, surveillance renforcée et critères de retour documentés.