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.

Penser un projet Smart City avec la cybersécurité

Il est fondamental d’intégrer les aspects cybersécurité dès le démarrage d’un projet Smart City. En effet, le réaliser plus tard dans le projet pourra s’avérer plus complexe et couteux, avec le risque de ne pas en traiter / pouvoir traiter tous les risques.

Ceci nécessite de repenser l’organisation du projet vis-à-vis de la donnée et de la gouvernance de la sécurité : les principes de sécurité doivent être définis à l’échelle globale du projet et pris en compte par chacun des sous projets composant la Smart City, en fonction de leurs contraintes. Cela est d’autant plus vrai que les Smart Cities impliquent un grand nombre d’acteurs aux cœurs de métier, aux moyens et à la maturité cybersécurité différents. Une vision globale et partagée est indispensable pour s’assurer que chaque élément traite la donnée avec le niveau de sécurité adéquat.

Il convient ensuite de définir les grands principes d’architecture et d’interopérabilité, selon les contraintes inhérentes à la Smart City, liées à l’Edge Computing et au déploiement d’objets en milieu hostile. La résilience du système doit être au cœur des exigences de sécurité, la chute ou la compromission d’un élément ne devant pas entrainer la chute de la totalité du système.

A cet effet, des standards communs doivent être adoptés, en s’appuyant sur des frameworks spécifiques comme ETSI ou OneM2M. Ces derniers augmentent les chances de maintenir des systèmes interopérables évolutifs. Plus généralement, le NIST ou la norme ISO 27002 sont des référentiels de cybersécurité éprouvés sur lesquels il serait intéressant de s’appuyer.

Le mode de développement doit être agile, en intégrant une vision sur le long terme pour anticiper les nouveaux cas d’usage, et en jalonnant court afin de délivrer rapidement les premiers services. La cybersécurité doit être incluse dans les processus de développement, par la définition d’Evil User Stories, permettant d’identifier et de prendre en compte les risques à chaque évolution des services ou du SI, et par la nomination d’experts cybersécurité dans un rôle de support et de validation.

La définition et le maintien d’un niveau de sécurité satisfaisant passera plus que jamais par l’intégration rigoureuse de la sécurité dans toutes les phases du projet, cela pouvant induire des investissements humain et technologique plus importants mais nécessaires.

Protéger les données critiques et régulées

Etant donnée la propension de la Smart City à collecter et traiter de grandes quantités de données, leur protection passera en premier lieu par l’identification des données et des actifs critiques.

La majorité des services proposés par la Smart City sont à destination des citoyens. Par conséquent, des données identifiantes et ainsi potentiellement sensibles vont être collectées. Par ailleurs, une perte de disponibilité ou d’intégrité de certains services pourront avoir de graves répercussions étant donné que certaines composantes du SI ont une prise directe sur le monde physique. Les Smart Cities n’échappent pas aux réglementations, notamment au Règlement Général sur la Protection des Données (RGPD), mais aussi selon les usages au Référentiel Général de Sécurité (RGS), à la Loi de Programmation Militaire (LPM) ou à la directive européenne Network and Information Security (NIS), dont les exigences en matière de protection des données devront être intégrées dans les programmes.

Des niveaux de classification de la sensibilité de la donnée doivent donc être formalisés afin de permettre la priorisation des actions et la mise en place de cadres de traitement des données critiques adaptés tels que le chiffrement et l’anonymisation.

Le problème de l’accès aux données devra aussi être posé. Les acteurs de la Smart City sont nombreux et il sera nécessaire de segmenter la « vision » qu’ils pourront avoir du SI. Cela passera par une phase préalable de définition des profils d’habilitations, nécessaires au respect du principe de moindre privilège, associée à une revue régulière de leurs affectations afin de s’assurer qu’elles soient toujours légitimes.

Opérer sur des environnements de confiance

Le projet Smart City s’appuiera nécessairement sur différents socles techniques et organisationnels. Si ces socles sont au Système d’Information ce que les fondations sont à une maison, il est aisé de comprendre qu’il sera difficile de bâtir quoi que ce soit si cette base est fragile.

Comme toujours, ces socles techniques doivent être couverts par les mesures fondamentales de la sécurité : mise en place de bulles de confiance, durcissement des systèmes, patch management, sécurisation des comptes à privilèges et de leur usage, etc.

Par ailleurs, un système d’information à la surface d’attaque aussi large que celui de la Smart City devra nécessairement rompre avec le modèle de sécurité traditionnel dit « château-fort », en jouant davantage sur des aspects de cloisonnement et de contrôle d’accès à la donnée elle-même. La conformité des actifs au sein du système d’information devra être évaluée continuellement en s’appuyant sur des référentiels de configuration et de durcissement communs. Les systèmes et applications exposés doivent faire l’objet de contrôles et audits, particulièrement pendant la phase de développement, mais aussi pendant la phase d’exploitation.

Par ailleurs, la continuité et la reprise d’activité devront être au cœur de la stratégie de sécurité. Des plans devront être formalisés, mais aussi testés, incluant à la fois les considérations techniques comme la résilience des différents systèmes, incluant la capacité à restaurer des systèmes indépendamment des autres, mais aussi organisationnelles par la réalisation d’exercices de gestion de crise.

Enfin, la Smart City impliquant un grand nombre d’acteurs, toutes les parties prenantes devraient garantir la mise en œuvre de moyens significatifs dans la protection des systèmes d’information impliqués et se conformer aux exigences de la politique de sécurité du projet. Pour cela, ils devront être engagés contractuellement, à minima par l’inclusion d’exigences de sécurité dans les contrats, mais aussi par la formalisation et la mise en œuvre de plans d’assurance sécurité, notamment pour les prestataires les plus critiques. Des contrôles réguliers pourront être commandités afin de s’assurer du maintien du niveau de sécurité dans le temps et adresser les futurs scénarios de risque.

Détecter, réagir et partager

La Smart City ne peut se passer d’un service de détection et de traitement des incidents de sécurité.

Il conviendra de collecter les traces de l’activité sur les systèmes et rechercher les signaux faibles. Face au nombre important d’évènements à traiter, il sera indispensable de définir les risques dont on souhaite se prémunir et de s’appuyer sur des solutions de corrélation afin de faciliter ces recherches. L’utilisation d’outils d’automatisation permettra d’effectuer un premier tri des faux positifs, facilitant le travail des analystes dans la qualification des alertes de sécurité.

La construction du service de détection et de réaction pourra se faire en s’appuyant sur les référentiels PDIS et PRIS. On pourra au besoin recourir à des fournisseurs externes qualifiés sur ces deux services.

Le recours à des services de Cyber Threat Intelligence apportera un gain important d’efficacité dans la création et l’enrichissement des règles de détection du SOC. En effet, il sera ainsi possible d’adopter une posture de détection proactive en effectuant une veille sur les attaques ayant ciblé des Smart Cities et des modes opératoires utilisés. Ceci présentera également l’avantage d’améliorer l’efficacité du service de réaction par l’économie d’un temps d’investigation précieux.

Enfin, le processus de traitement des incidents de sécurité significatifs et majeurs ne pourra se faire sans la formalisation d’une cellule de gestion de crise, composée d’acteurs aux rôles bien définis et formés à cet exercice. Un point d’attention particulier sera porté sur le dispositif de communication externe, la « gravité » d’une crise dépendant autant de l’événement qui en est à l’origine que de la perception qu’en a le monde extérieur.

En conclusion, et comme nous l’avons vu au travers de ces deux articles, la Smart City est une évolution qui s’impose d’elle-même dans une époque où se mêlent à la fois des enjeux démographiques, écologiques et économiques. Ses promesses sont séduisantes, mais le cadre de mise en œuvre peut susciter certaines craintes.

Comme pour n’importe quelle transformation numérique, la garantie d’un niveau de sécurité en adéquation avec les enjeux du projet passera nécessairement par l’identification des failles et des risques de sécurité qu’elle engendre.

A l’ère des cyberguerres et des cybermenaces, la Smart City devrait être considérée comme un Fournisseur de Service Numérique, au sens de la directive NIS, et être protégée par les mesures de sécurité adaptées à ce statut.

La proposition de services sécurisés, respectueux des données de leurs usagers est une condition sine qua none au succès d’un projet Smart City, dont les bénéfices n’auront d’égal que l’ampleur de l’impact d’une cyberattaque réussie.

Cet article Les enjeux de Cybersécurité autour de la Smart City (2/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.

« Une ville intelligente et durable est une ville novatrice qui utilise les nouvelles technologies pour améliorer la qualité de vie, l’efficacité des services urbains ainsi que la compétitivité, tout en respectant les besoins des générations actuelles et futures dans les domaines social et environnemental. »,  Institution spécialisée des Nations Unies pour les Technologies de l’Information et de la Communication.

Augmentation de la population urbaine, urgence écologique et transition énergétique, contraintes sur les finances publiques, besoin de réinventer le lien entre le service public et l’usager, augmentation du confort de vie des habitants, etc. : toutes ces problématiques sont autant de défis que la Smart City pourrait contribuer à adresser et qui poussent les collectivités à investir dans cette direction.

Afin de répondre à ces enjeux d’aujourd’hui et de demain, la Smart City va devoir créer une synergie entre différents domaines tels que la gestion intelligente du trafic, le développement de nouveaux modes de transports, l’optimisation de la consommation d’énergie et de la gestion des déchets, la protection des biens et des services, la domotique etc.

Tous ces services pourront être fédérés autour d’un centre de contrôle unique qui assurera une liaison montante et descendante donnant la possibilité de collecter des informations sur l’état des services et/ou d’agir directement sur l’infrastructure.

Une nouvelle cible pour les cyber attaquants

De nombreuses villes en France et dans le monde, se sont emparées du sujet Smart City pour faire face aux défis énoncés précédemment : de grandes métropoles bien sûr, mais également des villes de tailles plus modestes.

En parallèle de ces initiatives, il devient de plus en plus fréquent d’observer des attaques d’origine cyber cibler des villes. A titre d’illustration, en 2019, 22 municipalités américaines ont été victimes de cyberattaques. Les pertes se chiffrent en millions. Le gouverneur de Louisiane est allé jusqu’à décréter l’état d’urgence à la suite d‘attaques contre plusieurs villes de son Etat. Mais ces attaques ne se limitent pas aux Etats-Unis, comme peuvent en témoigner les attaques en France sur les villes de Sarrebourg (Moselle), Sequedin (Nord), Huez (Oisans), La Croix-Valmer (Var) ou encore de Nuits-Saint-Gorges (Côtes-d’Or).

Ainsi, la question est désormais de savoir pourquoi les Smart Cities présentent un nouveau terrain de jeu pour les Cyber Attaques et comment s’en protéger.

La Smart City induit un changement de paradigme

Mener un projet Smart City nécessite de modifier les façons habituelles de procéder par la mise en place d’un système d’information d’un nouveau genre, mêlant de nombreuses problématiques et générant de nouveaux risques en matière de CyberSécurité.

Une architecture complexe

La ville intelligente est en partie caractérisée par la structure nouvelle de son architecture. Son système d’information atypique compile à la fois les contraintes d’un système d’information de gestion, celles d’un système d’information industriel et celles d’un système d’information IoT.

Ainsi, son SI de gestion aura une propension à collecter et traiter un grand nombre de données alors que son SI industriel aura la caractéristique d’être en prise directe sur le monde physique : gestion de l’eau, des feux de circulation, de la signalisation routière variable, de bornes rétractables, de l’éclairage intelligent, pilotage de voitures autonomes, etc. et la conciliation des enjeux de ces deux mondes n’est pas chose facile : là où le monde industriel met traditionnellement l’accent sur la disponibilité, le monde IT se concentrera sur l’intégrité et la confidentialité des informations et des traitements, considérant par ailleurs que la Smart City renforcera la dimension informatique et numérique existante des systèmes industriels.

De plus, il faut considérer la raison d’être d’un système d’information IoT qui est de collecter des données au plus près de leurs sources, par le déploiement d’objets connectés, multiples points d’entrée sur le SI dans des environnements potentiellement hostiles. Par conséquent, ces objets seront exposés unitairement à des attaques physiques contre lesquelles il n’était pas nécessaire ou plus facile auparavant de se prémunir (ex : accès physique à un port série ou USB, remplacement de la mémoire flash, etc.).

Enfin, les systèmes qui composent la Smart City doivent être en capacité d’évoluer rapidement de manière à bénéficier des innovations des acteurs du marché. L’enjeu est de réussir à construire un SI flexible en capacité de pouvoir répondre à des usages encore non identifiés à l’heure actuelle tout en prévoyant des systèmes capables d’être maintenus dans le temps, à l’échelle d’une ville intelligente construite pour des dizaines d’années.

Le paradoxe de l’interopérabilité

Par ailleurs, une démarche Smart City se veut inclusive afin de tirer parti des forces de l’ensemble des acteurs du territoire. Cela induit de gérer des systèmes hétérogènes, mêlant nouvelles et anciennes briques technologiques, et de maitriser l’ouverture de son SI.

La polymorphie des Smart City complexifie la définition de politiques de sécurité globales. Leurs mises en œuvre évoluent parallèlement au développement de nouvelles technologies, rendant obsolètes, ou inapplicables, les politiques de sécurité d’une autre génération. Cette problématique est déjà présente dans le monde industriel depuis des années, où les contraintes opérationnelles font qu’il est parfois impossible de faire évoluer des systèmes devenus vulnérables.

Au-delà de la politique de sécurité, si l’interopérabilité entre des systèmes multigénérationnels permet de développer de nouvelles fonctionnalités créatrices de valeur pour l’usager, elle implique aussi l’utilisation de protocoles disparates pouvant induire des failles de sécurité. Une approche de « sécurité by design » consisterait à identifier le besoin actuel et ses évolutions potentielles, afin d’être capable de proposer un cahier des charges intégrant à la fois les réponses concrètes au besoin fonctionnel mais aussi les clauses de sécurité minimales permettant de déployer le service avec un niveau de confiance satisfaisant. Toutefois, ceci est susceptible de s’opposer au principe d’inclusivité de la Smart City.

L’importance de la donnée

Un enjeu opérationnel et politique

L’information remontée du terrain est d’une importance prégnante parce qu’elle permet de piloter la Smart City : aide aux prises de décisions, communication d’informations aux citoyens, planification d’événements, et évaluation des politiques publiques. Si la donnée en elle-même n’est pas forcément critique, cela n’est plus vrai lorsqu’elle est agrégée dans un ensemble plus large. Des erreurs dans la collecte ou le traitement de la donnée pourront à la fois provoquer des dysfonctionnements opérationnels dans les services ou des choix inadaptées à la conjoncture.

Par ailleurs, la construction de la Smart City est faite par couche. Progressivement, de nouveaux services apparaissent et se développent. Historiquement silotés, la tendance est à la recherche de synergies entre les différents services pour créer toujours plus de valeur ajoutée pour l’usager. Ces interconnexions grandissantes et cette superposition induisent une complexité telle qu’en cas de panne, il existe un risque, si l’on n’y prend pas garde, de voir l’ensemble de l’infrastructure s’écrouler, par propagation de l’erreur, ou parce que chaque service est devenu dépendant des autres.

La sécurité: une demande qui émane des citoyens eux-mêmes

Elabe et Wavestone ont réalisé une enquête qualifiant l’importance de la donnée dans les services publics de demain, et sur les enjeux auxquels devront faire face les parties prenantes de tels projets.

Parmi ces enjeux réside l’utilisation qui est faite de la donnée à caractère personnel de l’usager. Globalement, les citoyens sont favorables à l’idée de la transformation numérique des services publics, et à fortiori à la Smart City en tant que service public, mais restent soucieux de la finalité des traitements de leurs données.

Cependant, une part non négligeable de la population, soit entre 30% et 50% n’est pas favorable à la cession de ses données même si cela pourrait permettre de faire des économies, gagner du temps ou réduire son empreinte carbone. Cela pourrait être dû au fait que 76% de la population interrogée estime que l’administration n’est pas apte aujourd’hui à assurer la sécurité des données qu’elle collecte.

Le succès de la Smart City réside donc aussi dans la capacité des parties prenantes à rassurer les usagers sur l’usage et la protection de leurs données.

Ainsi, nous avons vu que la Smart City induisait un changement de paradigme qui, associé aux fortes attentes du grand public sur la sécurité de ses données, nécessitait d’adapter son approche. En effet, à mesure que la Smart City se développe, l’activité urbaine devient de plus en plus dépendante de ses services, accroissant d’une part ses besoins de sécurité, mais aussi l’intérêt que lui porte les cyber attaquants. Fort de ces constats, l’enjeu sera donc d’identifier quelle démarche mettre en œuvre pour prendre en compte les risques de Cyber Sécurité et, à défaut de les supprimer totalement, les réduire. Nous vous en parlerons dans un second article.

Cet article Les enjeux de Cybersécurité autour de la Smart City (1/2) est apparu en premier sur RiskInsight.

Quels risques dans le monde de l’IoT ?

L’avènement de l’IoT a permis l’apparition de millions de nouveaux usages potentiels pour les consommateurs et les entreprises. Mais avec ces nouveaux usages émergent certains risques plus marqués dans le domaine des objets connectés.

Figure 1 – Des risques métier et technologiques plus marqués dans le monde de l’IoT

Ces risques métier et technologiques, pouvant induire des impacts potentiellement forts pour les consommateurs et les entreprises, doivent ainsi être identifiés dès les phases amont d’un projet IoT.

Quelle méthodologie projet pour assurer la sécurité d’un objet connecté ?

Même si les thématiques sécurité à aborder dans le cadre d’un projet IoT sont communes à tout autre projet, notre conviction est qu’il est nécessaire de structurer les réflexions autour du cycle de vie de l’objet concerné.

Le schéma ci-dessous met en évidence l’ensemble des étapes du cycle de vie d’un objet connecté.

Figure 2 – Un cycle de vie permettant d’aborder l’ensemble des thématiques sécurité

Regardons quelques questions que soulève cette approche.

1. Phase de conception, de fabrication et de distribution

Cette première phase permet d’adresser les questions liées à la conception de l’objet en regard des enjeux métier, de la cible utilisateurs (B2B, B2C, B2E), de l’environnement de déploiement (contrôlé ou non) et de la criticité de l’usage :

• Quelles sont les contraintes réglementaires s’appliquant aux usages de mon objet ?
• Quelle identité lui donner et comment la créer ?
• Comment assurer la sécurité matérielle et logicielle des secrets et des données stockées dans l’objet ?
• Comment initialiser l’état d’un objet sur la plate-forme de gestion et s’assurer qu’il n’a aucun droit sur le SI avant l’étape d’initialisation ?

Les choix mis en œuvre lors des phases de fabrication sont essentiels car ils déterminent les caractéristiques et capacités de base de l’objet. Un certain nombre seront dès lors immuables tout au long de la vie de l’objet et imposeront des contraintes fortes dans les étapes suivantes.

Par ailleurs, bien que la fin de la phase de fabrication marque le début de l’existence de l’objet sur la plate-forme de gestion d’objet, il n’y a encore aucune raison d’envisager une interaction avec le SI. Toute interaction ayant lieu avant l’association de l’objet à un utilisateur (physique ou moral) signifierait qu’il a été détourné dans l’étape de distribution. Tout accès au SI avant l’étape d’initialisation doit donc être strictement limité à la seule mise à jour du firmware (version N installée en usine et version N+1 disponible lors du déballage) ou à la pré-personnalisation de l’objet (paramétrage de fonctionnement ou injection de secret non liés à l’utilisateur). Au-delà de la sécurité du SI, un objet inutilisable avant toute phase d’appairage réduira le risque de vol de cet objet en usine ou lors de sa distribution.

2. Phase d’initialisation

La phase d’initialisation matérialise l’étape d’association (ou d’appairage) entre un objet et son propriétaire. Toute donnée générée par l’objet (ou action réalisée) est alors déclarée comme appartenant à son propriétaire (ou étant imputable à celui-ci). Dès lors, le principal enjeu est d’assurer un niveau d’association utilisateur/objet fiable et correspondant aux enjeux métier :

• Niveau d’association requis faible (situation à faible risque) : un employé déclare l’usage d’un système d’identification de présence en salle de réunion ;
• Niveau d’association requis fort (situation à fort risque) : lors de l’achat d’une serrure connectée, un consommateur fournit un numéro de série et code secret à usage unique pour autoriser son application mobile à déverrouiller la porte de son domicile.

Attention néanmoins à trouver le bon équilibre entre l’expérience utilisateur et la sécurité. La robustesse de l’association attendue pourra varier selon la nature des services auxquels le client a souscrit.

3. Phase d’utilisation

La définition des usages des objets connectés est l’étape la plus anticipée par les entreprises mais de nombreux aspects de la sécurité restent négligés. Outre les cas d’usage métier, il convient donc de se poser des questions complémentaires telles que :

• Comment assurer la mise à jour régulière des objets connectés ?
• Quels rôles entre les différents acteurs de l’entreprise pour le maintien de la couche système d’exploitation de l’objet ? de la couche applicative ? du module réseau ?
• Quels besoins de détection et de réaction en cas de compromission d’un objet ?
• Comment tirer parti du SIEM (Security Information and Event Management) et du SOC (Security Operation Center) de l’entreprise pour les incidents de sécurité techniques (compromission logicielle de l’objet) ? pour les incidents de sécurité métier (détournement de l’usage ou vol d’un objet) ?
• Comment maintenir la rétrocompatibilité des protocoles et des API utilisés par différentes versions d’un même type d’objet ?
• Quels modèles de rôles et d’interactions entre les différentes populations agissant sur l’objet ?

Sur cette dernière question, et à titre d’exemple, le schéma ci-dessous illustre la complexité possible des interactions et du modèle de rôle sur un objet tel qu’un véhicule connecté.

Figure 3 – Exemple d’un modèle de rôle et d’interaction avec un véhicule connecté (travaux menés avec l’IMT Atlantique)

4. Phase de revente

La revente est aujourd’hui l’étape la plus négligée lors de la conception d’un objet mais elle n’en reste pas moins critique. Cet événement concerne essentiellement les objets à destination du marché B2C soulevant des enjeux très spécifiques :

• Comment détecter et prendre en charge le cas de la revente d’un objet entre particuliers ?
• Quels principes de privacy-by-design mettre en œuvre pour protéger les secrets et données de l’ancien propriétaire lors d’une remise à zéro d’un objet ?
• Comment supprimer les droits d’accès du précèdent propriétaire à l’objet ?
• Quels moyens pour réinitialiser un objet dans un état stable et intègre avant un nouvel appairage ?

La difficulté majeure concerne la détection de l’événement de revente permettant de déclencher des processus de désappairage objet/utilisateur, de réinitialisation de l’état de l’objet…

Notre expérience nous permet d’identifier certaines circonstances pouvant signaler un changement de propriétaire.

Figure 4 – Exemples d’événements pouvant signaler un changement de propriétaire

Malgré ces exemples, nous constatons que la revente reste un événement complexe à identifier. C’est pourquoi certaines entreprises font tout simplement le choix de ne pas autoriser la revente d’un objet via un contrat de location. L’objet doit dès lors être restitué lors de la résiliation du service ; à défaut il doit être rendu inutilisable. Ce modèle est comparable à celui de la location d’une box Internet auprès d’un FAI (Fournisseur d’Accès Internet).

5. Fin de vie et recyclage

Bien qu’indispensable, nous avons actuellement peu de recul sur cette étape mais les enjeux sont multiples :

• Révoquer les droits accès sur le SI d’un objet en fin de vie ;
• Renouveler l’identité d’un l’objet recyclé ;
• Assurer le remplacement d’un objet défectueux en en réassociant un nouveau avec le même propriétaire et les mêmes données ;
• Détecter l’inactivité d’un objet pour déclencher un remplacement.

Les principaux risques sont la perte de la maîtrise des accès sur le SI de l’entreprise via des identifiants associés à des objets recyclés, la divulgation de données personnelles de l’ancien propriétaire ou encore le surcoût de licence pour des données induites par des objets considérés hors parc.

Une capacité d’action face aux risques variable selon la nature du projet ?

À ce stade de votre lecture vous vous dîtes probablement que cet article vous concerne peu car vous faites l’acquisition de modules ou d’objets connectés préconçus ?

Faux, vous êtes exposés aux mêmes risques ! Même si vous ne faites qu’acquérir ou accueillir des objets connectés au sein de votre SI, adresser l’ensemble des problématiques listées ci-dessus vous permettra d’alimenter le contenu d’un cahier des charges à destination de vos fournisseurs.

En conclusion, quelle que soit la nature de votre projet IoT, il est essentiel de concevoir votre objet en structurant les réflexions autour de son cycle de vie : de sa fabrication à sa mise au rebut. Il faut dès lors, à chaque étape, aborder l’ensemble des thématiques sécurité pertinentes : sécurité réseau / applicative / matérielle, standards, détection et réaction, gouvernance, maintien en condition de sécurité…

Figure 5 – Thématiques de sécurité majeures pour

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

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

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

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

Un objet connecté, oui… mais avec quoi ?

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

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

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

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

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

Figure 2 – Chaîne technologique type

2. Un objet utilisé par les clients finaux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Cette saga se propose de vous présenter dans un premier temps le véhicule connecté et les défis cybersécurité associés ; les principales sources de menace et les risques seront abordés lors d’une prochaine publication. Enfin, un troisième article vous présentera nos convictions et premiers éléments de réponse pour y faire face.

La voiture connectée : un objet au cœur d’interactions multiples

Divertissement, extension du smartphone, mobilité partagée, gestion de vie de la voiture … Les utilisateurs sont demandeurs de nouvelles expériences et ces services et applications engendrent de multiples interactions. On peut ainsi imaginer une voiture communicante capable de trouver une place de parking libre, planifier automatiquement un rendez-vous pour sa maintenance ou déclencher un feu au vert à son passage. Depuis le 1^er avril 2018, tous les nouveaux modèles de véhicules doivent d’ailleurs posséder un système d’appel d’urgence et de géolocalisation pour contacter les secours en cas d’accident. A ce titre, ils sont déjà « connectés ».

Les constructeurs et autres acteurs se saisissent déjà de cette opportunité de maintenir une relation étroite avec les clients tout au long du cycle de vie du véhicule. Ils deviennent ainsi des « fournisseurs de services et de solutions mobilités », s’appuyant entre autres sur les données collectées. D’autant plus que cette connectivité constitue une étape vers l’autonomie, le véhicule ayant besoin de pouvoir communiquer avec ses homologues et avec l’environnement. Le mouvement est en marche et va s’amplifier progressivement.

Cependant, le constat est aujourd’hui sans appel : la problématique de cybersécurité n’est pas ou peu prise en compte, alors qu’elle doit être partie intégrante de la solution connectée, dès sa phase conception et jusqu’à la fin du cycle de vie. Cette réflexion est essentielle pour réussir à préserver l’intégrité du véhicule, la vie des passagers et respecter les réglementations en vigueur et à venir.

Le premier prérequis consiste à correctement appréhender les technologies et l’écosystème du véhicule connecté.

Comment le véhicule interagit-il avec son environnement ?

Un véhicule connecté est un véhicule qui possède la particularité d’être en interaction avec son écosystème, à courte ou à longue portée, via des flux de données mobiles.

• Connexion courte portée: Le véhicule interagit directement avec un objet (smartphone, infrastructure, etc.), sans intermédiaire. Il utilise des technologies avec un rayon d’action limité (WAVE, Wifi on board, bluetooth, etc.) avec des échanges en local.
• Connexion longue portée: Le véhicule utilise un accès distant pour interagir avec des éléments externes via une plateforme cloud. Les connections 4G et bientôt 5G sont les technologies de prédilection pour raccorder le véhicule à internet.

Ce concept de véhicule connecté englobe également les échanges avec l’environnement direct du véhicule sous le terme de «Vehicle-To-Everything » (ou V2X). Enfin, la norme ISO 20077 décrit l’« Extended Vehicle » (ou ExVe) comme étant un ensemble composé du véhicule physique ainsi que toutes les plateformes et infrastructures qui sont sous la responsabilité du constructeur automobile.

De nombreux écosystèmes et acteurs devront cohabiter

La voiture était autrefois un système très fermé ; à l’exception d’une prise diagnostique pour les garagistes et d’un peu de connectivité pour diffuser du contenu multimédia, le risque était jusque-là contenu. Aujourd’hui, la multiplication des éléments de connectivité et l’accès à internet ouvrent de nouvelles opportunités pour les constructeurs et fournisseurs de services, mais aussi pour une personne malveillante.

Le premier écosystème à considérer est celui du véhicule embarqué. Les systèmes électroniques et de communication doivent pouvoir communiquer entre eux sans que les données transmises ou les secrets stockés ne soient altérés ou dérobés. Parmi ces systèmes, on retrouve les ECU, ces mini « ordinateurs embarqués » qui pilotent des fonctions clés du véhicule telles que le système de freinage, la climatisation, l’éclairage, etc.

Au-delà de la sécurité embarquée, on retrouve les utilisateurs et le propriétaire (qui n’est pas forcément un particulier) bénéficiant de droits afin de donner des ordres au véhicule selon les règles prédéfinies. Dans le futur, leur authentification sera certainement primordiale pour des questions de responsabilités ainsi que la vérification de la légitimité des ordres qu’ils émettent.

Un autre aspect très important concerne les services connectés qui utilisent des plateformes centralisées, voire dans le cloud, mises en œuvre par les constructeurs ou par des partenaires. Ces plateformes représentent une menace importante car elles peuvent déclencher des commandes sur une flotte entière de véhicules, et donc avoir un impact démultiplié. Les constructeurs devront mettre en place des solutions sécurisées adéquates pour autoriser ces services, en combinant leur propre plateforme, celle des partenaires et les API sur le véhicule, et s’assurer du niveau de confiance de l’environnement.

Enfin, à moyen terme, les objets extérieurs et l’environnement proche (autres véhicules, garage, parking, infrastructure routière, etc.) devront communiquer et partager des informations. Les enjeux de sécurisation en temps réel (disponibilité, intégrité, etc.) seront alors des challenges complexes à relever.

Des enjeux cybersécurité : du monde virtuel à la réalité

La sécurité des hommes à l’intérieur et à l’extérieur du véhicule est une préoccupation de tout premier plan pour le secteur automobile. Il serait donc logique de penser que les problématiques de cybersécurité soulevées par le véhicule connecté seront traitées avec la même rigueur, dans le but de garantir les fonctions de safety et d’intégrité de la voiture.

Le premier enjeu est un défi organisationnel à relever pour tous les acteurs et notamment les constructeurs, car l’avènement de ce nouveau modèle provoque la réunion de deux mondes opposés : d’un côté, celui des services et de l’autre celui de l’ingénierie. Le premier est tout en agilité et rapidité, avec de très nombreux projets à court terme. Le second, avec un cycle de développement plus long, doit répondre à des exigences en matière de safety et de qualité afin de permettre l’homologation du véhicule. Cette dichotomie a des impacts sur la cybersécurité et notamment son intégration dans les projets, ou encore la couverture du risque end-to-end. Par exemple, le backend devient, de par sa position, un point névralgique à sanctuariser pour éviter tout risque d’attaque systémique avec des répercussions sur l’ensemble de la flotte. Malheureusement sa sécurité n’est aujourd’hui pas appréciée à sa juste valeur, principalement pour des exigences de time-to-market très court.

En ce qui concerne les autres enjeux, force est de constater que les thématiques de cybersécurité pour le véhicule connecté ne diffèrent pas beaucoup de celles que l’on connait dans le monde SI : gestion des identités et des accès, détection et réponse, sécurité des infrastructures, cryptographie, gestion des parties tierces ou encore patch management… Un véhicule connecté est un SI « mobile », et les différentes normes de sécurité (ISO2700x, NIST 800, etc.) sont déjà déclinées sous forme de bonnes pratiques dans différents guides et référentiels (SAE J3061, AUTOISAC, NHST, etc.) et seront prochainement l’objet de la norme ISO/SAE 21434.
Cependant, un certain nombre de contraintes inhérentes au véhicule et aux systèmes embarqués impliquent de considérer ces sujets sous des angles spécifiques et originaux.

La mobilité et la connectivité du véhicule complexifient sa sécurisation : il faut prévoir la sécurité dans un contexte de connexion limité ou inexistante, avec un environnement changeant. L’aspect réglementaire n’est pas en reste, le véhicule étant amené à se déplacer à l’international.

Le monde de l’embarqué pose également des restrictions sur le matériel, en termes de coût, de puissance de calcul et d’encombrement.

La question de la mise à jour des composants et des services se pose vis-à-vis d’un système devant fonctionner à tout moment mais pouvant aussi être arrêté sur de longues périodes.

Enfin, le véhicule est promis à un cycle de vie long, ce qui implique de penser dès le début sa sécurité notamment par rapport à la gestion des identités et des accès. Cette durée de vie impose aussi de réfléchir à des standards évolutifs dans le temps, ainsi qu’à un modèle de mises à jour garantissant la sécurisation du véhicule de manière durable et soutenable pour les constructeurs.

La route est longue et la cybersécurité s’invite à un carrefour où on ne l’attendait pas il y a une dizaine d’années encore. Il est urgent que chaque acteur réalise l’importance de l’effort demandé et commence à prendre le virage dès maintenant, avant qu’il ne soit trop tard.

Cet article Saga 1/3 : La voiture connectée, entre cybersécurité et safety 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.

Entre 50 et 70 milliards d’objets connectés dans le monde à horizon 2020

La plupart de ces objets connectés seront portés sur les individus (wearables) ou utilisés quotidiennement. Parmi ceux qui sont au cœur de l’actualité de l’International CES 2015, on peut citer le cuissard connecté de Cityzen Sciences ou la brosse à dents connectée pour enfants Vigilant Rainbow. Ces objets produisent automatiquement des données concernant notre corps et notre mode de vie qui, considérées individuellement, peuvent sembler anodines. Mais la finalité assumée par les services de quantified self est le recoupement des données collectées qui peut mener à un certain nombre de corrélations et définir des tendances générales sur la santé des personnes.

Donnée de santé ou donnée de bien-être ?

Les données produites par des objets connectés peuvent être distinguées en deux catégories : les données de santé et les données de bien-être. La frontière entre ces deux types de données est à ce jour encore floue du fait de l’absence de définition précise de la donnée de santé. Ceci rend difficile l’application d’une réglementation à ces données issues d’objets connectés.

Les données de santé à caractère personnel, « recueillies ou produites à l’occasion des activités de prévention, de diagnostic ou de soins » ( Art. L. 1111-8 du Code de la Santé Publique ) sont soumises à un certain nombre de réglementations, notamment concernant leur hébergement. Les hébergeurs de données de santé doivent assurer un niveau de protection maximal face à ces données, considérées comme sensibles. Mais que dire des données recueillies par un bracelet connecté ou une application mobile ? Doivent-elles être soumises à cette réglementation puisqu’elles portent plutôt sur le mode de vie des utilisateurs ? Ce sont les questions que se pose aujourd’hui la Commission Nationale de l’Informatique et des Libertés (CNIL) qui se penche sur l’utilisation et la sécurisation de ces données.

La CNIL redoute les dérives du quantified self

La CNIL redoute que les données collectées par des objets connectés ne soient utilisées à titre commercial. L’encadrement de la protection et de l’utilisation de ces données est aujourd’hui nécessaire pour éviter les dérives. Les 16 et 17 septembre 2014, les autorités de l’Union Européenne de protection des données ont adopté un avis sur l’Internet des objets. Il propose des recommandations pratiques aux acteurs (fabricants d’appareils, développeurs d’applications, plateformes sociales, etc.) pour se conformer au cadre réglementaire européen sur le traitement des données collectées par des « objets intelligents ». Les recommandations mentionnent à la fois les obligations des acteurs, les droits des utilisateurs et les mesures de sécurité à mettre en œuvre. En particulier, recueillir le consentement des utilisateurs et leur permettre de rester maîtres du partage de leurs données, sont des actions qui rassurent leurs utilisateurs clients. En suivant ces recommandations des autorités européennes, les acteurs peuvent disposer d’un avantage concurrentiel.

Les objets connectés sont de plus en plus « proches » de notre corps pour nous permettre de mieux nous connaître, par des mesures continues et automatiques. Nous arrivons aujourd’hui à une nouvelle conception de l’individu, fait d’un corps et de données. La question aujourd’hui est de savoir jusqu’où ira cette volonté de connaissance de soi et si nous serons dépendants de ces objets connectés qui nous entourent au quotidien ou réactifs face aux risques qu’ils impliquent.

Cet article Quantified self : jusqu’où aller pour mieux se connaître ? est apparu en premier sur RiskInsight.

Capitaliser sur leurs forces et leur légitimité pour proposer des offres à forte valeur ajoutée

 Pour gagner leur place dans ce marché en construction et convaincre les consommateurs, les assureurs doivent proposer de nouveaux produits offrant une proposition de valeur forte et différenciante, fondés sur une tarification personnalisée, un univers de services proposant un accompagnement complet et une nouvelle expérience client. Ils y parviendront en capitalisant sur leur légitimité, en automobile et en MRH d’abord.

Dans le domaine plus complexe de la santé, ils doivent saisir l’opportunité offerte de jouer un rôle central dans la prévention, les parcours de soin et le maintien à domicile des personnes dépendantes. Leur légitimité sur le sujet reste cependant à construire. Elle s’imposera via de nouveaux partenariats (avec les pouvoirs publics, les professionnels de santé, des partenaires technologiques innovants) et, là encore, en capitalisant sur leurs offres existantes (programmes de prévention, téléassistance…).

Gagner la confiance des consommateurs

« Connecté, donc plus de vie privée… » : un exemple de réaction qui traduit le sentiment général vis à vis des objets connectés. Les inquiétudes suscitées auprès du grand public par l’usage des données personnelles collectées par les objets connectés constituent un des freins majeurs à leur développement. Comment convaincre les clients de passer outre cette méfiance, de s’équiper d’objets connectés et, surtout, de confier ces données à leur assureur ? En les rassurant sur leurs usages : les données sont utilisées dans leur intérêt (améliorer leur qualité de vie, leur proposer des tarifs plus avantageux…) et en toute sécurité (données anonymisées, chiffrées, supprimées rapidement…). Autrement dit, pour lever ces inquiétudes, les assureurs devront proposer à leurs clients un véritable contrat de confiance. Il définira clairement l’usage qui sera fait des données collectées, les modalités d’accès et le droit à leur effacement, tout en garantissant leur sécurité.

En définitive, quatre axes doivent être privilégiés par les assureurs dans ce domaine : construire une offre transparente, prendre en compte le respect de la vie privée dès l’élaboration de l’offre, se mettre en conformité avec la législation et notamment la loi Informatique et Libertés, et enfin sensibiliser les utilisateurs aux mesures de sécurité indispensables à la protection de leurs données.

Créer ou s’inscrire dans de nouveaux écosystèmes

Si l’assureur est légitime sur son marché et qu’il a une proposition de valeur forte, une intégration de la chaîne de valeur peut être légitime. Cette stratégie lui permettra de garder la maîtrise de son offre et des gains qu’elle génère. En revanche, si la légitimité de l’assureur reste à asseoir et si sa proposition de valeur repose essentiellement sur des services venant compléter ceux déjà portés par un objet connecté, alors l’assureur choisira la stratégie inverse : mettre en avant l’objet, capitaliser sur la marque de son fabriquant, quitte à moins maîtriser la chaîne de valeur.

Quoi qu’il en soit, sur ce marché encore en construction, les assureurs devront multiplier les initiatives et les partenariats avant que des standards technologiques et commerciaux n’émergent. Créer ou s’intégrer à de nouveaux écosystèmes, avec des acteurs différents des partenaires habituels des assureurs (start-ups innovantes, industriels, collectivités locales, spécialistes de la relation client…) et reposant sur de nouveaux types de partenariats, constituera une des clés du succès.

Adapter leurs méthodes de travail et leurs systèmes d’information

La révolution des objets connectés sera aussi une révolution interne aux organisations. Elle implique notamment de modifier les méthodes de création et de lancement d’offres, via des équipes plus agiles, associant experts marketing, juridiques, techniques et de la sécurité ; changer les techniques actuarielles pour prendre en compte de nouvelles données, plus nombreuses, moins structurées ; adapter les circuits de distribution pour pouvoir proposer des objets physiques et toucher de nouveaux publics ; adapter les systèmes d’information pour pouvoir collecter, stocker et traiter les données issues des objets connectés et en garantir la sécurité. Autant de challenges à relever pour ne pas se laisser distancer et prendre une place de choix sur ce marché.

Pour approfondir le sujet, découvrez notre synthèse Solucom : « Assurance : comment négocier le virage des objets connectés ? »

Cet article Assurance : 4 clés pour relever le défi des objets connectés 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.