Los sistemas integrados con frecuencia, están en el centro de la vida útil y la seguridad de productos fundamentales. Como tales, están sujetos a diversas regulaciones y normas que rigen su seguridad. Los fabricantes los analizan para comprobar una amplia variedad de posibles peligros que provienen de fuentes como la falta de fiabilidad de los componentes, el error de usuarios, el uso físico indebido y los posibles errores de diseño. Sin embargo, agregar una red a estos dispositivos, incorpora un nuevo riesgo a la seguridad de los dispositivos.
Proteger los sistemas integrados a los que se puede tener acceso de forma remota mediante una red crea un desafío para muchos fabricantes. El desarrollador de sistemas integrados tradicionales no está familiarizado con la tecnología de seguridad o la evaluación de riesgos de un posible pirata informático que explota la vulnerabilidad de un dispositivo. Lamentablemente, el mundo de la tecnología de la información (TI) no sirve de mucha ayuda porque los expertos en ese área no están familiarizados con los sistemas de control en tiempo real, la gestión de riesgos de seguridad o el desarrollo de software regulado.
Un enfoque
La adición de sistemas “en red” a sistemas integrados aumenta el alcance de este sistema a la red y potencialmente a todo lo que esté conectado a ella. Se han desarrollado diversos procesos que pueden aplicarse para analizar de forma eficiente y eficaz un sistema así y tomar decisiones informadas e inteligentes acerca de cómo hacerse cargo de la amenaza de seguridad. El Instituto Nacional de Normas y Tecnología (NIST) ha publicado dos de esos procesos: SP-800-30 and SP-800-39.
Un análisis de seguridad comienza con un modelo de amenaza creado al enumerar las amenazas, vulnerabilidades y activos en el contexto del sistema completo. A continuación, se utilizará un enfoque impulsado por el riesgo para guiar la toma de decisiones para donde se puedan necesitar controles de seguridad adicionales, y qué partes del sistema contienen el mayor riesgo de seguridad. El riesgo de seguridad tradicionalmente se analiza en la “triada CID”: confidencialidad (asegurar que se acceda al sistema (incluidos los datos) solo de formas definidas), integridad (asegurar que el sistema cambie o se manipule solo de formas definidas) y disponibilidad (asegurar que el sistema sea accesible y esté operativo cuando sea necesario).
Igualmente esencial para el desarrollo de los sistemas integrados seguros, es la implementación de un ciclo de desarrollo seguro para gestionar el riesgo de forma continua. La publicación SP 800-39 del NIST y otras reconocen la importancia de establecer requisitos de seguridad y hacerlo al inicio y durante el ciclo del dispositivo. Esto puede adoptar la forma de un aumento del “caso de uso” normal con un conjunto de “casos de abuso” que documenten lo que un atacante podrían intentar, que se debe rechazar en el diseño.
El análisis de riesgos y la toma de decisiones debe continuar durante el ciclo. Debe analizarse la arquitectura de hardware/software en busca de puntos débiles y deben aplicarse controles para mitigar las vulnerabilidades potenciales. Se deben desarrollar estrategias para el análisis de código y pruebas basadas en la seguridad, como las pruebas difusas y las pruebas de penetración.
Es importante recordar que, cuando se aborda un riesgo de seguridad, no es posible demostrar que un dispositivo es seguro. Todo lo que se puede hacer, es elevar los estándares para aumentar la confianza de que las vulnerabilidades de seguridad fáciles, no fructificarán. Por consiguiente, es importante diseñar métodos para recopilar información de dispositivos de campo para identificar vulnerabilidades no detectadas y aplicar un mecanismo para implementar revisiones de forma segura cuando problemas recientemente descubiertos crucen el umbral de riesgo para generar una respuesta.
Un ejemplo: dispositivos médicos
Los problemas analizados anteriormente son especialmente críticos y oportunos en el caso de los dispositivos médicos. La Ley de Tecnología Informática en Salud para la Salud Económica y Clínica (HITECH) de 2009 incentivó el uso de sistemas de historias clínicas electrónicas y con ello, el impulso para integrar una amplia gama de dispositivos médicos a estos sistemas de historias clínicas.
Las oportunidades que vienen con dicha integración son obvias: la eliminación de papel y errores de transcripción, menor carga de trabajo clínica y la monitorización continua con alertas, por nombrar algunas. Los riesgos pueden no ser tan obvios. Debido a que un dispositivo médico electrónico integrado recopila información que se utilizará en el diagnóstico de un paciente (p. ej., monitores de cabecera) o bien puede proporcionar terapia directamente a un paciente (p. ej., bomba de infusión), el funcionamiento incorrecto de un dispositivo médico electrónico puede llevar a dañar al paciente. Los usuarios maliciosos (o incompetentes) pueden afectar al paciente.
Como ejemplo específico, considere una bomba de infusión de medicamentos de cabecera diseñada para proporcionar un flujo medido de un medicamento a un paciente. Las sobredosis y las dosis insuficientes pueden ser peligrosas e incluso fatales. De hecho, el grupo de investigación independiente ECRI indica “errores con medicamentos de bombas de infusión” como el segundo peligro de la tecnología de salud para el año 2014 en un informe1 recientemente publicado. Como dispositivo autónomo, se agregaron muchas características sofisticadas, como alarmas locales para bajo flujo/sobreflujo/bloqueo/recarga necesaria/etc., para mitigar muchos de estos peligros de seguridad.
Para complementar las alarmas locales, se agregó un interfaz de red para comunicar las alarmas a una estación de enfermería remota. Para reducir al mínimo los errores en administrar el medicamento adecuado/la dosis adecuada/el paciente adecuado, se agregaron diccionarios de medicamentos, lectores de códigos de barra y acceso remoto al peso del paciente y estado de la receta. De vuelta a la triada CID, los siguientes son algunos aspectos que enfrentan los nuevos dispositivos en red.
Confidencialidad
Una bomba de infusión contiene información como el nombre del paciente, un identificador para el paciente (posiblemente su ID del registro del hospital) e información sobre el medicamento que se administra y su dosificación. Debido a las leyes de privacidad de la HIPAA, esta es información de salud protegida (PHI) y se debe mantener de manera confidencial. Claramente, cuando esa información se envía en la red, en cualquier dirección, debe estar adecuadamente cifrada. El análisis debe extenderse a los datos mantenidos en el dispositivo, específicamente cuando se retira la bomba del paciente y se envía a almacenamiento o a un nuevo paciente.
Integridad
Asegurar la integridad de la bomba implica analizar los mecanismos que controlan el acceso a la bomba desde la red. Claramente, se debe proteger la configuración de infusión que impulsa la administración del medicamento y solo se debe permitir la modificación por medios autorizados. El diccionario de medicamentos y los procesos para actualizarlos deben protegerse de una forma similar. Los protocolos para acceder a la información del paciente, como el peso del paciente y el medicamento recetado, deben estar diseñados para eliminar información falsa que se le entregue a la bomba. La fuente de los datos debe autentificarse adecuadamente, ya que un peso incorrecto/paciente incorrecto/receta incorrecta puede ocasionar un daño al paciente.
Un activo menos obvio cuya confianza se debe asegurar es el software de la bomba. Si un atacante puede modificar o reemplazar el software del dispositivo, las protecciones incorporadas en el software legítimo son inoperantes. Se deben usar mecanismos de autenticación que protejan el acceso a la funcionalidad de revisiones/reprogramación. Se pueden agregar opciones de hardware de bajo coste, como Trusted Platform Module2 (TPM) que ofrecen una confirmación de alta confianza de la integridad del software durante el proceso de inicio.
Disponibilidad
Las consideraciones de disponibilidad incluyen asegurarse de que la bomba sigue realizando su operación normal aunque interfiera un actor malicioso con la conexión de la red. Aunque un ataque de denegación del servicio a la conexión puede interrumpir la capacidad de cambiar la bomba a un medicamento o paciente diferentes, un diseño robusto debe eliminar la dependencia de la red para una operación normal. Si la red se usa para informes de alarmas remotas, se pueden proporcionar advertencias en el dispositivo si no se puede mantener una conexión con el administrador de alarmas anterior.
Conclusión
Como lo demuestra el estudio de este caso, una vez que un dispositivo electrónico integrado está conectado a una red, la seguridad pasa a ser una consideración importante del dispositivo. Al mismo tiempo, también aumenta drásticamente la complejidad del sistema. Afortunadamente, hay procesos y procedimientos disponibles, como los ejemplos del NIST citados anteriormente, que ofrecen una metodología formal para evaluar los riesgos de seguridad de un sistema y priorizar las mitigaciones para abordar esos riesgos.