Sécuriser l'open source dans l'IoT : atténuer les risques logiciels

Il y a maintenant 7 milliards d'appareils IoT dans le monde. Lev Lesokhin de CAST projette que ce nombre triplera d'ici 2025, atteignant 21,5 milliards de dispositifs. Cette croissance rapide a poussé les fabricants à lancer des produits plus vite que jamais, souvent au détriment de la qualité logicielle.

Pour accélérer le time-to-market, de nombreuses entreprises s'appuient sur des packages prêts à l'emploi des communautés open source comme GitHub et Apache. Pourtant, comme le montre le rapport 2018 Software Intelligence de CAST, une grande part de ces projets échouent à la conformité sécurité.

Le code open source vient rarement avec une sécurité robuste intégrée. Dans la précipitation de livrer, les entreprises peuvent faire l'impasse sur les revues de sécurité approfondies, laissant chacun des sept milliards d'appareils vulnérables aux attaquants.

Contrairement aux systèmes de transaction enterprise-grade, beaucoup de firmware IoT provient d'ingénieurs logiciels embarqués dont le focus principal est la fonctionnalité plutôt que la protection des données. Ce décalage signifie que de nombreux développeurs manquent des compétences spécialisées requises pour sauvegarder les données sensibles.

Puisque n'importe qui peut contribuer à l'open source, garantir que les standards de sécurité et qualité sont respectés est intrinsèquement difficile. Du code inefficace, bâclé, voire malveillant peut passer inaperçu.

Les acheteurs repèrent rarement ces faiblesses. Ils voient les appareils IoT comme outils d'efficacité business, pas comme vecteurs potentiels qui peuvent être armés contre leurs propriétaires.

Les yeux du monde sont sur votre code

Le code propriétaire in-house peut contenir des failles, mais seuls les développeurs contractuels les voient généralement. Le source propriétaire est privé et protégé des regards indiscrets. En contraste, l'open source est publiquement accessible — tout le monde, y compris attaquants potentiels, peut l'examiner avant qu'il ne soit incorporé.

En 2013, Target a subi une violation de cartes de crédit coûtant 220 millions $ (≈194 millions €) après que des attaquants ont exploité une faille dans son système de contrôle climatique. Les identifiants du fournisseur avaient été volés et laissés inchangés au déploiement, laissant chaque unité installée exposée.

Vérifiez-vous avant de vous wreck vous-même

Si les vulnérabilités ne peuvent jamais être éliminées entièrement, leur probabilité peut être réduite en suivant trois étapes clés :

1. Comprenez la lignée de votre logiciel. Les fabricants doivent savoir précisément quel code ils expédient. Utilisé responsablement, l'open source peut être inestimable, mais sa provenance doit être tracée à la source et croisée contre les vulnérabilités connues.

2. Allouez du temps suffisant pour la sécurité. Les correctifs post-fabrication sont coûteux et souvent inefficaces. L'incident Target illustre comme il est facile pour les attaquants d'exploiter des failles persistantes une fois un dispositif sur le terrain.

3. Effectuez une analyse de bout en bout. Scannez toute la codebase, adressez promptement les faiblesses signalées, et éliminez la dette technique. L'objectif : un système résilient protégeant les utilisateurs finaux pour des années.

En fin de compte, le fournisseur de contrôle climatique de Target reste sous enquête, avec des coûts continus autour de 18,5 millions $ (≈16,3 millions €). Un tel oubli coûteux peut — et doit — être évité.

Auteur de ce blog : Lev Lesokhin, EVP Strategy & Analytics chez CAST.