Scot Morrison, directeur général de la division Platform Business Unit de la division des systèmes embarqués chez Mentor, une entreprise de Siemens.

Les capteurs colorimétriques affichent les vraies couleurs des menaces dangereuses

Cet article a paru dans Electronic Design et a été publié ici avec permission.

L’électronique et les logiciels intégrés aux dispositifs médicaux sont de plus en plus sophistiqués. Les plates-formes utilisant Linux embarqué sont également courantes de nos jours. De même, la sûreté et la sécurité restent primordiales pour les dispositifs médicaux.

Conception électronique Bill Wong s’est entretenu avec Scot Morrison, directeur général de l’unité commerciale des plates-formes de la division des systèmes intégrés de Mentor, une entreprise de Siemens, au sujet du développement de dispositifs médicaux à l’aide de Linux, de la gestion de la sécurité et de la sûreté, pour assurer le succès des performances des produits.

Scot Morrison, directeur général de la division Platform Business Unit de la division des systèmes embarqués chez Mentor, une entreprise de Siemens.

Scot, comment le logiciel open source Linux peut-il être utilisé pour la sécurité des dispositifs médicaux?

Linux a été déployé en toute sécurité dans une grande variété de dispositifs médicaux, mais pour utiliser Linux dans un dispositif médical qui a une exigence de sécurité, les développeurs embarqués doivent suivre le processus défini par la norme de certification pour la conformité et la certification.

Alors, Linux peut-il être pré-certifié pour une utilisation dans un dispositif médical?

Pas vraiment. Certains systèmes d’exploitation en temps réel (RTOS) tels que Nucleus RTOS de Mentor, peuvent être acquis pré-certifiés, tout comme d’autres composants logiciels embarqués d’un certain nombre de fournisseurs. Pour obtenir ce type de pré-certification, le fournisseur doit être en mesure de démontrer que le processus de développement logiciel complet – exigences, conception, développement, test et vérification, ainsi que toutes les étapes de développement – a été exécuté conformément aux normes de l’industrie médicale telles que ISO 13485 et / ou CEI 62304. Linux et autres composants open source ne sont pas développés selon ces normes, ils ne sont donc pas pré-certifiés.

Il y a eu des efforts pour montrer la conformité de Linux aux concepts généraux de la sécurité fonctionnelle, comme le mappage à la CEI 61508, dont de nombreuses normes industrielles sont dérivées, y compris la CEI 62304. Bien que cette approche ne réussisse pas, le projet ELISA, un processus, se montre prometteur en améliorant les processus de développement de logiciels open source et en mappant la sortie de meilleure qualité à ces normes. Cependant, cette promesse est probablement dans des années avant d’être complètement réalisée.

Sur quoi les développeurs embarqués s’appuient-ils actuellement pour garantir la sécurité de leurs dispositifs médicaux basés sur Linux?

Au lieu de la pré-certification, Linux est généralement géré en utilisant un concept de la CEI 62304 appelé Software of Unknown Providence, ou SOUP, pour les dispositifs médicaux d’aujourd’hui. Selon ces directives, Linux est considéré comme faisant partie de l’évaluation des risques de l’ensemble du périphérique, et les pannes potentielles de Linux telles qu’elles sont utilisées dans le périphérique doivent être prises en compte et atténuées si elles peuvent nuire à un patient. Cette évaluation des risques doit répondre aux exigences des directives de la FDA avant et après la soumission.

Ainsi, sur le front-end, cela nécessite des considérations sur l’utilisation de Linux dans la conception, la mise en œuvre, les tests et la vérification de l’appareil. Ensuite, l’utilisation de Linux, et de tous les logiciels open source, doit prendre en compte la possibilité que des problèmes soient détectés après la sortie du produit. Les certificateurs examinent de très près cet aspect de l’open source, en particulier en ce qui concerne les problèmes de sécurité.

La sûreté et la sécurité sont nécessaires lorsque nous examinons les dispositifs médicaux. Nous entendons dire que vous ne pouvez pas avoir de sécurité sans sécurité, mais pourquoi?

La sécurité est quelque chose qui peut être considéré comme autonome. Même dans les dispositifs médicaux, tous les aspects de la sécurité ne sont pas liés à la sécurité. Par exemple, lorsque nous parlons de protéger les informations personnelles d’une personne, il s’agit d’un aspect de la sécurité qui ne recoupe pas la sécurité. Mais lorsque nous parlons de sécurité, les choses qui pourraient mal tourner auront un impact sur la santé du patient. Si l’appareil n’est pas sécurisé, il permet aux mauvais acteurs de provoquer ces impacts négatifs accidentellement ou délibérément.

L’utilisation de Linux et d’autres logiciels open source aide-t-elle à protéger ces appareils?

Linux est le système d’exploitation le plus utilisé pour les appareils disposant d’une large base de développeurs mondiale. Cette communauté mondiale de développeurs s’efforce de garantir que Linux fonctionne comme prévu dans toutes les conditions et qu’il est aussi sécurisé que possible.

En tant que système d’exploitation le plus étudié au monde, la grande majorité des développeurs travaillent consciencieusement à l’amélioration de Linux et d’autres packages open-source. Mais il y a aussi un petit nombre d’acteurs qui cherchent des moyens de s’introduire sous Linux à leurs propres fins. La sécurité des applications utilisant l’open source est un bras de fer constant entre ces forces opposées. Sans sécurité, vous ne pouvez pas avoir de sécurité.

Comment est-il possible que Linux puisse avoir autant de failles de sécurité que nous en trouvons toujours plus?

Linux et d’autres packages open-source majeurs comme OpenSSL ou SQLite sont des packages volumineux qui peuvent avoir des interactions imprévisibles avec d’autres logiciels s’exécutant sur le même système. Ceci est combiné avec le fait que de nombreuses failles sont difficiles à trouver dans les revues de code, les tests normaux ou par l’analyse statique. Et ils sont indétectables à moins que le logiciel ne soit combiné avec la commutation de tâches et la communication inter-processus. Les meilleures pratiques n’identifieront pas toutes les failles ou exploits possibles, et une grande partie des logiciels open source sur lesquels nous nous appuyons n’a pas été initialement développée avec les meilleures pratiques actuelles en place.

Cependant, les logiciels open source les plus importants utilisés dans les appareils du monde entier sont beaucoup plus stables et sécurisés maintenant qu’il y a cinq ans. Cela est principalement dû au travail acharné et à la diligence des ingénieurs du monde entier pour identifier les avenues d’exploitation, les corriger quand ils les trouvent, et avec la communauté mondiale à la recherche de problèmes similaires dans leurs propres projets. Le travail ne sera jamais terminé, mais il devient de plus en plus difficile de trouver des failles exploitables dans cet important logiciel d’infrastructure.

Que se passe-t-il lorsqu’un problème de sécurité est détecté sous Linux?

Les problèmes de sécurité sous Linux, y compris d’autres logiciels importants comme OpenSSL, sont découverts par les ingénieurs soit par hasard, comme un bogue qu’ils découvrent pendant un projet, soit par des efforts concertés pour trouver des exploits, comme le piratage «white hat». Ou bien, un exploit sera trouvé lors d’une analyse post-mortem d’une attaque, mais c’est rare.

Dans les deux cas, le découvreur d’exploits informera la communauté du composant open source incriminé. Ensuite, le découvreur ou le membre de la communauté Linux informera le groupe CVE (Common Vulnerability and Exposures), géré par MITRE, une organisation étroitement liée à la base de données nationale américaine sur les vulnérabilités (NVD) gérée par le National Institute of Standards and Technology (NIST). .

Une fois qu’une vulnérabilité est comprise et qu’un correctif est disponible, le CVE est rendu public par l’inclusion dans ces listes. Si l’exploit est suffisamment sérieux, le problème est débattu par la communauté de sécurité du monde entier. C’est le point où les appareils sont potentiellement les plus vulnérables. Puisque la plupart des vulnérabilités sont découvertes par les «gentils», les mauvais acteurs les découvriront comme le reste du monde. Ces mauvais acteurs peuvent alors déployer des exploitations qui tirent parti de la vulnérabilité nouvellement découverte.

Cela dit, cette publicité est très importante, car elle alerte la communauté mondiale à la fois du problème et du correctif. Ainsi, une organisation peut déterminer si un exploit particulier peut affecter ses appareils, et si c’est le cas, elle peut atténuer le problème avant qu’il ne soit attaqué. Bien sûr, tout le monde ne pourra pas mettre à jour ses appareils, ce qui les exposera aux attaques. Mais comme il n’y a pas de vrais secrets dans le monde, cette ouverture prévient plus de problèmes qu’elle n’en cause.

Retour a la sécurité. Quelle est la sécurité de Linux?

Un système d’exploitation comme Linux ne fait rien directement pour rendre un appareil plus sûr. Le système d’exploitation n’empêche pas une panne de se produire, ni ne permet au système de se rétablir en cas de panne. Lorsque vous mettez Linux sur un système sans autre application et que vous l’activez, Linux démarre; cependant, il se trouve juste là à une invite de connexion. Il ne fait rien tant que les applications qui tirent parti de Linux ne sont pas en cours d’exécution, et ce sont ces applications qui contribuent à la sécurité globale de l’appareil. Bien qu’un système d’exploitation ne soit pas un mécanisme de sécurité, il les active et est considéré comme un élément de sécurité.

Avec les microprocesseurs avancés et abordables d’aujourd’hui, comment un système multiprocesseur affecte-t-il la sécurité?

Les microprocesseurs actuels sont puissants et complexes, conçus pour prendre en charge le multitraitement hétérogène. Ils comprennent de puissants cœurs polyvalents pour exécuter un système d’exploitation comme Linux, et des cœurs plus spécialisés pour gérer d’autres fonctions. La conception pour la sécurité est une question de systèmes intégrés, pas seulement de matériel ou de logiciel.

Pour tirer pleinement parti des coûts de nomenclature de la carte et de l’intégration accrue des composants dans un multiprocesseur avancé pour une conception sensible à la sécurité, les applications doivent être séparées – ce que l’on appelle la criticité de sécurité mixte.

Simultanément, la partie critique pour la sécurité du système s’exécute sur un cluster distinct dédié au traitement en temps réel. Il possède des fonctionnalités telles que des données étroitement couplées et une mémoire d’instructions avec des cycles d’extraction extrêmement faibles et des performances hautement déterministes, ou un mode lockstep pour la détection d’erreur.

Les systèmes multitraitement avancés contiennent une isolation renforcée par le matériel qui sépare le monde des applications et celui de la sécurité. Cependant, le concepteur de logiciels doit utiliser des intergiciels tels que Mentor Hypervisor ou Mentor Multicore Framework pour tirer parti de ces fonctionnalités matérielles. Ces progiciels permettent des fonctions importantes au niveau du système telles que la communication sécurisée entre processeurs (IPC) entre les grappes de processeurs.

Scot, merci. Où nos lecteurs peuvent-ils en savoir plus sur Linux et les logiciels embarqués de Mentor?

Notre site Web www.mentor.com/embedded-software/ propose une large gamme de livres blancs et de webinaires à la demande sur des sujets tels que Linux, la criticité mixte, la sûreté et la sécurité pour améliorer le développement embarqué.

Scot Morrison est le directeur général de la Business Unit Platform, division des systèmes embarqués de Mentor Graphics, supervisant les gammes de produits Linux, Nucleus et AUTOSAR; middleware; et services professionnels. Avant de rejoindre Mentor Graphics en 2012, Morrison était directeur général et vice-président des produits chez Wind River Systems Inc., où il occupait auparavant le poste de vice-président de l’ingénierie. Il a rejoint ISI en 1986, où il a passé 14 ans à divers postes de direction, pour la dernière fois en tant que vice-président et directeur général de l’unité commerciale des solutions d’automatisation de la conception en 1999, responsable des systèmes d’exploitation et des intergiciels et outils associés.

Articles similaires

Commencez à saisir votre recherche ci-dessus et pressez Entrée pour rechercher. ESC pour annuler.

Retour en haut