Por qué es tan difícil solucionar las vulnerabilidades de seguridad en dispositivos médicos, IoT

Cuando su familia abrió esa computadora nueva cuando era niño, no pensó en todo el trabajo de terceros que hizo posible escribir en ese primer programa BASIC. Hubo un tiempo en el que no teníamos que preocuparnos por las empresas que producían todos los bits de software o hardware con licencia que sustentaban nuestra experiencia informática. Pero los recientes ataques de malware y otros eventos de seguridad han demostrado cuánto debemos preocuparnos por la cadena de suministro detrás de la tecnología que usamos todos los días.

La vulnerabilidad URGENT/11, objeto de un aviso de la Agencia de Seguridad de Infraestructura y Ciberseguridad emitido en julio pasado, es uno de esos eventos. Nos obliga a cuidarnos porque afecta a múltiples dispositivos médicos. Y sirve como una demostración de cómo la cadena de suministro de componentes de software y la disponibilidad de soporte pueden afectar la capacidad de las organizaciones para actualizar los dispositivos para corregir errores de seguridad, especialmente en el espacio informático integrado.

URGENT/11 es una vulnerabilidad en la pila TCP/IP (IPNet) de Interpeak Networks, que se otorgó con licencia a varios proveedores de sistemas operativos integrados. IPNet también se convirtió en la principal pila de redes en Wind River VxWorks, hasta que Wind River adquirió Interpeak en 2006 y dejó de admitir IPNet. (Intel adquirió Wind River en 2009 y se escindió en 2023). Pero el final del soporte no impidió que otros fabricantes continuaran usando IPNet. Cuando se descubrieron errores críticos en IPNet, provocó un susto entre los numerosos fabricantes de dispositivos médicos que lo ejecutan como parte de la construcción de su producto.

El dispositivo médico o de Internet de las cosas (IoT) promedio se basa en múltiples utilidades de software libre o de código abierto. Estas piezas de software son mantenidas por una cantidad de terceros, a menudo por solo una o dos personas. En el caso de Network Time Protocol (ntp), software que se encuentra en miles de millones de dispositivos, su código lo mantiene una sola persona. Y cuando salió a la luz la vulnerabilidad OpenSSL Heartbleed en 2023, dos desarrolladores trabajaron en el proyecto OpenSSL. Si bien hay muchos más desarrolladores trabajando en ello ahora, la crisis de Heartbleed es emblemática de lo que sucede cuando usamos software gratuito en nuestros dispositivos: el software se adapta, no se parchea realmente y no se mantiene realmente en el dispositivo, y se recuperan pocos beneficios. al proyecto

Economía del parche

Las empresas están bajo constante presión para desarrollar productos y reducir gastos. Para ahorrar tiempo de comercialización y reducir costos, los fabricantes de hardware a menudo crean productos utilizando diseños de referencia. Estos diseños vienen con paquetes de soporte de placa, que contienen el código y los controladores necesarios para instalar y ejecutar con éxito un sistema operativo en el diseño dado. A veces también vienen con utilidades para realizar diagnósticos, depuración de hardware o monitoreo en los dispositivos.

Pero el Board Support Package no siempre se actualiza para abordar las vulnerabilidades o los sistemas operativos más nuevos. Este es el caso de muchos dispositivos Android que continúan utilizándose pero que no obtienen actualizaciones de software, debido a cambios en el kernel que los paquetes de soporte de la placa y los controladores no admiten. A menudo, el fabricante del dispositivo necesita actualizar estos paquetes para cada nueva versión de un sistema operativo. Luego necesita reconstruir la nueva versión de su sistema operativo y las aplicaciones encima. Los componentes de terceros, como cámaras o sensores adicionales, también necesitan tener sus controladores actualizados. La cantidad de trabajo necesaria para hacer esto es significativa y requiere un grado de prueba similar al de un dispositivo nuevo.

Los fabricantes más grandes, como Samsung, son capaces de absorber los costos y pueden proporcionar actualizaciones de dispositivos a un precio más bajo porque controlan numerosos segmentos del mercado (pantalla, memoria, etc.). Apple también es capaz de proporcionar estas actualizaciones durante varios años debido a su control de la cadena de suministro detrás de sus dispositivos, incluidos los procesadores, y su alejamiento de la propiedad intelectual de terceros.

Pero para otros fabricantes, el alto costo de actualizar los paquetes de soporte de la placa, los controladores asociados (cuando existen) y las aplicaciones dificulta la actualización de los dispositivos a una versión completamente nueva de un sistema operativo. Y a menudo no es posible actualizar ni siquiera un componente específico. Como resultado, las expectativas establecidas por las principales empresas de software no se trasladan bien a los mercados en los que no se venden tantos dispositivos y existe una enorme presión del mercado para aumentar las ganancias.

Los dispositivos médicos no son teléfonos inteligentes

Es posible que este tipo de cosas no se perciba como un gran problema en un mercado de dispositivos de consumo, donde los fabricantes intentan impulsar un ciclo constante de actualización de hardware. Pero existe la expectativa de que los dispositivos médicos se usen por más tiempo que otros dispositivos: se consideran gastos de capital y se incluyen en los presupuestos de construcción de nuevas instalaciones.

Solicitar a los proveedores de dispositivos médicos que se comprometan con el soporte a largo plazo para los componentes y el soporte a largo plazo de la cadena de suministro tiene un costo correspondiente que correrá a cargo de los usuarios finales. Debido al costo de brindar soporte a estos dispositivos, muchas organizaciones abandonarán el soporte del fabricante y utilizarán una empresa de terceros para brindar soporte técnico y administración de dispositivos. Esto elimina el incentivo para que los fabricantes brinden apoyo adicional.

Y los proveedores de dispositivos médicos no siempre tienen la flexibilidad para actualizar sus plataformas subyacentes debido a la forma en que licencian los componentes. Dado que los componentes de terceros suelen tener licencia para una función preconstruida, la licencia solo puede permitir el uso del dispositivo con una determinada versión de un sistema operativo o kernel.

Si bien la comunidad de Linux ha sido increíble en el mantenimiento de versiones anteriores del kernel y en la resolución de problemas de seguridad mucho después de que se hayan lanzado versiones más nuevas del kernel, implementar ese kernel parcheado requiere un trabajo significativo. Hay muchas dependencias entre todas las partes, y es muy difícil mantener todo para poder proporcionar actualizaciones de seguridad para un dispositivo o sistema operativo en particular, así como lo hacen Microsoft, Apple o IBM Red Hat a escala. Y las versiones anteriores del kernel y la biblioteca significan que el software más nuevo no será tan fácil de transferir y usar, en todo caso. Lograr que Apache 2.4 se ejecutara en Red Hat Enterprise Linux 5.x, por ejemplo, fue una tarea ardua.

Sin solución fácil

Será difícil superar los desafíos que estos problemas plantean para la seguridad de los dispositivos médicos. El esfuerzo de la Administración Federal de Drogas para exigir una lista de materiales de software a través de su Guía de seguridad cibernética previa a la comercialización es un buen comienzo. Debería ayudar a desenredar las dependencias de los paquetes de soporte de la placa, las actualizaciones del kernel, las compilaciones de aplicaciones asociadas y el hardware de soporte.

Sin embargo, abordar los riesgos significa comprender y abordar la cadena de valor de cómo evoluciona un dispositivo desde el concepto hasta la disposición. También debemos evolucionar la forma en que se diseñan y actualizan los dispositivos para que coincidan con el nivel de soporte que brindan Samsung y Apple. Esto significa que los fabricantes deben dedicarse a usar plataformas durante más tiempo y comprometerse a mantener actualizadas las cadenas de construcción para poder entregar parches y actualizaciones a los clientes de manera constante.

Este no es tanto un problema técnico como uno comercial y de la cadena de suministro. Necesitamos comunicar y establecer las expectativas con nuestros proveedores de dispositivos médicos e IoT de que queremos tener soporte de software y parches durante un período de tiempo esperado y que debemos asegurarnos de que todo en el dispositivo esté actualizado, incluso las aplicaciones y terceros. bibliotecas del partido. Tener un lenguaje contractual sólido para abordar esto es primordial.

Tenemos que ser sinceros sobre cuánto tiempo pretendemos usar estos dispositivos y cuáles son nuestras expectativas de seguridad, niveles de servicio y actualizaciones. También necesitamos reducir la variedad de los dispositivos que usamos y estandarizar con la menor cantidad de proveedores posible para que podamos aprovechar los recursos limitados y mantener estos dispositivos en buen estado y mantenimiento. También podemos reducir la superficie de ataque de nuestra red al tener menos proveedores que accedan a los dispositivos de forma remota. El soporte cuesta dinero en todos los niveles, y pedirle al proveedor que realice cambios para el soporte a largo plazo requerirá un compromiso financiero para hacerlo de ambas partes. También necesitamos usar esa lista de materiales de software para identificar los componentes de terceros y garantizar por contrato que puedan ser compatibles como otros dispositivos.

Pero debemos entender que las expectativas que Microsoft, Apple y otros grandes proveedores han establecido para los parches de seguridad no pueden ser igualadas por un proveedor que fabrica como máximo unos cientos de miles de unidades de un dispositivo. Este es un mercado mucho más pequeño que tiene una criticidad significativamente mayor y requiere un mayor grado de prueba. Fuera de los principales fabricantes, muchas de las empresas que fabrican estos dispositivos son empresas más pequeñas y deben poder permitirse el lujo de desarrollar nuevos dispositivos y respaldar lo que tienen al mismo tiempo, lo que a menudo es difícil incluso para las grandes empresas.

Necesitamos asociarnos con nuestros proveedores de dispositivos médicos para resolver problemas como Urgente/11 a través de mejores procesos. Necesitamos comprender cómo funcionan los dispositivos, y debemos comprender que se necesita mucho trabajo para obtener un parche para dispositivos que son más complejos que una PC estándar. La implementación de parches en estos dispositivos también conlleva diferentes riesgos.

Mitch Parker es el director de seguridad de la información de Indiana University Health y profesor adjunto de informática de la salud en Indiana University-Purdue University Indianapolis.