Pourquoi le logiciel safety-critical devient un pilier de la révolution IoT

La prolifération d'appareils connectés apporte de nouveaux défis de sécurité, souvent imprévus, au paysage IoT.

Les applications safety-critical se sont appuyées sur le software depuis des décennies. Par exemple, le programme de vol Apollo lancé par le Président John F. Kennedy en 1961 incorporait du logiciel de vol embarqué pour guider les missions d'alunissage.

Si la cybersécurité domine fréquemment les manchettes, la qualité logicielle — particulièrement pour la sécurité — reste souvent sous-examinée. « Je pense que le monde software s'est réveillé à la sécurité. Je ne pense pas qu'ils se soient réveillés yet aux contraintes de sécurité », a dit Kate Stewart, senior director of strategic programs à la Linux Foundation et finaliste pour le IoT World Leader of the Year Award.

[IoT World is North America's largest IoT event where strategists, technologists and implementers connect, putting IoT, AI, 5G and edge into action across industry verticals. Book your ticket now.]

Dans l'IoT, la convergence des realms digital et physique transforme les opérations across secteurs — des dispositifs médicaux au gear militaire. Pourtant cette innovation fuel aussi une collision entre paradigms de développement, comme l'explique l'expert cybersécurité Bruce Schneier dans « Click Here to Kill Everybody: Security and Survival in a Hyper-connected World. »

Le développement Agile priorise vitesse et adaptabilité, alors que les domaines aérospatial, industriel et médical requièrent testing rigoureux, certification, et engineering licensed — un contraste highlighted par Schneier.

À la Linux Foundation, Stewart champions le Zephyr Project, un real-time operating system designed for safety et security sur devices resource-constrained.

« Dans Internet of Things, les gens focus leur lens sur ce qu'ils're comfortable with », a dit Stewart. « Je focus sur le deep embedded side et collecting data safely et securely. » Elle ajoute que beaucoup de standards de sécurité ont 20–30 ans et souvent lag derrière les pratiques software modernes.

Un défi clé est d'évaluer comment une mise à jour software pourrait inadvertamment créer des problèmes de sécurité. « Quand vous faites beaucoup de security updates to that software, does that invalidate your initial analysis ? What do you need to do to make sure that by applying a bug or security fix that you're not going to be making things worse ? We don't necessarily have the best tools right now for figuring that out », a expliqué Stewart.

Les standards de sécurité fermés ajoutent une autre couche de difficulté. « Il y a toute une série de [safety] standards right now que tout le monde looks to, et le challenge interesting from an open source perspective is that these standards are all closed », a noté Stewart. « Open source developers don't necessarily want to be paying $3,000 to look at the standards. »

Ces hurdles highlight le besoin de collaboration plus étroite entre régulateurs sécurité, autorités certification, et développeurs software. « We're working right now with people who specialize in safety et at the various certification authorities, as well as potentially some of the regulations to understand what's really important, et how we make safe software development practical for everyone », a dit Stewart.