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

Los programas complejos y arcanos de divulgación de vulnerabilidades obstaculizan la seguridad

La mayoría de las vulnerabilidades de los productos ahora no las descubre el proveedor afectado, sino por fuentes externas como investigadores externos, y están en todo el mapa.

Las vulnerabilidades que crean posibles agujeros de seguridad en los productos de Internet de las cosas (IoT) y del sistema de control industrial (ICS) siguen creciendo.

Se revelaron más de 600 en el primer semestre de este año, según el último Informe de riesgo y vulnerabilidad de ICS de Claroty. La mayoría son de gravedad alta o crítica, pueden explotarse fácil y remotamente y hacen que el componente afectado sea completamente inutilizable. Una cuarta parte no tiene solución o solo puede repararse parcialmente.

Un ejemplo de los posibles daños que podrían ser causados ​​por vulnerabilidades desconocidas que acechan en la cadena de suministro de software es el grupo BadAlloc recientemente nombrado en RTOS y las bibliotecas de soporte de múltiples proveedores. Estos pueden explotarse para ataques de denegación de servicio o ejecución remota de código.

haga clic para ver la imagen a tamaño completo

(Fuente:Instituto Nacional de Estándares y Tecnología)

Millones de dispositivos de IoT y tecnología operativa (OT), así como sistemas de consumo como automóviles y dispositivos médicos, se ven potencialmente afectados. Sin embargo, los usuarios de OEM y propietarios de activos no sabían que existían estas fallas hasta que Microsoft las reveló en abril.

Sin embargo, la mayoría de las vulnerabilidades de los productos ahora no son descubiertas por el proveedor afectado, sino por fuentes externas como investigadores externos. Por eso existen los programas de divulgación de vulnerabilidades (VDP). Como explica la Guía definitiva de 2021 para la divulgación de vulnerabilidades de Bugcrowd, los VDP se han configurado para proporcionar "un mecanismo para identificar y remediar las vulnerabilidades descubiertas fuera del ciclo típico de desarrollo de software". Por lo general, las administran entidades federales, organizaciones de la industria y algunos grandes proveedores de productos.

No hay coherencia entre los programas

En respuesta a una directiva operativa vinculante de septiembre de 2020 de la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA), las agencias federales están publicando sus políticas de divulgación de vulnerabilidades, de manera confusa, también indicadas por el acrónimo "VDP". En julio, CISA anunció su plataforma VDP. Proporcionado por Bugcrowd y EnDyna, servirá a las agencias federales civiles como un sitio administrado de forma centralizada donde los investigadores de seguridad y otros pueden informar vulnerabilidades en los sitios web de las agencias.


Ron Brash

Pero la mayoría de los VDP controlan las vulnerabilidades de los productos, no los procesos o las configuraciones. Desafortunadamente, hay muy poca coherencia entre ellos. "Estos programas están por todas partes:incluso las agencias federales de EE. UU. Hacen lo suyo", dijo Ron Brash, director de información sobre seguridad cibernética de Verve Industrial Protection, a EE Times . "Ninguno de ellos está configurado para una máxima eficiencia". Incluso aquellos con buenos mecanismos, como los programas NIST e ISO / IEC, tienen disparidades entre esos mecanismos:qué se informa y cómo, cumplimiento y cómo un grupo determinado realiza los cambios necesarios.

Brash también criticó la falta de transparencia en los informes. El gobierno de EE. UU. No ha desarrollado el código para los productos de tipo COTS que generalmente compra, por lo que las agencias federales no tienen una propiedad real y deben actuar como policías de tránsito, dijo. “Las personas que deberían estar haciendo la 'vigilancia' no tienen el conocimiento para comprender verdaderamente los problemas en cuestión o su impacto; no puede remediar de forma eficaz las vulnerabilidades debidas a presupuestos, aprobaciones, una plataforma de EoL inadecuada o la incapacidad de provocar a un proveedor para que proporcione una solución; y no tiene los medios para aplicar consecuencias o forzar mejoras ".

También falta la propiedad de un aviso dado y de la sincronización de lo que se ha hecho al respecto en los programas gubernamentales y los portales de proveedores. "Es todo el mejor esfuerzo", dijo Brash. “Los grandes proveedores a menudo se apropian, pero es posible que todas sus unidades de negocios lo hagan de manera diferente. Dado que cada producto puede combinar varios productos, la cantidad de proveedores se multiplica aún más ”.

El sistema de informes CVE tiene limitaciones

CISA patrocina los dos VDP de EE. UU. Más importantes:la Base de datos nacional de vulnerabilidades (NVD), alojada por el Instituto Nacional de Estándares y Tecnología (NIST), y el programa Common Vulnerabilities and Exposures (CVE), un poco más antiguo, dirigido por MITRE, que detalla públicamente vulnerabilidades conocidas. CISA también alberga los avisos de ICS-CERT, que incluyen exploits y problemas.

“Incluso si ignoramos todo el proceso de divulgación y los aspectos de la investigación, el sistema [de informes CVE] es arcano y complejo”, dijo Brash. “La mayoría de los propietarios de activos no tienen los conocimientos necesarios para comprender adecuadamente los avisos de seguridad de OT / ICS ni para actuar en consecuencia. Entonces, se quedan paralizados por la gran cantidad de información ". Esta complejidad se hace evidente al ver la presentación de Brash en YouTube, un básico para descifrarlos.

El sistema CVE no lo incluye todo:un número creciente de vulnerabilidades no aparece allí. Según Risk Based Security, en julio se publicaron 2158 vulnerabilidades, 670 de ellas sin un ID de CVE.

"Los CVE se limitan a vulnerabilidades que afectan a una amplia gama de software que muchas empresas pueden utilizar", dijo a EE Times el investigador de seguridad independiente John Jackson, fundador del grupo de piratería ética Sakura Samurai. . "[Pero] una vulnerabilidad podría ser específica de la lógica en el software o en un servidor que solo posee una empresa".

Los VDP federales apuntan principalmente a agencias federales, dijo Brash. Hay pocas cosas disponibles para las empresas comerciales:algunas industrias tienen sus propios reguladores, como la Corporación de Confiabilidad Eléctrica de América del Norte (NERC) para las empresas de servicios eléctricos. Aunque las políticas y los procedimientos de las agencias federales podrían reflejarse para su uso en la industria privada, estos pueden cambiar con cada elección presidencial, señaló.

“Algunos proyectos comunitarios de código abierto están gestionando bastante bien las divulgaciones de vulnerabilidades”, dijo Brash. “Por ejemplo, algunas partes del kernel de Linux están bien administradas; otros no tanto, y eso sin siquiera considerar el ecosistema general de Linux. Y en comparación con otros proyectos de software gratuitos y de código abierto, o incluso con varios productos patentados, también tienen prácticas de seguridad muy variables ”.

Informes, problemas de divulgación

La falta de coherencia entre los programas, especialmente en los informes, puede poner a los investigadores externos en un aprieto, sin mencionar los posibles problemas legales causados ​​por la Ley de Abuso y Fraude Informático (CFAA).


John Jackson

“Muchos VDP requieren que los piratas informáticos no discutan sus hallazgos, pero los programas no les pagan, ni les dan ningún incentivo para incluso piratear”, dijo Jackson. “Además, por lo general están mal administrados o mal administrados por personal que no es de seguridad, y eso dificulta la colaboración. Los VDP que usan Bugcrowd son un buen comienzo porque permiten que los piratas informáticos colaboren de manera efectiva y los evaluadores pueden echar un vistazo a la vulnerabilidad primero para confirmarla. Aún así, esto no mitiga la necesidad de una seguridad regular ".

Un informe de 2016 del NTIA Awareness and Adoption Group dijo:“La gran mayoría de los investigadores (92%) generalmente participan en alguna forma de divulgación coordinada de vulnerabilidades. La amenaza de acciones legales fue citada por el 60% de los investigadores como una razón por la que podrían no trabajar con un proveedor para divulgarla. Solo el 15% de los investigadores esperaba una recompensa a cambio de la divulgación, pero el 70% esperaba una comunicación regular sobre el error ".

Según la Guía definitiva de Bugcrowd de 2021, el 87% de las organizaciones con su propio VDP informaron haber obtenido una vulnerabilidad crítica. Pero mientras el 99% dice que considera unirse a su VDP con un programa de recompensa por errores, solo el 79% dice que realmente paga a los investigadores por "hallazgos impactantes".

Debido a que el problema se complica especialmente con las vulnerabilidades en los productos de IoT integrados, el proceso de divulgación debe estandarizarse, dijo Brash. También debe haber "un palo para hacer cumplir", tanto en el propietario del activo como en el desarrollador del producto OEM. Él prevé un registro para productos de IoT integrados como los de retiradas de automóviles. “Creo que debería estar en la placa del proveedor y del integrador de sistemas asegurarse de que el propietario de un activo esté al menos informado de una vulnerabilidad en su activo. Al igual que con el retiro del mercado de un automóvil, el propietario puede decidir aceptar el riesgo, repararlo o comprar un producto diferente ".

>> Este artículo se publicó originalmente en nuestro sitio hermano, EE. Tiempos.


Tecnología de Internet de las cosas

  1. El camino hacia la seguridad industrial de IoT
  2. Redefiniendo la seguridad del firmware
  3. Abordar las vulnerabilidades de seguridad del IoT industrial
  4. Gestión de la seguridad de IIoT
  5. Seguridad de IoT:¿de quién es la responsabilidad?
  6. Todo va a IoT
  7. Seguridad de IoT:¿una barrera para la implementación?
  8. Modernización de la ciberseguridad
  9. Protección de IoT mediante engaños
  10. Una lista de verificación de seguridad de ICS
  11. La vulnerabilidad de la cadena de suministro de IoT representa una amenaza para la seguridad de IIoT