Security by Design : les règles à suivre pour les équipements de sécurité connectés

La sécurité dès la conception est à la fois un objectif et une philosophie. Cette démarche nécessite une approche globale. Au programme, analyse du code, corrections, mise en production, architectures orientées micro-composants, API standardisées et orchestrateur de déploiement et d’exploitation.

Wannacry, Petya, NotPetya, Industroyer… Des campagnes massives de rançongiciels cryptolockers ont sérieusement endommagé les systèmes d’information de nombreuses entreprises. Ces attaques ont réussi notamment parce que des équipements de sécurité électronique ont révélé leurs vulnérabilités. Entre autres des caméras de vidéosurveillance connectées, ce qui semble quelque peu paradoxal ! Mots de passe ouverts à tous vents, absence de mise à jour du système d’exploitation, adresses IP librement accessibles aux moteurs de recherche… Il devient urgent de renforcer la cybersécurité des équipements de sécurité électronique dès leur conception. « Il est nécessaire de s’appuyer sur des produits ou des processus de confiance », insiste Jacques Roujansky, délégué permanent CSF-IS (¹) et délégué général du CICS (²). Problème : 85 % des logiciels dans le monde contiennent au moins une vulnérabilité, selon SOSS V9. Comment mettre en place une stratégie de « Security by Design » dans les systèmes de sécurité électronique ?

Sécuriser l’équipement, le protocole et la cible d’enregistrement

Pour le fabricant allemand de caméras de vidéoprotection Mobotix, il faut sécuriser à la fois l’objet connecté. Mais aussi le protocole de communication avec lequel l’équipement échange sur le réseau. Ainsi que la cible d’enregistrement des images. « Aucun de ces trois maillons ne doit être faible », indique Patrice Ferrant, responsable commercial France et Afrique chez Mobotix. Baptisée « Cactus », cette approche holistique de la sécurité a été certifiée par l’ANSSI (³) et le CNPP (⁴).

« Le CNPP nous a conduit à évoluer dans le processus d’installation. Désormais, nous obligeons l’installateur à changer le mot de passe de la caméra. S’il ne le fait pas, il ne peut poursuivre son installation », précise Patrice Ferrant. Ensuite, la caméra IA MX7, codéveloppée avec Konica-Minolta (actionnaire majoritaire de Mobotix depuis 2016) bénéficie de deux environnements propres. La caméra gère en local ses enregistrements, ses traitements d’image et sa protection contre les attaques en déni de service. Ensuite, elle possède une machine virtuelle qui embarque les algorithmes d’intelligence artificielle de partenaires. « Nous désolidarisons donc le fonctionnement de « l’œil intelligent » des algorithmes tiers. Ce qui renforce la sécurité », fait valoir Patrice Ferrant.

Scanner les vulnérabilités du code source

« La Security by Design est à la fois un objectif et une philosophie. Elle n’est pas inatteignable. Mais elle n’est pas non plus définitive. Il y a donc des méthodes pour s’approcher d’un optimum, expose Stéphane de Saint Albin, vice-président d’Hexatrust, l’association qui fédère des entreprises françaises spécialisées en cybersécurité. On peut commencer par scanner les vulnérabilités du code source. » Parmi les acteurs capables de réaliser ces analyses, citons Veracode. Ce fournisseur étasunien, qui figure au Magic Quadrant 2020 du Gartner, affirme que 70 % de ses clients comblent les failles du code qu’ils développent. Mentionnons aussi CheckMarx, ImmuniWeb ou Synopsys. « C’est la base du DevSecOps, à savoir l’intégration de la sécurité au sein du processus de développement agile du code avant la mise en production », reprend Stéphane de Saint Albin.

Théorie mathématique des méthodes formelles

Parmi les stars de l’analyse itérative, la startup française TrustInSoft fait figure à part. C’est l’un des rares éditeurs au monde dont la technologie s’appuie sur la théorie mathématique des méthodes formelles. Autrement dit, son service apporte la preuve mathématique que le code n’a plus de bug ! Pour y arriver, le code à analyser passe à la moulinette de la plateforme de TrustInSoft. « Les erreurs de conception et les bugs apparaissent alors soulignés en rouge », explique Fabrice Derepas, cofondateur de TrustInSoft. Il ne reste alors plus aux DevSecOps que de les corriger. Par itérations successives, le code sera ainsi nettoyé de toutes ces vulnérabilités. Reste que certains codes sont trop importants pour être aisément analysés et corrigés. Notamment les applications de sécurité dans le Cloud qui fonctionnement avec des IoT.

Sécuriser les API

C’est pourquoi les nouvelles architectures logicielles reposent sur des composants qui échangent leurs données via des API (⁵). « Les API publiques qui font partie d’un service et concernent les utilisateurs finaux. Quant aux API privées, ces interfaces techniques se placent entre des briques du système d’information. Elles ne sont visibles que par un superviseur, décortique Édouard Viot, directeur produit chez Rohde & Schwarz. En fonction de leur maturité, les entreprises sécurisent en priorité les API publiques car ce sont les plus exposées. Mais les plus matures sécurisent également les API privées. » Une manière de sécuriser ces architectures dès la conception consiste à connecter les composants ou applications à des WAF (⁶). « Le DevSecOps écrit son API selon la spécification standard Open API 3.0. Laquelle renseigne ce qu’elle expose et accepte. Autrement dit à qui et comment elle parle », renchérit Édouard Viot.

Des architectures de micro-composants

L’autre dimension des nouvelles architectures, c’est la conteneurisation d’applications. Objectif : automatiser leur déploiement et leur maintenance. Les architectures les plus récentes conteneurisent non plus des applications entières dans une machine virtuelle mais des micro-services dans un Docker. Intérêt : on ne clone que ce dont on a besoin. Ces micro-composants s’assemblent également via des API et constituent l’application globale que supervise un orchestrateur comme Kubernetes. Cette plateforme Open Source que Google a offerte à la Cloud Native Computing Foundation, automatise le déploiement, la montée en charge et la mise en œuvre de conteneurs, notamment de Dockers. « 20 % des entreprises, principalement les startups, savent déployer les conteneurs. Les autres recourent à des machines virtuelles », analyse Édouard Viot.

Sécuriser les API entre les micro-composants

Point fort de Kubernetes, il permet, selon ses configurations, aux DevSecOps de mener des investigations de bugs. « Comme l’exploitation est automatisée, le DevSecOps corrige les bugs directement dans le code source, puis redéploie automatiquement l’application. Plus besoin d’attendre des mois pour une correction, c’est du Continuous Delivery, souligne Édouard Viot. Les entreprises les plus matures le font quatre fois par jour. Les autres une fois par mois. » En outre, les DevSecOps vont compter sur une arme supplémentaire pour intégrer la sécurité à la conception : Rohde & Schwarz compte lancer d’ici cet automne un micro-WAF. Autrement dit un firewall en micro-service, proche de l’application, qui pourra protéger deux Dockers de micro-composants. En clair, la sécurité logique va commencer dès l’échelle microscopique.

Erick Haehnsen

(¹) Comité stratégique de filière des industries de sécurité

(²) Conseil des industriels de la confiance et de la sécurité

(³) Agence nationale de la sécurité des systèmes d’information

(⁴)Centre national de prévention et de protection

(⁵) Application Programming Interface ; interface de programmation applicative

(⁶) Web Application Firewall