Pourquoi devriez-vous passer à Connext DDS Secure

ity apparaît dans le contexte des environnements cliniques intégrés (ICE). Le cadre ICE, tel que défini par la norme ASTM F2761-09, fournit une approche pour intégrer des dispositifs médicaux hétérogènes et coordonner leurs activités pour automatiser les flux de travail cliniques. D'un point de vue de haut niveau, l'idée derrière ICE est de permettre aux dispositifs médicaux conformes à la norme ICE, de manière native ou à l'aide d'un adaptateur de rechange, d'interagir avec d'autres dispositifs conformes à ICE, quel que soit le fabricant. Si elle est effectuée correctement, cette approche a la promesse de permettre des améliorations spectaculaires de la sécurité des patients. Les exemples connus incluent les transferts de patients de la salle d'opération (OU) aux unités de soins intensifs (USI) ou la réduction des fausses alarmes dans les systèmes d'analgésie contrôlée par le patient (ACP). Dans ces deux exemples, les communications inter-dispositifs entre fournisseurs réduisent considérablement les erreurs médicales évitables. OpenICE est une implémentation de référence open source de la plate-forme ICE qui utilise DDS comme mécanisme de connectivité sous-jacent.

OpenICE - Développé par MD PnP Lab, il permet la connectivité entre différents types de dispositifs médicaux.

Sans déploiement de mesures de sécurité explicites, une plate-forme médicale IIoT telle que ICE est sensible aux attaques de sécurité qui pourraient mettre en danger la sécurité et la vie privée des patients. Un exemple d'attaque peut être vu dans la vidéo suivante dans laquelle l'attaquant agit comme un homme du milieu. Elle masque les lectures d'un appareil d'oxymètre réel et fabrique de fausses lectures d'oxymètre avec l'intention malveillante de cacher l'état potentiellement critique du patient du poste de soins infirmiers.

La sécurité au niveau du transport est-elle suffisante pour protéger la connectivité dans ICE ?

Comme décrit dans un scénario d'attaque plus détaillé dans ce document, même si toutes les communications sont cryptées et authentifiées avec une sécurité au niveau du transport (par exemple, TLS/DTLS), un périphérique interne compromis peut toujours causer des dommages à l'ensemble du système, simplement parce que ce qu'il peut ou ne peut pas publier n'est pas applicable sans un contrôle d'accès granulaire. La sécurité DDS permet un contrôle d'accès précis par appareil, atténuant dans une large mesure l'impact de ce type important d'attaque interne.

En outre, il est particulièrement important de pouvoir affiner les mesures de sécurité en fonction du risque pour les appareils aux ressources limitées ou les systèmes ICE ou IoT médicaux à grande échelle avec des applications sensibles à la bande passante ou au délai. En outre, un tel réglage devrait idéalement se produire avec des modifications minimales, voire inexistantes, de la base de code, car le code peut ne pas être disponible pour modification ou être trop coûteux à modifier. Comme mentionné ci-dessus, le manque de prise en charge de la multidiffusion, qui s'est avérée extrêmement utile pour une découverte et un échange d'informations efficaces et évolutifs, s'ajoute à ces lacunes.

Bien sûr, cela ne veut pas dire que les solutions basées sur TLS/DTLS ne doivent pas du tout être utilisées. RTI a déjà des clients qui utilisent nos transports TLS ou DTLS personnalisés avec DDS, car ils conviennent mieux à leurs cas d'utilisation spécifiques. Chez RTI, nous sommes heureux de vous aider à prendre une décision éclairée quant à ces choix en fonction des exigences de risque et de performance au cours de nos études d'architecture.

Conclusion et références

Nous vous conseillons vivement de considérer RTI Connext DDS Secure et la norme sur laquelle il est basé, OMG DDS Security, en particulier si vous développez des applications pour une infrastructure critique. Les références suivantes peuvent vous être utiles :

[1] Les spécifications de sécurité OMG DDS peuvent être trouvées ici.[2] La dernière version de l'Industrial Internet Reference Architecture (IIRA) est disponible ici.[3] Le cadre de connectivité Internet industriel (IICF) peut être trouvé ici.[4] Industrial Internet Security Framework (IISF) peut être trouvé ici.[5] Des informations sur la protection des environnements cliniques intégrés (ICE) peuvent être trouvées dans cet article.

上一页  [1] [2] 

Santé IIoT :les idées sont faciles. L'exécution est difficile. Comment concevoir des systèmes IoT industriels avec DDS et LabVIEW 2017