IoT : pensez Cyber-as-a-Feature !

L'université de Singapour vient de découvrir 16 failles permettant de prendre le contrôle d'un appareil via Bluetooth en exécutant un simple code. Cette intrusion serait réalisable à l'infini ! Smartwatch, domotique, e-santé… L'internet des objets nous accompagne au quotidien. IDC prévoit 80 milliards d'appareils connectés d'ici 2025, soit 152 200 appareils par minute ! Pourtant, la plupart de ces terminaux restent peu sécurisés... Quels sont les bons réflexes à adopter dans leur conception ?

Les failles insoupçonnées  

Fin septembre 2021, Bobby Rauch, chercheur en sécurité, a pointé du doigt la sécurité des AirTags d’Apple qui pourraient être détournés afin d’aspirer vos données personnelles suite à une faille du mode perdu. Dans la même période, les chercheurs des universités de Birmingham et Surrey ont montré la possibilité de dérober n’importe quel montant d’une carte Visa depuis un iPhone verrouillé, en raison de failles supposées dans le protocole Apple Pay et dans l’infrastructure de paiement de Visa. La forte croissance de l’IoT conduit les industriels à investir massivement. Cependant, la sécurité des applications (web, mobiles, et embarquées) est souvent mise de côté par manque de connaissance d’une part, et par manque de ressources (financière et humaine) d’autre part. Or, concevoir un objet connecté est si complexe que les développeurs pensent d’abord à la fonctionnalité d’un objet avant sa sécurité. Cela est plutôt logique, mais c’est aussi très risqué ! Désormais, les concepteurs doivent penser “Cyber-as-a-Feature” (CaaF). La cybersécurité doit être une fonctionnalité à part entière de l’objet connecté. Voire un argument marketing.

La sécurité : une priorité avant même la conception

Lorsque l'on parle de sécurité, il faut toujours réaliser une analyse de risque préalable. Ces risques sont souvent déterminés par la localisation physique de notre application et ses interactions avec l'extérieur : si je développe un objet connecté qui communique par Bluetooth, alors un attaquant devra être dans un périmètre de 10m autour de mon objet pour essayer de se connecter à mon objet. Dans ce cas, mon objet est peu exposé aux risques, car il est compliqué et souvent peu rentable pour un attaquant de se déplacer lui-même et de trouver une faille de sécurité. Au contraire, si je conçois un objet qui peut se connecter à Internet, le monde entier pourra potentiellement accéder à mon application. La conception d’application et d’objets connectés doit passer par une approche "Secure by Design" : quel que soit le code ajouté pour améliorer le produit, l’architecture de l’application doit être conçue pour prévenir toute faille technique ouvrant la voie à une intrusion ou l'accès aux données personnelles. 

Le choix du langage approprié

Certains langages sont plus exposés aux risques d’attaques. Javascript est l’un des langages web les plus utilisés au monde. La surface d’attaque est donc plus importante. A contrario, Rust ou Kotlin ont été pensés pour faciliter la prise en compte des bonnes pratiques des règles de sécurité. Les applications faites avec Rust sont - au moins dans une certaine mesure - "Secure by design" car le langage comporte une feature de "memory-safety" empêchant un programme externe d’accéder aux variables de l’application.

Les défis de sécurité sont multiples : former les concepteurs et développeurs de ces objets, intégrer la sécurité “by design” lors du développement des futurs terminaux, superviser leur sécurité après leur lancement, définir des standards, mettre à jour les firmware des objets déjà déployés etc.