Les objets connectés dont on entend surtout parler vont du plus WTF [UNICORN] à la smart, car [NISSAN] en passant par des choses touchant à la sécurité physique [EXTINGUISHER] et d'autres permettant de mieux gérer ses dépenses en énergie [NEST]. Ces usages grand public vont aussi avoir des impacts sur le système d'information des entreprises, même si vous laissez tous vos bidules connectés à la maison avant d'aller travailler...
1. L'Internet des objets en entreprise
Dans la suite de cet article, nous entendons un objet connecté comme un objet répondant à un besoin précis, dans un contexte donné, permettant de connecter le monde physique en le mesurant et/ou en agissant dessus, n'embarquant que peu d'intelligence et étant connecté à une chaîne de management (définie dans la suite). Concernant ces deux derniers points, certains objets tels les smart cars peuvent être vus comme une chaîne de management en eux-mêmes. Un peu à la façon d'une matriochka.
Les premiers objets connectés que l'on va retrouver en entreprise sont ceux qui lui appartiennent et font partie de son système d'information. On y retrouvera entre autres :
- le parc de véhicules ;
- le matériel de contrôle d'accès comme les serrures et les badgeuses ;
- toute la domotique des locaux : la gestion de l'éclairage, de la température, de l’arrosage, etc.
Un autre type d'objet apparentant à cette catégorie, même s'ils proviennent de l'extérieur, sont les objets BYOD, ou plutôt BYOIoT (Bring Your Own IoT) tels que les wearables (objets que l'on porte sur soi) des salariés, leur voiture et tout autre objet qu'ils pourraient connecter au SI.
D'autres objets vont être amenés à entrer en contact avec le SI de l'entreprise, ceux qui proviennent de l'extérieur. On pensera par exemple aux wearables des visiteurs et à leur smart car, qui sont finalement les mêmes que les objets BYOIoT, mais non intégrés au système d'information.
2. Système d'information, petit rappel
La finalité d'un SI, qu'il appartienne à une entreprise ou non, est de permettre le stockage, le traitement et la distribution d'information.
Mais ce qui va surtout nous intéresser est les différents éléments qui le composent, à savoir du matériel et du logiciel de différentes générations interconnectés les uns avec les autres, des processus indiquant comment gérer l'information et enfin des utilisateurs pour le faire fonctionner. Le tout fonctionnant dans une relative cohérence, mise en péril à chaque fois qu'un de ces éléments est modifié. C'est le cas ici, avec l'arrivée de l'Internet des objets.
3. Ce qui change avec l'Internet des objets
Actuellement, le nombre d'ordinateurs ou assimilés (on pensera notamment aux smartphones) par personne, toujours dans un contexte entreprise, reste assez faible. Rien qu'en reprenant les quelques types d'objets listés précédemment, on s’apercevra que ce nombre est amené à augmenter significativement, surtout si on ajoute à cette liste tous les objets de santé permettant au personnel de santé de suivre leurs patients à distance.
Une autre spécificité des objets connectés, que l'on retrouve aussi, dans une moindre mesure, avec les smartphones est le contrôle que les constructeurs exercent sur les devices. Celui-ci se fait au niveau de la disponibilité de mises à jour, de la continuité de service, de l'accès aux interfaces utilisateur, etc. Ce contrôle peut, dans certains cas, avoir des conséquences assez désagréables pour les utilisateurs finaux [HUMMUS].
Toujours en reprenant les quelques exemples d'objets présentés en début d'article, on pourra noter, en plus de la variété de cas d'usages, une certaine hétérogénéité dans les plateformes et technologies utilisées. En termes de technologies de communication, on trouvera aussi bien du filaire que du sans fil (BLE, WiFi, 3G/4G, LoRa, SigFox, NFC, ZigBee, etc.) en fonction des besoins liés aux cas d'usage (longue ou courte distance, consommation électrique, fréquence de communication, taille des données à transmettre, mobilité ou non de l'objet, etc.). La même variété existe aussi pour les côtés matériels et logiciels des objets, toujours en liaison avec le cas d'usage.
Figure 1 : Chaîne de management utilisée pour l'Internet des objets.
Le dernier point de différence touche à la chaîne de commande (voir figure 1), chacun de ses composants répond à un besoin particulier :
- les objets agissent sur le monde physique et/ou le mesurent. En fonction des ressources disponibles (de très contraintes à l’équivalent d’un ordinateur), les mesures de sécurité qui y sont implémentées peuvent varier du tout au tout (aucune défense, protections physiques, chiffrement des données locales, etc.) ;
- dans certains cas, l'objet passe par un collecteur pour communiquer avec le reste de la chaîne. C'est par exemple le cas d'un grand nombre de wearables qui utilisent le smartphone de l'utilisateur comme point de collecte. Ce point de collecte peut prendre différentes formes (application spécifique ou boîtier dédié) et cela va influer sur les mesures de sécurité qui y seront implémentées (qui vont se rapprocher de celles qu'il est possible de mettre en place sur les objets) ;
- la couche de transport permet aux objets de communiquer avec le reste de la chaîne, les technologies utilisées pouvant être très variées, les mesures de sécurité que l'on pourra y appliquer vont l'être aussi (cryptographie ultra légère, XOR, détection d'erreurs) et comme à chaque fois dépendre des cas d'utilisation ;
- la partie management offre le stockage et le traitement des données remontées par les objets. On pourra par exemple l'héberger dans un nuage et y appliquer les mesures liées à ce type d'environnement ;
- enfin, la chaîne offre des API et/ou des interfaces graphiques (web, application smartphones, etc.). Celles-ci permettent aux utilisateurs et à d'autres chaînes de managements ou logiciels d’interagir avec le système. Les principales menaces pesant sur cette partie-ci sont celles listées dans le Common Weakness Enumeration [CWE].
La principale difficulté consiste à garder une cohérence et un bon niveau de sécurité sur tous les niveaux, et ce malgré la forte hétérogénéité en termes de technologies.
4. Périmètres existants
L'utilisation de la défense en profondeur et de la défense périmétrique permettent d'isoler efficacement le SI d'une entreprise de l'extérieur ainsi que, au besoin, ses différents composants. Pour rappel, la défense en profondeur consiste à « empiler des couches », à la manière des feuilles d'un oignon pour assurer une certaine protection. La défense périmétrique, quant à elle, repose sur le découpage du réseau de manière à pouvoir mieux gérer les accès aux différentes ressources de l'entreprise.
Figure 2 : Exemple d'entreprise vue par son réseau.
La figure 2 représente une entreprise vue par l'organisation de son réseau et servira d'exemple dans la suite de l'article. On remarquera la présence d'une zone démilitarisée (DMZ) faisant office de zone tampon entre l'Internet et le réseau interne, lequel permet d'accéder à un réseau restreint.
5. Dépérimétrisation
5.1 Risques liés aux objets internes
Figure 3 : Réseau d'entreprise intégrant un extincteur connecté.
Pour communiquer avec le reste de la chaîne de management, un objet doit pouvoir se connecter (sic) à Internet via le réseau de l'entreprise (voir figure 3). Autrement dit, cela signifie que toutes les données remontées par les objets, telles que des indicateurs de présence, des relevés de température, etc. sortent du périmètre de l'entreprise pour aller sur les serveurs du fournisseur de l'objet. Pour ce qui est des ordres, ils descendent du fournisseur vers l'objet en prenant le chemin inverse. La question de la propriété des données, de leur confidentialité, de leur utilisation et de la juridiction dans laquelle elles sont stockées doit aussi être posée. Concernant les objets capables d'agir sur leur environnement, la question de la responsabilité se pose : à qui la faute dans le cas d'une action non souhaitée ? Un autre point concerne la perte de la connexion entre l'objet et le reste de sa chaîne de management, y a-t-il un comportement par défaut de prévu ? L'objet reste-t-il utilisable et dans quelle mesure ou devient-il une brique [HUMMUS] ?
L'objet constitue donc une porte d'entrée privilégiée vers le SI, depuis la chaîne de management détenue par son fournisseur. C'est exactement ce qui s'est passé dans le cas de l'attaque de Target, fin 2013, où les attaquants ont tout d'abord attaqué le prestataire gérant les systèmes de climatisation pour ensuite rebondir sur le SI de la chaîne de grande distribution. C'est grâce à la connexion directe des systèmes de climatisation au réseau de l'entreprise que cela s'est avéré possible [TARGET]. En reprenant l'exemple donné en figure 3, la compromission du fournisseur permettrait à un attaquant de contourner la DMZ et d'arriver directement dans le réseau interne de l'entreprise. Il lui serait ensuite possible de rebondir sur d'autres équipements y étant connectés, qu'il s'agisse d'autres objets connectés, d'équipements réseau (pour tenter de pénétrer dans le réseau restreint par exemple), d'imprimantes, etc.
La sécurité du système d'information dépend aussi de celle des chaînes de management des objets que l'entreprise utilise en son sein.
5.2 Risques liés au BYOIoT et aux objets de l'extérieur
Les objets de type BYOIoT, tout comme ceux n'ayant pas été enrôlés dans le SI constituent une jonction entre la sphère personnelle et la sphère professionnelle. De la même manière que pour les objets appartenant à l'entreprise, les questions relatives aux données sont à se poser. Il y a tout de même une particularité pour les objets BYOIoT concernant l'utilisation professionnelle ou personnelle au moment de la collecte des données. La question de l'espionnage doit aussi être posée. En effet, il peut être difficile, voire impossible de demander à chaque personne entrant sur le périmètre (physique) de l'entreprise de laisser ses objets à l'entrée (un pacemaker en est un bon exemple), afin d'éviter qu'ils ne captent des informations ne devant pas sortir de l'entreprise. On notera que certains objets comme l’une des premières montres connectées de Samsung proposaient une caméra directement dans son bracelet [SAMSUNG]. La fonctionnalité semblait intéressante au premier abord, mais très dérangeante d'un point de vue vie privée et confidentialité.
L'autre risque que cela introduit vient de la possibilité de connecter ces objets directement à des équipements appartenant au SI, que ce soit physiquement ou over the air. Le cas le plus facilement envisageable est la recharge d'un objet : la durée d'une charge étant une des grosses faiblesses des wearables, il est nécessaire de les recharger assez régulièrement, la plupart du temps via USB. Ainsi, on pourrait très bien voir arriver avec les objets connectés les problèmes que nous avons déjà avec les clés USB et smartphones [PLANE], qui peuvent jouer le rôle de vecteur d'infection et être mis à contribution pour attaquer le système d'information.
Concernant les connexions « sans fil », leur particularité vient du fait qu'elles ne sont pas visibles à l’œil nu : cela les rend plus facilement dissimulables. De plus, elles peuvent offrir des possibilités intéressantes comme celles de scanner les différents devices utilisant la même technologie pour communiquer, ou bien exploiter des vulnérabilités à distance (c'est pour cela que l'ancien vice-président étasunien Dick Cheney avait fait désactiver les fonctionnalités sans fil de son pacemaker [CHENEY]). Afin de bien illustrer les dangers liés au « sans fil », faisons abstraction de tout le côté technologique et prenons l'exemple de l'arrivée au bureau, pour commencer sa journée de travail. Il est alors courant de saluer ses collègues, en leur serrant la main. Il arrive que certaines personnes, bien qu'étant malades, continuent à observer ce rituel et contaminent leurs collègues de travail. Si nous revenons maintenant à nos moutons, la figure 4 détaille ce qui pourrait se passer avec un objet connecté : son porteur se déplace avec sur tout le périmètre de l'entreprise et contamine/scanne tout ou partie de l'entreprise.
Figure 4 : Contamination du système d'information par un objet BYOIoT.
5.3 Risques liés au multi-management d'objets
Figure 5 : Exemple de multi-management d'objet connecté.
Cette façon de gérer les objets connectés peut s'avérer très intéressante dans le cas où plusieurs acteurs doivent pouvoir accéder directement aux ressources d'un même équipement. La figure 5 reprend l'exemple de l'objet appartenant au système d'information (voir figure 2) en lui ajoutant deux entités, à même de communiquer avec lui et de le gérer. Dans cet exemple, il semble en effet normal que le service assurant la sécurité des bâtiments ait accès à l'état des extincteurs en direct, quitte à passer par le fournisseur pour avoir accès à certaines fonctionnalités (même en cas de perte de connectivité avec l'extérieur, il faut que l'état des extincteurs reste accessible). L'idée est similaire avec les pompiers.
Dans le cas où l'objet n'est managé que par son fournisseur, celui-ci se trouve à la croisée de deux entités : l'entreprise et le fabricant. Avec le multi-management, l'objet devient un pont entre plusieurs entités, au nombre de quatre dans notre exemple : l'entreprise hôte, le service de sécurité, le fabricant et les pompiers.
Les risques identifiés dans le premier cas se trouvent alors amplifiés par la présence de ces deux entités supplémentaires : qui récupère quelle donnée ? pourquoi faire ? où la stocke-t-il ? etc. Pour un actionneur, la possibilité d'imputer une action sur l'environnement à une des entités est primordiale, d'autant plus que deux entités pourraient très bien émettre des ordres contradictoires. Toujours comme dans le premier cas, il reste possible d'utiliser l'objet pour rebondir d'une entité à l'autre, le nombre de cibles potentielles a juste augmenté avec le nombre d'entités pouvant manager l'objet. La sécurité de chaque entité est donc mise en péril par une potentielle insécurité des autres.
Les besoins fonctionnels et de sécurité de chaque entité étant différents, il est fort probable que leurs politiques de sécurité concernant l'objet le soient aussi. Ces collisions signifient donc la possibilité de gérer les droits finement sur les objets ainsi qu'une bonne traçabilité des actions qui y sont effectuées. Le principal problème que cela pose vient du déport d'une partie de l'intelligence de la chaîne de management vers l'objet. Compte tenu du nombre potentiel d'objets déployés, cela revient à décentraliser grandement une partie de la sécurité.
6. Pistes de recherche et solutions
6.1 Solutions à court terme
Les principaux problèmes qu'amènent l’utilisation d'objets connectés dans le cadre de l'entreprise touchent aux points de contact entre le système legacy et ces nouveaux équipements, la gestion des accès au legacy depuis ces équipements et donc les possibilités de compromission du réseau de l'entreprise.
Une solution relativement simple à mettre en œuvre pour limiter ces problèmes d'accès serait l'utilisation d'un réseau spécifique aux objets, à la manière d'un réseau invité Wi-Fi. Reste le problème des communications sans-fil, le brouillage semble être une solution un peu extrême qui pourrait perturber les systèmes déjà en place. Par contre, l'utilisation de chiffrement permettrait de résoudre les problèmes liés aux écoutes, mais cela ne peut pas être considéré comme une solution complète au problème. En effet, si nous prenons l'exemple d'une chaîne de management gérant des détecteurs de fumée et utilisant du chiffrement sur sa couche de transport, allumer un briquet sous un des détecteurs renverra une fausse information d’incendie, mais non espionnable du fait du chiffrement de la couche de transport. Il en serait bien évidemment de même pour les payloads transitant par cette couche.
6.2 Pistes de recherche
Il est d’usage de parler d’informatique et de chaîne de confiance, de démarrage sécurisé, de TPM [TCG], de code signé, d’analyse statique et dynamique de code, etc. L’ensemble de ces éléments concourt à la mise en place de systèmes de production fiables dans un environnement clos. Mais ces éléments, liés les uns aux autres, permettent-ils vraiment de bâtir des chaînes de confiance dès lors que des entités externes, non contrôlées, sont insérées dans les chaînes de productions des SI ?
Au lieu des chaînes de confiance, il semble que les environnements IdO nécessitent la mise en œuvre de chaînes de responsabilité, potentiellement dynamiques et de systèmes pour les gérer. Il semble en effet important de savoir :
- qui est responsable en cas de problème ?
- en quoi un fabricant d’extincteurs est-il responsable d’un DoS survenant sur le site de son client et prévenant toute détection d’incendie ?
- en quoi une attaque informatique chez un premier client impacte-t-elle la responsabilité du fabricant d’extincteurs par rapport au fait que les pompiers n’ont pas été avertis à temps d’un incendie chez un second client suite à la saturation de leurs réseaux, qui sont interconnectés aux extincteurs du premier client ?
- etc.
Si l’on combine ces concepts d’usages et d’impacts de l’IdO dans les SI avec les notions de virtualisation, alors l’établissement de chaînes de responsabilité devrait pouvoir se faire a priori (sécurité et responsabilité par conception), mais aussi a posteriori, suite à un incident (par analyse de la cause première), sur des topologies de réseaux mouvantes du fait des mouvements des objets connectés, BYOIoT, etc.
Une première thématique de recherche pourrait être la qualification de ces chaînes de responsabilités dynamiques en environnements évolutifs. Cette approche est intimement liée à la notion de management de la menace pour les SI actuels, laquelle intègre l’aspect mobilité des objets connectés et le fait qu’ils s’affranchissent de la sécurité périmétrique existante. Un exemple de menace pourrait être celle pesant sur un local technique à restriction d’accès, dont l’un des murs serait colocalisé avec un distributeur de boissons. Un des serveurs du local pourrait très bien être attaqué à distance (en cas de sensibilité à des stimulations) par un objet, BYOIoT ou externe, d’un des utilisateurs du distributeur lors d’une pause café. L’unique rôle du distributeur étant de rapprocher objets et serveur.
Toujours dans cette notion d’informatique de confiance pour l’IdO, il est courant de prendre comme exemple la santé et d’imaginer des systèmes extrêmement verrouillés et clos (opérés verticalement). Mais ces modèles fermés par essence ne s’appliqueront pas à la maîtrise des modèles ouverts auxquels une très grande majorité des entreprises vont être confrontés.
Une piste intéressante serait la mise à disposition, de manière libre et ouverte, des briques de base fournissant de la sécurité (via du confinement, de l’isolation des problèmes de sécurité de chacune des entités interconnectées sur un équipement) et pouvant être embarquées dans n’importe quel silicium ou circuit électronique. Il reste encore à définir les approches à privilégier, les modèles de sécurité à implémenter et les niveaux d’assurance à proposer.
À la lecture des différents exemples cités en début d’article, on notera qu’il y a plusieurs typologies d’objets connectés. Ceux-ci n’ont pas tous besoin des mêmes niveaux d’assurance, par rapport aux services rendus (un capteur de température peut être utilisé en domotique comme dans une chaîne de production de chimie industrielle, mais avec des besoins de sécurité différents). Une typologie, voire une taxonomie des besoins de sécurité de ces équipements, ainsi qu’un modèle de menaces et de risques sont aussi des référentiels nécessaires pour partager le même vocabulaire et les mêmes classes de problèmes à traiter.
Une autre dimension de recherche, nécessaire pour un usage massif de l’IdO (relais de croissance attendu, ou pas [EZRATTY], selon Gartner et d’autres cabinets), serait de résoudre le problème de l’administration à distance de ces équipements. Est-il concevable de penser que les objets connectés seront toujours capables de s’assurer de la légitimité des ordres qui leur seront envoyés ? Ces modes de management pourront-ils prendre en compte la pluralité des rôles et responsabilité que l’on pressent dans l’émergence de l’IdO ? Ces contrôles doivent-ils être confinés dans les équipements contenant souvent peu de ressources ou doivent-ils être externalisés vers des serveurs plus puissants et capables d’en faire l’analyse ? Peut-on, enfin, entrevoir des modèles libres et ouverts pour ces nouveaux modes de management ?
Conclusion
Nous avons présenté divers risques liés à l'intégration d'objets connectés au sein d'une entreprise via une dépérimétrisation, quelques solutions qu'il est possible d'apporter à court terme pour y remédier, au moins partiellement et des pistes pour de futures recherches.
En plus de l'objet, le système d'information de l'entreprise est connecté à une autre partie de la chaîne de management : les interfaces graphiques et API. On y retrouve les mêmes problèmes qu'avec les applications de type Software as a Service. Il convient alors aussi de porter une attention spécifique à cet autre point d'entrée.
Remerciements
Pour finir, nous souhaiterions remercier Jean-Philippe Gaulier, pour ses relectures attentives et conseils avisés.
Références
[UNICORN] Campagne de financement du projet Tootz the Unicorn : https://www.indiegogo.com/projects/tootz-the-unicorn#/
[NISSAN] Fiche produit de la Nissan LEAF : http://www.nissanusa.com/electric-cars/leaf/features/
[EXTINGUISHER] Fiche produit de l'extincteur connecté en-Gauge : http://www.engaugeinc.net/fire-extinguisher-monitoring
[NEST] Fiche produit du thermostat Nest : https://nest.com/thermostat/meet-nest-thermostat/
[HUMMUS] Arlo Gilbert, « The time that Tony Fadell sold me a container of hummus » : https://medium.com/@arlogilbert/the-time-that-tony-fadell-sold-me-a-container-of-hummus-cb0941c762c1
[CWE] Common Weakness Enumeration : http://cwe.mitre.org/
[TARGET] United States Senate, Commitee on Commerce, Science, and Transportation, « A “Kill Chain” Analysis of the 2013 Target Data Breach », 26 mars 2014
[SAMSUNG] Zach Honig, « Samsung unveils Galaxy Gear smartwatch with 1.63-inch AMOLED touchscreen, built-in camera, 70 apps » : http://www.engadget.com/2013/09/04/samsung-unveils-galaxy-gear/
[PLANE] Christoph Steitz, « German nuclear plant infected with computer viruses, operator says » : http://www.reuters.com/article/us-nuclearpower-cyber-germany-idUSKCN0XN2OS
[CHENEY] Dan Kloeffler & Alexis Shaw, « Dick Cheney Feared Assassination Via Medical Device Hacking: 'I Was Aware of the Danger' » : http://abcnews.go.com/US/vice-president-dick-cheney-feared-pacemaker-hacking/story?id=20621434
[TCG] Trusted Computing Group : http://www.trustedcomputinggroup.org/
[EZRATTY] Olivier Ezratty, « La grande intox des objets connectés » : http://www.oezratty.net/wordpress/2015/grande-intox-objets-connectes/
