Por qué debería cambiar a Connext DDS Secure

"La seguridad debe estar integrada, no atornillada". Verdadero. Lo has escuchado. Yo también lo he escuchado. De hecho, con el IIoT convirtiéndose rápidamente en una realidad, esta frase se repite tantas veces que me preocupa que se convierta en un cliché que cree una sensación de urgencia sin potencia real. Pero, para empezar, ¿por qué la seguridad a menudo se atornilla? ¿Comprender las razones nos ayudará a evitarlo? Eso espero. Hay muchas razones, que van desde las económicas hasta las reglamentarias, educativas y técnicas, en las que no puedo entrar en detalle en esta publicación de blog (consulte el IISF para obtener detalles adicionales).

En algunos casos, el panorama de amenazas, los riesgos asociados y las consideraciones de seguridad no se han pensado bien durante el desarrollo de la arquitectura del sistema. En otros casos, los sistemas existentes se reutilizan para operar en condiciones completamente diferentes con amenazas completamente diferentes. Los analistas de seguridad a menudo desdeñan tales esfuerzos y es comprensible. Sin embargo, la gestión de alto nivel suele estar impulsada a tomar decisiones por las fuerzas del mercado, dando mayor prioridad a la eficiencia y la funcionalidad de alto rendimiento. Quizás la seguridad es una sobrecarga de la que puede preocuparse una vez que ponga en marcha el sistema básico. O tal vez piense que su sistema tendrá "huecos de aire". Pero probablemente sea demasiado tarde en ese momento para considerar la seguridad debido al costo de rediseñar el sistema. Por lo tanto, uno intentaría hacer todo lo posible agregando seguridad más tarde después de poner en funcionamiento el sistema básico. En muchos casos, el proceso de cómo agregar seguridad posteriormente no está bien definido o, en los casos en que existen mejores prácticas conocidas, no se sigue correctamente. Entonces, ¿por qué debería sorprendernos el estado decepcionante de la seguridad en el IIoT?

Parte del desafío de la ingeniería de seguridad consiste en diseñar arquitecturas que brinden una protección aceptable contra las amenazas a la seguridad que se derivan de errores, desgracias o malicia, al mismo tiempo que reducen al mínimo las funciones comerciales y el rendimiento del sistema. Esto suena fácil, pero es bastante difícil de lograr en la práctica, especialmente a medida que los sistemas se vuelven más complejos e interdependientes y a medida que grupos de personas más grandes y diversos trabajan para realizarlos. Para los sistemas IIoT en particular, las medidas de seguridad deben considerarse dentro de las restricciones más amplias de interoperabilidad, rendimiento, escalabilidad, resiliencia, seguridad y cumplimiento, en entornos donde las amenazas de seguridad y los riesgos asociados cambian con bastante rapidez. Estas consideraciones se han debatido y considerado enérgicamente en el desarrollo de la Especificación de seguridad DDS y Connext® DDS Secure de RTI.

Si ya es un usuario de DDS o está evaluando DDS para convertirse en uno, definitivamente debería considerar RTI Connext DDS Secure. A continuación, analizaré cómo Connext DDS Secure permite configuraciones de seguridad que permiten a los arquitectos e ingenieros encontrar el equilibrio adecuado entre seguridad y rendimiento, según los riesgos de seguridad y los requisitos de rendimiento. También proporcionaré un ejemplo de un proyecto de investigación que tiene como objetivo la integración segura de entornos clínicos para mejorar significativamente los resultados del paciente.

¿Es DDS Security la opción adecuada para su caso de uso?

Los ingenieros de RTI suelen utilizar una regla general para ver si la arquitectura del sistema de un cliente basada en DDS realmente tiene sentido, o si es mejor que utilicen otro marco de conectividad (consulte IICF para obtener una discusión técnica detallada sobre este tema). En general, si la respuesta a al menos tres de las siguientes cinco preguntas es un "sí", DDS sería el marco más adecuado para el sistema entre otros marcos de conectividad existentes:

1. ¿Es un gran problema si su sistema deja de funcionar por un tiempo breve?
2. ¿Ha dicho "milisegundos" o "microsegundos" en las últimas dos semanas?
3. ¿Tiene más de 10 ingenieros de software?
4. ¿Está enviando datos a muchos lugares, en lugar de solo uno (por ejemplo, a la nube o una base de datos)?
5. ¿Está implementando una nueva arquitectura IIoT?

Si su respuesta a la pregunta 1 es afirmativa, tiene requisitos estrictos de disponibilidad y tolerancia a fallas. DDS ya proporciona características que ayudan enormemente con estos requisitos, incluida la operación de igual a igual (por lo tanto, carece de puntos únicos de falla) y varios parámetros relevantes, incluidas las políticas de propiedad, durabilidad, vivacidad y fecha límite de QoS. Además, DDS Security permite la segregación de dominios DDS, la autenticación de participantes DDS, autorizándolos a publicar o suscribirse a temas DDS y la autenticación de mensajes DDS antes de que los datos pasen del middleware a aplicaciones de nivel superior. Estas características permiten la prevención y / o la mitigación significativa del impacto de algunas clases de ataques de denegación de servicio (DOS). Estas características, junto con las medidas de control de acceso adecuadas en la red, el sistema operativo y los niveles de aplicación, brindarían una mayor protección contra posibles ataques DoS en sistemas basados ​​en DDS.

Si su respuesta a la pregunta 2 es afirmativa, es probable que tenga requisitos importantes en tiempo real. Para tales casos, querrá ajustar la seguridad de su sistema DDS en función de los requisitos de riesgo y rendimiento. Por ejemplo, es posible que no le importe que una lectura de temperatura de un sensor en un espacio público esté cifrada y se transmita de forma confidencial, pero es probable que le importe la autenticidad de esas lecturas. DDS Security le permite definir y hacer cumplir dichas configuraciones, sin introducir ningún cambio en el código de su aplicación.

Una respuesta positiva a la pregunta 3 probablemente signifique que desea minimizar el costo de interoperabilidad entre los equipos de desarrollo de software, cada uno de los cuales trabaja en diferentes aspectos de un proyecto de software bastante grande. El diseño centrado en datos de DDS permite que los equipos de software acuerden qué datos (es decir, tipos y temas) deben distribuirse y cómo (es decir, con qué configuraciones de QoS), sin la necesidad de exponer necesariamente las API de procesamiento de datos. De manera similar, las configuraciones de DDS Security para complementos incorporados (por ejemplo, gobierno de dominio y archivos de permisos de participantes) permiten definir políticas de seguridad para la distribución de datos. Estas políticas explícitas se crean en función de sus modelos de datos y de cómo le gustaría proteger los dominios DDS. Estas políticas pueden ser revisadas de forma independiente por ingenieros de seguridad y arquitectos de sistemas, y reajustadas en función del análisis de riesgos y los requisitos de rendimiento sin introducir cambios en el código de la aplicación.

Una respuesta positiva a la pregunta 4 probablemente signifique que desea aprovechar al máximo la multidifusión para una entrega de datos mucho más eficiente. A diferencia de las soluciones de nivel de transporte populares como TLS / DTLS que no pueden utilizar los beneficios de la multidifusión, DDS Security viene integrado con soporte de multidifusión que permite un rendimiento de entrega de datos más optimizado.

Si su respuesta a la pregunta 5 es positiva, tiene la oportunidad de incorporar seguridad sin preocuparse demasiado por tener que lidiar con el código heredado. Al mismo tiempo, es probable que tenga escalabilidad, interoperabilidad y evite el bloqueo de proveedores en su lista de requisitos. DDS es una de las tecnologías de conectividad centrales para IIoT (consulte IICF para obtener más detalles) y se basa en un conjunto de especificaciones disponibles públicamente. Además, DDS Security utiliza una arquitectura conectable con API estandarizadas para autenticación, autorización, criptografía, etiquetado de datos y registro. Estas características, junto con el soporte de políticas de seguridad explícitas y granulares para la distribución de datos, hacen que DDS sea un candidato sólido para los sistemas IIoT de próxima generación, lo que permite diseñar la seguridad en la arquitectura de su sistema, no atornillarla.

Todo esto suena interesante, pero ¿alguien está usando DDS Security? La respuesta es un sí rotundo. RTI Connext DDS Secure ya ha sido evaluado y utilizado por varios de nuestros clientes comerciales y gubernamentales. Hemos reflejado los comentarios que hemos recibido de estos primeros usuarios en nuestra línea de productos. En los casos en los que se han necesitado más aclaraciones o actualizaciones de la Especificación de seguridad de DDS, hemos planteado los problemas a la comunidad de DDS para mejorar aún más el estándar.

Ejemplo:seguridad DDS para la interoperabilidad segura de dispositivos médicos

Un ejemplo interesante que muestra los beneficios de DDS y DDS Security aparece en el contexto de los entornos clínicos integrados (ICE). El marco ICE, según lo define la norma ASTM F2761-09, proporciona un enfoque para integrar dispositivos médicos heterogéneos y coordinar sus actividades para automatizar los flujos de trabajo clínicos. Desde una perspectiva de alto nivel, la idea detrás de ICE es permitir que los dispositivos médicos que cumplen con el estándar ICE, ya sea de forma nativa o usando un adaptador del mer

[1] [2] 下一页