Por qué debería cambiar a Connext DDS Secure

cado de accesorios, interoperen con otros dispositivos compatibles con ICE independientemente del fabricante. Si se realiza correctamente, este enfoque promete permitir mejoras drásticas en la seguridad del paciente. Los ejemplos conocidos incluyen transferencias de pacientes desde la sala de operaciones (quirófano) a las unidades de cuidados intensivos (UCI) o la reducción de falsas alarmas en los sistemas de analgesia controlada por el paciente (PCA). En ambos ejemplos, las comunicaciones entre dispositivos entre proveedores reducen significativamente los errores médicos evitables. OpenICE es una implementación de referencia de código abierto de la plataforma ICE que usa DDS como su mecanismo de conectividad subyacente.

OpenICE:desarrollado por MD PnP Lab, permite la conectividad entre varios tipos de dispositivos médicos.

Sin el despliegue de medidas de seguridad explícitas, una plataforma médica IIoT como ICE es susceptible a ataques de seguridad que podrían poner en peligro la seguridad y privacidad de los pacientes. Se puede ver un ejemplo de un ataque en el siguiente video en el que el atacante actúa como un intermediario. Ella enmascara las lecturas de un dispositivo de oxímetro real y fabrica lecturas de oxímetro falsas con la mala intención de ocultar la condición potencialmente crítica del paciente de la estación de enfermería.

¿Es suficiente la seguridad a nivel de transporte para proteger la conectividad en ICE?

Como se describe en un escenario de ataque más detallado en este documento, aunque todas las comunicaciones están encriptadas y autenticadas con seguridad a nivel de transporte (por ejemplo, TLS / DTLS), un dispositivo interno comprometido puede causar daños en todo el sistema, simplemente porque puede o no puede publicar no se puede hacer cumplir sin un control de acceso granular. DDS Security permite un control de acceso detallado por dispositivo, lo que mitiga en gran medida el impacto de este tipo significativo de ataque interno.

Además, poder ajustar las medidas de seguridad en función del riesgo es especialmente importante para dispositivos con recursos limitados o sistemas ICE o IoT médicos a gran escala con ancho de banda o aplicaciones sensibles al retraso. Además, tal ajuste fino debería ocurrir idealmente con cambios mínimos, si es que hay alguno, en la base del código, ya que el código puede no estar disponible para su modificación o ser demasiado costoso de modificar. Como se mencionó anteriormente, la falta de soporte de multidifusión, que ha demostrado ser extremadamente útil para el descubrimiento e intercambio de información eficientes y escalables, es una adición a estas deficiencias.

Por supuesto, esto no quiere decir que las soluciones basadas en TLS / DTLS no deban utilizarse en absoluto. RTI ya tiene clientes que utilizan nuestros transportes TLS o DTLS personalizados con DDS porque se adaptan mejor a sus casos de uso específicos. En RTI, nos complace ayudarlo a tomar una decisión informada sobre cómo tomar tales decisiones en función de los requisitos de riesgo y rendimiento durante nuestros estudios de arquitectura.

Conclusión y referencias

Recomendamos encarecidamente considerar RTI Connext DDS Secure y el estándar en el que se basa, OMG DDS Security, especialmente si está desarrollando aplicaciones para infraestructura crítica. Puede encontrar útiles las siguientes referencias:

[1] La especificación de seguridad OMG DDS se puede encontrar aquí. [2] La última versión de la Arquitectura de referencia de Internet industrial (IIRA) se puede encontrar aquí. [3] El Marco de conectividad industrial a Internet (IICF) se puede encontrar aquí. [4] El Marco de seguridad de Internet industrial (IISF) se puede encontrar aquí. [5] En este documento se puede encontrar información sobre la protección de entornos clínicos integrados (ICE).

上一页  [1] [2] 

Salud IIoT:las ideas son fáciles. La ejecución es difícil. Cómo diseñar sistemas de IoT industriales con DDS y LabVIEW 2017