Por que você deve mudar para Connext DDS Secure

“A segurança deve ser integrada, não aparafusada.” Verdadeiro. Você já ouviu isso. Eu também ouvi isso. Na verdade, com a IIoT rapidamente se tornando uma realidade, esta frase está sendo repetida tantas vezes que estou preocupado com ela se tornar um clichê que cria um senso de urgência sem potência real. Mas, para começar, por que a segurança é frequentemente reforçada? Compreender as razões nos ajudará a evitá-lo? Espero que sim. Há muitos motivos, desde econômicos até regulatórios, educacionais e técnicos, que não posso abordar nesta postagem do blog em detalhes (consulte o IISF para obter detalhes adicionais).

Em alguns casos, o cenário de ameaças, os riscos associados e as considerações de segurança não foram bem pensados ​​durante o desenvolvimento da arquitetura do sistema. Em outros casos, os sistemas existentes são redefinidos para operar em condições totalmente diferentes com ameaças totalmente diferentes. Os analistas de segurança costumam rejeitar tais esforços e isso é compreensível. A gestão de nível superior, no entanto, é normalmente orientada para tomar decisões pelas forças de mercado, dando maior prioridade à eficiência e funcionalidade de alto desempenho. Talvez a segurança seja uma sobrecarga com a qual você possa se preocupar depois de colocar o sistema básico em funcionamento. Ou talvez você ache que seu sistema ficará "sem ar". Mas provavelmente é tarde demais para considerar a segurança devido ao custo de redesenhar o sistema. Portanto, deve-se tentar fazer o melhor adicionando segurança mais tarde, após colocar o sistema básico em execução. Em muitos casos, o processo de como adicionar segurança posteriormente não está bem definido ou, nos casos em que existem práticas recomendadas conhecidas, não é seguido corretamente. Por que, então, deveríamos nos surpreender com o status decepcionante da segurança na IIoT?

Parte do desafio da engenharia de segurança está em conceber arquiteturas que forneçam proteção aceitável contra ameaças de segurança que se originam de erros, azar ou malícia, ao mesmo tempo em que reduzem a sobrecarga nas funções de negócios e no desempenho do sistema. Isso parece fácil, mas é bastante difícil de conseguir na prática - especialmente à medida que os sistemas se tornam mais complexos e interdependentes e grupos maiores e mais diversos de pessoas trabalham para realizá-los. Para sistemas IIoT em particular, as medidas de segurança devem ser pensadas dentro das restrições mais amplas de interoperabilidade, desempenho, escalabilidade, resiliência, segurança e conformidade, em ambientes onde as ameaças à segurança e os riscos associados mudam muito rapidamente. Essas considerações foram vivamente discutidas e consideradas no desenvolvimento da Especificação de Segurança DDS e do Connext® DDS Secure da RTI.

Se você já é um usuário DDS ou está avaliando o DDS para se tornar um, você definitivamente deve considerar o RTI Connext DDS Secure. A seguir, discutirei como o Connext DDS Secure permite configurações de segurança que permitem que arquitetos e engenheiros encontrem o equilíbrio certo entre segurança e desempenho, com base nos riscos de segurança e requisitos de desempenho. Também fornecerei um exemplo de projeto de pesquisa que visa integrar ambientes clínicos com segurança para melhorar significativamente o resultado do paciente.

A segurança do DDS é a opção certa para o seu caso de uso?

Os engenheiros da RTI normalmente usam uma regra prática para ver se arquitetar o sistema de um cliente com base em DDS realmente faz sentido, ou se é melhor usar outra estrutura de conectividade (consulte IICF para uma discussão técnica detalhada sobre este assunto). Em geral, se a resposta a pelo menos três das cinco perguntas a seguir for um "sim", o DDS seria a estrutura mais adequada para o sistema entre outras estruturas de conectividade existentes:

1. É um grande problema se o seu sistema para de funcionar por um curto período de tempo?
2. Você disse "milissegundo" ou "microssegundo" nas últimas duas semanas?
3. Você tem mais de 10 engenheiros de software?
4. Você está enviando dados para muitos lugares, em vez de apenas um (por exemplo, para a nuvem ou um banco de dados)?
5. Você está implementando uma nova arquitetura IIoT?

Se sua resposta à pergunta 1 for sim, você tem requisitos rigorosos de disponibilidade e tolerância a falhas. O DDS já fornece recursos que ajudam muito com esses requisitos, incluindo operação totalmente ponto a ponto (sem nenhum ponto único de falha) e vários parâmetros relevantes, incluindo políticas de propriedade, durabilidade, vivacidade e prazo de QoS. Além disso, a Segurança DDS permite a segregação de domínios DDS, autenticação de participantes DDS, autorizando-os a publicar ou assinar tópicos DDS e autenticação de mensagens DDS antes que os dados sejam passados ​​do middleware para aplicativos de nível superior. Esses recursos permitem a prevenção e / ou mitigação significativa do impacto de algumas classes de ataques de negação de serviço (DOS). Esses recursos, em conjunto com medidas de controle de acesso adequadas nos níveis de rede, sistema operacional e aplicativo, forneceriam maior proteção contra ataques DoS em potencial em sistemas baseados em DDS.

Se sua resposta à pergunta 2 for sim, é provável que você tenha requisitos de tempo real significativos. Nesses casos, você pode querer ajustar a segurança de seu sistema DDS com base nos requisitos de risco e desempenho. Por exemplo, você pode não se importar se uma leitura de temperatura de um sensor em um espaço público é criptografada e transmitida confidencialmente, mas provavelmente você se preocupa com a autenticidade dessas leituras. A Segurança DDS permite que você defina e imponha tais configurações, sem introduzir nenhuma alteração no código do aplicativo.

Uma resposta positiva à pergunta 3 provavelmente significa que você deseja minimizar o custo de interoperabilidade entre as equipes de desenvolvimento de software, cada uma trabalhando em diferentes aspectos de um grande projeto de software. O design centrado em dados do DDS permite que as equipes de software concordem sobre quais dados (ou seja, tipos e tópicos) devem ser distribuídos e como (ou seja, com quais configurações de QoS), sem a necessidade de necessariamente expor APIs de processamento de dados. Da mesma forma, as configurações de segurança DDS para plug-ins integrados (por exemplo, controle de domínio e arquivos de permissão de participante) permitem definir políticas de segurança para distribuição de dados. Essas políticas explícitas são criadas com base em seus modelos de dados e como você gostaria de proteger os domínios DDS. Essas políticas podem ser revisadas de forma independente por engenheiros de segurança e arquitetos de sistema e ser reajustadas com base na análise de risco e nos requisitos de desempenho, sem introduzir alterações no código do aplicativo.

Uma resposta positiva à pergunta 4 provavelmente significa que você deseja fazer o melhor uso de multicast para uma entrega de dados muito mais eficiente. Ao contrário das soluções populares de nível de transporte, como TLS / DTLS, que não podem utilizar os benefícios do multicast, o DDS Security vem integrado com suporte multicast, permitindo um desempenho de entrega de dados mais otimizado.

Se sua resposta à pergunta 5 for positiva, você tem a chance de criar segurança sem se preocupar muito em ter que lidar com o código legado. Ao mesmo tempo, você provavelmente terá escalabilidade, interoperabilidade e evitar o bloqueio de fornecedor em sua lista de requisitos. DDS é uma das principais tecnologias de conectividade para a IIoT (consulte IICF para obter mais detalhes) e é baseada em um conjunto de especificações disponíveis publicamente. Além disso, o DDS Security utiliza uma arquitetura plugável com APIs padronizadas para autenticação, autorização, criptografia, marcação de dados e registro. Esses recursos, juntamente com o suporte a políticas de segurança explícitas e granulares para distribuição de dados, tornam o DDS um forte candidato para sistemas IIoT de última geração, permitindo projetar a segurança, e não fixá-la, na arquitetura do seu sistema.

Tudo isso parece interessante, mas alguém está usando o DDS Security? A resposta é um forte sim. O RTI Connext DDS Secure já foi avaliado e usado por vários de nossos clientes comerciais e governamentais. Nós refletimos o feedback que recebemos desses primeiros usuários em nossa linha de produtos. Nos casos em que mais esclarecimentos ou atualizações forem necessários para a Especificação de Segurança do DDS, levantamos os problemas para a comunidade DDS para melhorar ainda mais o padrão.

Exemplo:Segurança DDS para interoperabilidade segura de dispositivos médicos

Um exemplo interessante que mostra os benefícios do DDS e da Segurança DDS aparece no contexto de Ambientes Clínicos Integrados (ICE). A estrutura ICE, conforme definido pelo padrão ASTM F2761-09, fornece uma abordagem para integrar dispositivos médicos heterogêneos e coordenar suas atividades para automatizar fluxos de trabalho clínicos. De uma perspectiva de alto nível, a ideia por trás do ICE é permitir que dispositivos médicos em conformidade com o padrão ICE, seja nativamente ou usando um adaptador pós-venda, interoperem com outros dispositivos compatíveis com ICE, independentemente do fabricante. Se feito corretamente, essa abordagem tem a promessa de permitir melhorias dramáticas para a segurança do paciente. Exemplos conhecidos incluem transferências de pacientes da Sala de Cirurgia (SO) para Unidades de Terapia Intensiva (UTI) ou redução de alarmes falsos em sistemas de Analgesi

[1] [2] 下一页