IoT : Risques, enjeux et solutions

Bien que les objets connectés soient présents partout dans notre entourage, il est bien plus difficile d’en donner une définition précise tant ils diffèrent. En effet, on regroupe sous IoT ou Device IoT des produits du simple « gadget » telle qu’une balance connectée à un système industriel gérant un processus complexe tel que le contrôle d’un réacteur d’avion.

Mais bien qu’ils soient très différents en termes d’architectures matérielles, de fonctions qu’ils réalisent, ou encore des exigences auxquelles ils doivent répondrent, il n’en reste pas moins que tout objet connecté est, avant tout, un système « embarqué ». Comme tout système embarqué, on peut le décomposer en deux parties : une partie matérielle (électronique) et une partie logicielle (application) dont la fonction première est d’assurer la gestion d’un processus. En cela rien de nouveau puisque cela exite depuis des décennies. 
De même, la notion de « réseau » n’est pas en soit une nouveauté dans les systèmes embarqués. La conception de systèmes distribués (plusieurs calculateurs connectés entre eux) est une architecture utilisée et maitrisée depuis longtemps. Mais la particularité de ces « réseaux » est qu’ils sont généralement dédiés (bus de terrains types liaisons Série, CAN, Ethernet, ...), majoritairement filaires et fermés. De même, les protocoles de communication utilisés sur ces réseaux industriels (Modbus, CANopen, Devicenet, Ethercat, EthernetIP, …) sont d’une utilisation plus « confidentielle ».

Il en résulte que, jusqu’à récemment et bien qu’ils soient éventuellement en réseau, les systèmes embarqués actuels évoluaient en vase clos. Un parfait exemple étant l’automobile : quasiment la totalité des calculateurs sont interconnectés entre-eux (via le bus CAN principalement) mais jusqu’à présent aucune connexion vers l’extérieur du véhicule n’était possible.

L’évolution IoT est justement la connexion de ces équipements à des réseaux extérieurs ou ouverts, qu’ils soient publics tel que Internet ou dédiés tels que LoRa ou Sigfox, voire le SI de l’entreprise lui-même connecté au monde extérieur. L’autre particularité est que bon nombre de ces connexions sont des connexions sans fil (wireless).

Le risque principal de cette interconnectivité, notamment via internet, est l’accès non autorisé au système embarqué. Connecter un équipement quelqu’il soit à un réseau ouvert, c’est mettre une porte d’entrée sur son système. Dès lors, le système lui-même devient visible pour l’ensemble des équipements connectés au réseau et pas uniquement auprès de ceux avec qui il doit communiquer.
Dans le cas d’une connexion internet, cela revient à rendre visible son système potentiellement au monde entier. Il est donc crucial non seulement de contrôler l’accès au système, mais également d’être à même de détecter des tentatives d’accès non autorisées.
Un exemple illustrant cette importance est la faille OPM en 2015 (Bureau de la gestion du personnel aux USA). Plus de 21 Millions de dossiers personnels (notamment de personnes demandant des accréditations d’accès à des ressources de sécurité) ont été dérobés. L’intérêt de ce rapport est que la faille n’a été détectée que plus d’un an après l’intrusion dans le système. L’autre point marquant est que les pirates se sont servis d’un premier point d’accès pour installer une porte dérobée afin d’accéder à des niveaux plus confidentiels de l’OPM. Cela montre que dans le domaine de la sécurité, les pirates s’attaquent d’abord aux systèmes les plus faibles afin de les utiliser comme points d’entrées sur des systèmes plus sécurisés.

Un autre exemple est le malware MIRAI dont les cibles principales sont les objets connectés. Le but de MIRAI est d’utiliser les systèmes faillibles pour les intégrer (lui et les autres systèmes connectés) à un Botnet permettant ainsi de disposer d’une puissance de feu pour lancer des attaques DDOS (Distributed Denial of Service). Dans un bulletin d’alerte d’octobre 2016(1), l’ISC-CERT (Industrial Control System Cyber Emergency Response Team) indique ainsi qu’un fabricant leur a signalé que certaines de ses passerelles cellulaires pour les objets connectés seraient susceptibles d’être infectées par ce malware. En utilisant les fonctions de mises à jour du firmware à distance, MIRAI récupère une version modifiée permettant la prise de contrôle de l’équipement et potentiellement des devices qui y sont reliés.
MIRAI montre bien la problématique de fond sur la sécurité dans l’IoT : tout système industriel connecté qui présente une faille de sécurité, peut être utilisé comme munition pour une attaque malveillante de plus grande envergure.
Lors de la conception d’un produit destiné à être connecté, la question en termes de sécurité n’est pas seulement de faire une analyse de risque par rapport à la criticité d’une attaque et des conséquences sur le produit lui-même (vol de données, arrêt du service, etc), mais également en termes d’utilisation frauduleuse du produit. Ce dernier point posant, entre autres, comme question la notion de responsabilité : quelles seraient les conséquences (pénales, financières, commerciales) si le produit que l’on a conçu est, en raison d’une faille de sécurité, responsable d’une malveillance sur un système tiers ?

N’évoluant pas dans un monde parfait, il n’y a pas une solution unique et définitive réglant une fois pour toutes la problématique de sécurité pour les systèmes embarqués. D’une part, les systèmes embarqués sont, par nature, très différents les uns des autres, que ce soit en termes d’architecture matérielle, d’architecture logicielle ou de ressources disponibles. D’autre part les écosystèmes dans lesquels ils évoluent sont également différents suivant les produits et les métiers. Enfin les attaques ont de multiples facettes et évoluent en permanence et c’est toujours l’éternelle course entre le gendarme et le voleur. 
Dès lors, les solutions et techniques de protection sont multiples et doivent être évolutives. On retrouve donc pour l’embarqué les mêmes principes de sécurité que pour les Systèmes d’information (SI). De même, si protéger les équipements est une nécessité, il ne faut pas oublier non plus que la première faille de sécurité (volontaire ou non) est l’homme. Pour un système connecté, il est donc également nécessaire d’éduquer les utilisateurs et de protéger l’accès physique à l’équipement.

Si d’autres problématiques doivent être prises en compte (par exemple une certification pour un domaine industriel donné), ce dossier se concentre sur les différents aspects de la « cybersécurisation », pour lesquels on peut définir les points clés suivants :

La sécurité doit intervenir dès la conception du produit : Secure by Design.
Un code non maitrisé c’est une faille de sécurité potentielle. Pour ce faire il faut mettre en place un Plan d’Assurance Qualité Logiciel (PAQL) :

• Suivre et appliquer les normes sécurité (ISO2700x, EDSA, ISA/IEC62443, …) qui apparaissent et donnent des recommandations (voir imposent pour certaines certification sécurité) utiles pour les logiciels
• Définir des méthodologies de développement, gérer les exigences
• Vérifier/tester le code : couverture structurelle, analyse statique des sources, des binaires, des COTS

Spécialiste de l’Assurance Qualité Logiciel, l’équipe de la BU AQL d’ISIT sera à même de vous aider à faire l’analyse des risques, définir votre PAQL, vous former sur les normes sécurité et vous indiquer les outils permettant d’automatiser tout ou partie de ces tâches.

Des mécanismes de protection doivent être intégrés dans le produit dès sa conception. Si le degré de protection dépend de la criticité du produit dans l’écosystème dans lequel il opère, tout ou partie des points suivants sont à prendre en compte :

• Protéger les communications (Chiffrement)
• Authentifier/contrôler les accès à distance (certificats, gestion des clés)
• Protéger/contrôler l’accès physique à l’équipement (login, mot de passe)
• Sécuriser le cycle de démarrage (boot secure) et les mises à jour (secure update)
• Implémenter un firewall / filtrer les connexions
• Détecter / Signaler les intrusions et tentatives d’intrusions
• Gérer les alertes (journaux d’évènements), intégration aux SIEM (Security Information and Event Management)

Experte dans les outils pour le Temps Réel Embarqué, l’équipe de la BU TRE d’ISIT peut vous proposer une gamme complète de librairies et plateformes logicielles vous permettant d’intégrer ces différents blocs sécurisés dans votre logiciel

Une des problématiques de la sécurité dans les systèmes embarqués est que bien souvent on souhaite ou on doit connecter un produit existant non sécurisés ou un ensemble de produits non sécurisé d’un réseau local à un réseau ouvert. Dès lors il devient nécessaire de protéger ce ou ces produits immédiatement, sans attendre la refonte ou l’évolution des produits concernés (approche souvent impossible techniquement ou financièrement).
La solution est d’insérer dans la chaine un système autonome sécurisant l’ensemble :

• Firewall Matériel
• Passerelles/switch sécurisés

Spécialisée dans les Réseaux Industriels et Automates, l’équipe de la BU RI&A d’ISIT dispose des passerelles sécurisées permettant de filtrer et contrôler les communications entre votre produit/réseau local.

Une fois le nouveau produit connecté totalement fiabilisé, reste à s’assurer que la production ne permettra pas d’introduire des failles ou de contourner les sécurités mises en place à la conception. De nouvelles fonctions sont ainsi intégrées dans les équipements de programmation destinés à la production pour compléter cet arsenal.
Contactez l’équipe de la BU Production & Tests pour plus d’informations sur ce sujet.