Prepare el software de su dispositivo médico para la nueva guía de ciberseguridad de la FDA

A medida que la FDA agrega más requisitos de ciberseguridad en su nueva guía de validación de software, los fabricantes de dispositivos médicos pueden recurrir al análisis estático, el método más eficaz para abordar las preocupaciones de seguridad y brindar software predecible.

Como mencioné en un entrada de blog hace unas semanas, este año en Embedded World, disfrutamos de muchas más conversaciones con los fabricantes de dispositivos médicos que nunca. Así que pensé en abordar el tema de muchas de estas conversaciones, centradas en la ciberseguridad y el análisis estático. Está claro que los fabricantes de dispositivos médicos se están enfocando en mejorar sus procesos de desarrollo de software para (a) abordar las crecientes amenazas de seguridad y (b) satisfacer los requisitos de la FDA, que son cada vez más precisos.

Nueva guía de ciberseguridad de la FDA

La FDA solía centrarse en seguridad funcional aspectos de los sistemas, pero ahora la seguridad cibernética es un tema de igual importancia. Aunque la seguridad y la protección son muy similares (y fácilmente se podría argumentar que ambas cosas se tratan simplemente de crear software predecible), la FDA ahora está considerando la ciberseguridad como algo que requiere atención y medidas específicas.

Se acerca una nueva norma de la FDA. En el borrador “Contenido de las presentaciones previas a la comercialización para la gestión de la ciberseguridad en los dispositivos médicos” podemos leer:

“La necesidad de una ciberseguridad eficaz para garantizar la funcionalidad y seguridad de los dispositivos médicos se ha vuelto más importante con el uso cada vez mayor de dispositivos inalámbricos, conectados a Internet y a la red, medios portátiles (por ejemplo, USB o CD) y el frecuente intercambio electrónico de dispositivos médicos. información de salud relacionada ".

¿Cuáles son los nuevos requisitos de la FDA?

Entonces, ¿qué cambian los nuevos requisitos para la organización típica que desarrolla software para dispositivos médicos? Bueno, los requisitos de los estándares médicos anteriormente no eran muy específicos con respecto a las recomendaciones para las pruebas. Incluso si echamos un vistazo de cerca a los documentos reglamentarios populares, como IEC 62304 o los Principios generales de validación de software de la FDA, no encontraremos un requisito para usar análisis estático o pruebas dinámicas con cobertura de código. Con el nuevo estándar, esto se vuelve más claro, directamente como parte de la presentación.

En el punto VII.B del “Contenido de los envíos previos a la comercialización para la gestión de la ciberseguridad en dispositivos médicos” podemos encontrar las recomendaciones sobre el contenido del informe de gestión de riesgos de un dispositivo de confianza:

“4. Una descripción de las pruebas que se realizaron para garantizar la idoneidad de los controles de riesgo de ciberseguridad ... c) análisis de código estático y dinámico, incluidas pruebas de credenciales que están "codificadas", predeterminadas, fáciles de adivinar y fácilmente comprometidas "

Esta es una recomendación clara para definir y seguir el proceso de análisis estático. ¿Cómo hacerlo? Mucho depende de los procesos existentes en la organización y de las tecnologías utilizadas para el desarrollo.

Cómo adoptar el análisis estático para los nuevos requisitos de desarrollo de software de la FDA

Muchos de nuestros clientes de dispositivos médicos, al comenzar desde cero, han tenido éxito al introducir análisis estático para C / C ++ siguiendo estos pasos:

1. Revise las pautas existentes en la organización, e incluso si están diseñadas para ser aplicadas manualmente, asignelas tanto como sea posible a los verificadores que se proporcionan con la herramienta de análisis estático. Una herramienta de análisis estático madura probablemente cubrirá la mayoría de ellos, y puede considerar la creación de verificadores personalizados para las pautas restantes que no se pudieron asignar a los verificadores de análisis estático de inmediato.
2. Revise los estándares de codificación populares, especialmente aquellos creados pensando en la seguridad, y seleccione un subconjunto de pautas para que las siga su equipo. Al seleccionar las pautas, tiene sentido seguir la categorización de los estándares y seleccionar las pautas que están categorizadas como las más importantes. Por ejemplo, para las pautas del CERT probablemente desee comenzar con las pautas L1, y para MISRA C 2012 (con la Enmienda 1) querrá revisar las pautas obligatorias.
3. Defina la configuración de la herramienta de análisis estático e incluya las pautas específicas de su organización y las pautas seleccionadas (es decir, CERT). No habilite todas las fichas a la vez, pero comience con un pequeño subconjunto para evitar inundar a los desarrolladores con infracciones.
4. Asegúrese de que sus desarrolladores puedan escanear su código inmediatamente después de su creación. También tiene sentido incluir el análisis estático en el proceso de CI / CD.
5. A medida que los desarrolladores progresan y limpian el código fuente, asegúrese de habilitar progresivamente más comprobadores de su lista. Al final del día, desea proporcionar evidencia de que cumple con todo el conjunto de pautas que seleccionó (no que se detuvo a la mitad). Para orientarse mejor en el proceso y comprender su progreso actual, puede implementar un sistema de informes central para ayudarlo a agregar los datos de prueba y monitorear el trabajo del desarrollador. Vea un ejemplo de esto a continuación:

Demostración de la idoneidad de la herramienta de análisis estático (calificación de la herramienta)

Dado que los informes de análisis estáticos pasan a formar parte del Sistema de gestión de calidad, no puede utilizar cualquier herramienta. La FDA exige que todas las herramientas utilizadas en el desarrollo y la verificación del software sean validado para el uso previsto. Hay diferentes formas de demostrar la idoneidad de la herramienta para su uso en desarrollos críticos para la seguridad. Dependiendo del riesgo del dispositivo, podría ser tan simple como reutilizar un certificado de cumplimiento o completar el proceso más largo de calificación de la herramienta.

Usando una certificación TÜV SÜD

Para el usuario final, la opción más conveniente es atribuirse el mérito del trabajo realizado por el proveedor de la herramienta y reutilizar la certificación otorgada para la herramienta de prueba por una organización de certificación externa como TÜV SÜD. Parasoft C / C ++test, por ejemplo, está cubierto con una certificación TÜV SÜD que se puede reutilizar para demostrar la idoneidad para desarrollar software de acuerdo con estándares médicos como IEC 62304.

Realización de la calificación de la herramienta

Para los dispositivos de alto riesgo, como la Clase C, es posible que deba validar la herramienta internamente en su entorno de desarrollo. La intención es proporcionar la evidencia de que la herramienta funciona de acuerdo con sus requisitos operativos, recopilados en el entorno de desarrollo del proyecto. Este es un proceso muy tedioso y que requiere mucho tiempo.

La mejor situación es si su proveedor de herramientas puede apoyarlo en este esfuerzo y proporcionar un Kit de calificación de herramientas especial, que contiene casos de prueba bien diseñados, el marco de automatización para ejecutarlos en el entorno de desarrollo del proyecto y generar automáticamente la documentación que puede servir como la evidencia para la validación de herramientas. Aquí nuevamente, el producto insignia de Parasoft, prueba C / C ++, proporciona un muy buen soporte en forma de kit de calificación de herramientas automatizado.

Endurecimiento de dispositivos médicos

La introducción del análisis estático, por supuesto, es un esfuerzo dedicado, que requiere tiempo y costo del desarrollador. Pero es una forma probada de fortalecer su sistema contra ataques maliciosos. La implementación del análisis estático con un conjunto bien pensado de pautas de seguridad le permite crear sistemas que puedan resistir futuros ataques imprevistos.