Manufactura industrial
Internet industrial de las cosas | Materiales industriales | Mantenimiento y reparación de equipos | Programación industrial |
home  MfgRobots >> Manufactura industrial >  >> Industrial Internet of Things >> Tecnología de Internet de las cosas

Seguridad para IoT:¿Qué puede aprender el IoT industrial del reciente ataque DDoS?

El ataque Mirai DDoS (Denegación de servicio distribuida) del viernes pasado reveló una debilidad fundamental de las implementaciones actuales de IoT y mostró la absoluta necesidad de nuevos modelos de seguridad. El ataque DDoS fue contra el dispositivo IoT del consumidor, pero existen muchos paralelismos entre el IoT del consumidor y el industrial. Este ataque involucró a decenas de millones de direcciones IP [i], una cantidad masiva y sin precedentes de dispositivos. Desafortunadamente, parece que fue bastante fácil de llevar a cabo, especialmente porque se puede acceder fácilmente al código fuente de la botnet Mirai. La herramienta principal para piratear una variedad de dispositivos de IoT de consumo (cámaras habilitadas para Internet, DVR, etc.) fue un conjunto de contraseñas predeterminadas establecidas por el fabricante. [ii] ¿Cuántos han encontrado contraseñas predeterminadas en dispositivos industriales operativos? O quizás sería mejor preguntar, ¿cuántos se han encontrado alguna vez con una contraseña que se ha cambiado? Este último probablemente sería más fácil de contar.

Es fácil pensar que este ataque en particular puede no tener la misma forma en una red industrial. Existe una variedad de diferencias en el diseño de la red, los tipos de dispositivos utilizados, la administración de la red y el control de acceso. Sin embargo, la estrategia utilizada en este ataque es muy relevante para las aplicaciones industriales. Explote uno o muchos dispositivos comprometidos, que no son el objetivo principal, para derribar otro dispositivo o toda la red; necesitamos planificar una defensa contra este tipo de ataque.

Hay algunas características clave de este ataque, especialmente con respecto a los dispositivos desde los que se lanzaron:

  1. Los dispositivos se implementan en ubicaciones remotas y difíciles de administrar. Las actualizaciones de software son esporádicas, si es que ocurren.

  2. Los dispositivos funcionan sin mantenimiento directo ni participación del operador. "Administradores", si están involucrados, simplemente configúrelo y olvídelo.

  3. Los dispositivos tienen acceso a una red más amplia y comparten datos en la red.

  4. El dispositivo puede verse comprometido fácilmente.

  5. Los datos de la red se basan en un nivel de seguridad de la red o del transporte y no son intrínsecamente seguros.

  6. Los dispositivos comprometidos no eran el objetivo final, sino herramientas para lograr un objetivo diferente. Esto implica que hay pocos incentivos para que los fabricantes de dispositivos gasten dinero en diseñar sistemas seguros.

¿Suena esto como una red industrial con la que ha trabajado? A mí me lo hace.

Aunque nos gustaría pensar que los dispositivos y redes industriales tienen una seguridad mejor que esta, desafortunadamente este no es el caso. Solo tenemos que mirar el ataque de 2015 a los sistemas SCADA de distribución de electricidad de Ucrania como prueba. Las redes industriales se han basado principalmente en el anonimato y el aislamiento de las redes públicas para su seguridad. Pero a medida que se implementan más dispositivos en aplicaciones industriales y se conectan más redes privadas a la web, esto ya no es suficiente. El acceso a estas redes no siempre es un ataque directo, pero podría provenir de una brecha física (por ejemplo, el ataque Stuxnet), que puede abrir un agujero en los firewalls de seguridad para comprometer aún más los dispositivos. Sin mencionar las redes comprometidas involuntariamente debido a un software mal diseñado. El sistema de IoT debe diseñarse asumiendo que habrá malos actores dentro de la red a los que no podemos excluir. La tecnología y los estándares utilizados deben diseñarse para mitigar el impacto potencialmente adverso de dichos actores. Entonces, ¿cuál es la solución?

El primer requisito es asegurar los propios dispositivos; la industria necesita mejorar y desarrollar sistemas para firmar y proteger todo, desde los chips de hardware hasta el sistema operativo, las bibliotecas y las aplicaciones que tienen permiso para ejecutarse. Esto es fundamental. La seguridad ascendente debe ser la norma para estas redes. La cadena de confianza, el arranque seguro y los sistemas operativos seguros que utilizan software firmado y de confianza deben ser un requisito para operar en redes industriales.

Sin embargo, no podemos asumir que todos los dispositivos de una red son seguros y debemos planificar su funcionamiento cuando los dispositivos o las aplicaciones se vean comprometidos. Los datos son fundamentales para el funcionamiento de una red industrial y la seguridad debe ser una cualidad fundamental de cualquier dato.

¿Existe un estándar que haga que la seguridad sea parte de la infraestructura y que sea simple de implementar pero muy robusto? Sí, el estándar OMG Secure DDS y RTI Connext® DDS Secure es una solución de este tipo. RTI Connext DDS se basa en el estándar OMG Secure DDS e incluye características como:

  1. Autenticación de descubrimiento
  2. Control de acceso centrado en datos
  3. Criptografía
  4. Etiquetado y registro
  5. No repudio
  6. multidifusión segura

No solo eso, sino que es independiente del transporte y está construido con una arquitectura de plug-in. Esto significa que la seguridad de los datos y la comunicación es independiente del transporte de red utilizado y las bibliotecas de seguridad estándar se pueden reemplazar (utilizando API estándar) para adaptarse a los requisitos de seguridad de la aplicación.

Existen diferencias clave entre el enfoque Secure DDS y otras soluciones de seguridad de red. Con DDS:

  1. La seguridad es parte de la infraestructura y se incluye en las métricas de calidad de servicio.
  2. Permite un control de acceso detallado de los datos, lo que llamamos seguridad del flujo de datos, a nivel de tema de datos.
  3. Permite una combinación de funciones de seguridad que pueden incluir cifrado, autenticación y control de acceso para que la seguridad se pueda ajustar a las necesidades del tema de los datos.
  4. Todo esto se realiza mediante configuración, por lo que el programador de la aplicación no necesita comprender o administrar la implementación de seguridad, puede ser manejada por el arquitecto del sistema.

Secure DDS es un enfoque fundamentalmente diferente de la seguridad que incorpora seguridad a la infraestructura desde el principio. Esto tiene muchos beneficios positivos para la facilidad de uso, el rendimiento y la solidez de la arquitectura de seguridad. Pero no confíe en nuestra palabra, pregunte a nuestros clientes que utilizan DDS Secure en algunas de las aplicaciones de red más importantes.

Las herramientas existen, solo necesitamos usarlas y trazar un camino para migrar a este nuevo paradigma seguro. Puede obtener más información sobre RTI Connext DDS Secure aquí y comuníquese conmigo si desea obtener más información sobre las soluciones de RTI para proteger el IIoT.

[i] http://www.techrepublic.com/article/dyn-ddos-attack-5-takeaways-on-what-we-know-and-why-it-matters/

[ii] http://www.computerworld.com/article/3134746/security/fridays-iot-based-ddos-attack-has-security-experts-worried.html


Tecnología de Internet de las cosas

  1. Desempaquetando IoT, una serie:El desafío de seguridad y lo que puede hacer al respecto
  2. El camino hacia la seguridad industrial de IoT
  3. La búsqueda de un estándar de seguridad de IoT universal
  4. Abordar las vulnerabilidades de seguridad del IoT industrial
  5. Protección de IoT contra ciberataques
  6. Perspectivas para el desarrollo de IoT industrial
  7. Conexión de IoT:la oportunidad de banda estrecha
  8. ¿Qué puede ofrecer 5G para el automóvil conectado?
  9. Estamos sentando las bases para IoT en la empresa
  10. Seguridad de IoT:lo que podemos aprender de las amenazas recientes
  11. Protección de IoT desde la capa de red hasta la capa de aplicación