X
BLOG

La cura para los defectos y las vulnerabilidades del software en los dispositivos médicos

La cura para los defectos y las vulnerabilidades del software en los dispositivos médicos Tiempo de leer: 3 minutos

Los dispositivos médicos modernos aprovechan cada vez más los microprocesadores y el software integrado, así como las conexiones de comunicaciones sofisticadas, para una funcionalidad que salva vidas. Las bombas de insulina, por ejemplo, se basan en una batería, un mecanismo de bomba, un microprocesador, sensores y software integrado. Los marcapasos y los monitores cardíacos también contienen baterías, sensores y software. Muchos dispositivos también tienen capacidades de comunicación basadas en WiFi o Bluetooth. Incluso las habitaciones de hospital con sistemas de administración de fármacos por vía intravenosa están controladas por microprocesadores y software integrados, que con frecuencia están conectados a la red de la institución. Pero estas innovaciones también significan que un defecto de software puede causar una falla crítica o una vulnerabilidad de seguridad.

Preocupaciones reales sobre la seguridad del software para dispositivos médicos

En 2007, el ex vicepresidente Dick Cheney tenía las capacidades inalámbricas de su marcapasos desactivadas. sobre las preocupaciones "sobre los informes de que los atacantes podrían piratear los dispositivos y matar a sus propietarios". Desde entonces, las vulnerabilidades causadas por la mayor superficie de ataque en los dispositivos médicos modernos han pasado de ser hipotéticas a demostrables, en parte debido a la complejidad del software y en parte debido a la falla en el endurecimiento adecuado del código.

En octubre 2011, The Register informó que "un investigador de seguridad ha ideado un ataque que secuestra bombas de insulina cercanas, lo que le permite administrar subrepticiamente dosis fatales a pacientes diabéticos que dependen de ellas". La bomba de insulina funcionó porque la bomba contenía una radio de corto alcance que les permitía a los pacientes y a los médicos ajustar sus funciones. El investigador demostró que, mediante el uso de una antena especial y un software personalizado, podía localizar y tomar el control de cualquier dispositivo de este tipo en un radio de 300 pies.

En una informe publicado por Evaluadores de Seguridad Independientes (ISE) que examinó 12 hospitales, la organización concluyó que “los adversarios remotos pueden implementar fácilmente ataques que manipulen registros o dispositivos con el fin de comprometer completamente la salud del paciente” (p. 25). Más adelante en el informe, los investigadores muestran cómo demostraron la capacidad de manipular el flujo de medicamentos o muestras de sangre dentro del hospital, lo que resultó en la entrega de tipos y dosis de medicamentos inadecuados (p. 37), y todo esto desde el vestíbulo del hospital. . También pudieron piratear y controlar de forma remota los monitores de pacientes y los tubos de respiración, y activar alarmas que podrían hacer que los médicos o enfermeras administraran medicamentos innecesarios.

Guía de la FDA para software de dispositivos médicos

Los reguladores están tomando nota. En junio de 2013, el Administrador de Alimentos y Medicamentos de EE. UU. (FDA) emitió una alerta de seguridad sobre "Ciberseguridad para dispositivos médicos y redes hospitalarias". Si bien la mayoría de estas pautas se centran en cuestiones específicas de seguridad (como la protección de nombres de usuario y contraseñas), incluyen las mejores prácticas para los desarrolladores de software integrado. Por ejemplo, a la FDA le preocupan las "vulnerabilidades de seguridad en el software comercial diseñado para evitar el acceso no autorizado a dispositivos o redes, como texto sin formato o sin autenticación, contraseñas codificadas, cuentas de servicio documentadas en manuales de servicio y codificación / inyección SQL ".

Más allá de la ciberseguridad: gestión de riesgos asociados con defectos de software

Si bien las brechas de seguridad son lo más importante para muchas organizaciones, una preocupación mayor deberían ser los defectos del software. Una sobrecarga del búfer, un controlador de errores insuficientemente probado, una fuga de memoria o un defecto que provocaría un bloqueo inconveniente en una aplicación de teléfono inteligente, por ejemplo, podría causarle al paciente un daño real en un dispositivo médico.

La implementación de una política de ingeniería de software automatizada puede evitar que se introduzcan defectos en la base de código y reducir el riesgo comercial. Pero muchos fabricantes de software de dispositivos médicos parecen carecer de la visibilidad del proceso que garantizaría el cumplimiento de la política. Según un julio de 2012 informe de la Revista de Ingeniería Electrónica, "En los dispositivos médicos que contienen software, puede ser extremadamente difícil evaluar si una empresa sigue sus procesos para los controles de diseño, especialmente en las áreas de validación, análisis de riesgos / peligros y cambios de diseño". Como resultado, se informaron varios defectos de codificación. Además, "algunos defectos eran violaciones básicas de las prácticas de codificación de software, mientras que otros eran defectos nuevos que se introdujeron durante la corrección de defectos anteriores".

¿Qué se puede hacer? Los desarrolladores de dispositivos médicos deben seguir las mejores prácticas para el desarrollo de software incrustado crítico para la seguridad, al tiempo que son conscientes de que la funcionalidad cada vez más sofisticada (incluida la conectividad externa) se suma a las amenazas y al no determinismo de esos dispositivos. Cuando un monitor cardíaco o una bomba intravenosa se pueden administrar y controlar de forma remota, los riesgos se multiplican mucho más allá de la complejidad de un simple dispositivo independiente.

Una guía útil es la norma ISO IEC 62304: 2006, "Software de dispositivos médicos: procesos del ciclo de vida del software. " Al igual que con todas las normas ISO, es muy detallado y abarca el diseño, la arquitectura, las pruebas de integración de pruebas unitarias y más. La mejor solución: Comprenda los riesgos y siga las pautas para administrar el riesgo durante todo el ciclo de vida del desarrollo de software. Puede ser una cuestión de vida o muerte.

Por cierto, el análisis estático de Parasoft incluye Varias reglas integradas para desarrollar software compatible con la FDA utilizando lenguajes C / C ++, .NET y Java.

Escrito por

Alan Zeichick

Alan Zeichick es analista principal de Camden Associates; anteriormente, Alan fue editor en jefe de SD Times de BZ Media. Síguelo @zeichick.

Reciba las últimas noticias y recursos sobre pruebas de software en su bandeja de entrada.

Prueba Parasoft