Gracias de nuevo por asistir a nuestra sesión sobre la seguridad de los dispositivos médicos. Aquí están las preguntas que siguieron a la presentación y sus respuestas. Si tiene más preguntas, no dude en ponerse en contacto con nosotros.
¿Podemos proporcionar actualizaciones de seguridad de software a los dispositivos en los hospitales sin violar nuestra certificación de dispositivos de la FDA?
La FDA afirma que los MDM (fabricantes de dispositivos médicos) siempre pueden actualizar un dispositivo médico para reforzar la ciberseguridad, y la FDA normalmente no necesita revisar la actualización. Debe proporcionar instrucciones al equipo responsable de la actualización de su dispositivo, implementar un procedimiento de actualización seguro con estructura de clave pública/privada, e incorporar un código a prueba de fallos para que el dispositivo no esté en funcionamiento cuando se actualice.
¿Una contraseña y un cortafuegos hospitalario no protegerán mi dispositivo de la piratería?
Sí, en cierto modo, pero creo que Robert ha señalado muy bien que hay una amplia gama de cosas que hay que implementar. Una contraseña puede evitar que alguien llegue a ella, pero pueden comprar uno de tus dispositivos y empezar a trabajar en él fuera de un entorno hospitalario, o robarlo, o lo que sea. Así que no se puede contar con los usuarios y hacerles recaer la responsabilidad de decir: "Tienen que mantener nuestro producto seguro". Tienes que construir la seguridad en tus dispositivos. Creo que Robert hizo un gran trabajo hablando del procedimiento para actualizar los productos y mantener la seguridad en el entorno en el que se despliega el producto.
¿Examina la FDA la ciberseguridad?
Es una gran pregunta, Rich. Y el hecho es que la FDA no hace pruebas específicas para ningún tipo de infección de malware o ciberseguridad. Están emitiendo recomendaciones en constante evolución, pero no hay pruebas específicas, y declaran explícitamente que es responsabilidad del fabricante de dispositivos médicos.
Teniendo en cuenta algunas filosofías diferentes sobre la seguridad, ya sea basada en hardware o en software, ¿qué solución es realmente la mejor?
Yo diría que, para una seguridad realmente óptima, se necesita una combinación de hardware y software. El hardware aporta algunas de las cosas que hemos discutido, como las capacidades anti-sabotaje en la mezcla. El software empieza a ofrecerte una fuente lógica de ataques. Así que, si piensas en el antimanipulación como una contramedida física, cuando combinas el hardware y el software, obtienes lo mejor de ambos cuando se trata de vectores de ataque lógicos y físicos, en cuanto a lo que puedes proteger. La otra cosa que hay que tener en cuenta, sin embargo, es la naturaleza de la información que estás tratando de proteger. Por lo tanto, es posible que necesites diferentes funcionalidades desde el punto de vista del hardware o del software, dependiendo de los perfiles de protección a los que te dirijas con tu dispositivo.
Sí. Y voy a intervenir. Quiero decir, sólo para ampliar eso, es por eso que pasé tiempo en mi parte de la presentación hablando de aprovechar el hardware. Hay muchas cosas que el hardware es capaz de hacer o de ayudar al software, pero el software tiene que estar ahí para aprovechar todo eso, ya sabes. Y es sólo con los dos trabajando en conjunto que el dispositivo puede realmente ser más seguro.
Si lo que dices es que todo el mundo debería utilizar algunos niveles de seguridad de hardware y software, pero cada aplicación es diferente, ¿cómo puedo saber qué seguridad es la adecuada para mí?
En los casos en los que no estás seguro de por dónde empezar, o qué nivel de seguridad es necesario para tu aplicación, recibimos a menudo esta pregunta de, ya sabes, "no soy un experto en seguridad. ¿Cómo puedo empezar?" Lo más fácil, por supuesto, es encontrar la norma más aplicable a su clase de dispositivo y utilizarla como punto de partida. Y, en última instancia, si no estás seguro ni siquiera de con qué norma empezar, el NIST es siempre un buen lugar para empezar, por ejemplo, el Instituto Nacional de Estándares y Tecnología. Tienen un marco de ciberseguridad que han publicado, y que puede utilizarse como guía tanto para los novatos como para los veteranos en el ámbito de la seguridad. Así que, ese sería un lugar que definitivamente recomendaría para al menos empezar a echar un vistazo si no estás familiarizado con la seguridad, o si eres nuevo en la seguridad.
Y luego, algunas de estas otras normas que se han discutido a lo largo del seminario web también. Así, por ejemplo, Bob había mencionado FIPS. Es otra norma del NIST, por así decirlo, que vemos que mucha gente apunta o busca diseñar hacia ella. La otra cosa que puedes hacer es consultar con socios que son expertos en seguridad, como las personas que están en la llamada de hoy, yo mismo, Robert y Bob. O, si usted tiene su propia experiencia interna, por supuesto, utilizar eso también.
¿Qué tiene de específico el mercado médico en materia de seguridad frente al mercado general?
Bueno, puedo hacer la respuesta de una sola palabra para eso, que es nada. Ya sabes, las técnicas que creo que los tres hemos hablado hoy no son realmente específicas para el mercado médico en absoluto. Son cosas más generales en las que pensar si estás haciendo conducción autónoma, ¿verdad? Los requisitos de seguridad y las técnicas son esencialmente los mismos.
La diferencia está realmente en el énfasis, ya sabes. Si estoy haciendo un dispositivo de consumo, y mi dispositivo de consumo se ve comprometida, y los datos personales se transmite a los malos, o una aplicación web, o lo que sea, eso es embarazoso, y es costoso. Pero las leyes son completamente diferentes.
El escrutinio realizado por los reguladores es totalmente diferente. La mayoría de los otros sectores consideran que la seguridad es básicamente lo que ocurre cuando se abre la puerta del establo y se escapan todos los caballos. Mientras que los reguladores médicos tratan de asegurarse de que se cierra la puerta del establo antes de que se escapen los caballos. Y ahí es donde se pone todo el énfasis. No se trata sólo de ti, y de cómo te enfrentas a ello después de que ocurra. Son los reguladores diciendo: "Oye, ¿cómo vas a evitar que esto suceda?" Y así, aunque lo correcto sería considerar todas estas cosas por adelantado para cualquier tipo de dispositivo, la industria médica lo requiere.
Patrick: Robert, una cosa más que me gustaría añadir a eso también. A menudo recibo la comparación, la gente dice que la seguridad es un poco como el seguro. Y lo es. Pero cuando se habla de la industria médica, en particular, yo diría que sí, es como un seguro, y la responsabilidad es mucho mayor también en las aplicaciones médicas.
¿Cómo ayudan las cosas que hemos discutido con los tipos de ataques médicos que aparecen en las noticias (redes de hospitales comprometidas, ransomware, etc.)?
Bueno, como dije en mi presentación, nada es perfecto. Pero el tipo de medidas de las que todos hemos hablado en nuestras presentaciones individuales realmente ayudan. Si a un hacker le resulta difícil o imposible conseguir un dispositivo para poder sondearlo y averiguar sus puntos débiles, o el dispositivo queda invalidado de alguna manera cuando eso ocurre, entonces les resulta mucho más difícil averiguar cómo atacar el dispositivo.
Si tu software se desarrolla con técnicas preventivas y utiliza las mejores prácticas de seguridad de alta calidad, entonces, incluso si consiguen acceder al dispositivo, será mucho más difícil para ellos inyectar, digamos, malware en el dispositivo, que es de donde provienen el ransomware y otros ataques a la red del hospital. Y así, al menos puedes proteger el dispositivo en la mayor medida posible, y luego esperas que los otros proveedores de la red del hospital estén haciendo lo mismo, y por lo tanto, la red del hospital será al menos más segura.
Rich: Y sé que has dicho que lo hace más difícil, pero no imposible.
Robert: Sí, todo se remonta a, ya sabes, los guardias armados y el dispositivo de hormigón.
¿Cuáles son los problemas de seguridad al utilizar hardware de código abierto, como BeagleBone y Raspberry Pi, en productos de dispositivos médicos? Bob, ¿quieres probarlo?
Claro, también nos lo dicen nuestros clientes. Y el reto es la compensación de tiempo. Es decir, las cosas que Siemens ha implementado, y Digi ha implementado, e Infineon ha implementado y/o pondrá a disposición de nuestros clientes, todo puede hacerse usando software de código abierto. Pero es una gran cantidad de trabajo, y tiempo, y esencialmente estás por tu cuenta, reuniendo tus propias herramientas, tus propias piezas, e integrándolas sobre el hardware de código abierto. Y tienes que hacerlo bien. Así que es mucho tiempo, y luego tienes el problema de la certificación, pasando por las diferentes certificaciones globales y mostrando lo que has hecho, cuando, de nuevo, no tendrás ningún apoyo de tus proveedores para eso. Así que, supongo que la respuesta más corta es que sí, es posible, pero realmente, extremadamente difícil.
¿Cómo se detecta la infección por malware?
Es importante diseñar funciones de detección en un dispositivo conectado. Esto puede incluir el registro de los intentos de ataque y el examen de los registros en busca de actividad inesperada en un dispositivo. También es posible detectar la actividad de la red a direcciones IP inesperadas o la actividad de un dispositivo. Si un dispositivo falla o empieza a funcionar mal, hay que retirarlo de la red y comprobar si hay malware o código que no pertenece al dispositivo. Hay empresas y laboratorios que pueden comprobar la presencia de malware en los dispositivos.