Cahier des charges IoT pour un bâtiment : transformer NIST SP 800‑213 en exigences concrètes (mises à jour, accès, logs, fin de vie)

Illustration générée par IA — visuel conceptuel.

Dans un bâtiment tertiaire (bureaux, retail, hôtellerie), les objets connectés ne sont pas seulement un « lot capteurs ». Ils deviennent des briques d’exploitation (confort, énergie, sûreté, supervision) et, de fait, des points d’entrée possibles si les exigences d’accès, de mises à jour, de journalisation et de support ne sont pas cadrées dès l’appel d’offres.

Ce guide propose une méthode simple pour traduire l’approche NIST SP 800‑213 en clauses actionnables dans un cahier des charges (CCTP/CDC) : ce que l’on attend de l’équipement (capacités techniques) et ce que l’on attend du fabricant / support (capacités non techniques : documentation, alertes, gestion de vulnérabilités, fin de support, etc.).

Important : les publications NIST sont des guides (usage volontaire) et ne constituent pas, en elles-mêmes, une obligation réglementaire universelle. L’objectif ici est d’outiller un projet (achat + recette + exploitation), pas de « cocher une norme ».

Pourquoi partir de NIST SP 800‑213 (au lieu d’une liste de “bonnes pratiques”)

NIST SP 800‑213 propose une logique utile pour un maître d’ouvrage et une équipe de conception : formaliser des “device cybersecurity requirements” en distinguant :

• Les capacités cybersécurité attendues du device (ce que l’objet sait faire).
• Les capacités de support attendues du fabricant et/ou de tiers (ce que l’écosystème autour de l’objet garantit sur la durée de vie).

Cette distinction évite un piège fréquent : exiger un “device sécurisé” sans exiger la capacité de le maintenir (bulletins de sécurité, canal de vulnérabilités, fin de support, documentation d’exploitation…).

Références NIST à garder dans le dossier d’appel d’offres :

• NIST SP 800‑213 — IoT Device Cybersecurity Guidance for the Federal Government (PDF).
• Page de publication NIST SP 800‑213 (CSRC).

Étape 1 — Définir le périmètre IoT “bâtiment” avant d’écrire les clauses

Avant les exigences cybersécurité, posez le cadre : vous éviterez des réponses incomparables entre intégrateurs, et des angles morts entre lots (GTB, réseau, sûreté, GRMS, audiovisuel, etc.).

Périmètre technique (à rendre explicite)

• Typologies d’objets : capteurs (IAQ, présence, énergie), passerelles, contrôleurs, actionneurs, objets “IT-like” (écrans, terminaux, interphones IP…), et les serveurs/VM éventuels.
• Mode d’exploitation : local uniquement, cloud obligatoire, cloud optionnel, accès distant maintenance, multi-sites.
• Interfaces et dépendances : GTB/BMS, PMS/GRMS (en hôtellerie), contrôle d’accès, supervision/alerting, annuaire, NTP, sauvegardes, etc.

Périmètre contractuel (qui fait quoi)

• Rôles : qui administre les objets (exploitation bâtiment ? IT ? prestataire ?), qui valide les mises à jour, qui gère les comptes et accès distants.
• Livrables : dossier d’exploitation, inventaire, matrices d’accès, procédures d’update/rollback, preuves de recette.
• Durée de vie visée : sans chiffrer arbitrairement, exigez un engagement clair de support, et surtout un processus de notification de fin de support.

Lecture utile (architecture et cloisonnement) : Comment séparer les équipements du bâtiment du réseau informatique des bureaux ?

Étape 2 — Exigences côté équipement : clauses basées sur la “core baseline” NISTIR 8259A

NISTIR 8259A formalise une baseline de capacités techniques (core baseline) pour la cybersécurité des devices IoT : identification, configuration, protection des données, accès logique aux interfaces, mises à jour logicielles, et remontée d’état cybersécurité. Source (PDF) : NISTIR 8259A — IoT Device Cybersecurity Capability Core Baseline. (Page de publication : NISTIR 8259A (CSRC).) (Référence programme : NISTIR 8259 series (NIST).)

Ci-dessous, des clauses “copier-adapter” + des preuves attendues (documentaires) et des tests de recette (réalisables en projet). Adaptez le niveau d’exigence au risque : un capteur non critique n’est pas une serrure connectée, ni un contrôleur CVC.

Capacité : identification (inventaire)

Clause-type

• Chaque équipement IoT livré doit être identifiable de manière unique : identifiant logique et identifiant physique, accessibles aux entités autorisées, et exploitables pour l’asset management (inventaire).
• L’identification doit permettre de relier sans ambiguïté : modèle, version logicielle/firmware, numéros de série, rôle dans l’architecture (zone/site/armoire), et propriétaire d’exploitation (lot/mainteneur).

Preuves attendues : format d’identifiants, emplacement (étiquette/QR, interface UI/API), méthode de lecture, export inventaire.

Recette (exemples de tests) : vérifier qu’un échantillon d’équipements permet d’extraire l’identifiant et la version logicielle, et que ces données sont cohérentes entre l’étiquette, l’interface d’administration et l’export.

Capacité : configuration (durcissement et restauration)

Clause-type

• Les changements de configuration doivent être possibles uniquement par des entités autorisées (rôles/permissions), avec une traçabilité exploitable.
• L’équipement doit offrir une capacité de restauration vers une configuration sécurisée définie/validée (pour remise en état après incident ou maintenance).

Preuves attendues : matrice des paramètres de sécurité (réseau, services, comptes), mécanisme de sauvegarde/restauration, traces d’audit.

Capacité : protection des données (au repos / en transit) et effacement

Clause-type

• Les données sensibles (identifiants, secrets, configurations, journaux, données métier selon cas) doivent être protégées en stockage et en transit par des mécanismes cryptographiques adaptés, et le fournisseur doit documenter les choix de sécurité (ex. gestion des clés, renouvellement, stockage sécurisé).
• En cas de retrait, retour SAV, revente ou décommissionnement, l’équipement doit permettre de rendre les données inaccessibles (effacement du stockage et/ou destruction des clés) selon une procédure documentée.

Recette (exemples de tests) : vérifier l’existence d’une procédure d’effacement, et réaliser un test sur un équipement de démonstration (après effacement, contrôle que l’accès admin est réinitialisé et que les données ne sont plus disponibles via UI/API/export).

Lecture utile (fin de vie “support stockage”) : Remplacer un NVR/NAS/serveur vidéo : comment effacer disques et cartes SD avant revente (méthode NIST 800‑88).

Capacité : accès logique aux interfaces (réduire la surface d’attaque)

Clause-type

• Les interfaces locales et réseau non nécessaires au fonctionnement doivent pouvoir être désactivées.
• L’accès logique aux interfaces, protocoles et services doit être restreint aux seules entités autorisées (principes de moindre privilège et de séparation des rôles).
• Les identifiants par défaut (comptes et mots de passe) doivent être traités explicitement : politique de changement, désactivation, ou mécanisme équivalent (selon type d’équipement).

Preuves attendues : liste des interfaces/services, possibilités de désactivation, gestion des comptes/rôles, compatibilité avec une segmentation OT/IT cible.

Capacité : mises à jour logicielles (patch management)

Clause-type

• L’équipement doit intégrer un mécanisme de mise à jour sécurisé et configurable, utilisable par des entités autorisées.
• Le fournisseur doit décrire : modalités de publication (bulletins, notes de version), mécanismes de validation, procédure de rollback ou de retour arrière (si disponible), prérequis d’exploitation (fenêtres de maintenance, redémarrage, indisponibilité attendue, etc.).
• Le cahier des charges doit exiger un processus : qualification en préproduction (quand applicable), planification, déploiement, et preuve d’exécution (reporting).

Recette (exemples de tests) : réaliser au moins un cycle d’update sur un lot pilote, vérifier la traçabilité (version avant/après), et constater les impacts (reboot, interruption service, reprise).

Lecture utile (méthode d’exploitation) : Comment mettre à jour des équipements en limitant les interruptions (inventaire, fenêtres, rollback).

Capacité : “cybersecurity state awareness” (logs et état)

Clause-type

• L’équipement doit être capable de rapporter son état cybersécurité (au minimum distinguer un état normal et un état dégradé), et rendre cette information exploitable par une brique externe (supervision / collecte d’événements).
• Les journaux et événements de sécurité doivent être exploitables : horodatage cohérent, export, et périmètre documenté (quels événements, quelle granularité).

Recette (exemples de tests) : provoquer un événement de sécurité simple (ex. tentative de login invalide, changement de mot de passe, activation/désactivation d’interface) et vérifier qu’il est journalisé, horodaté, et exportable.

Point d’attention opérationnel : des logs inutilisables (heure incohérente, formats inexploitables) rendent le diagnostic fragile. Voir : Caméras et contrôle d’accès : pourquoi synchroniser l’heure des équipements ?

Étape 3 — Exigences côté fabricant / support : clauses basées sur NISTIR 8259B

La cybersécurité IoT ne tient pas si le support n’est pas organisé. NISTIR 8259B formalise une baseline de capacités non techniques : documentation, réception des questions (dont vulnérabilités), diffusion d’information (dont alertes et fin de support), et sensibilisation/formation. Source (PDF) : NISTIR 8259B — IoT Non-Technical Supporting Capability Core Baseline (présentation : page NIST).

Capacité support : documentation (pré-achat + exploitation)

Clause-type

• Le fournisseur doit fournir une documentation cybersécurité exploitable pour décider l’achat et exploiter le produit : architecture, interfaces, ports/protocoles, mécanismes d’authentification, gestion des comptes, politique d’update, journalisation, sauvegarde/restauration, décommissionnement.
• La documentation doit être maintenue à jour pendant la période de support.

Preuves attendues : guides officiels, matrice des ports/services, matrice des rôles, et fiche “secure deployment” (ou équivalent).

Capacité support : canal de réception (questions, incidents, vulnérabilités)

Clause-type

• Le fournisseur (ou son représentant/support) doit mettre à disposition un canal dédié pour : demandes d’information, incidents, et signalement de vulnérabilités.
• Le cahier des charges doit exiger une organisation lisible : accusé de réception, suivi, et points de contact.

Capacité support : diffusion d’information (alertes, avis, fin de support/EoL)

Clause-type

• Le fournisseur doit disposer d’une procédure de notification : avis de sécurité, vulnérabilités, correctifs, contournements, et statut de résolution.
• Le fournisseur doit notifier les conditions de support des mises à jour et la fin de support / fin de fonctionnalité selon un mécanisme formalisé (bulletin, mailing list, portail, etc.).
• Le cahier des charges doit prévoir l’effet “projet” de la fin de support : options (migration, remplacement, segmentation compensatoire), livrables, et responsabilités.

Point d’attention : ne remplacez pas cette clause par une durée “au doigt mouillé”. Ce qui protège l’exploitation, c’est la capacité contractuelle à être informé à temps et à décider (remplacer, isoler, migrer).

Capacité support : éducation et sensibilisation

Clause-type

• Le fournisseur doit fournir des contenus de formation (ou supports) permettant aux équipes d’exploitation/intégration de configurer, administrer, mettre à jour, sauvegarder et dépanner l’équipement sans dégrader la posture de sécurité.

Étape 4 — Dossier de preuve & recette : ce que vous devez pouvoir vérifier

Un cahier des charges efficace ne se limite pas à “exiger”. Il doit préciser comment on prouve et comment on réceptionne (tests, documents, démonstration). Ci-dessous un modèle minimal.

Livrables (dossier de preuve)

• Fiche d’architecture : rôles des équipements, flux principaux, dépendances (DNS/NTP, cloud, API…).
• Liste des interfaces, ports et services + recommandations de durcissement (désactivation services inutiles).
• Matrice des rôles et accès (qui peut faire quoi) + procédure de création/suppression des comptes.
• Politique de mises à jour : cycle, notes de version, procédure de retour arrière si disponible, et impacts attendus.
• Journalisation : quels événements sont produits, comment ils sont exportés, et prérequis d’horodatage.
• Procédure de décommissionnement/effacement.
• Engagements de support : documentation, canal vulnérabilités, diffusion d’alertes, fin de support.

Exemples de tests de recette (réalisables) et limites

Exigence à vérifier	Test de réception (exemple)	Limite / point d’attention
Identification unique	Extraire identifiant + version firmware via interface admin et comparer à l’étiquette physique	Un export ponctuel ne prouve pas la tenue d’inventaire sur la durée (process à cadrer)
Désactivation interfaces	Inventorier services actifs, désactiver un service non requis, vérifier continuité fonctionnelle	Selon les produits, certains services sont “cachés” : exiger documentation claire
Contrôle d’accès admin	Créer deux profils (admin/exploitant), vérifier séparation des actions (config vs lecture)	Une UI simple peut masquer des accès API plus larges : demander périmètre API
Mise à jour	Appliquer une mise à jour sur un lot pilote, mesurer indisponibilité et vérifier version	Un test “sur table” ne remplace pas un plan de déploiement en exploitation
Logs / événements	Provoquer un événement (login invalide) et vérifier horodatage + export	La qualité d’horodatage dépend souvent de NTP et du design réseau
Effacement	Appliquer procédure d’effacement, vérifier réinitialisation et absence de données via UI	Selon les produits, seule une destruction de clés est possible : exiger documentation

Étape 5 — Exploitation : clauses pour que la sécurité survive au “jour 2”

Les meilleures clauses “device” échouent si l’exploitation n’est pas cadrée. Sans entrer dans un contrat SLA chiffré, vous pouvez exiger un socle de gouvernance.

Accès et maintenance à distance

• Interdire les accès distants “non tracés” (comptes partagés, VPN fournisseur non documenté, etc.).
• Exiger une matrice d’accès et un processus : création, révocation, audit périodique.

Gestion des mises à jour (processus)

• Exiger un cycle : qualification → validation → fenêtre de déploiement → preuve de déploiement → gestion d’incident/rollback.
• Clarifier qui prend la décision (maître d’ouvrage/exploitant vs mainteneur) et sur quel périmètre (pilote, site, global).

Fin de vie (EoL) : décider, isoler, remplacer

• Exiger l’anticipation : notification de fin de support, options (migration, remplacement), et impacts (compatibilité, licences, dépendances cloud).
• Exiger une procédure de retrait : sauvegarde si besoin, effacement, et mise à jour de l’inventaire.

Pour cadrer la dimension “contrat de service” (responsabilités, engagements réalistes, accès, pièces, organisation), voir : Maintenance des équipements d’hôtel : quels engagements prévoir dans le contrat ?

Annexe — Modèle de section « Cybersécurité IoT » (à copier dans un CCTP/CDC)

Vous pouvez reprendre ce modèle comme base, puis l’adapter par lot (GTB, capteurs énergie, contrôle d’accès, GRMS…).

1) Exigences minimales côté équipements (capacités techniques)

• Identification : identifiants uniques logiques et physiques, exploitables pour l’inventaire (modèle, version, n° série, rôle).
• Configuration : changements autorisés uniquement, restauration configuration sécurisée.
• Protection des données : protection des données au repos/en transit + procédure documentée d’effacement / décommissionnement.
• Accès aux interfaces : désactivation interfaces/services non requis + restriction aux entités autorisées.
• Mises à jour : mécanisme sécurisé et configurable + documentation exploitation (impacts, notes, options retour arrière si disponibles).
• État / logs : capacité à rapporter l’état cybersécurité et à fournir des logs exploitables (horodatage, export).

2) Exigences minimales côté support (fabricant / tiers)

• Documentation : guides de déploiement sécurisé, matrice ports/services, rôles, logs, updates, décommissionnement.
• Canal questions/vulnérabilités : point de contact, suivi, accusé réception.
• Diffusion d’information : avis de sécurité, correctifs, contournements, conditions de support, fin de support/fin de fonctionnalité.
• Éducation/sensibilisation : supports de formation exploitation/intégration.

3) Dossier de preuve & recette

• Liste des livrables documentaires attendus (à fournir avant recette).
• Plan de tests (échantillonnage, scénarios de mise à jour, tests de logs, tests d’accès, test d’effacement sur équipement de démonstration).
• Critères d’acceptation et réserves typiques (écarts documentaires, impossibilité de désactiver des services, absence de canal vulnérabilités, etc.).

4) Exploitation (jour 2)

• Processus de gestion des accès (création/révocation/audit).
• Processus de mises à jour (qualification, déploiement, preuve).
• Processus fin de vie : notification, décision, isolement/remplacement, effacement, mise à jour inventaire.

Aller plus loin selon le type de projet

Selon l’usage, la cybersécurité IoT doit se lire « système » : réseau, segmentation, interfaces, et exploitation. En hôtellerie, le CDC doit aussi rester cohérent avec la logique chambre et les interfaces PMS/GRMS.

Lecture complémentaire : Cahier des charges GRMS hôtel : les points à spécifier avant l’appel d’offres.

Sources et documentation

• NIST SP 800‑213 — IoT Device Cybersecurity Guidance (PDF)
• NIST SP 800‑213 (CSRC)
• NISTIR 8259A — IoT Device Cybersecurity Capability Core Baseline (PDF) (page : NISTIR 8259A (CSRC))
• NISTIR 8259B — IoT Non-Technical Supporting Capability Core Baseline (PDF)
• NIST — IoT Non-Technical Supporting Capability Core Baseline (page)

Si vous souhaitez transformer ces clauses en annexes prêtes à intégrer à vos DCE (par lots, avec une stratégie de recette réaliste et des responsabilités claires), Domocasa peut vous aider à cadrer les livrables, la segmentation et les critères d’acceptation.