Quels besoins pour l’IAMoT ?

Il est possible de définir l’IAM comme une discipline permettant de « donner les bons droits, aux bonnes personnes, aux bons moments ». L’IAMoT vient ajouter une composante à cette définition pour permettre de « donner les bons droits, aux bonnes personnes et aux bons objets, aux bons moments ».

Mettre en œuvre des solutions pour permettre une gestion adaptée des identités des objets connectés se traduit donc par le besoin de prendre en compte :

• La gestion des identités des objets et de leur état (voir l’article détaillant le cycle de vie des objets) ;
• La gestion du contrôle d’accès et des habilitations :
  • des objets sur le SI et sur ses données ;
  • des objets sur les autres objets et leurs données ;
  • des employés/partenaires de l’entreprise sur l’objet et ses données ;
  • des clients finaux sur l’objet et ses données ;
• La gouvernance des identités des objets et la pertinence des droits associés dans le temps.

Tout comme pour l’IAM, pour chacun de ces domaines, il va être nécessaire de définir des processus, une organisation associée et des outils adaptés aux contraintes technologiques du projet.

La question est donc maintenant : vers quelles solutions s’orienter pour répondre à mes besoins ?

Des plates-formes IoT orientées connectivité et gestion de flotte

Le premier réflexe est de se tourner vers les services que peuvent fournir les plates-formes de gestion d’objets connectés.

En étudiant ces plates-formes plus en détail, nous avons fait le constat que leur priorité est déjà de couvrir les services essentiels pour la gestion de la flotte des objets connectés :

• gérer la connectivité multi-protocolaire des objets avec le SI de l’entreprise (SigFox, LoRa, 3/4/5G…) ;
• maîtriser l’inventaire des objets déployés et en assurer la configuration ou la mise à jour via un module de « Device Management » (LWM2M, OMA-DM, TR-069/CWMP…) ;
• permettre la remontée et la mise à disposition des données générées par l’objets (DTLS, CoAP, MQTT, AMQP…).

Ces fonctions s’accompagnent de solutions techniques d’authentification de l’objet sur les plates-formes mais celle-ci n’offrent aucune opportunité de couverture des besoins métier.

Dans ce cas, que font les acteurs traditionnels de l’IAM et du CIAM ? Puis-je me tourner vers leurs solutions qui sont aujourd’hui orientées sur la couverture des besoins des utilisateurs ?

Des marchés IAM et CIAM en mutation pour couvrir une infime partie du besoin IoT

Les éditeurs historiques de solutions IAM et CIAM ont compris l’énorme opportunité que représente l’IAMoT et orientent progressivement leurs offres et le discours associé sur ce marché. Néanmoins, nous constatons qu’ils ne couvrent encore que très partiellement les besoins identifiés ci-dessus et que selon leur capacité à innover le délai de mise en œuvre des nouveautés pourra être important.

Forts de leurs savoir-faire technologiques, ils se concentrent aujourd’hui quasi-exclusivement sur le volet contrôle d’accès. Ils offrent ainsi des solutions pertinentes pour permettre l’authentification applicative des objets sur le SI et la délivrance de jetons d’autorisation dont la gestion du contenu relève encore d’un défi propre à chaque projet. Sur les autres volets de l’IAMoT tels que la gestion de l’identité et de l’état des objets, la gestion du modèle de rôles liant objets / utilisateurs / identités internes / identités externes, ou la gouvernance des droits dans le temps, il est urgent que leur offre s’étoffe.

Dès lors, comment peut-on couvrir des besoins IAMoT bien présents malgré les lacunes du marché ?

Une hétérogénéité des usages rendant complexe la normalisation des pratiques et la standardisation des solutions

La diversité des usages et donc des modes de fonctionnement des objets connectés est évidemment à l’origine de la difficulté des éditeurs à proposer une offre générique adaptée à ses clients. Mais les projets IoT sont là et il n’est pas envisageable d’attendre que le marché prenne forme.

Mais si l’harmonisation est actuellement impossible au niveau global du marché, un effort peut être consenti au niveau de l’entreprise afin d’essayer d’harmoniser les réponses pour l’ensemble de ses usages IoT. Ainsi tout en cherchant à tirer parti de ce que propose le marché IAMoT, il est nécessaire d’envisager le développement modulaire des briques manquantes et en priorité celles ayant trait à la gestion des relations « objets / utilisateurs / identités internes / identités externes ». Attention toutefois à ne pas succomber aveuglement à l’utilisation des frameworks bas-niveau propriétaires proposés par les plates-formes IoT. Chacun devra être vigilant à conserver un niveau d’abstraction et d’autonomie suffisant pour ne pas être lié ad vitam æternam à un éditeur unique. Ce point d’attention est d’autant plus important dans un marché peu mature et en explosion où les bonnes idées se font et se défont.

Que faut-il retenir ?

Aucune solution du marché ne couvre l’intégralité des besoins fondamentaux de l’IAM of Things. Les plates-formes IoT se limitent aux fonctions de connectivité des objets, de gestion de flotte et de remontée de données. Les plates-formes IAM et CIAM n’offrent quant à elles que des réponses technologiques aux besoins d’authentification et d’autorisation.

Afin de combler les manques, chaque entreprise devra évaluer le besoin de se lancer dans le développement de ses propres modules applicatifs. Un effort tout particulier devra être entrepris pour atteindre un niveau adapté de généricité des modules pour l’ensemble de leurs usages et d’indépendance vis-à-vis des solutions éditeur.

Cet article IAM of Things, un marché émergeant mais un besoin déjà présent est apparu en premier sur RiskInsight.

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.

1. 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.

2. 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.

3. 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)

4. 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).

5. 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

Cet article Une approche par le cycle de vie pour la sécurité de l’IoT est apparu en premier sur RiskInsight.

Les objets connectés apportent de nouvelles perspectives pour l’évolution des processus et méthodes de travail des entreprises et utilisateurs. En effet, ces objets sont aujourd’hui en capacité d’interagir avec leur environnement pour échanger des informations ou exécuter des actions. Ces échanges se caractérisent notamment par des relations avec le système d’information de l’entreprise, les employés, les utilisateurs finaux et même les autres objets. Afin d’assurer la sécurité de ces échanges, il est absolument nécessaire de mettre en œuvre des mécanismes de contrôle d’accès, ce qui implique de connaître et de maîtriser les identités de l’ensemble des objets connectés du parc ainsi que celles des utilisateurs.

Cette discipline de gestion des identités est connue au sein des entreprises et rattachée au domaine de l’IAM (Identity & Access Management), c’est-à-dire la gestion du cycle de vie des identités des collaborateurs et partenaires (IAM traditionnel) ou des clients finaux (Customer IAM ou CIAM). Elle doit désormais se décliner sur le périmètre des objets connectés : c’est l’IAM of Things (IAMoT).

Figure 1 – IAM traditionnel, Customer IAM et IAMoT : trois domaines fortement liés

Un objet connecté, oui… mais avec quoi ?

Les interactions entre un objet connecté et son environnement peuvent être regroupées en 3 catégories principales.

1. Un objet connecté au SI de l’entreprise

C’est le premier cas d’usage qui vient à l’esprit. Chaque objet communique avec le SI via une identité unique qui le caractérise et des droits d’accès associés. Cela implique la mise en place de principes de création, de référencement, de gestion, de contrôle et de pilotage de ces identités. L’état d’un objet ou l’identité de son propriétaire doivent être connus à tout moment.

Dans une chaîne technologique type « objets – relais – plate-forme IoT – applications » la plate-forme IoT offre un point central permettant la gestion de l’ensemble des identités des objets.

Dans ce cadre, il est par ailleurs essentiel de maîtriser l’authentification des objets auprès des applications, et donc de définir les principes de génération des secrets qu’ils utiliseront.

Figure 2 – Chaîne technologique type

2. Un objet utilisé par les clients finaux

Pour ce type d’objets, une relation forte avec le domaine du Customer IAM apparaît. En effet, l’objet doit être en mesure de vérifier l’identité de l’utilisateur auprès du CIAM et de déterminer les services auxquels il a souscrit.

En cas d’usage partagé d’un même objet, un modèle de rôles et de données impliquant différents types d’utilisateurs finaux doit aussi être envisagé.

Prenons l’exemple d’un véhicule connecté :

• Le conducteur du véhicule souhaite accéder au service GPS. Avant de permettre l’accès au service le véhicule doit répondre à de nombreuses questions. Quelle est l’identité du conducteur et quel profil personnel dois-je utiliser (chargement des précédents trajets) ? Est-il propriétaire du véhicule, locataire ou s’agit-il d’un prêt pour un usage ponctuel ? Le conducteur a-t-il souscrit au service GPS auprès du fabricant et à quel niveau de service (calcul des trajets uniquement ou alerte des zones de danger) ?

3. Un objet en interaction avec les employés de l’entreprise et ses partenaires

Dernier cas, chaque objet peut interagir avec les employés de l’entreprise, des prestataires ou des partenaires. La relation avec le domaine de l’IAM traditionnel assurant la gestion des habilitations et des rôles des partenaires et employés de l’entreprise est alors essentielle.

Les différents usages de l’objet imposent la création d’un modèle de rôle permettant de répondre à la question : quels droits pour quelles populations sur quelles fonctionnalités de l’objet ?

Reprenons l’exemple d’un véhicule connecté :

• Lors d’une réparation un garagiste doit pouvoir, à des fins de diagnostic, visualiser les derniers indicateurs de fonctionnement d’un véhicule avant une panne. S’agit-il d’un garagiste du réseau constructeur ou d’un garagiste indépendant ? Peut-il accéder aux informations GPS ou uniquement aux indicateurs techniques du moteur ? Le client final peut-il consentir ou a minima être informé de l’accès aux données de son véhicule ?

Cet exemple met aussi en évidence le fait que les droits accordés peuvent être étroitement liés à la notion de temps (uniquement pendant la durée de la réparation) ou à la nature d’une donnée (protection de la vie privée dans le cas des données GPS).

L’IAM of Things, c’est aussi des processus

Tous les experts de l’IAM vous le diront : il n’y a pas d’IAM sans une étude approfondie du cycle de vie de identités concernées. L’IAMoT doit étudier l’ensemble des processus impliquant l’objet sur l’ensemble de son cycle de vie. En effet, tout au long de la vie d’un objet, la nature des interactions avec son environnement est amenée à évoluer selon l’état dans lequel il se trouve. Un objet neuf devra, par exemple, être associé à son utilisateur principal via un processus d’appairage assurant un niveau de confiance en cohérence avec les enjeux.

Appuyons-nous une dernière fois sur l’exemple du véhicule connecté :

• Un particulier vient de faire l’acquisition d’un véhicule connecté d’occasion auprès d’un autre particulier. Dans le cadre de cette revente, il est nécessaire pour le nouvel acquéreur de s’assurer que les accès aux services sont révoqués pour le précédent propriétaire. La détection de l’événement de revente doit donc déclencher un processus de désappairage de l’ancien propriétaire.

Figure 3 – Ingrédients pour la recette de l’IAM of Things

L’IAM of Things, une nouvelle discipline s’appuyant sur des concepts maîtrisés

Cet article met en évidence la problématique de la gestion des identités pour l’IoT et souligne les liens existant avec les autres domaines de l’IAM. Il est important de retenir que, même si les principes fondamentaux de l’IAM s’appliquent aussi à l’identité des objets connectés, des réponses adaptées à chaque contexte projet doivent être étudiées.

Cet article Qu’est-ce que l’IAM of Things ? est apparu en premier sur RiskInsight.