BACnet/SC pour les nuls

Par Dan Napar, Président BACnet France

Un rappel technique nécessaire

À mesure que les échéances réglementaires se rapprochent – NIS2, le CRA, le guide ANSSI GTB/GTC – le sigle BACnet/SC revient dans toutes les conversations sans que sa mécanique interne soit toujours bien comprise. Avant d’aller plus loin dans nos analyses réglementaires, il paraît utile de revenir aux fondamentaux : que fait réellement BACnet/SC, et en quoi diffère-t-il de BACnet/IP classique ?

Le problème que BACnet/SC vient résoudre

BACnet, normalisé en 1995, a été conçu pour un objectif précis : garantir l’interopérabilité entre équipements de fabricants différents sur un même réseau de gestion technique du bâtiment. Sa version la plus répandue aujourd’hui, BACnet/IP, s’appuie sur le protocole UDP et diffuse ses messages sur un réseau IP classique, souvent partagé avec d’autres usages informatiques du bâtiment.

Cette conception n’a jamais intégré de mécanisme de sécurité natif. Les trames BACnet/IP circulent en clair : n’importe quel équipement présent sur le même segment réseau peut les lire, et rien n’empêche un émetteur de se faire passer pour un autre – il n’existe aucune authentification des équipements qui communiquent entre eux. Tant que les réseaux de GTB restaient physiquement isolés du reste du système d’information, cette absence de sécurité native restait un risque théorique. La convergence avec les réseaux IT et l’exposition croissante des installations à la supervision distante ont changé la donne : cette faiblesse protocolaire est devenue une vulnérabilité concrète et documentée.

Ce que change BACnet/SC : une nouvelle couche de transport

BACnet Secure Connect (BACnet/SC), défini par l’Addendum 135-2016bj à la norme BACnet, ne se contente pas d’ajouter un chiffrement en périphérie d’un protocole inchangé. Il remplace la couche de transport elle-même : au lieu de diffuser des trames UDP en clair, BACnet/SC établit des connexions WebSocket sur TLS entre les équipements. Concrètement, chaque échange devient une session point à point, chiffrée et authentifiée, alors que BACnet/IP diffusait ses messages en clair sur un segment réseau partagé.

Ce changement de transport apporte trois garanties que BACnet/IP classique n’offre pas :

• La confidentialité – les échanges sont chiffrés par TLS, ce qui empêche un tiers présent sur le réseau de lire le contenu des trames.
• L’authentification mutuelle – chaque équipement doit prouver son identité avant de pouvoir communiquer, grâce à un certificat numérique.
• L’intégrité des messages – un message modifié en transit est détecté et rejeté, ce qui empêche la falsification de commandes envoyées à un automate.

L’architecture : un modèle hub-and-spoke piloté par certificats

BACnet/SC repose sur une topologie hub-and-spoke : un hub central assure le routage des messages entre l’ensemble des nœuds du réseau, avec la possibilité de déployer un hub de secours pour la redondance sur les installations critiques. Des connexions directes entre deux nœuds, sans passer par le hub, restent possibles en option pour certains échanges nécessitant une latence minimale.

Ce qui rend cette architecture sûre, c’est le mécanisme d’authentification qui la sous-tend : chaque équipement du réseau – qu’il s’agisse d’un simple contrôleur de terrain ou du hub lui-même – doit disposer d’un certificat numérique (norme X.509) signé par une autorité de certification reconnue par l’ensemble du réseau. Lorsqu’un équipement tente d’établir une connexion, il présente son certificat ; le récepteur vérifie qu’il a bien été signé par l’autorité de confiance attendue avant d’accepter l’échange. Un équipement qui ne dispose pas d’un certificat valide ne peut, par construction, rejoindre le réseau – ce qui élimine le risque qu’un appareil non autorisé, branché sur le réseau physique, puisse se faire passer pour un automate légitime.

Une conséquence organisationnelle à ne pas sous-estimer

Cette architecture de confiance a une implication concrète pour ceux qui l’exploitent : gérer un réseau BACnet/SC, c’est gérer un cycle de vie de certificats – leur émission initiale, leur renouvellement avant expiration, et leur révocation rapide si un équipement est suspecté compromis ou remplacé sans procédure propre. C’est une compétence que le monde BACnet/IP traditionnel n’exigeait pas, et qui rapproche la gestion d’un réseau de GTB des pratiques classiques d’une direction des systèmes d’information.

Pourquoi ce protocole compte aujourd’hui plus qu’hier

BACnet/SC n’est plus un simple raffinement technique optionnel. Il répond directement aux objectifs que portent les textes réglementaires : authentification des équipements et chiffrement des communications figurent parmi les mesures attendues par le référentiel ReCyF de l’ANSSI pour la mise en conformité NIS2, et les recommandations du guide ANSSI GTB/GTC sur l’isolation des flux d’administration trouvent, avec BACnet/SC, une réponse native et par conception là où elles imposaient jusqu’ici un tunnel VPN ajouté en périphérie d’un protocole resté vulnérable. La compatibilité ascendante continue avec BACnet/SC, et donc l’investissement déjà fait pour BACnet sera préservé pour l’utilisateur.

Comprendre ce que fait réellement BACnet/SC – et pas seulement retenir qu’il s’agit de « la version sécurisée de BACnet » – est la condition pour engager une migration cohérente : un chiffrement mal compris se traduit vite par une architecture de certificats bâclée, qui finit par coûter plus cher en exploitation que la vulnérabilité qu’elle était censée corriger.