El malware Ripple20 destaca la seguridad industrial …



Las malas prácticas de seguridad permitieron que las vulnerabilidades del software package se propagaran por los productos industriales y de IoT durante más de 20 años.

los descubrimiento reciente de 19 vulnerabilidades en una biblioteca de TCP / IP liviana ha provocado ondas de choque en todas las industrias, ya que expone a millones de organizaciones a posibles ciberataques. Conocidas como Ripple20, estas vulnerabilidades se encontraron en una biblioteca lanzada por primera vez en la década de 1990.

Las vulnerabilidades varían en gravedad, pero algunas pueden permitir que un atacante controle un dispositivo afectado de forma remota o causar problemas de disponibilidad. Se estimó que el número de sistemas afectados ascendía a cientos de millones, y los productos afectados incluyen «dispositivos domésticos inteligentes, equipos de redes eléctricas, sistemas de atención médica, equipos industriales, sistemas de transporte, impresoras, enrutadores, equipos de comunicaciones móviles / satelitales, centros de datos dispositivos, dispositivos de aviones comerciales, diversas soluciones empresariales y muchos otros «.

Evidentemente, todo el mundo se preguntaba en voz alta cómo podían existir estas vulnerabilidades en tantos productos y pasar desapercibidas durante más de 20 años. Sin embargo, no me sorprende la situación. Las malas prácticas de seguridad implementadas en los sistemas de control industrial (ICS) y el World wide web de las cosas (IoT) han contribuido a cómo las vulnerabilidades como las descritas en la investigación de Ripple20 se propagan a través de tantos productos.

Comprensión del riesgo, calidad del software en ICS
Los productos de varios fabricantes de ICS, incluidas varias marcas y modelos de controladores lógicos programables (PLC) y varios fabricantes de interfaces hombre-máquina (HMI), están diseñados principalmente teniendo en cuenta la seguridad y la disponibilidad. La confiabilidad de los PLC es excepcional: los sistemas ICS se pueden implementar en instalaciones de producción durante décadas y seguir funcionando correctamente.

La seguridad está diseñada en todos los sistemas ICS a nivel físico, no solo a un nivel lógico. Esto me lleva al tema del riesgo en relación con la mayoría de los sistemas de control industrial.

Si bien hay ciertas industrias en las que la seguridad puede tener implicaciones catastróficas en el mundo genuine, como el sector de la energía nuclear y otra infraestructura crítica, la gran mayoría de los sistemas ICS no tienen que lidiar con estas consideraciones extremas. La realidad para la mayoría de las plantas de fabricación es que existe un riesgo financiero presente con respecto a los problemas de seguridad: los procesos pueden interferir para interrumpir la producción, los productos pueden contaminarse si el proceso se modifica de manera específica o la propiedad intelectual puede ser robada en forma de recetas, fórmulas y detalles de procesos patentados.

Es importante comprender adecuadamente los riesgos que podría enfrentar un proceso por posibles problemas de seguridad sin reaccionar de manera exagerada. Si bien pueden surgir problemas de producción que afectan la calidad del producto, dichos problemas se identificarán durante el proceso de manage de calidad. Los fabricantes cuentan con procesos para detectar problemas, investigarlos, desechar lotes contaminados, limpiar equipos o solucionar el problema y luego reanudar la producción. Si bien este proceso puede ser costoso, no es necesariamente awful.

Un problema común que enfrentan los integradores de sistemas es verse obligados a utilizar application propietario de mala calidad. Si bien los PLC en sí están diseñados y fabricados para ser extremadamente robustos y confiables, no se puede decir lo mismo de otro program lanzado por estos fabricantes. Cuando se trabaja con algunos de los programas de application de menor calidad, no es raro tener varios bloqueos por día mientras se united states of america el software program según lo previsto.

TI vs . OT
Dado que la disponibilidad es fundamental para los sistemas ICS, y dado que los propios sistemas pueden ser frágiles y extravagantes, estos son generalmente responsabilidad de los equipos de tecnología operativa (OT). El equipo de tecnología de la información (TI) generalmente administra la purple corporativa. Los empleados de OT están familiarizados con la tecnología de procesos y los sistemas que administran, pero generalmente no saben mucho sobre seguridad de la información, lo que puede conducir a implementaciones inseguras.

Una situación bastante común para los fabricantes es una división, a veces contradictoria, entre el personal de TI y OT dentro de una empresa.

Los empleados de OT no quieren que el personal de TI manipule sus sistemas por temor al tiempo de inactividad que puede costarle a la empresa. Por lo que hemos visto, estas relaciones a menudo se parecen a las actitudes del equipo rojo frente al equipo azul en muchas organizaciones. El equipo azul puede resentir los esfuerzos del equipo rojo porque esos esfuerzos crean más trabajo para el equipo azul y pueden considerarse una crítica a su trabajo.

Los empleados de OT a menudo no quieren consultar con sus contrapartes de TI cuando hacen arreglos como el acceso remoto, lo que lleva a situaciones como RDP en redes de handle que comúnmente están expuestas a la World wide web pública. Los equipos de TI y OT están en el mismo equipo y necesitan educarse entre sí y capacitarse mutuamente para lograr sus objetivos y mandatos.

Garantizar la seguridad del producto en ICS
Las industrias de ICS / IoT enfrentan muchos de los mismos desafíos que las tiendas tradicionales de desarrollo de software. Sin embargo, existen desafíos únicos en ICS / IoT, donde los dispositivos se pueden implementar durante décadas y podrían necesitar sistemas heredados sin parches en la pink para respaldarlos. Es posible que no exista el reemplazo directo de un componente heredado, y la reingeniería del proceso para acomodar un componente más moderno, junto con las pérdidas financieras derivadas del tiempo de inactividad para completar las actualizaciones, podría tener un costo prohibitivo.

De manera comparable, existen desafíos con la gestión de la cadena de suministro. Los fabricantes que integran componentes de terceros en sus productos pueden no saber si alguno de sus componentes individuales contiene bibliotecas vulnerables. La falta de seguridad básica y principios de codificación segura en la educación de desarrolladores significa que a menudo no son conscientes de las debilidades de seguridad. Los colegios y universidades tienen la responsabilidad de capacitar a los desarrolladores para producir computer software seguro de la misma manera que necesitan asegurarse de que los estudiantes de ingeniería puedan diseñar una estructura que no colapse.

Cada uno de estos problemas debe abordarse de manera sistemática si queremos ver un aumento en la seguridad de los dispositivos integrados que controlan gran parte de nuestro entorno, a menudo inadvertidos, en segundo plano. Si bien prevenir estas vulnerabilidades en primer lugar es best, tener una forma de rastrear componentes de terceros potencialmente vulnerables en los productos es imprescindible para facilitar la aplicación de parches y otros esfuerzos de corrección.

Paul es un director técnico en Security Compass con una sólida experiencia en ICS, desarrollo integrado y evaluaciones de seguridad. Como consultor de seguridad, Paul ha realizado pruebas de penetración de la crimson, evaluaciones de seguridad de aplicaciones, evaluaciones de seguridad de dispositivos integrados, … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia original