Por que você deve mudar para Connext DDS Secure

a Controlada pelo Paciente (PCA). Em ambos os exemplos, as comunicações entre dispositivos de vários fornecedores reduzem significativamente os erros médicos evitáveis. OpenICE é uma implementação de referência de código aberto da plataforma ICE que usa DDS como seu mecanismo de conectividade subjacente.



OpenICE - desenvolvido pelo MD PnP Lab, permite a conectividade entre vários tipos de dispositivos médicos.

Sem a implantação de medidas de segurança explícitas, uma plataforma médica IIoT como o ICE é suscetível a ataques de segurança que podem colocar em risco a segurança e a privacidade dos pacientes. Um exemplo de ataque pode ser visto no vídeo a seguir, em que o invasor age como um intermediário. Ela mascara as leituras de um dispositivo de oxímetro real e fabrica leituras falsas de oxímetro com a intenção maliciosa de esconder a condição potencialmente crítica do paciente do posto de enfermagem.

A segurança de nível de transporte é suficiente para proteger a conectividade no ICE?

Conforme descrito em um cenário de ataque mais detalhado neste documento, mesmo que toda a comunicação seja criptografada e autenticada com segurança de nível de transporte (por exemplo, TLS / DTLS), um dispositivo interno comprometido ainda pode causar danos em todo o sistema, simplesmente porque pode ou não pode publicar não é aplicável sem controle de acesso granular. A segurança DDS permite um controle de acesso refinado por dispositivo, reduzindo em grande parte o impacto desse tipo significativo de ataque interno.

Além disso, ser capaz de ajustar as medidas de segurança com base no risco é especialmente importante para dispositivos com recursos limitados ou ICE em grande escala ou sistemas IoT médicos com largura de banda ou aplicativos sensíveis a atrasos. Além disso, esse ajuste fino deve acontecer idealmente com mudanças mínimas, se houver, na base do código, já que o código pode não estar disponível para modificação ou ser muito caro para modificar. Como mencionado acima, a falta de suporte multicast, que se provou extremamente útil para descoberta e troca de informações eficientes e escalonáveis, é um acréscimo a essas deficiências.

Obviamente, isso não quer dizer que as soluções baseadas em TLS / DTLS não devam ser usadas. A RTI já tem clientes que usam nossos transportes TLS ou DTLS personalizados com DDS porque são mais adequados para seus casos de uso específicos. Na RTI, temos o prazer de ajudá-lo a tomar uma decisão informada sobre como fazer tais escolhas com base nos requisitos de risco e desempenho durante nossos estudos de arquitetura.

Conclusão e referências

Aconselhamos enfaticamente considerar o RTI Connext DDS Secure e o padrão no qual ele se baseia, OMG DDS Security, especialmente se você estiver desenvolvendo aplicativos para infraestrutura crítica. Você pode achar as seguintes referências úteis:
[1] As especificações de segurança OMG DDS podem ser encontradas aqui. [2] A última versão da Arquitetura de Referência da Internet Industrial (IIRA) pode ser encontrada aqui. [3] O Industrial Internet Connectivity Framework (IICF) pode ser encontrado aqui. [4] O Industrial Internet Security Framework (IISF) pode ser encontrado aqui. [5] Informações sobre a proteção de Ambientes Clínicos Integrados (ICE) podem ser encontradas neste documento.

上一页  [1] [2] 

Healthcare IIoT:As ideias são fáceis. A execução é difícil. Como projetar sistemas industriais de IoT com DDS e LabVIEW 2017