Débranchez Internet
(computer.rip)- Après de grands incidents de sécurité comme celui de CrowdStrike, on entend souvent : « il n’aurait pas fallu connecter ces systèmes à Internet ». Mais, pour beaucoup de systèmes métiers, l’échange d’informations est une fonction essentielle, et un simple blocage ne résout pas le problème
- Les systèmes qui franchissent les frontières organisationnelles et géographiques, comme les systèmes de réservation et de planification aériennes, relèvent davantage d’une infrastructure de communication ayant remplacé le téléphone et le télégraphe ; supprimer le réseau, c’est aussi supprimer leur valeur intrinsèque
- « Non connecté à Internet » peut recouvrir un appareil isolé, un air gap strict, une diode de données, un WAN privé, un tunnel VPN, un routage limité, ou encore un AWS private VPC : le modèle de menace varie donc fortement
- Dans les environnements hors ligne ou à connectivité limitée, les mises à jour d’OS, les gestionnaires de paquets, les dépôts internes, les magasins de confiance TLS, les licences cloud, les mises à jour de contenu et le traitement des images Docker font tous grimper les délais et les coûts
- Il est possible d’appliquer des politiques réseau restrictives à davantage de systèmes et de concevoir des logiciels en pensant à l’exploitation hors ligne, mais l’écosystème logiciel actuel continue de prendre la connexion Internet comme valeur par défaut
Les limites de « ne le connectez pas à Internet »
- Chaque fois qu’un grand incident de sécurité fait l’actualité, la réaction « ce genre de système ne devrait pas être connecté à Internet » revient
- Ce jugement a un attrait intuitif du point de vue de la sécurité et de la résilience, mais peu d’environnements fonctionnent réellement ainsi
- Le problème central est que la simple formule « ne pas être connecté à Internet » ne suffit pas à préciser la conception réelle, les coûts d’exploitation ni le modèle de menace
Les systèmes métiers modernes ressemblent à des dispositifs de communication
- De façon abstraite, un ordinateur peut créer de la valeur par le calcul, mais dans les environnements industriels, les systèmes relèvent davantage des technologies de l’information que du calcul
- Les technologies de l’information doivent recevoir et produire de l’information ; l’ancien modèle où un opérateur insérait une bande est plus coûteux et plus lent que les communications en temps réel
- La plupart des ordinateurs professionnels modernes fonctionnent comme des dispositifs de communication
- Peu de systèmes créent de la valeur sans être connectés à d’autres systèmes métiers
- Ces connexions franchissent souvent les frontières organisationnelles et géographiques
- Les systèmes de réservation et de planification aériennes sont issus de systèmes qui remplaçaient le téléphone et le télégraphe ; le réseau fait partie intégrante de leur fonction
La maintenance et l’exploitation ont aussi besoin du réseau
- Même lorsque les communications en temps réel ne sont pas indispensables à l’objectif métier, la connectivité réseau apporte une grande valeur opérationnelle
- Sans connexion Internet, on se heurte immédiatement à des questions comme : comment récupérer les mises à jour logicielles, et comment superviser le système ?
- Même si l’on décide qu’un système est « terminé » et n’a pas besoin de mises à jour ni de supervision en temps réel, les exigences métier évoluent avec le temps
- La connectivité réseau réduit fortement le coût de traitement de ces changements
« Non connecté à Internet » recouvre plusieurs niveaux
- L’état « non connecté à Internet » n’a pas un sens unique : c’est un ensemble de modes de mise en œuvre
- Les formes possibles vont de l’isolement total à la connectivité limitée
- Un appareil unique sans aucune connexion réseau
- Un air gap strict, sans connexion au-delà d’un LAN privé et sans passage de données à travers la frontière de sécurité
- Un air gap où des données sont importées dans la frontière de sécurité via des DVD-R
- Une architecture où une cross-domain solution ou une data diode déplace les données d’un réseau de faible sécurité vers un réseau de haute sécurité
- Une architecture utilisant une cross-domain solution non certifiée par la NSA
- Les réseaux étendus privés se déclinent eux aussi en plusieurs niveaux
- Un WAN privé reposant sur une infrastructure physique totalement indépendante et des mesures anti-altération
- Des formes utilisant des fourreaux partagés, de la leased dark fiber ou une longueur d’onde sur fibre éclairée
- Un virtual private ethernet basé sur MPLS
- Un virtual private ethernet fondé sur des tunnels avec chiffrement et authentification
- Le trafic privé sur des réseaux de communication publics est parfois lui aussi qualifié de « non connecté »
- Une forme où des équipements matériels établissent des tunnels chiffrés et authentifiés sur un common-carrier network comme Internet
- Une forme utilisant des équipements non certifiés par la NSA
- Un tunnel logiciel vérifié, configurant la pile réseau du système d’exploitation à bas niveau pour empêcher le contournement du tunnel
- Un tunnel logiciel avec un niveau de vérification plus faible
- Une combinaison de WireGuard et de scripts iptables
- La connectivité Internet limitée est aussi regroupée sous la même expression
- Un réseau privé n’autorisant qu’un flux de trafic extrêmement restreint via du routage fondé sur des politiques, etc.
- Une architecture où les flux autorisés restent consignés dans de vieux tickets Jira, certains ayant été ajoutés « pour que ça marche »
- Une architecture basée sur un pare-feu, relativement permissive en sortie et stricte en entrée
- Dans le cloud aussi, le périmètre varie
- Un AWS private VPC sans routage externe
- Un VPC communiquant avec d’autres private VPC via PrivateLink, etc.
- Une architecture où certains VPC connectés ont un routage vers Internet
- Une architecture avec NAT Gateway et Internet Gateway, mais des security groups configurés strictement dans les deux sens
- Toutes ces formes ont déjà été qualifiées de « non connectées à Internet », mais leur surface d’attaque et leurs risques diffèrent
- Quand on dit qu’un système de réservation aérienne « ne doit pas être connecté à Internet », si l’on ne parle pas d’un état totalement sans réseau, on vise en réalité l’un de ces niveaux intermédiaires, chacun avec ses propres considérations pratiques
Les environnements hors ligne augmentent fortement coûts et délais
- Exploiter un logiciel sans connexion Internet, ou sur un réseau fortement limité, augmente fortement les estimations de planning et de coût
- Pour une forme faible comme un AWS private VPC, on peut compter environ 3 à 5 fois plus
- Pour une forme forte, proche de l’isolement total, le facteur peut aller de 10 fois à bien davantage
- La quasi-totalité de l’écosystème logiciel est conçue en supposant une connexion Internet
- Les systèmes d’exploitation cherchent à récupérer leurs mises à jour depuis des serveurs en ligne
- Les éditeurs d’OS payants peuvent proposer une infrastructure de mise à jour interne au réseau privé, sous licence payante séparée
- Pour les OS gratuits, on peut gérer soi-même, mais les technologies récentes peuvent entraîner de grosses complications
- Dans le développement et le déploiement, les problèmes liés aux différents gestionnaires de paquets et dépôts internes se répètent
- Le niveau de prise en charge des dépôts internes privés varie selon les gestionnaires de paquets
- La combinaison de plusieurs gestionnaires de paquets, modes d’appel et environnements d’exécution augmente la complexité
- Les certificats TLS des services internes créent eux aussi des tâches récurrentes
- Les services situés dans un réseau privé n’utilisent souvent pas de certificats issus du programme racine d’une CA publique
- Certains composants, comme la JRE, ont leur propre trust store, et dans certaines stacks, le comportement varie selon les bibliothèques
- Même s’il existe un trust store du système d’exploitation, si chaque outil utilise son propre magasin, des ajustements séparés sont nécessaires
- La vérification des licences cloud et des droits d’usage constitue aussi un obstacle
- Certains logiciels tentent de se connecter à l’extérieur pour vérifier une licence cloud
- Les contournements vont de l’ajout massif d’exceptions de pare-feu à l’émission de systèmes de licence personnalisés, et peuvent prendre du temps
- Les mises à jour de contenu hors ligne peuvent devenir complexes du seul fait des processus du fournisseur
- Dans un cas de logiciel d’entreprise, il fallait passer par un ancien portail de support client et un portail d’entitlements séparé
- L’ouverture de compte et les escalades ont pris plus de trois mois, et le portail final présentait un certificat TLS invalide
- La procédure documentée d’application des mises à jour ne fonctionnait plus, ce qui a nécessité de longs échanges d’e-mails avec les ingénieurs
- Malgré une licence annuelle à cinq chiffres, celle-ci était presque expirée au moment où l’environnement était prêt à l’emploi, et le retard d’émission de la licence prolongée a provoqué l’arrêt du pipeline CI
- La difficulté de l’exploitation hors ligne ne vient pas d’une tâche isolée qui serait impossible, mais plutôt d’une forme de death by a thousand cuts, où chaque tâche devient un peu plus difficile
- Les produits qui n’ont pas été conçus pour les environnements hors ligne répondent souvent par des scripts ad hoc et des rustines, et cette dette technique est transférée au client qui exploite l’environnement hors ligne
- Red Hat répond relativement bien à ce domaine, mais le temps économisé se paie en cash
Ces environnements sont rares et concentrés dans certaines industries
- Les formes fortes d’environnements non connectés à Internet se rencontrent surtout dans la défense et les agences de renseignement
- Certaines banques ont aussi des pratiques strictes de séparation réseau
- La défense, le renseignement et les banques sont aussi connus comme des secteurs coûteux et lents, ce qui n’est pas sans lien avec ce mode d’exploitation
- Les formes faibles de connectivité limitée sont surtout présentes dans les secteurs fortement réglementés comme la finance et la santé
- Il existe aussi, à l’occasion, des éditeurs de logiciels ordinaires qui accordent une très grande importance à la sécurité et verrouillent fortement leur réseau
Réponses pratiques possibles dès maintenant
- L’idée d’avoir moins de systèmes connectés à Internet n’est pas mauvaise en soi
- Mais l’industrie logicielle actuelle n’est pas prête à permettre une exploitation confortable dans des environnements sans Internet ou à connectivité limitée
- La réponse réaliste consiste moins à réclamer l’isolement total qu’à accroître la connectivité limitée et la capacité à fonctionner hors ligne
-
Restreindre autant que possible les politiques réseau
- Il faut appliquer des politiques réseau restrictives au plus grand nombre possible de systèmes
- Les fournisseurs cloud rendent ce type de configuration plus simple qu’auparavant
- Sur AWS, exploiter un environnement de routage pratique sans Internet n’est pas très facile, mais ce n’est pas non plus impossible
- Tant que l’on reste dans le périmètre des AWS managed services, la douleur est généralement limitée, mais il y a un coût
-
Concevoir les logiciels en pensant aux environnements hors ligne
- Les fonctionnalités qui doivent se connecter à l’extérieur devraient pouvoir être désactivées lorsque c’est possible
- Si la désactivation est difficile, le client devrait pouvoir modifier l’endpoint utilisé
- Si l’on permet de changer l’endpoint, il faut aussi fournir un moyen pour que le client exploite son propre endpoint
- S’il s’agit de simples fichiers statiques, cela peut être fourni assez facilement avec nginx et un répertoire
- S’il s’agit d’une API, il peut être nécessaire de distribuer l’implémentation interne au client, ce qui crée une charge de maintenance
-
Réduire les hypothèses sur TLS et les dépendances
- Dans les environnements hors ligne, de petites hypothèses concernant la connexion à d’autres services deviennent complexes
- Il ne faut pas supposer que l’on peut accéder à Let’s Encrypt
- Les environnements hors ligne impliquent presque toujours une autorité de certification interne
- Il faut utiliser le system trust store
- Il ne faut pas récupérer les exigences ou dépendances au moment du déploiement
- Docker avait l’avantage de promettre des paquets autonomes, mais certains conteneurs ne démarrent pas s’ils ne peuvent pas accéder à un dépôt npm, etc.
- Comme il faut parfois modifier le TLS trust store de chaque conteneur Docker, Docker peut au contraire compliquer l’administration en environnement hors ligne
Le lien entre l’incident CrowdStrike et la connexion Internet
- À propos de l’incident CrowdStrike, plusieurs réactions ont demandé « pourquoi était-ce connecté à Internet ? », mais la question de la connexion Internet était presque orthogonale au problème survenu
- Les mises à jour de contenu CrowdStrike sont le type de mises à jour qui, dans un environnement idéal, devraient aussi être fournies rapidement aux environnements hors ligne
- Dans les vrais environnements fortement hors ligne, les miroirs internes de mises à jour CrowdStrike peuvent avoir des jours, des semaines, des mois, voire des années de retard
- Un tel retard peut permettre d’éviter le problème, mais cela ressemble surtout à une coïncidence heureuse résultant de deux erreurs qui se compensent
1 commentaires
Avis sur Hacker News
Je travaille dans la sécurité/les systèmes/l’exploitation, mais je ne suis fondamentalement pas d’accord avec ce postulat. Je comprends que l’auteur dise que « ce n’est pas si simple », et je suis tout à fait d’accord, mais cela ne veut pas dire pour autant que le travail est bien fait.
Malheureusement, la plupart des gens ne font pas du bon travail, et tout le secteur est conçu pour permettre de survivre même en travaillant mal, tout en rendant difficile le fait de bien travailler.
Si vous déployez de l’affichage numérique, l’accès réseau devrait être autorisé via liste blanche uniquement vers les adresses IP de mes serveurs, et seules les connexions établies avec des mises à jour signées et de l’épinglage de certificats (certificate pinning) devraient être acceptées.
Avec cela, il devient presque impossible pour un attaquant distant d’y toucher. Quand on regarde l’industrie de la sécurité qui a grossi avec l’essor de l’Internet des objets (IoT), il existe clairement des panneaux d’affichage ou d’autres équipements IoT/SCADA/de déploiement qui conservent des ports ouverts et des mots de passe par défaut.
L’IoT, ce ne sont que des ordinateurs, mais ce sont aussi des ordinateurs encore plus négligés que les serveurs ou machines virtuelles que l’on n’arrive déjà pas à exploiter correctement.
Il y a des acteurs qui font bien les choses, mais ils sont très rares, parce que la structure d’incitation ne récompense pas le fait de bien faire. Suivre les « bonnes pratiques » ou les consignes d’un fournisseur ne veut pas dire que l’on fait bien les choses ; cela signifie souvent seulement que l’on en a fait assez pour que le fournisseur assure le support, et dans beaucoup de cas cela implique un accès réseau sans restriction.
Il faut toujours se préoccuper des bugs réseau, des failles cryptographiques, des erreurs de configuration et d’autres problèmes pouvant permettre à un attaquant distant d’exploiter le système. Pour soutenir cet argument, il faudrait donner un exemple littéralement non connecté à Internet, pas simplement un cas mieux verrouillé.
Je ne vois pas bien où tu diverges de l’auteur du billet. Ou bien veux-tu dire qu’il est fondamentalement impossible d’améliorer la sécurité des systèmes connectés à Internet parce que les gens n’en ont pas les compétences ?
En Suède, il existe un réseau privé séparé d’Internet, Sjunet, utilisé par les prestataires de santé. L’objectif est de faire des ordinateurs des outils de communication utiles, sans exposer l’IT des hôpitaux à l’ensemble d’Internet.
On attend des membres de Sjunet qu’ils connaissent leur propre réseau et qu’ils contrôlent strictement leur informatique.
Sjunet peut être vu comme un environnement air gap à l’échelle d’un secteur. Il améliore la sécurité tout en coûtant, selon moi, moins cher que si chaque organisation exploitait son propre réseau air gap avec une énorme liste blanche.
Cela donne un faux sentiment de sécurité et sert aussi d’excuse à de mauvaises politiques de sécurité. La bande passante est faible et coûteuse.
C’est un réseau qui relie des administrations comme les bureaux de comté ou les mairies, et leur permet d’accéder à une base de données centrale contenant les données personnelles des citoyens. Il est utilisé pour des opérations comme un changement d’adresse, l’émission d’une nouvelle carte d’identité, ou l’enregistrement des naissances et des mariages.
À ma connaissance, l’application « Źródło » tourne sur un ordinateur séparé, « air gap », qui n’a pas accès à Internet mais accède au réseau interne, et s’authentifie au moyen d’un certificat client cryptographique via carte à puce.
Sont-ils tous à jour avec les derniers correctifs ? Sait-on que les gens ne branchent pas n’importe quel périphérique USB ?
Quelque chose qui ressemble à Tor, mais sans les trucs louches.
En tant qu’ingénieur en contrôle-commande, j’ai construit des centaines de machines. Il y a des câbles Ethernet pour les réseaux de bus de terrain, mais ils ne doivent absolument jamais être connectés à Internet.
Dans chaque atelier d’outillage et de moulage de la zone industrielle du coin, on trouve des machines CNC avec des ports Ethernet qu’il ne faut pas exposer à Internet. Toute usine de production avec des équipements sur mesure, des lignes de convoyeurs, des presses, des robots, des CNC, des stations de pompage, etc. utilise de l’Ethernet, mais aussi des systèmes PLC et HMI qui ne sont pas adaptés à une exposition sur Internet.
L’article dit que les ordinateurs de travail modernes sont presque surtout des appareils de communication, et qu’il existe peu de systèmes opérationnels créant de la valeur sans être connectés à d’autres systèmes métier, mais il ignore toute l’industrie manufacturière et les appareils électroniques qu’elle fabrique.
Des millions de systèmes embarqués et de PLC vérifient toutes les millisecondes si l’état des entrées numériques physiques et logiques a changé et, si c’est le cas, modifient l’état des sorties numériques physiques et logiques, créant de la valeur toute la journée.
Il n’est pas nécessaire d’installer un système de sécurité version 2024 dans une soudeuse par résistance dont les pièces de fonderie datent d’il y a plus de 100 ans, et dont la dernière mise à jour, en 2003, a consisté à ajouter un PLC et un écran noir et blanc pour régler les recettes. Il suffit d’y aller avec un presse-papiers, de saisir les valeurs cibles et de faire fondre l’acier correctement.
En général, pour se connecter à ce genre de machine, il faut prendre un ordinateur portable, un câble Ethernet de brassage, et marcher jusqu’à la machine. Si le client a besoin de davantage, on s’attend à ce qu’il la place sur un réseau OT (technologies opérationnelles) protégé par un pare-feu, ou qu’il relie l’IT et l’OT avec un équipement SCADA/VPN comme Tosibox ou Ixon.
Ce sur quoi vous travaillez n’est peut-être pas quelque chose que quelqu’un voudrait exploiter, mais les PLC sont souvent présents dans les infrastructures critiques et les sites de fabrication avancée, ce qui en fait des cibles attrayantes pour des acteurs malveillants. Ils peuvent chercher à exploiter des infrastructures critiques, ou à infecter un appareil peu sécurisé auquel un terminal de grande valeur, comme un ordinateur portable d’ingénierie, pourrait un jour se connecter directement.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
Je ne suis toujours pas convaincu par l’argument selon lequel il ne faudrait pas isoler les systèmes du réseau parce qu’on ne pourrait plus utiliser des pratiques de développement centrées sur Internet. Je trouve cet argument absurde.
Si un système est tel qu’il faut boucher ses ports Ethernet à l’époxy, alors il n’aurait jamais dû être programmé avec des pratiques de développement centrées sur Internet. Une machine IRM qui récupère ses dépendances JS depuis NPM au démarrage ? Prison immédiate. Et ce n’est pas une métaphore.
Après avoir vu une vidéo de quelqu’un manipuler une borne McDonald’s, j’ai commencé à essayer de faire la même chose avec les équipements que je voyais à différents endroits.
Dans une aire de restauration, il y avait une borne sous Windows avec un accès complet à Internet. Quelqu’un aurait pu télécharger un malware et voler des données de cartes bancaires. À chaque fois que je l’utilisais, je l’éteignais ou je laissais un message à l’écran, et ils ont fini par la remettre en mode kiosque.
Une autre était une borne de parking, qui n’était absolument pas renforcée. Les criminels ne s’en sont apparemment pas encore rendu compte.
La troisième était un affichage interactif d’une marque de bière. Ce n’était pas un objet capable de causer de gros dégâts, mais c’était agréable d’ouvrir le Bloc-notes et d’y laisser « Drink water ». Ils ont fini par l’éteindre, ce qui est aussi une solution.
« Ne pas donner d’argent à des passants au hasard » devrait figurer assez haut dans la liste des exigences, mais dans la réalité, ce n’était pas le cas.
Je comprends vraiment cette partie. J’essayais de faire comprendre au magasin de confiance JRE d’IntelliJ qu’il devait utiliser le nouveau certificat pour zscaler ; il y avait deux ou trois JDK possibles, j’ai ajouté le nouveau certificat dans chacun de leurs magasins de confiance, et pourtant ça ne fonctionnait toujours pas, sans que je sache pourquoi.
Il y a aussi hamnet. Sur le bloc d’IP 44Net, certaines routes peuvent être routées sur Internet et d’autres non.
https://hamnetdb.net/map.cgi
Comme cela utilise les bandes de fréquences de la radioamateur, il y a des contraintes intéressantes. Tout usage commercial est strictement interdit.
C’est le contrat social associé à ces bandes de fréquences : on peut accéder à bas coût à de nombreuses bandes, de 136 kHz à 241 GHz, mais on ne peut pas gagner d’argent avec.
Ce n’est assez répandu qu’aux Pays-Bas et en Allemagne : https://hamnetdb.net/map.cgi . Ici en Espagne, je ne peux l’utiliser nulle part près de chez moi.
Il semble assez évident que les systèmes de réservation des compagnies aériennes doivent au moins être connectés à un réseau, et j’ai rarement entendu quelqu’un affirmer qu’ils devraient être entièrement hors ligne. Mais j’ai aussi entendu parler, par exemple, de tours d’atelier qui se seraient arrêtés à cause de cet incident.
Il faut se demander s’ils devaient vraiment être en ligne. Il y a bien sûr des raisons, mais ces raisons doivent être mises en balance avec les risques.
Il existe beaucoup d’autres exemples encore plus absurdes d’objets connectés à Internet : réfrigérateurs, bouilloires, portes de garage. Je ne sais pas si ceux-ci ont été touchés par l’incident CrowdStrike, mais même si ce n’était pas le cas, ce n’est qu’une question de temps pour la prochaine fois.
Quant à l’affirmation selon laquelle les systèmes non connectés sont « très, très pénibles », mon expérience d’utilisateur est que toute sécurité est « très, très pénible ». Authentification à deux facteurs, changements de mot de passe obligatoires, appareils verrouillés, scanners de malware, nettoyeurs de liens : certains sont nécessaires, d’autres sont du bullshit, mais je ne suis pas qualifié pour distinguer lesquels, et il est certain qu’ils créent tous de la friction.
La grande conclusion que j’en tire n’est pas que « tous ces systèmes ne devraient pas être connectés à Internet », mais plutôt plusieurs autres points
Premièrement, ce type de système ne devrait pas autoriser les flux réseau sortants. Cela bloquerait toutes les mises à jour automatiques, qui pourraient ensuite être gérées via des canaux de déploiement internes
Deuxièmement, même sans aller jusque-là, beaucoup de logiciels d’entreprise permettent de désactiver les mises à jour automatiques. Windows en est l’exemple le plus représentatif, et c’est aussi le cas de CrowdStrike lui-même. J’ai entendu dire que, parmi les clients de CS, certains avaient désactivé les mises à jour automatiques et procédé à des déploiements manuels, ce qui leur avait permis d’éviter les dommages
Troisièmement, en complément du point 2, il faut déployer progressivement les mises à jour après les avoir soumises à quelques smoke tests. Juste au cas où. Là encore, j’ai entendu dire que certains clients de CS avaient procédé à un déploiement progressif, ce qui avait limité l’impact à une partie seulement de leur parc
C’est un article qui résume assez bien l’époque où je livrais des solutions d’IA de pointe à des clients militaires. 80 % des efforts consistaient à faire fonctionner sans accroc, dans des environnements air-gapped, des outils conçus avec Internet comme prérequis