Les systèmes intégrés sont souvent au cœur des produits indispensables à la sécurité des personnes. Ils sont par conséquent soumis à toute une série de réglementations et de normes de sécurité. Les fabricants les analysent en tenant compte de toutes sortes de dangers potentiels imputables à diverses raisons, comme le manque de fiabilité des composants, les erreurs de l'utilisateur, les défauts d'utilisation physique et les erreurs de conception possibles. La mise en réseau de ces dispositifs induit toutefois un nouveau risque de sécurité.
La sécurisation des systèmes intégrés accessibles à distance par le biais d'un réseau est un véritable casse-tête pour bon nombre de fabricants. Les développeurs de systèmes intégrés classiques ne maîtrisent pas les technologies de sécurité ou ne savent pas déterminer dans quelle mesure un pirate peut potentiellement exploiter une vulnérabilité de l'appareil. Malheureusement, l'univers classique des technologies de l'information ne s'avère pas d'une grande aide car les experts dans ce domaine connaissent mal les systèmes de commande intégrés en temps réel, la gestion des risques de sécurité ou le développement de logiciels réglementés.
Proposition d'approche
La mise en réseau des systèmes intégrés augmente la portée de ce système sur le réseau et, potentiellement, tout ce qui y est connecté. Il est possible d'appliquer divers processus afin d'analyser efficacement un tel système et de prendre des décisions intelligentes et en connaissance de cause face à la menace de sécurité. Le NIST (National Institute of Standards and Technology) a publié deux de ces processus, le SP-800-30 et le SP-800-39.
Une analyse de la sécurité commence par un modèle de menace créé en énumérant les menaces, les vulnérabilités et les atouts dans une vision de l'ensemble du système. Une approche formelle axée sur le risque est alors utilisée pour guider la prise de décision pour le cas où des contrôles de sécurité supplémentaires sont nécessaires, et pour déterminer quelles parties du système comportent le plus grand risque de sécurité. Le risque de sécurité est traditionnellement analysé selon trois critères de sensibilité : la confidentialité (garantir que le système (données incluses) est accessible uniquement dans les conditions établies), l'intégrité (veiller à ce que le système ne soit modifié ou manipulé que dans les conditions établies) et la disponibilité (garantir l'accessibilité et le bon fonctionnement du système lorsque cela est nécessaire).
La mise en place d'un cycle de vie de développement sécurisé est également essentielle au développement de systèmes intégrés sécurisés afin d'assurer une gestion continue du risque. Le SP 800-39 du NIST ainsi que d'autres processus reconnaissent qu'il est important d'établir les exigences de sécurité dès le départ et tout au long du cycle de vie du dispositif. Il est possible, par exemple, de s'éloigner des « cas d'utilisation normaux » en proposant une série de « cas abusifs » détaillant les tentatives potentielles d'un pirate qui doivent être rejetées dans la conception.
L'analyse des risques et le processus décisionnel doivent se poursuivre tout au long du cycle de vie. L'architecture matérielle/logicielle doit, si possible, être analysée afin d'en mettre en évidence les points faibles. Il convient en outre de mettre en place des contrôles de sécurité afin de réduire les vulnérabilités potentielles. Des stratégies doivent être élaborées pour l'analyse du code et les tests de sécurité, comme le fuzzing ou les tests de pénétration.
Il est important de garder à l'esprit que, face à un risque de sécurité, il est impossible de prouver qu'un appareil est parfaitement sécurisé. Il n'est possible que de placer la barre un peu plus haut pour avoir de bonnes chances d'espérer que les attaques les plus faciles ne porteront pas leurs fruits. Il est donc important de concevoir des méthodes permettant de collecter des informations sur les appareils en service afin d'identifier les vulnérabilités qui sont passées inaperçues, et de mettre en place un mécanisme de déploiement sécurisé des correctifs lorsque les nouveaux problèmes détectés dépassent un certain seuil de risque exigeant une réaction.
Exemple : appareils médicaux
Les questions abordées ci-dessus revêtent une importance toute particulière dans le cas des appareils médicaux. La loi HITECH (Health Information Technology for Economic and Clinical Health) de 2009 a encouragé l'utilisation de systèmes de dossiers médicaux électroniques intégrés et, par là même, ouvert la voie à l'intégration d'un large éventail d'appareils médicaux à ces systèmes de dossiers.
Une telle intégration offre des opportunités évidentes : élimination des dossiers papier et des erreurs de transcription, allègement de la charge de travail clinique, surveillance continue basée sur des systèmes d'alerte, etc. Mais les risques ne sont peut-être pas aussi visibles. Puisqu'un appareil médical électronique collecte des informations qui seront utilisées dans l'établissement du diagnostic d'un patient (ex. moniteurs placés près des lits), ou peut-être utilisé pour traiter directement le patient (ex. pompe à perfusion), le moindre dysfonctionnement de l'appareil peut causer du tort au patient. Les utilisateurs malveillants (ou incompétents) peuvent ainsi nuire au patient.
Prenons un exemple plus spécifique : imaginez une pompe à perfusion installée à côté du lit d'un patient pour lui injecteur une certaine quantité de médicaments. Un dosage excessif ou insuffisant peut être dangereux, voire fatal. Dans un récent rapport [1], le groupe d'études indépendant ECRI classait les « erreurs de médication liées aux pompes à perfusion » au deuxième rang des risques technologiques recensés en 2014 dans le domaine de la santé. De nombreuses fonctionnalités sophistiquées (par exemple, des alarmes locales en cas de débit excessif ou insuffisant, d'obstruction ou d'atteinte du seuil de remplissage) ont été ajoutées sous la forme de dispositifs autonomes afin de minimiser la plupart de ces risques de sécurité.
Pour compléter les alarmes locales, une interface réseau a été introduite afin de retransmettre ces alarmes à un poste de soins infirmiers distant. Pour limiter les erreurs associées à l'injection du bon médicament en juste quantité au patient concerné, on utilise désormais des dictionnaires de médicaments, des scanneurs de codes-barres et un accès distant au poids du patient et à son ordonnance. Revenons maintenant aux trois critères de sensibilité, qui laissent apparaître quelques difficultés pour ces nouveaux appareils en réseau.
Confidentialité
Une pompe à perfusion contient diverses informations, telles que le nom du patient, son identification (généralement son numéro de dossier hospitalier) et des informations sur le médicament injecté et le dosage. Selon les lois HIPAA relatives à confidentialité des données, ces informations relèvent de la catégorie des informations médicales protégées et leur confidentialité doit donc être préservée. Lorsque ces informations sont envoyées via le réseau, quelle que soit la direction, il est de toute évidence impératif de les chiffrer par des moyens adéquats. L'analyse doit être étendue jusqu'aux données stockées dans l'appareil, en particulier lorsque la pompe est retirée du patient pour être remisée ou être utilisée sur un autre patient.
Intégrité
Pour garantir l'intégrité de la pompe, il est indispensable d'analyser les mécanismes utilisés pour contrôler l'accès à la pompe à partir du réseau. Les paramètres de perfusion qui dictent le mode d'administration du médicament doivent évidemment être protégés et modifiés uniquement par des moyens autorisés. Le dictionnaire des médicaments et son processus de mise à jour doivent être protégés de la même manière. Les protocoles d'accès aux informations du patient (par exemple, le poids du patient et le médicament prescrit) doivent être conçus de telle sorte qu'aucune information erronée ne puisse être envoyée à la pompe. La source des données doit être authentifiée par des moyens appropriés dans la mesure où toute erreur de poids, de patient ou d'ordonnance risque de nuire au patient.
Il est par ailleurs difficile de garantir la fiabilité du logiciel de la pompe lui-même. Si un pirate est en mesure de modifier ou remplacer le logiciel de l'appareil, les protections intégrées dans le logiciel légitime ne seront d'aucun secours. Il convient d'employer des mécanismes d'authentification afin de protéger l'accès aux fonctionnalités de correctif/reprogrammation. Certaines options matérielles économiques, comme le Trusted Platform Module [2] (TPM) peuvent être ajoutées pour confirmer l'intégrité du logiciel avec un haut degré de confiance au cours du processus de démarrage.
Disponibilité
En matière de disponibilité, il est essentiel de veiller à ce que la pompe demeure parfaitement opérationnelle en toutes circonstances, même en cas de perturbation malveillante de la connexion réseau. Si une attaque par déni de service sur la connexion peut empêcher de changer le médicament de la pompe ou d'affecter la pompe à un autre patient, une conception robuste devrait pouvoir éviter toute dépendance au réseau en fonctionnement normal. Si le réseau est utilisé pour générer des alertes à distance, il est possible d'intégrer à l'appareil un système d'avertissement indiquant que la connexion sécurisée ne peut pas être maintenue avec le gestionnaire d'alarmes en aval.
Conclusion
Comme le montre cette étude de cas, toute mise en réseau d'un appareil électronique intégré implique d'importantes considérations de sécurité. Parallèlement à cela, la complexité des systèmes ne fait qu'augmenter. Il existe heureusement des processus et des procédures, comme les exemples NIST cités ci-dessus, qui fournissent une méthodologie formelle permettant d'évaluer les risques de sécurité d'un système et de prioriser ces risques compte tenu de leur importance.