Un rançongiciel qui coupe la ventilation d’un hôpital cesse d’être un problème informatique. Il devient un problème de bâtiment.

L’essentiel

  • Un rançongiciel a perturbé les accès et les systèmes de ventilation d’un hôpital de Winnipeg.
  • L’incident montre l’interdépendance des infrastructures physiques et numériques.
  • Toute organisation dont les systèmes soutiennent un service essentiel est concernée.
  • Identifier son système critique et tester sa restauration coûte du temps, pas du budget.

Que sait-on de l’incident ?

Selon les informations disponibles, un rançongiciel a perturbé les accès aux systèmes informatiques ainsi que les équipements de ventilation du Health Sciences Centre de Winnipeg, un établissement de santé majeur au Canada. Le mode opératoire et les demandes des attaquants n’ont pas été précisés.

Les conséquences exactes sur les opérations cliniques ou la sécurité des patients n’ont pas été divulguées. Nous nous gardons de les supposer : ce qui est établi suffit largement à la leçon.

Ce qui retient l’attention, c’est le périmètre touché. L’atteinte ne s’est pas limitée aux dossiers ou à la messagerie : elle a gagné des équipements qui règlent l’air d’un bâtiment. La frontière entre système d’information et système physique, dans les faits, n’existe plus.

flowchart LR A[Intrusion initiale] --> B[Chiffrement des donnees] B --> C[Perturbation des systemes] C --> D[Impact operationnel: acces et ventilation]

Pourquoi une PME devrait-elle s’y reconnaître ?

Parce que le mécanisme ne dépend ni de la taille ni du secteur. Une organisation dont l’activité repose sur des systèmes informatiques subit le même type d’interruption, avec une différence décisive : elle n’a pas les réserves d’un hôpital public pour absorber plusieurs jours d’arrêt.

L’interdépendance des infrastructures physiques et numériques est le risque le plus sous-estimé que nous rencontrons. Un atelier dont les machines sont pilotées depuis un poste bureautique, un entrepôt dont les portes et la réfrigération sont commandées par un automate raccordé au même réseau que la comptabilité : ce sont des configurations banales, et elles transforment un incident informatique en arrêt de production.

Les rançongiciels ne visent d’ailleurs pas que les grandes institutions. Le Centre canadien pour la cybersécurité le formule sans nuance : toutes les organisations canadiennes sont à risque, quelle que soit leur taille, parce que le ciblage est largement automatisé.

Que faire concrètement dans les prochaines semaines ?

Trois actions, dans cet ordre, et aucune ne demande un budget. Identifier le système dont l’arrêt vous empêcherait d’opérer. Vérifier qu’une sauvegarde de ce système a déjà été restaurée pour de vrai. Séparer ce qui pilote du physique de ce qui sert à la bureautique.

  • Identifier le système critique. Pas le plus visible ni celui dont on parle le plus, mais celui dont l’indisponibilité vous empêcherait de facturer, de produire ou de servir vos clients.
  • Prouver que la sauvegarde fonctionne. Le rapport vert du matin dit que la tâche s’est exécutée, pas qu’un fichier peut en être extrait. Le test de restauration est le contrôle, pas son option.
  • Cloisonner l’exploitation de la bureautique. L’objectif minimal, souvent suffisant comme premier palier : qu’un poste bureautique compromis ne puisse plus atteindre un équipement de production.
  • Écrire les procédures dégradées. Comment continuer une demi-journée sans le système principal : bon de commande papier, liste de contacts imprimée, caisse de secours. Cela paraît désuet jusqu’au jour où cela sauve la journée.

Nous restons à disposition pour évaluer l’exposition de votre organisation et la dépendance réelle de votre exploitation à vos systèmes.

FAQ

Nos équipements techniques sont-ils vraiment atteignables depuis le bureau ?

Dans la majorité des relevés que nous menons, oui, et l’organisation l’ignorait. La cause est rarement une décision : c’est une commodité de câblage, un automate raccordé à la prise la plus proche, un boîtier de télémaintenance livré avec une machine. Aucun de ces éléments ne figure dans la documentation officielle, ce qui les rend d’autant plus dangereux : ils ne sont ni surveillés, ni corrigés, ni inclus dans les périmètres d’audit.

Peut-on sécuriser un automate qu’on ne peut pas mettre à jour ?

Oui, en ne le touchant pas. Un automate dont l’éditeur ne publie plus de correctifs, ou dont la configuration a été validée par le constructeur de la machine, ne doit pas être mis à jour à l’aveugle : cela peut invalider une garantie ou un certificat de conformité. La réponse est l’isolement : réduire au strict minimum ce qui peut lui parler, journaliser ces échanges, et placer les contrôles au niveau du réseau plutôt que sur l’équipement.

Les données de santé changent-elles nos obligations ?

Elles les alourdissent. Des renseignements de santé sont des renseignements personnels sensibles, ce qui relève le niveau de protection attendu et durcit l’évaluation du risque de préjudice sérieux en cas d’incident. Pour une organisation québécoise qui en détient, même en petit volume, cela signifie un chiffrement réel, des accès restreints à ceux qui en ont besoin, et une journalisation des consultations.

Sources