Guía de Identificación de los SOUP

Tabla de Contenidos

2. Introducción

El presente documento describe los pasos a seguir en la correcta identificación de los Software de Origen Desconocido o SOUP.

3. Objetivos

Identificar en forma apropiada los componentes software, utilizados por el área de ingeniería para la generación de sus productos software, que no han sido fabricados por esta área, o no han sido desarrollados bajo estándares aceptados por la norma internacional UNE EN 62304

4. Destinatarios

  • Líder de Proyectos

  • Administrador de la configuración de proyectos de desarrollo de > software.

  • Responsable de Aseguramiento de la Calidad del Software

5. Documentos Relacionados

  • Norma UNE EN 62304-2007/AMD2015

6. Criterios para la identificación

6.1. Software de tercera parte

El software de tercera parte NO se considera SOUP si se cumplen de forma simultánea las siguientes condiciones:

  • El fabricante del software cuenta con la certificación de un Sistema > de Gestión de la Calidad (SGC) basado en la norma internacional > ISO 13485.

  • El software es fabricado y mantenido de acuerdo a los requisitos > establecidos por la norma internacional UNE EN 62304.

  • Se tiene acceso por contrato a la documentación del software > desarrollado por la tercera parte.

Nota 1: Este es el caso más simple, básicamente sucede cuando la tercera parte es un subcontratista o un fabricante de librerías de software, con la certificación ISO 13485 o un Sistema de Gestión de la Calidad (SGC) compatible con otra normativa equivalente y completado con los procesos de la norma UNE EN 62304. Este es el estándar de oro, pero no siempre es factible.

Nota 2: Si el software proviene de un repositorio de código abierto, de un laboratorio de investigación privada (incluso en su empresa), de una universidad, o de cualquier otra tercera parte que NO tiene un proceso que cumpla con la norma UNE EN 62304, entonces se lo considera SOUP. Esto es independiente de la veracidad de la fuente o de la calidad del software utilizado.

Nota 3: Si el software proviene de un repositorio de código abierto, de un laboratorio de investigación privada (incluso en su empresa), de una universidad, o de cualquier otra tercera parte que NO tiene un proceso que cumpla con la norma UNE EN 62304, entonces se lo considera SOUP.

6.2 Software Legacy

El estándar UNE EN 62304 denomina Software Legacy (o “software heredado”) a aquel software diseñado por la propia empresa antes de implementar un marco de procesos conforme a los requisitos impuestos por esta norma internacional.

El fabricante puede estar interesado en que este tipo de software responda a los requisitos de la norma, ya sea porque lo utilizará en un nuevo dispositivo médico, porque realizará una actualización de éste, o bien, porque utilizará una porción del mismo en un nuevo software.

6.2.1 Tipos de cambios realizados en el software legacy

Hay muchos tipos posibles de cambios que se pueden hacer a un software existente. Una forma de clasificarlos es según la profundidad de los cambios en el diseño o en funcionalidades.

No hay cambios: Ni de arquitectura, ni de diseño detallado, ni funcionalidades. Las diferencias entre versiones se basan en la eliminación de algunos errores.

Cambios ligeros: La arquitectura de software no se modifica, sólo se modifica el diseño detallado y/o se realizan mejoras o actualizaciones a funcionalidades existentes.

Cambios profundos: La arquitectura de software está profundamente modificada y/o se añaden nuevas funcionalidades.

6.3 Casos limítrofes

En la mayoría de los casos, la situación a la que se enfrenta la empresa se encuentra situaciones complejas, como por ejemplo:

  1. El software es un software heredado desarrollado antes de que la > empresa implemente la norma UNE EN 62304. Este tipo de software se > considera SOUP.

  2. El software proviene de una tercera parte que es la norma UNE EN > 62304, pero que no tienen acceso a la documentación del software, > puede intentar cambiar las condiciones contractuales o tratarlo > como un SOUP.

En general, el software de tercera parte se puede calificar como SOUP en una base de caso por caso. Depende principalmente del tipo de relación con el fabricante del software y la naturaleza de la documentación suministrada con el software.

6.4 Ejemplos de software calificados SOUP y No-SOUP

  1. Sistemas operativos Ningún sistema operativo se encuentra diseñado para ser utilizado con fines médicos. Todos los sistemas operativos comúnmente utilizados (Windows, Mac OS, iOS, Android, Linux, etc.) son considerados SOUP.

  2. Controladores de hardware Todos los controladores suministrados por los fabricantes de hardware son SOUP. A menos que este hardware sea fabricado para ser utilizado como un dispositivo médico o un accesorio de dispositivos médicos; y además, se encuentra diseñado y mantenido con respecto a las normas y reglamentos.

  3. Marcos de desarrollo de software Los marcos de desarrollo de alto nivel como J2EE, ASP.NET, Flash, Ruby on Rails no son considerados SOUP. Los marcos nivel inferior entregados por los fabricantes de microchips no son SOUP tampoco.

    Se utilizan en IDE en tiempo de diseño y nunca entregan al usuario final.

  4. Tiempos de ejecución Al contrario de los marcos, todos los tiempos de ejecución utilizados para hacer el trabajo de software son SOUP: tiempo de ejecución C, el tiempo de ejecución de la ADA, el tiempo de ejecución de Java, Common Language Runtime, tiempos de ejecución entregados por los proveedores de micro-controladores, cualquier intérprete de lenguaje de tiempo de ejecución.

  5. Bibliotecas de código abierto Cualquiera que sea la licencia, bibliotecas de código abierto son considerados SOUP. Los términos de licencia que se encuentran en licencias de código abierto como Apache o LGPL no contemplan el uso de software de 3ª parte en dispositivos médicos.

  6. IDE, compiladores Las herramientas de desarrollo no son SOUP, los compiladores tampoco. Se utilizan en la fábrica, no en entornos clínicos.

    Los compiladores “Just-in-Time” se pueden categorizar como SOUP, ya que corren con el software suministrado en el ámbito clínico.

7. Tratamiento de elementos soup

7.1 Criterios centrales de gestión del SOUP

Los requisitos sobre SOUP se distribuyen en la norma UNE EN 62304. Principalmente estos son aproximadamente:

  1. Gestión de la configuración: SOUPs que tienen que ser gestionados mediante el proceso de administración de la configuración del software.

  2. Análisis de riesgo: Es obligatorio hacer un análisis de riesgos relacionados con los componentes SOUP.

  3. Requerimientos: El fabricante deberá describir para qué requerimientos (funcionales o no funcionales) es necesario trabajar con un SOUP.

  4. Arquitectura: El fabricante deberá definir que labor cumple, en condiciones apropiadas, el/los componentes SOUP dentro de la arquitectura de software.

  5. Mantenimiento: El fabricante deberá controlar el ciclo de vida de los elementos SOUP que incluya en sus productos: parches, nuevas versiones, etc.

7.2 Recomendaciones para el tratamiento de Sistemas Operativos SOUP

Los sistemas operativos proporcionan docenas de servicios, algunos son básicos (sistema de archivos, la pila IP), algunos son de nivel superior (gestión de múltiples pantallas, herramienta de archivo por defecto).

Dependiendo de la clase de seguridad, la integración de su software en el sistema operativo debe darse por sentado o no.

Para la clase C (donde existe riesgo de lesiones severas o muerte), es necesario listar los servicios básicos que se utilizan y para ponerlos a prueba unitaria. Para otras clases (A o B), es una decisión caso por caso con base en el análisis de riesgos.

7.2.1 Requerimientos

El estándar UNE EN 62304 requiere que el fabricante describa los requerimientos en los que resulta necesario utilizar SOUP.

En el caso del sistema operativo, se puede tomar el problema en orden inverso. Es más relevante para definir los requisitos para tener su trabajo de software con los servicios prestados por el sistema operativo. Tal vez no todos los servicios (sí, si se utiliza el sistema de archivos), pero sólo aquellos que son relevantes y / o particulares de su software.

7.2.2 Arquitectura

La norma UNE EN 62304 requiere que el fabricante defina las condiciones en las cuales interviene SOUP en dentro de la arquitectura de software.

Una vez más, se puede tomar el problema en el orden inverso, y definir su arquitectura de modo de tener funcionando siempre al sistema operativo. Con esta arquitectura, que puede terminar con los requisitos de hardware, para que el sistema operativo funcione en condiciones adecuadas.

7.2.3 Mantenimiento

La norma UNE EN 62304 requiere que el fabricante controle el ciclo de vida de SOUP: parches, nuevas versiones. Hay dos principales casos posibles:

  1. La versión del sistema operativo se congela en el diseño. Por ejemplo: el software funciona en Debian Linux 6.0.7 con el escritorio KDE.

  2. La versión del sistema operativo es dependiente del usuario. Por ejemplo, el software funciona en Windows XP SP3 o superior.

En el caso congelado, sólo las actualizaciones de seguridad cibernética pueden imponer un cambio de versión. En el caso abierto, las actualizaciones del sistema operativo pueden ser analizadas para verificar que no se degradan actuaciones del software, ni darán a nuevos problemas de seguridad.

Eso puede conducir a una verificación completa de su software para actualizar el sistema operativo. Esta verificación depende de los tipos de cambios en el sistema operativo. Una verificación completa es muy probable cuando se actualiza a una nueva versión, mientras que algunas pruebas pueden ser suficientes si se aplica un parche de seguridad.

7.2.4 Análisis de riesgos

Es obligatorio hacer un análisis de riesgos relacionados con un SOUP. Pero, ¿cómo hacer un análisis de riesgos en relación con un sistema operativo?

El análisis de riesgos se basa en la probabilidad y las consecuencias que el sistema operativo no proporcione sus servicios con los rendimientos esperados.

Los servicios prestados por los sistemas operativos se dan por sentados. Es cuando el software funciona en condiciones límite que las fallas del sistema operativo pueden suceder.

Si el software de lectura escribe un archivo de 5 kb cada minuto, sabemos que funciona en un PC estándar. Pero si su software de lectura-escritura trabaja sobre un archivo de 5 GB cada minuto, puede que no funcione. En este caso, algunas pruebas preliminares son necesarias para verificar que el sistema operativo puede mantener la carga en el tiempo. Y la arquitectura SW / HW puede ser actualizada también.

La clase de seguridad del software también es importante en el análisis de riesgos. Para el software de clase C, puede ser relevante evaluar cada servicio del sistema operativo, mientras que para otras clases, una evaluación macroscópica de integración HW+ OS+ SW puede ser suficiente.

7.3 Recomendaciones para el tratamiento de Drivers SOUP

Los drivers son más o menos los servicios adicionales conectados en el sistema operativo. Incluso si el servicio que prestan es particular para un hardware dedicado, los drivers deben ser tratados de una manera muy similar, aunque no idéntica, a la del sistema operativo. La principal diferencia es la presencia de hardware periférico, controlado por el driver. Eso significa que usted tiene que verificar que el hardware funciona en condiciones adecuadas.

7.3.1 Requerimientos

En cuanto al sistema operativo, que es relevante para definir los requisitos para tener su trabajo de software con los servicios prestados por el conductor.

7.3.2 Arquitectura

Del mismo modo, es necesario definir la arquitectura que debe trabajar con el driver y el hardware subyacente. Con esta arquitectura, que puede terminar con los requisitos de hardware, sistema operativo para que los drivers+ OS + el software trabajen en condiciones adecuadas.

7.3.3 Análisis de riesgos

El análisis de riesgos se basa en la probabilidad y las consecuencias de que el driver no proporcione sus servicios con los rendimientos esperados.

Pero hay una nueva condición. El análisis de riesgo se basa en la probabilidad y las consecuencias de que el hardware conectado no funcione con los rendimientos esperados. Este análisis de riesgo del hardware tal vez ya haya sido completado a nivel del sistema y puede ser un dato de entrada de diseño del software.