C’est précisément là que se positionne la version 2.0 du guide « La cybersécurité des systèmes industriels – Mesures détaillées », publiée le 27 novembre 2025 : traduire les classes de cybersécurité en mesures concrètes, au moment où l’OT doit composer avec une menace plus pressante, des architectures plus interconnectées, et des exigences de conformité plus visibles. 

Ce guide fait directement écho à la publication de la deuxième version de la Méthode de classification des systèmes industriels de l’ANSSI en mars 2025, pour laquelle nous avions déjà rédigé un article. 

Une mise à jour dans la continuité : même ossature, même logique 

Évolutions du guide des mesures détaillées entre la première et la deuxième version

Sur la forme, le guide 2025 reste très proche de la version 2014 : on retrouve une première partie rappelant les contraintes et faiblesses propres aux environnements industriels, puis un découpage entre mesures organisationnelles et mesures techniques. Les thèmes, eux, ne surprendront pas : gouvernance, maîtrise des accès, cloisonnement, accès distants, sauvegardes, supervision, gestion des vulnérabilités, intégration de la cybersécurité dans le cycle de vie, préparation à l’incident. La continuité est assumée. 

Cette stabilité a un avantage : elle permet à une organisation déjà alignée sur la version 2014 de ne pas repartir de zéro. Mais elle montre aussi que la plupart des “grands sujets” étaient déjà connus il y a plus de dix ans. La question n’est donc pas tant “qu’apprend-on de nouveau ?” que “qu’est-ce qui devient réellement plus actionnable, et à quel prix ?”. 

Sur ce point, le guide est clair sur son périmètre : il propose un socle pour les dossiers d’homologations. Pour autant, le guide ne prétend pas se substituer à l’IEC 62443, ni offrir un cadre de certification. Il se contente d’en reprendre certains principes et exigences, et rappelle que les mesures ne suffisent pas, à elles seules, pour les systèmes les plus critiques.

Ce qui change concrètement : une nouvelle grammaire d’exigences restructurée 

Le changement le plus visible n’est pas une nouvelle thématique, mais une nouvelle manière d’exprimer les exigences : 

En 2014, le guide s’appuyait sur une distinction structurante : recommandations (R) et directives (D), avec un mécanisme de durcissement selon la classe. En 2025, cette grammaire disparaît. Le guide formalise une lecture par classe (C1 à C4) et introduit des variantes : recommandations “à l’état de l’art”, alternatives de niveau moindre représenté par un –, ou recommandations renforcées complémentaires représentées par un +. 

Schéma type d’une recommandation 

Deuxième évolution structurante : l’ajout explicite d’une quatrième classe et l’alignement renforcé avec l’IEC 62443, en accordement avec la mise à jour de la méthode de classification. Pour chaque recommandation, une correspondance avec une exigence de l’IEC 62443 est indiquée lorsqu’elle existe et référencée dans une annexe. 

Concernant l’évolution de ces mesures, une large partie des 214 recommandations trouve, comme détaillé dans l’annexe B, un équivalent direct dans l’ancienne version. Cela confirme que la refonte repose davantage sur une réorganisation et une reformulation que sur une remise en cause du fond. Après analyse des 35 mesures étant identifiées comme sans équivalence directe, nous pouvons affirmer que ces dernières ne sont pas nécessairement nouvelles. Comme représenté sur ce tableau, elles traduisent : 

Catégories des raisons de non-équivalence directes et exemples illustrés 

Résumé des recommandations sans équivalences directes dans l’annexe B 

Une doctrine plus architecturée sur les interconnexions et accès distants 

Là où la version 2025 change réellement la dynamique, c’est sur certains sujets traités de manière plus structurée. Dans la première version, la doctrine sur les interconnexions et les accès distants était déjà relativement prescriptive : elle insistait sur le fait que la télégestion augmente considérablement la surface d’attaque, posait des règles opérationnelles et allait jusqu’à interdire la télémaintenance en classe 3, avec une logique d’uni-directionnalité des flux.

La modernisation apportée par la version 2025 est d’avoir rendu l’ensemble plus cohérent et mieux structuré : on passe d’un raisonnement principalement centré sur des composants et des moyens (pare-feu, VLAN, diode, VPN) à une lecture en fonctions de sécurité que l’on doit composer et positionner selon les classes et les sens de flux dans le tableau 3. Les lignes de ce dernier correspondent à la classe émettrice (from) et les colonnes à la classe réceptrice (to) ; les icônes indiquent les fonctions de sécurité à implémenter pour autoriser le flux dans ce sens. Par exemple, de la classe C1 vers IT, seul un système permettant de vérifier si la donnée provient d’une source autorisée – Aut(IT) – est requis. 

Résumé du tableau 3 – Section 4.2.1 : toutes les mesures qui figurent sont accompagnées d’une fonction d’unidirectionnalité du transfert de données 

Il est à noter que la définition d’Inno (OT) ne figure pas directement dans le document. 

Du référentiel à l’application terrain 

La version 2025 des Mesures détaillées referme logiquement la refonte initiée par la publication de la seconde version de la méthode de classification et renforce la compatibilité avec l’IEC 62443. Dans un contexte où la menace sur les environnements industriels est désormais très visible, ce document tombe à point nommé : c’est l’occasion d’adapter son plan d’action ou carrément lancer une roadmap 2030 – un guide non appliqué n’a jamais arrêté un attaquant ! 

Dans les chantiers prioritaires à lancer on identifie régulièrement : 

• Revoir la cartographie et dépendances IT vis-à-vis du métier 
• Adapter son architecture technique en troquant de nouvelle autorisation contre un renforcement de l’authentification et un meilleur contrôle du contenu
• Durcir et centraliser les accès distants notamment liées aux nombreux fournisseurs présents dans l’environnement industriel 
• Renforcer ou raccorder les environnements industriels à son SOC 

Cet article La cybersécurité des systèmes industriels : la refonte du guide de l’ANSSI des « Mesures détaillées »  est apparu en premier sur RiskInsight.

De la conformité à l’efficacité : un changement de paradigme dans les KPI 

KPI signifie Key Performance Indicator (indicateur clé de performance). Cependant, nous avons tendance à créer des KPI pour suivre la progression par rapport à nos plans, non la performance réelle. Bien que cela soit utile, surveiller uniquement le déploiement ou la couverture (nombre de sites connectés au SOC, déploiement d’EDR sur les machines OT, nombre de sondes enregistrées sur la console de gestion) en dit très peu sur la capacité réelle de votre SOC à détecter un attaquant. 

Alors, quel niveau de confiance avez-vous dans vos outils de détection, vos use cases et vos processus ? La seule façon d’en être sûr est simple : les tester.  

Et le meilleur moyen de les tester est d’organiser des exercices de Purple Team. 

Qu’est-ce que le Purple Teaming en OT ? 

Un exercice de Purple Team est une mission collaborative entre la Red Team (attaquants) et la Blue Team (défenseurs). Contrairement à une évaluation Red Team classique, où les équipe de défense ne sont pas tenus informés, un exercice de Purple Team est un effort conjoint et itératif. 

Cette approche collaborative permet aux deux équipes de : 

• Partager les hypothèses sur l’environnement OT 
• Valider la logique de détection en temps réel 
• Identifier les zones d’ombre 
• Améliorer les playbooks et les pipelines de détection 
• Aligner tout le monde sur un modèle de menace réaliste 

Réaliser un exercice de Purple Team 

Un exercice Purple Team se déroule en trois grandes phases : 

1. Préparation

La phase de préparation est souvent la plus difficile, en particulier en OT, où la sureté de fonctionnement, la disponibilité de l’outil industriel et la dépendance aux fournisseurs doivent être prises en compte. 

Selon la maturité de l’organisation, la préparation peut aller du très simple au très sophistiqué : 

• Tests unitaires 
  Petits tests isolés de règles de détection spécifiques (ex. : « Détecter le code fonction Modbus 90 »). 
• Tests basés sur des scénarios redoutés 
  Construire des scénarios autour des « crown jewels » de l’organisation et des modes de défaillance (ex. : « Téléversement non autorisé d’un programme sur un automate contrôlant un procédé critique »). 
• Tests enrichis par la CTI 
  Intégrer la Threat Intelligence : tester les techniques utilisées par de vrais attaquants ciblant l’OT (ex. TTP de Volt Typhoon, Sandworm, Xenotime ou de groupes ransomware visant les environnements industriels). 

Pour structurer la phase de préparation, deux éléments sont essentiels : 

• Une bonne connaissance de votre environnement OT 
  Planifier un exercice pertinent pour les risques métier et la détection OT, sans impacter le procédé, nécessite une connaissance approfondie du site et de son automatisation. 
• Un mapping sur la matrice MITRE ATT&CK for ICS 
  Mapper vos tests avec la matrice ATT&CK vous donne un langage commun avec les équipes de détection. Cela permet de sélectionner les techniques pertinentes, d’éviter les angles morts et de garantir une couverture sur plusieurs couches : postes opérateurs, automates, IHM … 

2. Jour J (Exécution)

L’exécution est réalisée conjointement : 

• La Red Team lance des actions contrôlées et autorisées 
• La Blue Team surveille les évènements détectés en temps réel 
• Les deux équipes ajustent, documentent et valident les résultats tout au long de l’exercice 

Selon le périmètre et la complexité des tests, une opération Purple Team en milieu industriel peut durer de quelques heures à quelques jours. 

Assurer la reproductibilité des tests avec Caldera 

Pour garantir la répétabilité et la cohérence entre les exercices Purple Team, l’automatisation devient essentielle. Nous utilisons Caldera, un framework open-source de Breach & Attack Simulation (BAS) développé par MITRE pour cela. 

En tant qu’ancien pentester, je n’ai jamais aimé le terme « pentest automatisé », mais les outils BAS sont ce qui se rapproche le plus d’une exécution de stimulis d’attaque répétable et sûre. 

Pourquoi utiliser Caldera plutôt que de réaliser tous les tests manuellement ? 

Caldera permet de : 

• Préparer et valider une liste contrôlée de tests sur une liste contrôlée d’actifs 
• S’assurer que seules des actions autorisées sont exécutées 
• Garantir la reproductibilité entre les environnements 
• Rejouer exactement les mêmes actions pour mesurer les améliorations après des changements de configuration 

Des plugins OT spécifiques existent déjà dans le module Caldera-OT, prenant en charge Modbus, Profinet, DNP3, etc. 

Récemment, Wavestone a publié deux plugins OT supplémentaires : 

• Support du protocole Siemens S7 
• Actions de communication OPC-UA 

Caldera en bref 

L’utilisation de Caldera repose sur quatre notions de base : 

• Abilities : actions techniques atomiques (ex. lecture de coils, écriture de tags, scan d’un automate) 
• Adversaries : collections d’abilities formant un scénario 
• Operations : exécution en temps réel de ces adversaries sur une cible 
• Fact sources : paramètres fournis pour une opération ; on peut ainsi lancer les mêmes opérations sur différents environnements en changeant seulement la source de facts 

La vidéo suivante présente une démonstration de Caldera sur notre maquette ICS : 

3. Débriefing

La majorité de la valeur ajoutée de l’exercice provient du debrief. Les types suivants de KPI peuvent être utilisés : 

• Couverture de détection – quel pourcentage des stimuli exécutés a été détecté ? 
• Qualité des alertes – les alertes étaient-elles exploitables, précises et compréhensibles ? 
• Temps de réaction – combien de temps avant qu’une alerte soit déclenchée puis reconnue ? 
• Efficacité des playbooks – les bonnes actions ont-elles été prises dans les délais attendus ? 

Ces résultats peuvent permettre d’aboutir à : 

• Des règles de détection mises à jour 
• Des playbooks SIEM/SOC améliorés 
• Une meilleure architecture de supervision 
• Du matériel de formation pour les analystes et ingénieurs 

Commencez à tester dès maintenant ! 

Le Purple Teaming apporte une valeur immédiate, quel que soit votre niveau de maturité actuel : 

• Il valide vos outils dans des conditions réelles 
• Il forme vos équipes SOC et OT 
• Il révèle les angles morts tôt dans le programme 
• Il fournit des KPI quantitatifs pour piloter les améliorations de détection 

Et oui, cela est possible dans la plupart des environnements de production, sous les conditions suivantes : 

• Périmètre strictement contrôlé 
• Actions approuvées par les fournisseurs 
• Pas d’exécution de fonctions perturbatrices 
• Implication des équipes opérationnelles et sécurité 
• Surveillance continue du comportement du système pendant les tests 

En bref : commencez petit, restez prudent, et itérez. 

N’attendez pas que votre programme de sécurité OT soit “terminé” pour commencer à en tester l’efficacité ! 

Cet article Purple Teaming pour l’OT : Comment passer de la conformité à la performance ? est apparu en premier sur RiskInsight.

En 2024, on estimait le nombre d’appareils IoT connectés dans le monde à environ 18 milliards, soit plus de deux fois la population mondiale. Des alarmes connectées aux ascenseurs intelligents, en passant par les capteurs industriels ou les dispositifs médicaux, ces technologies rythment désormais notre quotidien. 

Les récentes avancées dans le domaine de l’IoT ont transformé la façon dont nous interagissons avec les objets connectés. Conçus pour être intuitifs, ils sont accessibles sans expertise spécifique. Les connexions entre ces derniers, souvent sans fil, passent presqu’inaperçues aux yeux des utilisateurs. Pourtant, derrière cette apparente simplicité se cachent des protocoles de communication élaborés dont MQTT fait partie.   

En raison de sa popularité et de sa présence croissante au sein d’opérations sensibles, MQTT fait depuis plusieurs années l’objet de recherches quant aux risques liés à son utilisation. Nous nous intéresserons ici à son fonctionnement, ses vulnérabilités potentielles ainsi qu’aux bonnes pratiques permettant d’assurer la sécurité des communications. 

MQTT et les raisons de sa popularité 

Les forces de ce protocole 

Développé en 1999 par Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom), l’objectif derrière la conception de MQTT était de fournir une solution légère, efficace, avec une faible consommation d’énergie et de bande passante pour surveiller des oléoducs isolés dans le désert par le biais d’une liaison satellitaire. 

Si MQTT s’est aujourd’hui établi comme une référence pour la transmission de données IoT, c’est précisément pour ces propriétés fondamentales. Ce protocole est par ailleurs fréquemment utilisé pour la remontée de données provenant de capteurs ou d’objets connectés vers des plateformes Cloud. 

Figure 1 – Caractéristiques principales de MQTT 

Son fonctionnement

Définitions des termes clés 

Client MQTT : Un dispositif échangeant des informations. 

Broker MQTT : Une entité intermédiaire permettant à des clients MQTT de communiquer et par laquelle tous les messages MQTT transitent. En particulier, le broker reçoit les messages publiés et les distribue aux destinataires concernés (les abonnés au topic correspondant). 

Topic : Une chaine de caractères permettant de filtrer et d’organiser les messages selon une structure hiérarchique. Lorsqu’un client publie un message, il l’associe à un topic. 

Publish/Subscribe : Modèle dérivé du Client/Serveur classique pour lequel les demandes ne sont pas initiées par un client demandant des ressources à un serveur mais par un serveur envoyant régulièrement des mises à jour à des clients sans sollicitation active. 

MQTT est un protocole de communication « Machine à Machine » ou M2M qui opère selon un modèle Publish/Subscribe ce qui permet une grande souplesse dans son implémentation. 

Les clients MQTT peuvent endosser le rôle de publisher, subscriber ou les deux.   

Afin de recevoir les informations dont ils ont besoin, les subscribers s’abonnent à des rubriques ou topics (1), généralement organisés de manière hiérarchique au sein du broker (ex. Maison/Chambre/…). Dès lors qu’un publisher aura émis un message destiné aux abonnés de ce topic (2), ils seront notifiés par le broker (3).    

De ce fait, les clients MQTT ne sont pas contraints de partager un même réseau, ni d’être actifs au même moment et ne nécessitent pas de synchronisation entre eux.  

Figure 2 – Illustration d’une architecture MQTT simplifiée 

Par ailleurs, MQTT propose un mécanisme de « Qualité de Service » de ses messages permettant d’adapter les communications aux exigences de l’application. Il est ainsi capable, par exemple, de garantir la livraison des messages en cas de connexion instable. Les clients MQTT peuvent sélectionner un niveau parmi trois de « QoS » pour la distribution de leurs messages : 

• QoS 0 « Au plus une fois » – Le message sera distribué une fois ou pas distribué du tout, sans accusé de réception. 
• QoS 1 « Au moins une fois » – Le message sera distribué périodiquement tant que l’expéditeur n’aura pas reçu d’accusé de réception. 
• QoS 2 « Une seule fois » – Le message est garanti d’être distribué et une seule fois. 

Le niveau de « QoS » choisi a également une incidence sur la durée de stockage du message localement auprès de l’expéditeur et du destinataire. 

Cette architecture permet d’établir des communications décentralisées et extensibles (scalable). Ces caractéristiques s’avèrent particulièrement avantageuses dans le domaine de l’IoT où la flexibilité est essentielle pour répondre à la diversité des cas d’usage. Elles expliquent également pourquoi MQTT dépasse largement le cadre de l’IoT et trouve des applications dans de nombreux autres environnements tels que la télémétrie et la surveillance industrielle. 

MQTT est-il vulnérable ? 

A l’instar de nombreux autres protocoles de communication, MQTT n’est pas sécurisé par défaut. Bien que la plupart de ses implémentations intègrent à présent des solutions de sécurité robustes, certaines faiblesses et erreurs de configurations persistent, rendant les systèmes vulnérables. 

Pour souligner ces notions, nous nous intéresserons à un exemple standard d’utilisation de ce protocole en milieu industriel. 

Figure 3 – Illustration d’un exemple d’utilisation industrielle de MQTT 

Dans ce scénario, tous les systèmes représentés contiennent un client MQTT permettant de souscrire ou de s’abonner à des topics et de communiquer avec le broker « on-premise ». Les communications MQTT ne sont pas chiffrées et il n’y aucune authentification du broker ou des clients, laissant la possibilité à un attaquant d’accéder aux données de production échangées en clair ou de transmettre des ordres aux équipements en usurpant l’identité du broker ou de l’un de ces clients. 

Comment se protéger ? 

Pour se protéger efficacement contre ces risques, le broker et les clients MQTT doivent être déployés et configurés avec vigilance. Nous proposons ici différentes étapes de sécurisation afin d’assurer la confidentialité, l’intégrité, l’authenticité et la disponibilité des communications de bout en bout. 

Sécurisation du broker MQTT 

Activation du chiffrement par défaut des communications 

Lorsque le port 8883 est l’unique port MQTT défini, les tentatives de communication non-chiffrées sur le broker sont rejetées. Par ailleurs, il est essentiel que le broker ait accès à un certificat ainsi qu’une clé privée valides et que la suite cryptographique utilisée soit sécurisée (par exemple TLS 1.2 ou 1.3).  

Figure 4 – Activation du chiffrement sur un broker MQTT Mosquitto par le biais d’un fichier de configuration 

De nombreux dispositifs IoT ont une faible capacité de calcul et peu de ressources, ajouter des mécanismes tels que TLS peut représenter une surcharge importante. 

Mise en place d’une authentification des clients et d’un contrôle de leurs droits d’accès 

MQTT permet l’authentification des clients se connectant à un broker, via des méthodes courantes telles que l’utilisation d’un nom d’utilisateur et d’un mot de passe (avec un fichier de mot de passe associé) et la vérification du certificat du client, validé par une autorité de certification (le broker devant disposer du certificat de cette autorité). Certains brokers permettent également l’utilisation de solutions d’authentification externes. 

Afin de restreindre l’abonnement ou la publication sur certains topics par les clients, une logique d’Access Control List ou ACL peut être ajoutée.

Figure 5 – Ajout d’une authentification par certificat et mot de passe avec un contrôle d’accès sur un broker MQTT Mosquitto 

Une gestion rigoureuse des topics est essentielle pour prévenir les fuites de données et limiter les risques de compromission du broker. L’utilisation des wildcards # et + doit être attentivement surveillée, car une configuration trop permissive permettrait à un attaquant d’accéder à tous les échanges en cours. 

Déploiement de mesures de protection du broker  

Une rapide recherche sur le moteur Shodan révèle l’exposition de milliers de brokers MQTT sur Internet souvent laissés dans leur configuration par défaut, dont les utilisateurs ignorent l’existence ou les implications. Il est donc primordial de protéger le broker de menaces à la fois internes et externes en appliquant de bonnes pratiques de sécurité, telles que la mise à jour régulière du système ou la restriction du nombre de requêtes et connexions simultanées, pour prévenir les attaques par déni de service et garantir sa disponibilité. 

Sécurisation des clients MQTT 

Activation du chiffrement des communications 

Afin de se connecter sur le broker, les clients devront utiliser le port 8883 et posséder un certificat ainsi qu’une clé privée valides auquel cas la connexion sera rejetée.   

Figure 6 – Connexion chiffrée sur un client MQTT Paho 

L’utilisation de certificats auto-signés pour la connexion au broker est fortement déconseillée car ces derniers peuvent être facilement substitués. 

Mise en place d’une authentification du broker (authentification mutuelle) 

En plus de l’authentification des clients, MQTT permet l’authentification du broker via la vérification de l’autorité de certification ayant signé son certificat, assurant ainsi une authentification mutuelle (mTLS) et la sécurité des communications. 

Figure 7 – Authentification du broker sur un client MQTT Paho 

Déploiement de mesures de protection du client 

En cas de compromission d’un client MQTT, un attaquant pourrait accéder à des nombreuses informations en fonction de la configuration du broker ciblé. C’est pourquoi les clients et leurs secrets doivent aussi être protégés par l’application de bonnes pratiques de sécurité sur la machine hôte du client et sur le contenu des échanges (ajout de mécanismes anti-rejeu sur les requêtes par exemple).  

Quel futur pour MQTT ? 

Malgré sa maturité, MQTT demeure un protocole en évolution et intègre progressivement des fonctionnalités innovantes afin de répondre aux exigences croissantes des environnements connectés. Dans un contexte où la demande pour des communications fiables, sécurisées et à faible consommation d’énergie ne cesse d’augmenter, il est vraisemblable que les cas d’utilisation de MQTT continueront de se multiplier au cours des années à venir.

Cet article La sécurité du protocole MQTT est apparu en premier sur RiskInsight.

RSSI, DSI et équipes DevSecOps s’interrogent tous sur la manière de le mettre en pratique et de l’exploiter.

Qu’est-ce que le SBOM et dans quel contexte intervient-il ?

Le SBOM (Software Bill of Materials) est un inventaire formel, généralement au format Xlsx, JSON, XML ou texte brut, qui est conçu pour être lu par des machines. Il contient des informations détaillées sur les composants logiciels d’un système, y compris leurs dépendances, leurs attributs et leurs relations hiérarchiques. L’objectif principal d’un SBOM est de fournir une vue complète et à jour de tous les éléments logiciels qui composent une application ou un système. (source : NTIA-Software-Bill-Of-Materials)

À l’instar d’un produit physique, un logiciel est un ensemble complexe composé de divers éléments. Il comprend du code développé en interne, des composants tiers (qu’il s’agisse de bibliothèques open source ou de modules soumis à différentes licences) ainsi que l’ensemble des outils nécessaires à l’assemblage du produit final.

Or, à chaque nouvelle vulnérabilité découverte par des chercheurs ou exploitée par des hackers, les fournisseurs et acheteurs, se retrouvent confrontés à une question cruciale : où se situent les éventuelles vulnérabilités critiques au sein de leur produit ?

Aujourd’hui, l’analyse de Wavestone atteste de manière formelle que le SBOM est indéniablement un élément essentiel pour résoudre cette problématique.

Méthodes de génération du SBOM

Une analyse technique approfondie des outils disponibles sur le marché a révélé les méthodes de génération des SBOMs (Software Bill of Materials).

Trois sources principales émergent pour créer un SBOM à partir d’un logiciel :

• Code Binaire (compilé)
• Code source du projet
• Conteneur d’image, généré par des plates-formes telles que Docker.

Ces trois sources ont la capacité de produire un fichier conforme aux standards établis, notamment SPDX et CycloneDX. Cependant, il est essentiel de noter que tous les outils ne prennent pas en charge ces trois entrées de manière uniforme.

Le défi technique réside, par exemple, dans la décompilation du code binaire, qui peut parfois entraver son intégration. Dans de tels cas, la recherche d’indicateurs spécifiques préalablement définis au sein du code s’avère être une méthode efficace pour identifier la majeure partie des interdépendances hiérarchiques dans un format approprié.

Types d’entrées pour la génération d’un SBOM

Malgré ces techniques d’extraction et d’analyse de code, l’exhaustivité des données n’est pas pour autant garantie et une vérification additionnelle doit être considérée.

Une génération facilitée mais une exploitation qui reste à déterminer et pose encore de nombreuses questions

La création d’un SBOM, s’est considérablement simplifiée grâce à la présence d’acteurs majeurs spécialisés sur le marché, tels que Dependency Track, Adolus ou encore Fossa, pour n’en nommer que quelques-uns. De plus, les outils d’Analyse de Composition Logicielle SCA, bien établis au sein des équipes de développement de nos clients offrent désormais la possibilité de générer et de lire un SBOM.

Sa génération n’est aujourd’hui plus un défi majeur, en raison de la mise en œuvre des standards énumérés plus haut. Ils facilitent la génération automatisée du SBOM en fournissant des directives claires sur la manière dont les informations sur les composants doivent être structurées et présentées.

Cependant, les systèmes conçus pour l’analyser ne sont pas encore pleinement matures. Par exemple. Les entreprises qui reçoivent ces inventaires se trouvent souvent confrontés à des questions sur la manière de les utiliser et de les partager avec d’autres parties. Par ailleurs, à cette problématique technique s’additionne des problématiques organisationnelles car le cadre d’utilisation entre organisations n’est pas encore clairement défini.

Néanmoins, des acteurs travaillent activement à mettre en place une architecture d’intégration sécurisée de ces SBOM au sein de leurs pipelines CI/CD. Actuellement, la récupération fiable du SBOM d’un tiers reste un défi. Les préoccupations sur l’échange et le partage émergent dès que l’on aborde ce sujet. La diversité des contrats avec les fournisseurs, qui souhaitent protéger leur propriété intellectuelle, et la difficulté de centralisation posent des défis au contenu de ce type d’inventaire. Chaque inventaire est élaboré de manière hétérogène, sans suivi ni cadre réglementaire uniforme imposé. D’un point de vue technique, chaque entité a la liberté de remonter les informations de son choix.

A date, nous constatons que les pionniers dans le domaine, optent pour la génération interne de leurs SBOM, y compris sur les logiciels tiers. Cette approche offre davantage de contrôle sur la qualité et la spécificité des données, soulignant la nécessité d’une réglementation plus détaillée et de normes plus strictes pour assurer la fiabilité des échanges d’inventaires logiciels.  

Le SBOM intégré au cœur de vos processus logiciels

Toutes ces lacunes ont incité à concevoir un processus optimal à l’état théorique pour le moment, afin d’intégrer un SBOM au sein d’un pipeline CI/CD, processus pouvant être décomposé en quelques étapes.

1. Création d’un espace de génération et de collecte du SBOM, en Automatisant la collecte de ces données pour garantir leur précision et leur exhaustivité ;
2. Stockage des SBOM dans un Répertoire, en Configurant un référentiel centralisé pour stocker tous les SBOM générés. Il peut s’agir d’un référentiel de gestion de versions ou d’un système de stockage de données adapté ;
3. Distribution d’un Paquet SBOM sur Demande d’un Client, en s’assurant que les SBOM sont facilement accessibles et que les clients peuvent les récupérer de manière sécurisée.

Projection sur l’intégration d’un SBOM au sein d’une chaîne d’approvisionnement logiciel

Cette prospective théorique ouvre la voie à une automatisation du processus de génération, stockage et diffusion des inventaires et rapports de vulnérabilité.

Cela offrira aux parties prenantes la capacité de :

• Recevoir en temps réel des SBOM et des rapports de vulnérabilité ;
• Authentifier la légitimité des artefacts reçus (conteneurs d’images, documents, etc..) ;
• Etablir une confiance et une validation par le bais de la transparence au cœur du processus de production logicielle.

Un futur radieux pour le SBOM ?

 Les instances politiques prennent conscience du niveau d’impréparation de leurs infrastructures face à la montée en puissance des cyberattaques. Dans ce contexte, le SBOM est de plus en plus considéré comme un moyen efficace d’accroître la réactivité en matière de vulnérabilités susceptibles d’affecter un grand nombre d’entreprises de manière concomitante.

Même si le marché n’est pas encore tout à fait prêt pour une transition vers une utilisation généralisée de cette solution, il est courant que la réglementation, même si elle peut sembler arbitraire, influence profondément la trajectoire dans une nouvelle direction.

Il est probable que l’Europe finira par converger vers la réglementation établie aux États-Unis, même si celle-ci semble encore être à un stade préliminaire et incomplet, en particulier en ce qui concerne les mécanismes de partage et d’échange de ces inventaires.

Dans le contexte actuel, les acteurs concernés se voient contraints de réévaluer leurs critères de priorité. Il sera important de disposer des données sur la composition des logiciels, l’origine de ses composants, leur provenance, les vulnérabilités connues, et d’avoir confiance dans le processus de production et de contrôle de qualité.

Cependant, il est nécessaire de remettre à l’ordre du jour la série de défis auxquels ils se confrontent plus généralement :

• Données lacunaires ou incomplètes, l’absence de données exhaustives sur la composition des logiciels peut rendre difficile l’évaluation des risques.
• Approches ad hoc pour le partage de données, les méthodes non standardisées et les approches improvisées pour le partage d’informations peuvent rendre la communication inefficace et peu fiable.
• Coûts additionnels pour la collecte et la maintenance des données, la collecte, la vérification et la mise à jour des informations sur la composition des logiciels peuvent engendrer des surcoûts ;
• Absence de standardisation, le manque de normes dans la collecte et le partage des données rend difficile la comparaison et l’analyse des informations entre les différentes parties prenantes ;
• Gouvernance et confidentialité des données, La gestion des données sensibles sur la composition des logiciels soulève des préoccupations quant à leur confidentialité, intégrité et disponibilité

Cet article Pourquoi le SBOM est considéré comme un allié indispensable de la sécurité de vos produits ? est apparu en premier sur RiskInsight.

Azure, ces dernières années, s’impose de plus en plus dans ce secteur, comme a pu le souligner le Gartner, qui les classe dans les leaders visionnaires des plateformes IIoT [1] en raison de ses capacités, et de sa couverture quasiment complète de tous les cas d’utilisation et secteurs d’activité.

L’IoT, par nature souvent largement exposé, voire sur Internet, peut-être la cible d’attaques.

Avant de passer à des recommandations spécifiques pour protéger vos dispositifs IoT et vos données, examinons comment les différents services d’Azure IoT peuvent être utilisés ensemble pour créer des solutions IoT sécurisées.

Présentation de l’offre Azure IoT

Microsoft Azure IoT est une plateforme de bout en bout pour la connectivité, l’analyse et la visualisation de données provenant d’appareils IoT. Elle offre également une interconnexion avec les autres services standards d’Azure comme Azure Machine Learning ou encore Azure SQL Database.

Azure IoT propose deux écosystèmes de solutions à ses clients :

• Azure IoT Central est une aPaaS, application Platform as a Service, entièrement managée qui simplifie la création de solutions IoT. Ce service est responsable de connecter, gérer et exploiter des flottes d’appareils, et fournit à une interface utilisateur de gestion. Azure IoT Central est en réalité un agrégat de différents services Azure IoT comme Azure IoT Hub ou encore Azure IoT Hub Device Provisioning Service (DPS).

Azure IoT Central propose des modèles d’application selon plusieurs domaines d’activité : Retail, Santé, Energie, Industrie, etc., et vise une mise en œuvre « clés en main ».  

• Un écosystème personnalisé grâce aux différents services PaaS, Platform as a Service, d’Azure. Dans cet écosytème, deux services ; Azure IoT Hub et Azure Digital Twins sont les fondations d’une solution IoT. Nous les avons également combinés à Azure Device Provisionning et Azure Device Update pour une couverture des besoins cybersécurité optimale.

Ces deux écosystèmes permettent à Azure de répondre à tous types de besoins IoT et IIoT :

• Azure IoT Central est un très bon service si vous souhaitez développer rapidement une application peu complexe grâce à son catalogue de modèle d’application.
• Si vous souhaitez une solution personnalisée, ou avec des fonctionnalités non supportées par Azure IoT Central : optez pour un écosystème fondé sur Azure IoT Hub.

Maintenant que nous avons une bonne compréhension des écosystèmes d’Azure IoT, il est important de se concentrer sur la sécurisation de ces écosystèmes. Comment protéger efficacement des dispositifs IoT et des données lors de l’utilisation des services Azure IoT ? C’est ce que nous allons étudier dans les prochaines parties.

Préambule : l’outil Azure CLI

Afin de gérer des ressources Azure, Microsoft met à disposition plusieurs outils, la plupart étant utilisables en CLI (Command Line Interface, ou en lignes de commandes). L’outil proposant le plus de fonctionnalités pour la gestion étant Azure CLI.

Cet outil, disponible pour les systèmes d’exploitation de type Windows et UNIX, permet notamment à un utilisateur membre d’un environnement Azure de gérer et d’obtenir des informations concernant des ressources Azure. Il est à noter que l’éventail des possibilités de cet outil varie en fonction des droits que possède l’utilisateur sur les ressources en question.

Pour l’installer, Microsoft met à disposition une page dédiée expliquant les étapes pour tout type d’environnement.

Afin de l’utiliser, il suffit de se connecter à un compte utilisateur Azure via l’interface de commande choisie (Powershell ou Bash), puis d’entrer les commandes voulues. Lorsque l’utilisation de cet outil est terminée, une déconnexion du compte est recommandée.

Une utilisation classique de cet outil est présentée ci-dessous :

La documentation de cet outil, présentant et expliquant l’ensemble des commandes possibles, est disponible à cette adresse.

Cet outil sera utilisé par la suite lors d’exemple de manipulations techniques.

1^er vecteur de sécurisation : authentification des objets

L’authentification des appareils est cruciale pour une infrastructure Azure car elle permet de garantir que seuls les dispositifs autorisés puissent accéder aux ressources Cloud. Les services Azure IoT supporte deux principaux moyens d’authentification pour les dispositifs IoT :

• Un Jeton SAS (Shared Access Signature, ou SAS Token en anglais) est une chaine de caractères permettant d’authentifier des appareils, ainsi que des services. Un jeton SAP à la structure suivante :

Ce type d’authentification a une durée de validité définie et des permissions, qui lui sont attribué à partir d’une stratégie d’accès, sur un périmètre donné. La signature, quant à elle, est un élément crucial car elle est responsable de garantir la sécurité des communications entre l’objet et les services Azure, mais également de prouver l’identité du dispositif. Cette signature est générée à partir d’un secret qui doit être propre à chaque appareil.

• Un certificat X.509 [2] est un certificat numérique permettant une authentification forte de l’objet. Il contient des informations sur l’entité émettrice du certificat, la durée de validité du certificat mais également l’identité du sujet (par exemple : l’objet). L’une des forces des certificats est la capacité à pouvoir créer des chaines de certificats, et ainsi créer des relations de confiance:

En termes de sécurité, les certificats X.509 offrent un niveau de sécurité plus élevé, en supposant un algorithme cryptographique à l’état de l’art, car ils permettent de représenter des relations de confiance. Cependant, la gestion et l’utilisation des certificats peut impliquer une complexité supplémentaire pour un projet IoT.

Afin de forcer l’utilisation des certificats X.509 pour authentifier des objets connectés, il est possible d’interdire les jetons SAS pour un IoT Hub. En effet, les IoT Hubs d’Azure possèdent trois propriétés liées à l’utilisation ou non des jetons SAS :  disableLocalAuth, disableDeviceSAS et disableModuleSAS. Par conséquent, la bonne pratique associée à l’interdiction des jetons SAS passe par l’attribution de ces trois paramètres à True. Cette manipulation peut être réalisée à l’aide de l’outil Azure CLI :

La vérification des valeurs de ces mêmes paramètres peut également être réalisée à l’aide d’Azure CLI :

Dans l’exemple de réponse ci-dessous, la propriété disableDeviceSAS a été correctement paramétrée, ce qui n’est pas le cas des deux autres.

Le portail d’Azure permet également d’effectuer cette vérification :

Le choix du moyen d’authentification pour Azure IoT dépendra des exigences de sécurité de votre solution. Si vous avez besoin d’une sécurité élevée et que vous avez une infrastructure pour gérer les certificats, alors l’authentification par certificat X.509 est une bonne option. Cependant, si vous recherchez une solution simple à gérer et à utiliser, le jeton SAS pourrait être plus adapté à vos besoins.

2^ème vecteur de sécurisation : RBAC et alertes

L’assignement des rôles sur votre infrastructure Azure IoT doit être réfléchi et défini selon les besoins des utilisateurs. Une définition de rôles et de permissions précise permet de limiter l’accès aux ressources et aux divers fonctionnalités disponibles sur la plateforme. Les différents services Azure IoT fournissent une multitude de rôles préconfigurés qui peuvent être adaptés à vos besoins et à votre organisation. Ensuite, appliquer le principe du moindre privilège, et limiter le nombre de comptes disposant de privilèges importants, permet d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Azure CLI permet notamment de lister les utilisateurs possédant des droits sur la ressource Azure IoT souhaitée, ainsi que leurs rôles associés. La commande suivante permet de réaliser cette action :

Il est possible d’utiliser des sélecteurs de chaînes de caractères (Select-String pour Powershell, grep pour Bash) afin de ne récupérer que les informations souhaitées.

Dans l’exemple ci-dessous, les noms, types et rôles ont été les seuls éléments récupérés à l’aide de Select-String :

La fonction des rôles intégrés Azure est disponible à cette page.

De plus, la configuration d’alertes basées sur les métriques de vos services Azure IoT est un autre outil à prendre en compte. Des alertes peuvent être configurées pour détecter des comportements suspects ou des anomalies, et ainsi permettre une investigation rapide sur votre infrastructure. Azure met à la disposition de ses clients une large collection de signaux permettant de définir des conditions d’alertes. Il est également possible de définir des signaux d’alertes customisés via le langage de requête utilisé par Azure Log Analytics.

Le Portail Azure est le moyen le plus facile pour mettre en place des alertes basées sur les données collectées par le IoT Hub. Par exemple, pour définir une règle d’alerte de journal, il faut :

1. Aller sur la page de management du IoT Hub souhaité ;
2. Aller dans la sous-catégorie Logs de la catégorie Monitoring;
3. Choisir une règle en utilisant le langage de Azure Log Analytics ;
4. Ajouter une règle d’alerte liée à cette requête ;
5. Choisir l’opérateur, l’unité, la valeur seuil, la récurrence de vérification et la période concernée par la règle.

Ces actions sont résumées par les captures d’écran ci-dessous :

Il suffira ensuite de choisir un groupe d’action lié à un type d’action (envoi de mail, de SMS, etc.).

L’exemple donné entrainera une action si le nombre de connexions échouées d’objets connectés à l’IoT Hub concerné dépasse les 10 échecs en 10 minutes ou moins.

En complément, un guide détaillé prenant la forme d’un tutoriel est disponible sur la documentation Azure. Il est à noter que ce service est payant en supplément.

3^ème vecteur de sécurisation : le service en lui même

Enfin, la mise en place d’une configuration adéquate des services Azure IoT est un autre élément clé pour améliorer le niveau de maturité cyber de la plateforme. Cela inclut des options telles que par exemple les règles de routage ou encore paramétrer la version minimum de TLS utilisé par les appareils pour se connecter sur Azure IoT Hub.

Les règles de routage sont utilisées pour rediriger les messages des appareils IoT vers un point de terminaison (stockage, services, base de données, etc.) et sont paramétrables par des requêtes de routage. Il est recommandé de filtrer les messages entrants, via les requêtes de routage, afin d’augmenter la sécurité de votre solution IoT.

La vérification de la version minimale de TLS acceptée peut être faite à l’aide d’Azure CLI : en effet, un IoT Hub possède l’attribut minTlsVersion permettant de contrôler cette propriété. Cette vérification est réalisée à l’aide de la commande suivante :

Si cette commande ne retourne rien, ou retourne une valeur inférieure à 1.2, alors la configuration n’est pas satisfaisante.

Le portail d’Azure permet également d’effectuer cette vérification :

En synthèse

La sécurité est un enjeu majeur pour les projets IoT : Microsoft, avec son produit Azure IoT, fournit une plateforme IoT répondant à une majorité des besoins IoT, et ce de manière sécurisée, sous couvert d’en faire la bonne configuration. Au cours de cette article, nous avons abordé des recommandations permettant d’améliorer le niveau de sécurité de votre infrastructure Azure IoT.

Il est important de garder en tête que d’autres vecteurs d’attaques existent, tels que les vulnérabilités matérielles et logicielles ainsi que les réseaux utilisés par les dispositifs IoT.  En somme, la sécurité d’une infrastructure IoT est un défi complexe qui nécessite une approche de bout en bout.

Avec la participation de Marius ANDRE

[1] “Magic Quadrant for Global Industrial IoT Platforms”

https://www.gartner.com/doc/reprints?id=1-2BQFX3BJ&ct=221116&st=sb

[2] “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”

https://www.rfc-editor.org/rfc/rfc5280

Cet article Améliorer la sécurité de son infrastructure IoT : conseils de configuration et bonnes pratiques sur Azure IoT est apparu en premier sur RiskInsight.

Dans cet exemple, nous supposerons que vous êtes un fabricant de machine à café. Votre projet actuel est de développer une machine à café connectée pour vos entreprises clientes. Vous avez identifié plusieurs cas d’utilisation pour cette machine IoT. Par exemple, elle permet de commander automatiquement de nouvelles capsules de café lorsque le stock atteint un certain seuil. Un deuxième cas consiste à ce qu’elle envoie des alertes automatiques à vos serveurs lorsque des actions de maintenance telle que le nettoyage et les réparations sont nécessaires. Enfin, elle offre également des fonctionnalités de suivi des consommations.

Comment choisir le réseau qui répond le mieux à vos besoins ? Quelles questions devriez-vous vous poser ? Comment faire le bon choix tout en considérant la sécurité globale de votre système ?

Première étape – Définir les besoins de votre entreprise et effectuer une analyse des risques

Tout d’abord, vous devez identifier les exigences de votre réseau IoT, qui sont doubles : les exigences fonctionnelles et de sécurité. Nous caractérisons ces exigences par des niveaux de 0 à 3, 0 étant le niveau le plus bas et 3 le plus élevé.

En ce qui concerne les exigences fonctionnelles, vous devez répondre à des questions telles que :

1. Quelle distance le signal de l’objet doit-il atteindre ?
2. De quelle largeur de bande avez-vous besoin ?
3. Quelle est l’autonomie de votre objet ?

Dans notre exemple, nous supposons que vos machines à café connectées seront distribuées à des entreprises clientes opérant sur une vaste zone géographique (c’est-à-dire dans un rayon de plus de 100 km). Par conséquent, vous aurez besoin d’une large couverture pour permettre aux différentes machines répandues de vos clients de communiquer avec votre système d’information.

Deux cas de figure sont présentés ici. Si votre client accepte de connecter votre machine à son réseau local existant, vous n’aurez alors qu’à utiliser un réseau sans fil à courte portée entre la machine et la passerelle internet. S’il refuse de le faire, vous devrez alors mettre en place un réseau longue portée car vous déploierez votre service et vos machines sur une vaste zone.

En ce qui concerne la bande passante, une petite quantité sera nécessaire, car il suffit de pouvoir envoyer de petits paquets de données quelques fois par jour au maximum (commandes de capsules, alertes, état général, …).

En ce qui concerne la consommation d’énergie, une machine à café est traditionnellement connectée à une prise électrique pour accomplir ses tâches ; ainsi, la machine IoT est constamment alimentée en électricité, et par conséquent l’autonomie de l’objet n’est donc pas une contrainte. En résumé, il n’y a pas d’exigence de consommation d’énergie en soi car elle est déjà couverte par le raccordement de la machine à café au réseau électrique.

Nous résumons les niveaux des exigences fonctionnelles comme suit :

• Portée (P) = 3 ou 1
• Bande passante (B) = 1
• Consommation énergétique (E) = 0

Après la définition des exigences fonctionnelles, une analyse des risques doit être effectuée pour formuler les exigences de sécurité de votre projet en termes de disponibilité, d’intégrité, de confidentialité et de traçabilité.

Une perte de disponibilité se produirait en cas de dysfonctionnement de la machine à café connectée, qui la rendrait inutilisable pour un client. Une perte d’accès au réseau ou l’indisponibilité des serveurs backend ne doit jamais entraîner l’indisponibilité de la machine : elle doit continuer à fonctionner hors réseau. Toutefois, si un dysfonctionnement de la machine se produit, il faudrait qu’il soit signalé le plus rapidement possible par le réseau afin que des actions de maintenance soient déclenchées.

En combien de temps cela devrait-il être fait ? La réponse est plusieurs heures plutôt que plusieurs jours, car nous ne voudrions pas priver les employés de leur pause-café ! Par conséquent, 4 à 24 heures est une fenêtre d’indisponibilité acceptable qui correspond à un niveau d’exigence de disponibilité égal à 2.

Une perte d’intégrité entraînerait une corruption des données. Par exemple, un excès potentiel dans une commande de capsules de café peut se produire en modifiant les messages envoyés par la machine à café ou en rejouant plusieurs fois la même commande. Dans les deux cas, cela entraînerait une perte financière pour votre client. En effet, ces données doivent être communiquées par le réseau de manière rigoureuse et exacte. Nous pouvons donc conclure qu’il s’agit d’une exigence d’intégrité de niveau 3.

Une perte de confidentialité entraînerait la divulgation des données ; les quantités des commandes sont des données plutôt sensibles qui ne devraient pas être partagées avec des tiers. Il faut s’assurer que les données soient communiquées de manière sécurisée sur le réseau et qu’elles ne sont pas accessibles par des parties externes.  Par conséquent, nous concluons que la confidentialité a un niveau d’exigence de 2.

Concernant la traçabilité, pour des raisons de simplification, nous choisissons de laisser cet aspect de côté en considérant qu’il est déjà pris en compte par l’étude des 3 premiers critères.

En résumé, l’analyse de risque conclut aux exigences de sécurité suivantes :

• Disponibilité (D) = 2
• Intégrité (I) = 3
• Confidentialité (C) = 2

Pour plus de détails sur la méthodologie d’analyse de risque pour les objets intelligents, nous vous invitons à consulter cet article.

A la fin de cette analyse, vous obtenez pour vos deux cas d’usage un diagramme radar représentant les niveaux de vos exigences opérationnelles, comprenant les exigences fonctionnelles et de sécurité.

Cas n°1 : votre client connecte la machine à café à son réseau local

Cas n° 2 : votre client ne connecte pas la machine à café à son réseau local

Bien qu’ils ne soient pas abordés dans cet article, les aspects financiers sont également importants et dépendent de divers facteurs tels que le modèle de tarification des opérateurs de réseau. Il en va de même pour les contraintes géographiques, car certains réseaux IoT peuvent ne pas être disponibles dans certaines régions.

Enfin, la facilité de configuration du réseau peut être incluse dans vos exigences fonctionnelles, surtout si votre objet connecté vise un public B2C.

Deuxième étape – Choisir votre réseau IoT

Sur la base des exigences fonctionnelles et de sécurité, nous avons élaboré une méthodologie qui permet de choisir le réseau optimal afin de répondre à vos besoins fonctionnels et de sécurité : portée, bande passante, consommation d’énergie, disponibilité, intégrité, confidentialité.

Les trois exigences fonctionnelles sont obligatoires, c’est-à-dire que le réseau que vous choisissez doit absolument les satisfaire, autrement, il sera écarté.

Pour les exigences de sécurité, l’évaluation nécessite une analyse préemptive. Entre deux réseaux qui couvrent les mêmes exigences fonctionnelles, vous devez choisir celui qui offre le meilleur niveau de sécurité avec le coût minimum.

Si un réseau ne répond pas à l’une des exigences de sécurité, vous devrez mettre en place un dispositif de sécurité supplémentaire dans le cadre de votre projet, ce qui augmentera vos coûts.

Vous devez également veiller à ce que la mise en œuvre supplémentaire n’affecte pas les performances du système. Par exemple, si vous mettez en œuvre le chiffrement des données au niveau de la couche applicative, l’augmentation des temps de traitement aurait un impact négatif sur votre débit de données maximum ou pourrait être limitée par les capacités matérielles du dispositif, avec un impact financier potentiel en cas de mise à niveau du matériel. Par conséquent, l’une de vos exigences fonctionnelles pourrait ne plus être satisfaite.

Si une haute disponibilité est requise (A=3), vous devriez choisir un réseau robuste de par sa conception qui répondra à vos besoins de temps réel.

En effet, les protocoles à spectre étalé (comme Bluetooth ou ZigBee) ou modulés par saut de fréquence (comme Sigfox ou Bluetooth) sont plus résistants au brouillage radioélectrique ou aux interférences radio.

Ces types de réseaux sont particulièrement recommandés lorsque la disponibilité est une exigence importante, comme sur une chaîne de production industrielle.

En outre, les protocoles maillés sont connus pour être plus fiables et plus évolutifs que les protocoles point à point. Toutefois, pour qu’ils soient efficaces, ils doivent être utilisés dans un contexte où plusieurs dispositifs connectés sont reliés entre eux. Les protocoles maillés comme WirelessHART peuvent également garantir des communications en temps réel. Leur utilisation est particulièrement adaptée à un contexte industriel.

Une méthodologie simple pour choisir le bon réseau consiste à confronter les exigences opérationnelles de votre entreprise aux caractéristiques fonctionnelles et de sécurité du réseau.

Dans les diagrammes radar suivants, nous présentons différents types de réseaux IoT offrant différents niveaux fonctionnels et de sécurité, et nous comparons chacun d’entre eux à vos exigences opérationnelles.

Cas n°1 : votre client connecte la machine à café à son réseau local

Cas n° 2 : votre client ne connecte pas la machine à café à son réseau local

Appliquons la méthodologie évoquée précédemment dans les 2 cas de figure. Tout d’abord, nous utilisons les diagrammes radar ci-dessus pour voir quels réseaux sont conformes à vos exigences fonctionnelles.

Cas n°1 : votre client connecte la machine à café à son réseau local

Dans ce cas, Bluetooth et Wi-Fi sont deux options viables à courte portée si votre client connecte la machine à son réseau local. D’une part, Bluetooth répond à toutes les exigences de sécurité, mais il est moins simple à mettre en œuvre que le Wi-Fi. D’autre part, le Wi-Fi répond à toutes les exigences, à l’exception de la disponibilité, mais nous pouvons y remédier grâce à des accords de niveau de service (SLA).

Cas n°2 : votre client ne connecte pas la machine à café à son réseau local

Dans ce cas, Zigbee, BLE et Wi-Fi sont clairement hors de l’équation car ils ne répondent pas aux exigences de portée. Cependant, LoRa, LTE-M et Sigfox sont des candidats potentiels.

Nous utilisons à nouveau les diagrammes radar, cette fois pour évaluer la conformité de ces trois candidats aux exigences de sécurité.

Sigfox ne répond pas à l’une de vos exigences de sécurité (confidentialité) alors que LoRa répond à toutes les exigences de sécurité. LTE-M est la meilleure offre car elle répond à toutes vos exigences, mais c’est aussi la plus chère. Nous en concluons que la LoRa est un candidat relativement bon.

En conclusion, vous disposez d’une part une option adéquate qui est LoRa et qui nécessitera le déploiement d’un nouveau réseau, et d’autre part d’une option alternative utilisant un réseau Wi-Fi préexistant. Il est à noter que votre client peut refuser de connecter la machine à café à son réseau Wi-Fi pour des raisons de sécurité.

Nous allons envisager un nouveau scénario dans un prochain article : une entreprise cliente achète la machine et discute de quelle option utiliser LoRa ou Wi-Fi.

Cet article Brancher sa cafetière connectée: oui, mais comment? est apparu en premier sur RiskInsight.

QU’EST-CE QU’UNE ANALYSE DE RISQUE CYBER?

Vous êtes-vous déjà demandé ce qui se passerait si un appareil que votre entreprise a mis au point et qu’elle vend divulguait les données qu’elle recueille ? Ou si ces données étaient corrompues ou soudainement rendues indisponibles ? Qu’est-ce qui serait le plus préjudiciable ? Et si votre solution était vulnérable à une cyberattaque ? Les conséquences pourraient-elles être une prise de contrôle d’un ou de plusieurs appareils qui entraînerait un risque pour la sécurité, comme un bâtiment qui prendrait feu ou même une victime humaine ? Ou peut-être s’agirait-il « seulement » d’une attaque pivot sur le réseau de votre client qui entraînerait une incapacité totale de fonctionnement de votre entreprise et de celle de votre client.

Si vous êtes en train de développer une solution IoT et que vous ne faites pas de dépression nerveuse en envisageant de telles possibilités, vous vous demandez probablement pourquoi votre RSSI (Responsable de la Sécurité des Systèmes d’Information) n’en fait pas une.

C’est probablement parce que votre RSSI a une méthode : il considère chaque risque d’un point de vue impartial et de manière comparable. La première étape importante consiste à s’assurer que chaque risque est correctement évalué (c’est-à-dire qu’il n’est ni surestimé, ni sous-estimé) et à partager les résultats de cette évaluation avec toutes les parties prenantes du projet. Une fois que toutes les parties prenantes se sont mises d’accord sur chaque risque, votre entreprise dispose d’une base adéquate pour décider des mesures de contrôle à implémenter.

Cette approche ne signifie pas que vous devez traiter tous les risques au point que votre solution soit pratiquement impossible à mettre en œuvre. D’ailleurs, c’est techniquement impossible, et votre budget disparaîtrait bien avant d’avoir atteint une solution dite de risque zéro. Chaque mesure de contrôle doit être hiérarchisée et proportionnelle à la probabilité et à la gravité du risque.

Ce que nous avons décrit ci-dessus est connu sous le nom de méthodologie d’analyse des risques. Les professionnels de la cybersécurité utilisent cette méthodologie comme base de référence pour les initiatives de leur entreprise en matière de cybersécurité. Les professionnels évaluent les scénarios de risque (souvent liés à la disponibilité des services, à l’intégrité des données, à la confidentialité et/ou à la traçabilité des actions) et les impacts sur l’image de marque de leur entreprise, les responsabilités légales, les conséquences sur la sécurité et bien sûr les résultats financiers. Plus le risque est évalué, plus la priorité est accordée à la réduction de la probabilité que le risque se produise (par exemple, ajouter des barrières à une attaque, réduire la surface d’attaque, etc.) ou à la gravité des résultats si le risque se produit (par exemple, appliquer une segmentation pour réduire la propagation d’une attaque).

Si vous voulez en savoir plus sur les méthodes d’analyse des risques existantes, vous devriez commencer par la norme ISO27005, qui a un large champ d’application et de compréhension dans divers secteurs.

Soyez rassuré sur le fait que parler des risques n’augmentera pas la probabilité que le problème se produise (si jamais vous le craigniez), mais ne pas en parler fait courir un grand risque au projet.

EN QUOI L’ANALYSE DES RISQUES D’UN PROJET IOT EST-ELLE DIFFÉRENTE ?

Nous espérons vous avoir convaincu de l’importance de l’analyse des risques de votre projet ; nous verrons comment vous pouvez vous y prendre rapidement dans le prochain chapitre. Avant d’en arriver là, nous allons détailler ce qui rend l’exercice spécifique à un projet IoT: quelles sont les caractéristiques de tels projets et qu’est-ce qui rend l’analyse des risques plus difficile ou plus simple ?

Commençons par les caractéristiques communes qui doivent être prises en compte pour une analyse des risques. Tout d’abord, une initiative IoT repose souvent sur un réseau de matériel très décentralisé (capteurs, passerelles, serveurs, etc.). Ces dispositifs peuvent être répartis sur une vaste zone géographique, parfois dans le monde entier, et sont destinés à rester longtemps sur le terrain avec peu ou pas de maintenance sur place. Il est courant de voir des dispositifs IoT B2B dont la durée de vie dépasse 10 ans (par exemple, un projet de mesure de l’eau pour les entreprises de services publics). Les dispositifs B2C peuvent également viser de telles durées de vie – pensez par exemple aux véhicules connectés. Il convient également de noter que les dispositifs IoT ont généralement des interfaces utilisateur limitées, telles qu’un écran et un clavier. Malgré cela, les boutons, les LED et les applications mobiles permettent les interactions ou les personnalisations nécessaires à l’appareil IoT pour que vous puissiez collecter des données sur le terrain. N’oubliez pas que les données collectées à partir des appareils connectés sont en fait là où réside toute la valeur de tels objets. Ainsi, le fait que ces données soient ou non critiques est essentiel dans l’évaluation des risques. Enfin, nous devons nous rappeler qu’un projet IoT est toujours un projet informatique. Si les dispositifs ne sont pas des ordinateurs portables typiques, les serveurs d’application et le stockage restent centraux dans la plupart des cas. C’est là qu’une grande partie du risque demeure, mais heureusement, il existe de nombreuses bonnes pratiques pour cette partie de la solution également.

Du point de vue de la cybersécurité, ces caractéristiques peuvent rendre les projets IoT plus risqués. Par exemple :

• La sécurité physique d’un réseau décentralisé est très difficile à implémenter. Où sont situés les appareils ? Sont-ils accessibles au public ? Quelqu’un peut-il facilement les voler, les endommager ou les altérer ? Par exemple, un tracker installé sur une palette se déplace à l’extérieur des locaux de confiance et peut être endommagé ou retiré – intentionnellement ou non. Bien entendu, ce risque est amplifié par une empreinte géographique plus large.
• Étant donné les interactions limitées des utilisateurs et la durée de vie plus longue des appareils, leur maintenance peut devenir très coûteuse et longue, surtout si vous devez dépêcher physiquement des techniciens. Une intervention manuelle peut être tout simplement irréaliste, mais même les mises à jour de microprogrammes ont un taux d’échec. Pour toutes ces raisons, les contrôles doivent être pertinents à long terme
• Dans tout projet IoT, la sensibilité des données est un facteur qui doit être pris en compte. Est-ce un facteur critique pour votre entreprise ? Pour les projets de consommation, la sensibilité des données peut être perçue comme très élevée car les appareils collectent des données du monde « réel ».
• Les solutions IoT sont constituées de nombreuses technologies et de nombreux fournisseurs différents. Cela constitue un réel défi : quelles sont les pratiques de sécurité suivies par chacun de ces fournisseurs et ces pratiques couvrent-elles suffisamment les risques identifiés ?
• Enfin, les contrôles de sécurité qui peuvent être appliqués dépendent des capacités des appareils et des logiciels. Par exemple, de nombreux capteurs fonctionnent sur des MCU 8 bits et ne peuvent donc pas exécuter des algorithmes de chiffrement compliqués.

ALORS MAINTENANT, COMMENT PUIS-JE COMMENCER ?

Prenez une grande respiration et impliquez votre RSSI.

Le RSSI doit identifier et évaluer les réglementations applicables, décider du niveau de risque acceptable, fournir des politiques à suivre et des outils pour mettre en œuvre les mesures de sécurité. Peut-être devriez-vous nommer un responsable de la sécurité des produits pour s’occuper spécifiquement de la sécurité de l’IoT dans votre entreprise ou même de la sécurité d’un produit IoT spécifique si les enjeux l’exigent.

Pour atteindre un niveau de sécurité acceptable, il faudra disposer d’une expertise dans les différents domaines de l’IoT. Si vous êtes cet expert, vous devriez probablement être prêt à vous impliquer. Cela amènera toute l’équipe à envisager:

• La sécurité de bout en bout sur la pile technologique : du matériel au cloud, y compris les logiciels intégrés, la connectivité réseau, les applications mobiles, etc.
• La sécurité de bout en bout du point de vue du cycle de vie des appareils. Lorsque vous concevez votre appareil, pensez à toutes les phases : de la fabrication à la distribution ; de la première utilisation à l’utilisation normale ; revente, remise à neuf, recyclage ou mise à la poubelle.
• L’implication des partenaires : veillez à ne pas les oublier et évaluez leur maturité. Vous devrez peut-être prendre des mesures pour les soutenir ou les perfectionner (conseil : demandez à votre RSSI ou à votre responsable de la sécurité des produits).
• L’audit de votre appareil et de toute la pile technologique. Faites-le régulièrement car il se peut que votre logiciel n’ait pas changé mais que les menaces et les vulnérabilités connues aient évolué.
• Les mises à jour et la maintenance de la sécurité à long terme : définissez pendant combien de temps vous allez mettre à jour et déployer vos appareils.
• L’organisation de la réponse aux incidents : définissez comment vous pouvez être informé des vulnérabilités ou des brèches et comment vous pouvez prévoir d’y répondre (d’un point de vue technique et de communication).

La cybersécurité de l’IoT n’est pas impossible. Elle fournit en fait des méthodologies et des outils pour aider à créer un environnement sûr.

Les acteurs du projet et les clients recherchent des produits sûrs et font pression pour qu’ils le soient. La réglementation visant à faire respecter la sécurité est imminente et les cadres de référence permettant d’aider chaque acteur à s’aligner sur ses devoirs continueront d’être appliqués. Il est temps d’aller de l’avant dès maintenant si vous cherchez à faire de la cybersécurité un atout pour votre produit sur votre marché !

Cet article Analyse des risques et IoT: un mariage d’amour ou de raison ? est apparu en premier sur RiskInsight.

A quoi ressemble l’outil « Jitsuin Archivist » ?

La start-up Jitsuin a développé un outil appelé « Jitsuin Archivist » qui repose sur la technologie de registres distribués (DLT : Distributed Ledger Technology). Le but de cet outil est de savoir : « Who did what to a Thing and When » qui lorsque traduit en français donne : « Qui a fait quoi à un Objet et quand ».

Pour le moment, 5 types d’utilisateurs peuvent interagir avec l’outil : Archivist Administrator, System Administrator, Maintenance Operator, Auditor, Custom (actuellement en version bêta).

Figure 1 – Les 5 rôles au sein de Jitsuin Archivist

Sur cet outil l’utilisateur a accès aux « Security Twins » de ses objets connectés. En effet, après s’être connecté, l’utilisateur accède à un dashboard au travers duquel il a une vue globale de l’ensemble des objets connectés reliés à l’outil. Il peut y voir des statistiques pertinentes en lien avec son déploiement IoT comme par exemple le nombre d’incidents critiques, l’activité des objets connectés etc.

L’utilisateur peut également accéder à la page « Manage Assets » où il va retrouver une carte avec la localisation de l’ensemble des objets connectés reliés à l’outil et une liste de ces derniers (où il pourra également voir plus en détails les évènements en lien avec un objet connecté en particulier).

Figure 2 – Les différentes vues de l’outil « Jitsuin Archivist » : 1. Dashboard avec une vue globale, 2. L’ensemble des objets et leur localisation, 3. La vue détaillée d’un objet, 4. L’ensemble des actions de l’objet utile lors d’audits de sécurité

Le PoC : Une maison disposant d’une serrure connectée

Wavestone s’est donc appuyé sur l’outil de la startup Jitsuin pour d’une part répondre à la problématique de gestion des identités et des accès dans les bâtiments à l’ère de la transformation digitale et d’autre part illustrer l’utilité des « Security Twins ».

Pour ce faire, Wavestone a utilisé la maison en lego appelée « Smart House».

Figure 3 – La Smarthouse

Equipée d’un lecteur de cartes RFID, d’un microcontrôleur Raspberry Pi et d’un servomoteur, la porte d’entrée de la « SmartHouse » ne s’ouvre qu’aux utilisateurs qui possèdent un badge avec les bons accès. Toutes les actions en lien avec l’ouverture, fermeture, attribution de droit d’entrée, etc. sont enregistrées sur l’outil « Jitsuin Archivist » (c.f. figure 4).

Figure 4 – Schéma fonctionnel de la SmartHouse

Afin de faciliter l’interaction avec la serrure connectée de la SmartHouse, une plateforme permettant de simuler les différentes opérations faites par des acteurs du cycle de vie d’un objet connecté a été créée en utilisant le framework web Django ainsi que Bootstrap. Cette plateforme permet entre autres de :

• Envoyer de patchs de sécurité à la serrure connectée (en utilisant Azure IoTHub)
• Attribuer des droits d’accès à la SmartHouse
• Visualiser l’historique des demandes de droits d’accès effectuées et celles en attente de validation, etc.

Voici à quoi ressemble la plateforme :

Figure 5 – La plateforme de gestion de la SmartHouse

L’utilisation de Jitsuin Archivist dans ce PoC est très intéressante d’un point de vue des audits de sécurité des objets connectés. En effet, comme l’outil Jitsuin Archivist repose sur la technologie de registres distribués (DLT), ce système peut être considéré comme « secure by design » puisqu’un(e) auditeur/auditrice a une garantie technique sur la non-compromission des données (à condition que l’envoi de ces données soit sécurisé).

Voici la « Auditor View » sur Jitsuin Archivist où il est possible de voir toutes les informations des objets connectés et savoir qui a fait quelle action :

Figure 6 – La « Auditor View » de Jitsuin Archivist

Le scénario du PoC : WaveHouse loue des SmartHouses sur le terriroire français …

Voici donc l’architecture générale du PoC :

Figure 7 – L’architecture générale du PoC

Comme vous pouvez le remarquer la serrure connectée (représentée par le lecteur de carte RFID, le microcontrôleur Raspberry Pi et le servomoteur) interagit également avec Azure IoTHub afin de faciliter la gestion des mises à jour de son micrologiciel.

Les principaux cas d’usage étudiées par Wavestone et Jitsuin

Les principaux cas d’usage étudiés par Wavestone et Jitsuin sont explicités dans la vidéo ci-dessous :

Conclusion

Les équipes de Wavestone et Jitsuin ont pu démontrer avec les différents cas d’usage illustrés ci-dessus dans la vidéo comment améliorer la sécurité des objets connectés :

• Tout d’abord, tous les acteurs du cycle de vie de la serrure connectée de la « SmartHouse » avaient accès au « Security Twin » de la serrure connecté. En effet chacun d’entre eux avait accès à un registre décentralisé et immuable fourni par l’outil Jitsuin Archivist avec toutes les informations en lien avec la sécurité de la serrure connectée
• Ensuite, comme évoqué précédemment, cette architecture est « secure by design » puisque comme Jitsuin Archivist repose sur la technologie de registres distribués (DLT), on a une garantie technique sur la non-compromission des données
• Le « Security Twin » de la serrure connectée permettait d’assurer la sécurité physique puisqu’il a été alimenté par les informations de gestion des droits permettant ainsi à l’ensemble des acteurs de savoir qui avait accès à la « SmartHouse ».

Cet article Les « Security Twins » : Le nouveau gage de sécurité des objets connectés (2/2) est apparu en premier sur RiskInsight.

Bien que très utiles, l’utilisation des objets connectés introduit malheureusement de nouveaux risques pour les entreprises. En effet, selon le rapport^[2]  de Palo Alto Networks publié en mars 2020, 57% des objets connectés analysés sont vulnérables à des attaques de moyenne ou haute gravité. Ceci n’est pas surprenant. Sécuriser des objets connectés s’avère une tâche ardue ce qui explique pourquoi Beecham Research ^[3] estime que 62 % des transformations industrielles de l’IoT à grande échelle échouent en raison d’un manque de confiance.

Nous nous sommes donc interrogés sur les enjeux de sécurité et confiance des objets connectés ainsi que sur comment les entreprises peuvent y faire face.

Quels sont les enjeux de sécurité et confiance des objets connectés ?

Afin d’atténuer les risques de sécurité sur les objets connectés, le NIST préconise dans son rapport^[4] publié en 2019 de se focaliser sur 6 grands axes :

• L’inventaire : Tenir à jour un inventaire précis de tous les objets connectés et de leurs caractéristiques les plus pertinentes tout au long de leur cycle de vie (voir l’article détaillant le cycle de vie des objets connectés)

Figure 1 – Le cycle de vie d’un objet connecté

• Les vulnérabilités: Identifier et éliminer les vulnérabilités connues des logiciels et micrologiciels des objets connectés afin de réduire la probabilité et la facilité d’exploitation et de compromission.
• Les accès: Empêcher l’accès physique et logique non autorisé et inapproprié aux objets connectés, leur utilisation et leur administration par des personnes, des processus et d’autres dispositifs informatiques.
• Détecter les incidents de sécurité des objets connectés: Surveiller et analyser l’activité de l’objet connecté pour détecter les signes d’incidents impliquant la sécurité de l’appareil.
• Détecter les incidents de sécurité en lien avec les données: Surveiller et analyser l’activité de l’objet connecté pour détecter les signes d’incidents impliquant la sécurité des données.
• Protéger les données: Empêcher l’accès et l’altération des données qui pourraient exposer des informations sensibles ou permettre la manipulation ou la perturbation du fonctionnement des objets connectés.

Or les plateformes IoT actuelles permettent seulement de répondre en partie à ces exigences de sécurité (voir l’article détaillant l’utilité des plateformes IoT).

Figure 2 – L’utilité des plateformes IoT

En effet, les architectures IoT traditionnelles s’appuient sur une plateforme cloud centralisée, opérée par un éditeur où le plus souvent les règles de collecte et de stockage des données sont opaques. Ce n’est pas la solution la mieux adaptée pour assurer la sécurité des objets connectés car :

• L’utilisation d’une plateforme cloud centralisée introduit le risque de « single point of failure » sur l’architecture IoT (bien qu’aujourd’hui ce risque soit atténué avec l’implémentation d’une architecture redondante et de backups)
• Il est tout à fait possible pour un attaquant de changer les données stockées dans la base de données sur le cloud. La prise de décision des différents acteurs est donc impactée.
• La collaboration entre les différents acteurs du déploiement (fabricants, opérateurs de maintenance, …) devient plus difficile car l’accès à la plateforme peut leur être restreint

L’utilisation d’un système décentralisé de gestion des objets connectés où tous les acteurs auraient la possibilité de consulter ou ajouter de manière fiable les informations concernant les objets connectés (version du micrologiciel, opérations de maintenance …) devient donc primordiale afin de garantir la sécurité et l’intégrité des données produites de ces derniers.

En quoi les « Security Twins » permettent-ils de répondre aux enjeux de sécurité des objets connectés ?

Afin d’épauler les plateformes IoT et améliorer la sécurité des déploiements IoT, il convient d’introduire la notion de « Security Twin » dans les déploiements IoT.

Le principe d’un « Security Twin » est simple. Il s’agit d’une représentation virtuelle de l’objet connecté qui regroupe toutes les informations de sécurité, comme par exemple la version du micrologiciel, les vulnérabilités … (cf. figure 3) de ce dernier sur lesquelles tous les acteurs impliqués dans sa gestion peuvent parvenir à un consensus (voir figure 3).

Figure 3 – Le mécanisme d’un « Security Twin » (source : Jitsuin)

Un « Security Twin » gagne en efficacité lorsque davantage d’acteurs du déploiement peuvent interagir avec lui et parvenir à un consensus sur l’exactitude des informations fournies/enregistrées.

Ainsi, les solutions basées sur la technologie de (Distributed Ledger Technology) représentent une première étape logique dans la création de « Security Twins », puisqu’elles permettraient de regrouper les informations de sécurité de l’objet connecté dans un registre décentralisé et immuable qui serait accessible par toutes les parties prenantes du déploiement IoT. La plus connue des solutions de registres distribués est la Blockchain (voir l’article sur les cas d’usage et limites de la Blockchain).

Si l’on reprend les points soulevés précédemment par le rapport du NIST, l’utilisation d’un « Security Twin » permettrait donc d’améliorer :

• La gestion des objets et la gestion des accès : tous les acteurs du déploiement IoT auraient accès à un registre décentralisé et immuable de tous les objets connectés avec toutes les informations de sécurité et confiance.
• La gestion des vulnérabilités et la détection des incidents de sécurité des objets : les différents acteurs pourraient partager des informations sur la sécurité de l’objet et prendre les actions nécessaires (par exemple le fabricant d’un objet connecté pourrait notifier les autres acteurs de la disponibilité d’une nouvelle mise à jour du micrologiciel grace au « Security Twin »).
• La protection des données et la détection des incidents de sécurité en lien avec les données : le principe même d’un « Security Twin » repose sur l’utilisation d’un registre décentralisé et immuable afin d’enregistrer les données en lien avec la sécurité des objets connectés. Il devient donc plus difficile pour des attaquants de changer les données ce qui diminue les risques d’incident de sécurité.

L’utilisation des « Security Twins » offre donc la possibilité de renforcer la sécurité, intégrité, confiance et résilience des objets connectés.

La start-up Jitsuin a développé l’outil « Jitsuin Archivist » basé sur la technologie de registres distribués (Distributed Ledger Technology) pour pallier le manque d’outils collaboratifs permettant de sécuriser les objets connectés. Le but de cet outil n’est pas de remplacer les plateformes IoT mais permettre la création de « Security Twins ».

Ensemble, Wavestone et Jitsuin ont cherché à démontrer les bénéfices de l’utilisation d’une architecture décentralisée avec des « Security Twins ». Les deux entreprises ont donc collaboré sur la construction d’un PoC (Proof of Concept) sur la gestion des identités et accès aux bâtiments avec des objets connectés qui sera à découvrir dans un prochain article.

[1] Gartner, 29 Août 2019 : https://www.gartner.com/en/newsroom/press-releases/2019-08-29-gartner-says-5-8-billion-enterprise-and-automotive-io

[2] Palo Alto Networks, 10 mars 2020, “Unit 42 IoT threat report”: https://unit42.paloaltonetworks.com/iot-threat-report-2020/

[3] Why IoT projects fail : https://www.whyiotprojectsfail.com/?cs=br2

[4] NIST – “Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks” : https://csrc.nist.gov/publications/detail/nistir/8228/final

Cet article Les « Security Twins » : Le nouveau gage de sécurité et confiance des objets connectés (1/2) est apparu en premier sur RiskInsight.

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.

Comment l’idée vous est-elle venue ?

Georges Bote (ICARE Technologies) raconte que l’idée est venue au fondateur, Jérémy Neyrou « il y a 6 ans de cela, en perdant mes clés de voiture sur une plage Corse complètement déconnectée de tout réseau, après avoir parcouru près d’une dizaine de kilomètres en plein soleil d’été à pied », il imagine un « objet à la fois intuitif et autonome qui permettrait d’embarquer [le] trousseau de clés et [les] moyens de paiement ». C’est ainsi qu’est née Aeklys, « cette bague intelligente qui permet d’embarquer jusqu’à 28 fonctionnalités différentes ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Georges Bote (ICARE Technologies) s’accorde également à dire que « la fraude à la fois bancaire et sur l’identité des personnes reste le grand risque pour les banques et leurs clients ». C’est pourquoi la bague connectée proposée par ICARE Technologies embarque un mécanisme de désactivation en cas de perte ou de vol, protégeant ainsi son propriétaire contre l’usurpation de ses moyens de paiement sans qu’il ne doive faire opposition d’une quelconque manière que ce soit.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

ICARE Technologies explique que la pertinence de la sécurité de sa solution « réside dans notre technique et différentes certifications bancaires. Notre secure element dispose d’un niveau EAL6+ certifié par l’ANSSI, ce qui nous permet de travailler dans le domaine militaire en plus d’avoir un chiffrement en AES 256 bits ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

La force du produit d’ICARE Technologies réside dans son innovation et en sa sécurité : « de plus, il caractérise une nouvelle forme de liberté et de sécurité qui est fortement attractive pour les clients potentiels. L’intérêt est donc d’en faire devenir un objet « à la mode » de manière à orienter la connotation sociale de la bague comme une tendance ».

Les synergies existent et la technologie est actuellement en phase de test avec des partenaires bancaires et industriels pour travailler notamment sur la sécurisation de valises informatiques. Georges Bote annonce « la préparation d’un 2ème tour de table et de belles surprises pour notre Go To Market qui sera prévu le 1er trimestre 2019 ».

Pour en savoir plus : https://fr.icaretechnologies.com/

Cet article L’INTERVIEW D’ICARE TECHNOLOGIES – LA BAGUE INTELLIGENTE SECURISEE est apparu en premier sur RiskInsight.

 AU COEUR DE LA TRANSFORMATION NUMÉRIQUE

Aucune industrie ne peut aujourd’hui ignorer cette tendance et les entreprises voient un intérêt grandissant à s’emparer de ce qu’elles perçoivent comme une véritable opportunité.

Alors que des start-ups conçoivent chaque jour des dispositifs intelligents, des partenariats se mettent en place entre les vendeurs et les industries traditionnelles – tels les secteurs de l’assurance, automobile, administratif, bancaire – afin d’offrir de nouveaux services aux consommateurs grâce à divers éléments connectés.

UNE SURFACE D’ATTAQUE DE PLUS EN PLUS EN PLUS VASTE POUR LES CYBERCRIMINELS

L’essor de cet Internet des Objets n’est pas sans danger, d’autant plus que les risques, qui étaient surtout virtuels, s’étendent au domaine du physique.

Une étude frappante a été menée par HP Fortify en 2014, mettant en avant un constat sans appel : en testant la sécurité des 10 des objets connectés les plus en vogue du moment, une moyenne de 25 vulnérabilités par objet a été trouvée. La plupart d’entre elles sont liées à des problèmes de sécurité basiques, tels que la mauvaise gestion de la confidentialité des données et des droits d’accès, l’absence de chiffrement des flux, une interface d’adminis­tration Web non sécurisée, ou encore une protection générale inadaptée. La suite de cette étude en 2015 a également montré que les 10 smartwatchs et les 10 systèmes de sécurité pour les particuliers les plus vendus présentaient tous des vulnérabilités majeures concernant la confidentialité des données de l’utilisateur.

Ce manque de durcissement augmente le risque de vulnérabilités pouvant affecter toute sorte d’objets : des réfrigérateurs aux toilettes connectées, en passant par les voi­tures et les serrures. L’actualité des derniers mois en est la preuve avec par exemple l’attaque DDoS sur le DNS Dyn avec le botnet Mirai en octobre 2016 ou la prise de contrôle à distance d’une Tesla par une équipe de hackers chinois en septembre 2016.

DANS QUELLE CATÉGORIE DE RISQUES VOUS SITUEZ-VOUS ?

En ce qui concernent les entreprises, les risques dépendent de la posture adoptée. Dans le cas des objets connectés, quatre cas sont possibles. Les différentes postures ont été réunies sous l’acronyme « CARA » (pour Concevoir, Acquérir, Recommander, Accueillir) comme le montre le tableau ci-dessous. Une fois la posture identifiée, il convient de spécifier les risques génériques et les recommandations associées.

Afin d’évaluer le risque, le cabinet Wavestone a développé un outil spécifique, la matrice « heat map ». Elle prend en compte deux dimensions : le niveau de risque et la posture.

UN OUTIL D’ÉVALUATION EFFICACE : LA MATRICE « HEAT MAP »

Le schéma ci-dessous présente l’exemple concret de l’utilisation d’objets connectés pour le secteur bancaire et ses divers ser­vices. Ce contexte présente des contraintes particulières. D’un côté la réalisation d’une transaction financière est plus risquée que la consultation du solde bancaire. Mais d’un autre côté, la personnalisation des fonctions de sécurité sur un appareil appartenant à un employé ou à un client est bien plus compliqué que le durcissement d’un produit choisi par l’entreprise et qui a été acquis à un fournisseur, ou même développé en interne.

Cette matrice permet de réaliser une cartographie des risques qui requièrent la plus grande attention.

DES DISPOSITIFS DE SÉCURITÉ HABITUELS : DE NOUVEAUX MODES D’IMPLÉMENTATION

Une fois la cartographie des risques établie, il faut s’intéresser aux réponses que l’on peut y apporter. Une référence intéressante à ce propos est celle de l’initiative « IoT Project » de l’OWASP (Open Web Application Security Project – organisation à but non lucratif) qui propose notamment une liste de recommandations de sécurité intéressantes et compréhensibles.

La première chose à noter à propos de ce guide est qu’il est divisé en 3 catégories selon les cibles d’audience visées : fabri­cants, développeurs, consommateurs. Cette structure a du sens dans la mesure où la sécurité est partagée entre ceux qui conçoivent les composants (matériel ou logiciel), et ceux qui les utilisent.

Par ailleurs, les dispositifs de sécurité doivent être complets – renforçant non pas les seuls objets connectés, mais aussi toute la sur­face d’une attaque (physique, matériel, logiciel, base de données, local ou à distance, etc.). À cet égard, les mesures de sécurité proposées sont surtout construites sur les bonnes pratiques de l’industrie de la sécurité.

L’Internet des Objets apporte un réel changement dans la mise en œuvre des dispositifs de sécurité.

En effet, plusieurs contraintes liées aux objets connectés sont à prendre en compte :

• Ergonomie : la taille et le design influenceront les mesures de sécurité acceptables par les utilisateurs – par exemple, la taille de l’écran pour taper un mot de passe.
• Puissance : les petits objets embarqués actuels ont une puissance de calcul limitée. Plusieurs opérations ne peuvent être réalisées en même temps dans un laps de temps raisonnable. Par exemple, Apple a conseillé aux développeurs de ne pas implémenter des fonctionnalités nécessitant de long temps d’exécution sur l’Apple Watch.
• Connectivité : l’Internet des Objets utilise généralement du Bluetooth ou des protocoles NFC, deux technologies ayant une portée et un débit limité, ce qui ne permet pas toujours d’embarquer un niveau de sécurité suffisant.
• Durée de vie de la batterie : les algo­rithmes cryptographiques (comme du chiffrement / déchiffrement asymé­trique en temps réel) peuvent affecter durement la consommation énergé­tique, même s’ils permettent de pro­curer un meilleur niveau de protection.
• Gestion des mises à jour : il est indis­pensable de mettre à jour le système, sans interférer avec l’utilisation de l’objet. Cela est particulièrement frap­pant dans le cas des voitures connec­tées que l’on ne peut pas conduire lorsque le logiciel est en train de se mettre à jour. Cela peut prendre plus de 45 minutes.

Au-delà de la sécurité, la confidentialité est également indispensable pour les consommateurs ainsi qu’une exigence pour les autorités. L’implémentation pourrait être complexe, mais plusieurs initiatives pour la confidentialité des objets connectés ont émergé ces dernières années.

Parmi ces initiatives, le projet PRESERVE est un exemple intéressant. Il offre à l’industrie automobile un nouveau moyen d’utiliser les PKI et les certificats numériques pour les voitures et les routes connectées. Le projet utilise des « pseudonymes » modifiés régulièrement afin de garantir que le conducteur reste anonyme tout en assurant que les communications entre les véhicules et l’infrastructure routière sont authentiques et sécurisées.

Nous sommes entrés dans une ère où sécurité et confidentialité des données sont devenues des critères essentiels dans le choix des consommateurs. Cette évolution ne peut plus être ignorée par les acteurs concernés, qu’ils conçoivent, acquièrent, recommandent ou accueillent des objets connectés.

Cet article Objets connectés : les 4 dimensions de la sécurité est apparu en premier sur RiskInsight.

Et puis sont venus les partenaires externes et leurs employés. Dans le cas d’usage classique, un constructeur d’avion doit pouvoir collaborer avec l’ensemble de ses sous-traitants : il faut leur permettre l’accès aux applications, gérer ou faire gérer leurs comptes et leurs droits. La fédération des identités ainsi que ses standards et protocoles ont permis de répondre à cette problématique. La gestion des identités si elle devait prévoir de nouveaux processus n’a été que faiblement impactée (la volumétrie restait d’un ordre de grandeur comparable, les utilisateurs restaient des humains maîtrisés, etc.)

Aujourd’hui, un premier palier doit être franchi pour gérer une volumétrie beaucoup plus forte et des utilisateurs d’un nouveau type : les clients. Des centaines de milliers voire des millions d’identités. Il faut maintenant gérer l’identité d’un client et pouvoir l’authentifier et l’autoriser sur les applications mises à sa disposition. Il faut savoir l‘authentifier simplement de son point de vue (e.g. via un réseau social) et faire le lien avec son compte traditionnel dans le CRM pour gérer la relation. Les opérateurs télécoms et les banques et leurs bases clients sont devenues le nouveau cas d’usage classique : les accès aux applications via Internet et terminaux mobiles sont dans l’air du temps.

Au-delà de ce changement d’échelle, les caractéristiques de ces identités de clients sont différentes des traditionnelles identités de l’entreprise : le nombre d’applications accédées et de rôles est plus faible. Par ailleurs, plus question de devoir gérer des cas particuliers, tous les clients sont logés à la même enseigne et ce pour le plus grand bénéfice des projets IAM qui vont enfin voir se réduire fortement leur complexité fonctionnelle.

Enfin, un deuxième palier s’annonce déjà : la gestion des identités des objets connectés. Le CES 2014 qui s’achève ces jours-ci nous en offre de multiples illustrations : brosses à dent, cocottes minutes, lits, ampoules, etc. Tous les objets du quotidien sont désormais connectés. Par ailleurs, la complexité et les facultés de ces objets nous environnant sont telles aujourd’hui que de nouvelles approches sont nécessaires.

Les premiers objets connectés étaient de simples capteurs : température, pression, cellules infrarouge, compteurs, etc. Généralement non connectés directement à Internet, ils émettaient de l’information dans un protocole spécifique à destination d’une passerelle qui elle avait pour rôle de centraliser les données et de les transmettre via Internet à un serveur de traitement.

Nouveaux usages et nouveaux besoins

L’identification de ces objets est alors très sommaire, allant de la simple déclaration d’adresse MAC jusqu’à l’utilisation d’une clé de chiffrement des échanges pour les installations les plus sophistiquées.

Les objets connectés sont maintenant non seulement émetteurs de données de plus en plus complexes mais également destinataires de commandes et d’action à réaliser, de correctifs et patches de sécurité, etc.

Dernier cas d’usage classique à la mode : la voiture connectée informe directement le constructeur ou le concessionnaire qu’un sous-composant est en mauvaise santé ou qu’une révision est nécessaire.

Ces objets doivent pouvoir être joints depuis n’importe où (et ne plus être masqués par une passerelle) et par ailleurs, les capacités d’attaques cybercriminelles ayant fortement augmentés ces dernières années, la sécurité des échanges et l’authentification préalable des objets est devenu un prérequis. Et nous voilà donc avec des milliers d’objets disposant d’une identité !

Cet article Des objets et des hommes est apparu en premier sur RiskInsight.