Comme pour la gestion des identités des employés ou des clients, l’approche par le cycle de vie des objets connectés permet de traiter l’ensemble des problématiques sécurité. Cet article présente les éléments clés de cette méthodologie et les points majeurs à adresser à chaque événement de la vie d’un objet connecté.
Quels risques dans le monde de l’IoT ?
L’avènement de l’IoT a permis l’apparition de millions de nouveaux usages potentiels pour les consommateurs et les entreprises. Mais avec ces nouveaux usages émergent certains risques plus marqués dans le domaine des objets connectés.
Figure 1 – Des risques métier et technologiques plus marqués dans le monde de l’IoT
Ces risques métier et technologiques, pouvant induire des impacts potentiellement forts pour les consommateurs et les entreprises, doivent ainsi être identifiés dès les phases amont d’un projet IoT.
Quelle méthodologie projet pour assurer la sécurité d’un objet connecté ?
Même si les thématiques sécurité à aborder dans le cadre d’un projet IoT sont communes à tout autre projet, notre conviction est qu’il est nécessaire de structurer les réflexions autour du cycle de vie de l’objet concerné.
Le schéma ci-dessous met en évidence l’ensemble des étapes du cycle de vie d’un objet connecté.
Figure 2 – Un cycle de vie permettant d’aborder l’ensemble des thématiques sécurité
Regardons quelques questions que soulève cette approche.
- Phase de conception, de fabrication et de distribution
Cette première phase permet d’adresser les questions liées à la conception de l’objet en regard des enjeux métier, de la cible utilisateurs (B2B, B2C, B2E), de l’environnement de déploiement (contrôlé ou non) et de la criticité de l’usage :
- Quelles sont les contraintes réglementaires s’appliquant aux usages de mon objet ?
- Quelle identité lui donner et comment la créer ?
- Comment assurer la sécurité matérielle et logicielle des secrets et des données stockées dans l’objet ?
- Comment initialiser l’état d’un objet sur la plate-forme de gestion et s’assurer qu’il n’a aucun droit sur le SI avant l’étape d’initialisation ?
Les choix mis en œuvre lors des phases de fabrication sont essentiels car ils déterminent les caractéristiques et capacités de base de l’objet. Un certain nombre seront dès lors immuables tout au long de la vie de l’objet et imposeront des contraintes fortes dans les étapes suivantes.
Par ailleurs, bien que la fin de la phase de fabrication marque le début de l’existence de l’objet sur la plate-forme de gestion d’objet, il n’y a encore aucune raison d’envisager une interaction avec le SI. Toute interaction ayant lieu avant l’association de l’objet à un utilisateur (physique ou moral) signifierait qu’il a été détourné dans l’étape de distribution. Tout accès au SI avant l’étape d’initialisation doit donc être strictement limité à la seule mise à jour du firmware (version N installée en usine et version N+1 disponible lors du déballage) ou à la pré-personnalisation de l’objet (paramétrage de fonctionnement ou injection de secret non liés à l’utilisateur). Au-delà de la sécurité du SI, un objet inutilisable avant toute phase d’appairage réduira le risque de vol de cet objet en usine ou lors de sa distribution.
- Phase d’initialisation
La phase d’initialisation matérialise l’étape d’association (ou d’appairage) entre un objet et son propriétaire. Toute donnée générée par l’objet (ou action réalisée) est alors déclarée comme appartenant à son propriétaire (ou étant imputable à celui-ci). Dès lors, le principal enjeu est d’assurer un niveau d’association utilisateur/objet fiable et correspondant aux enjeux métier :
- Niveau d’association requis faible (situation à faible risque) : un employé déclare l’usage d’un système d’identification de présence en salle de réunion ;
- Niveau d’association requis fort (situation à fort risque) : lors de l’achat d’une serrure connectée, un consommateur fournit un numéro de série et code secret à usage unique pour autoriser son application mobile à déverrouiller la porte de son domicile.
Attention néanmoins à trouver le bon équilibre entre l’expérience utilisateur et la sécurité. La robustesse de l’association attendue pourra varier selon la nature des services auxquels le client a souscrit.
- Phase d’utilisation
La définition des usages des objets connectés est l’étape la plus anticipée par les entreprises mais de nombreux aspects de la sécurité restent négligés. Outre les cas d’usage métier, il convient donc de se poser des questions complémentaires telles que :
- Comment assurer la mise à jour régulière des objets connectés ?
- Quels rôles entre les différents acteurs de l’entreprise pour le maintien de la couche système d’exploitation de l’objet ? de la couche applicative ? du module réseau ?
- Quels besoins de détection et de réaction en cas de compromission d’un objet ?
- Comment tirer parti du SIEM (Security Information and Event Management) et du SOC (Security Operation Center) de l’entreprise pour les incidents de sécurité techniques (compromission logicielle de l’objet) ? pour les incidents de sécurité métier (détournement de l’usage ou vol d’un objet) ?
- Comment maintenir la rétrocompatibilité des protocoles et des API utilisés par différentes versions d’un même type d’objet ?
- Quels modèles de rôles et d’interactions entre les différentes populations agissant sur l’objet ?
Sur cette dernière question, et à titre d’exemple, le schéma ci-dessous illustre la complexité possible des interactions et du modèle de rôle sur un objet tel qu’un véhicule connecté.
Figure 3 – Exemple d’un modèle de rôle et d’interaction avec un véhicule connecté (travaux menés avec l’IMT Atlantique)
- Phase de revente
La revente est aujourd’hui l’étape la plus négligée lors de la conception d’un objet mais elle n’en reste pas moins critique. Cet événement concerne essentiellement les objets à destination du marché B2C soulevant des enjeux très spécifiques :
- Comment détecter et prendre en charge le cas de la revente d’un objet entre particuliers ?
- Quels principes de privacy-by-design mettre en œuvre pour protéger les secrets et données de l’ancien propriétaire lors d’une remise à zéro d’un objet ?
- Comment supprimer les droits d’accès du précèdent propriétaire à l’objet ?
- Quels moyens pour réinitialiser un objet dans un état stable et intègre avant un nouvel appairage ?
La difficulté majeure concerne la détection de l’événement de revente permettant de déclencher des processus de désappairage objet/utilisateur, de réinitialisation de l’état de l’objet…
Notre expérience nous permet d’identifier certaines circonstances pouvant signaler un changement de propriétaire.
Figure 4 – Exemples d’événements pouvant signaler un changement de propriétaire
Malgré ces exemples, nous constatons que la revente reste un événement complexe à identifier. C’est pourquoi certaines entreprises font tout simplement le choix de ne pas autoriser la revente d’un objet via un contrat de location. L’objet doit dès lors être restitué lors de la résiliation du service ; à défaut il doit être rendu inutilisable. Ce modèle est comparable à celui de la location d’une box Internet auprès d’un FAI (Fournisseur d’Accès Internet).
- Fin de vie et recyclage
Bien qu’indispensable, nous avons actuellement peu de recul sur cette étape mais les enjeux sont multiples :
- Révoquer les droits accès sur le SI d’un objet en fin de vie ;
- Renouveler l’identité d’un l’objet recyclé ;
- Assurer le remplacement d’un objet défectueux en en réassociant un nouveau avec le même propriétaire et les mêmes données ;
- Détecter l’inactivité d’un objet pour déclencher un remplacement.
Les principaux risques sont la perte de la maîtrise des accès sur le SI de l’entreprise via des identifiants associés à des objets recyclés, la divulgation de données personnelles de l’ancien propriétaire ou encore le surcoût de licence pour des données induites par des objets considérés hors parc.
Une capacité d’action face aux risques variable selon la nature du projet ?
À ce stade de votre lecture vous vous dîtes probablement que cet article vous concerne peu car vous faites l’acquisition de modules ou d’objets connectés préconçus ?
Faux, vous êtes exposés aux mêmes risques ! Même si vous ne faites qu’acquérir ou accueillir des objets connectés au sein de votre SI, adresser l’ensemble des problématiques listées ci-dessus vous permettra d’alimenter le contenu d’un cahier des charges à destination de vos fournisseurs.
En conclusion, quelle que soit la nature de votre projet IoT, il est essentiel de concevoir votre objet en structurant les réflexions autour de son cycle de vie : de sa fabrication à sa mise au rebut. Il faut dès lors, à chaque étape, aborder l’ensemble des thématiques sécurité pertinentes : sécurité réseau / applicative / matérielle, standards, détection et réaction, gouvernance, maintien en condition de sécurité…
Figure 5 – Thématiques de sécurité majeures pour
