Seguridad en sistemas digitales embarcados

1
Seguridad en sistemas digitales embarcados
2
Concepto Certificación Aeronáutica

• Certificado de Tipo
• Funcionalidad, comportamiento, seguridad conforme
  a una Normativa
• Normativa de Certificación casi común
• CE / USA
• FAR 25 ACOrders Special Condition
• CS 25 AMCGMCRI
• Autoridad de Certificación FAA o EASA
• Certificación de organizaciones de diseño DOA /
  DOM
• Certificación de organizaciones de producción
• Certificación de organizaciones de mantenimiento

3
Proceso de Certificación y de aeronavegabilidad
continuada

• Solicitar iniciar un proceso de certificación de
  un nuevo tipo
• Acordar bases de Certificación
• Acordar un Plan de Certificación
• Generar evidencias (análisis, pruebas)
• Aprobación interna de las evidencias y manuales
  de operación y mantenimiento por los SCE / CVE
• Revisión por la autoridad de Certificación
• Emisión del certificado de tipo
• Certificado Suplementario para versiones
• Seguimiento incidentes / mejoras de diseño
• Boletines de Servicio
• Mantenimiento Programado

4
Ejemplos Sistemas Embarcados con SW

• Algunos ejemplos de sistemas embarcados
• Sistemas de Control Tail Boom
• Reabastecimiento en Vuelo DAL A
• Sistema de Gestión de Misión A 400
• Lanzamiento de Cargas DAL C

5
Requisitos genéricos para certificación en
sistemas embarcados

• Requisitos FAR 25 1309 AC 1309 1A / CS 25 1309
  características de seguridad comunes a todos los
  sistemas
• Conceptos Fallo Función / Efecto del Fallo
• Catalogación Efectos de Fallo en 4 niveles
• Catastrófico,Peligroso,Importante,Menor
• Protección contra fallo simple
• Objetivos Cuantitativos de Fiabilidad
• Medios de Cumplimiento aceptados
• Para sistemas basados en HW/SW SAE ARP 4754
• Establece el concepto DAL (Development Assurance
  Level) sistema
• Define requisitos de procesos en función DAL
• Requiere un proceso de análisis de seguridad
  SAE ARP 4761
• Invoca RTCA DO 178 B y RTCA DO 254 para HW y SW

6
Estructura ARP 4754

• Cap 3
• Define las características mas significativas de
  los sistemas integrados / complejos e introduce
  el concepto de DAL development assurance level
• Cap 4
• Resume la organización y coordinación del proceso
  de certificación e identifica la documentación a
  generar para soportar la certificación.
• Cap 5
• Describe el proceso para la identificación y
  clasificación de requisitos y para la asignación
  de los DAL a los elementos HW y SW del sistema en
  paralelo con el proceso de análisis de seguridad.

7
Estructura ARP 4754

• Cap 6
• Describe el proceso de análisis de seguridad que
  analiza los modos de fallo del sistema en función
  de la arquitectura y establece objetivos de
  seguridad cualitativos y cuantitativos para los
  elementos del sistema
• Cap 7
• Describe el proceso de validación para garantizar
  la corrección y completitud de los requisitos y
  la adecuación de la implementación
• Del sistema al uso previsto
• Cap 8
• Describe el procesos de Verificación que
  demuestra la correcta implementación de los
  requisitos en todos los productos intermedios
• Cap 9
• Describe el procesos de gestión de configuración
  que define la identificación y el control de
  cambios al sistema y sus elementos.
• Cap 10 Process Assurance
• Describe la adecuación de los procesos anteriores
  al DAL asignado al sistema. Es equivalente a una
  función QA especializada en procesos ARP 4754.

8
Documentación de Certificación por cada sistema

• Documentación entregable
• Plan de Certificacion (4.4.1)
• Requisitos
• Arquitectura
• Planes de todos los procesos de development
  assurance
• Indice de Configuracion (4.4.2)
• FHA
• PSSA / SSA
• CCA
• Documentación de verificación
• Documentación de Validación
• Resumen de Certificacion
• Evidencias de Process Assurance
• Evidencias de Gestión de Configuración
• No hay requisitos de formato o de soporte. Es
  aceptable soporte electrónico

9
Plan de Certificacion 4.4.1

• Descripción funcional operativa del sistema,
  arquitectura HW y SW, interfaces con el resto de
  sistemas y avión
• Resumen del FHA para las funciones relacionadas
• Resumen del PSSA , objetivos de seguridad de los
  elementos y DAL
• Nuevas tecnologías usadas
• Resumen de actividades de process assurance a
  realizar
• Documentación a generar / entregar
• Planificación de actividades en relación con
  certificación
• Personas de coordinación
• No hay requisitos de formato o de soporte. Es
  aceptable soporte electrónico

10
Análisis de Seguridad SAE ARP 4761

• Catalogo Funciones avión (ie control
  longitudinal)
• Análisis de Fallos función (HA) en distintos
  escenarios
• Catalogo de Fallos y Efectos (condiciones de
  Fallo)
• Catalogación condiciones de Fallo (catastrófico,
  peligroso, Importante, Menor)
• Asociación condiciones de Fallo función /
  sistemas contribuyentes
• Para cada condición de Fallo / Sistema
  contribuyente se desarrolla un árbol de fallos
  (FT)
• Asignación de objetivos de fiabilidad de
  componentes(subsistemas/equipos) del sistema. El
  SW no se considera en los análisis cuantitativos
• Realimentación con el diseño de arquitectura
  consideraciones de redundancia, monitorización,
  disimilaridad para eliminar el fallo simple y
  ajustar los objetivos cuantitativos de
  fiabilidad.
• Asignación del DAL a los componentes del sistema

11
Consideraciones sobre la asignacion del DAL

• El DAL del sistema junto con una serie de
  consideraciones en funcion de la arquitectura del
  sistema (redundancia, monitorizacion...) van a
  determinar el DAL de los elementos HW y SW.
• La asignación del DAL al sistema y a los
  elementos HW y SW se realiza durante la
  preparación del PSSA realizado de acuerdo a la
  ARP 4761.
• Los mecanismos de redundancia, monitorización...
  de acuerdo a los criterios de la tabla 5.2 y los
  párrafos 5.4.1.2 a 5.4.1.5 puede rebajar el DAL
  de un item.Esta rebaja debe estar justificado
  en el PSSA
• El DAL tiene un efecto importante en las
  actividades a realizar en función del DAL en los
  desarrollos HW (FPGAs,PLDs) y SW y que vienen
  reglamentadas por
• RTCA DO 178 B / ED 12 B
• RTCA DO 254 / ED 80

12
Consideraciones sobre la asignacion del DAL

• Redundancia de un elemento HW/SW
• Requerida para implementar el principio fail
  safe si la no disponibilidad de una función que
  implementa o a la que contribuye el elemento
  tiene una severidad catastrófica
• La redundancia puede implementarse como activo /
  activo , o activo /stand by . Requiere mecanismos
  de detección / conmutación
• Hay que garantizar que no hay causas comunes de
  fallo
• Pej alimentación eléctrica, vulnerabilidad por
  efectos zonales,
• Los elementos redundantes pueden ser disimilares
  o no
• Disimilaridad de elementos HW/SW
• Medio para evitar causas comunes de fallo por
  errores de diseño.
• Puede ser disimilaridad de diseño (requisitos
  comunes) o diseño disimilar independiente (
  requisitos y diseño).

13
Consideraciones sobre la asignación de DAL

• Monitorización
• Requerida para implementar el principio fail
  safe si la no integridad de una función que
  implementa o a la que contribuye el elemento
  tiene una severidad catastrófica
• Particionado (Segregación) de componentes HW/SW
  dentro de un elemento
• Pej Sistema Operativo ARINC 653 con particiones
• Segregación de componentes HW/SW que garantiza la
  no propagación de un fallo
• Permite asignar distinto DAL a los componentes
  segregadas
• No debe haber causas comunes de fallo
  (independencia)

14
Normativa para SW RTCA 178 B / ED 12 B

• Define requisitos para los procesos en funcion
  del Nivel (DAL) asignado al elemento SW
• Planificación (ciclo,métodos,herramientas,..
• Desarrollo
• Análisis de requisitos
• Diseño
• Programación
• Integración
• Verificación
• Gestión de Configuración
• Garantía de Calidad
• Enlace con autoridad de certificación
• Para cada subproceso de desarrollo productos y
  condiciones de terminación relacionadas con
  Verificación, GC y QA

15
RTCA 178 B / Interfaz con la autoridad de
Certificación

• Exige la entrega de una documentación mínima
  antes del comienzo y al finalizar
• Antes de comenzar el desarrollo la autoridad de
  certificación debe aprobar el Plan de de
  Certificación SW
• PSAC .
• Justificación del nivel (Ref. PSSA) , describe el
  tratamiento de algunos aspectos considerados
  (reutilización, carga, disimilaridad,) resume el
  cumplimiento de los objetivos e identifica los
  planes asociados desarrollo, verificación,
  gestión de configuración , garantía de calidad.
• La autoridad de certificación puede exigir
  información complementaria o/y auditar
  (típicamente cuatro veces en un desarrollo)

16
RTCA 178 B / Interfaz con la autoridad de
certificación

• Al finalizar el desarrollo y como parte de las
  evidencias para certificación
• SAS (Software Accomplishement Summary)
• Declaración Formal del cumplimiento planes
• Justificación de desviaciones
• Problemas que afecten seguridad
• CI (Configuration Index)
• Identificación de todos los componentes fuente
• Identificación de todos los documentos
• Instrucciones de regenerar un ejecutable
• Esta documentación debe ser preparada por cada
  versión que se utiliza en vuelo

17
RTCA 178 B / Restricciones SW COTS Sistemas
Operativos,Librerías graficas,Bases de Datos..)

• Tanto el SW de Aplicación como el SW de base
  tienen que haber sido desarrollados bajo RTCA 178
  B.
• Esto elimina para cualquier aplicación con
  involucraciones de seguridad por encima de DAL C
  (Fallo con efecto peligroso) cualquier producto
  comercial convencional y sw libre y en
  particular sistemas operativos.
• Hay productos comerciales especialmente
  desarrollados bajo RTCA 178 B como Sistemas
  Operativos (VxWorks, Integrity,LINX-OS..
  Librerías Open GL, pilas de protocolos de red
• Normalmente desarrollados en colaboración con el
  fabricante de los computadores (adaptación al HW)

18
Procesos RTCA DO 178 B

• Productos del Proceso de Planificación
• Plan de Desarrollo
• Debe identificar el ciclo (incremental, espiral,
  convencional..) y los standard de requisitos,
  diseño, programación.
• Plan de Verificación
• Criterios revisión, análisis a realizar,
  herramientas pruebas, infraestructura, (bancos)
  organización (independencia)
• Plan de Gestión de configuración
• Identificación, baselines,Cambios,
  Problemas,Copia y distribución
• Plan de Garantía de Calidad
• Organización, registros, auditoria producto
• Terminación
• Planes revisados y sometidos a CC

19
Procesos RTCA 178 B

• Proceso de Desarrollo
• Considera cuatro subprocesos pero no impone un
  modelo secuencial 
• Análisis de Requisitos sw 
• Diseño SW 
• Codificación 
• Integración
• En el proceso de desarrollo cada subproceso se
  da por terminado cuando se han generado los
  productos correspondientes, se ha realizado el
  análisis de trazabilidad y se han realizado las
  actividades de verificación, gestión de
  configuración y QA  
•  

20
Procesos RTCA 178 B

• Análisis de Requisitos SW
• Extraer de los requisitos sistema (funcionales,
  perfomance, interface) los requisitos sw. High
  Level Requirements.
• Identificar los requisitos adicionales con
  trazables a los requisitos sistema (consecuencia
  de la implementacion sw) y realimentarlos al
  análisis de seguridad
• Producto
• Documento / Base de Datos de Requisitos SW
• Conforme al standard de análisis de requisitos
  identificado en el Plan
• Tablas de Trazabilidad
• Terminación
• Revisión con los criterios Anexo A
• Evidencias registradas por QA

21
Procesos RTCA 178 B

• Diseño SW
• Definir una arquitectura sw donde se identifiquen
  los flujos de datos y de control entre los
  componentes sw
• Definir los requisitos (LLR) que permiten la
  codificación componentes
• Utilización frecuente de modelos como parte del
  diseño
• Productos
• Documento Descripción arquitectura
• Documento / Modelos requisitos bajo nivel
• Conforme al standard de diseño identificado en el
  Plan
• Tablas de Trazabilidad
• Terminación
• Revisión con los criterios Anexo A
• Evidencias registradas por QA

22
Procesos RTCA 178 B

• Codificación
• Generar el código fuente siguiendo el standard
  identificado en el Plan y utilizando un
  compilador cualificado generar código objeto. 
• SI se utilizan modelos en el diseño se puede
  generar código desde el modelo.
• Consideraciones sobre la calificación de
  compiladores y generadores de código desde
  modelos.
• Productos
• Código Fuente y Objeto
• Tablas de Trazabilidad
• Terminación
• Revisión del código con los criterios Anexo A
• Evidencias registradas por QA

23
Procesos RTCA 178 B

• Trazabilidad
• Se incluye dentro del macroproceso de desarrollo
  y su comprobación dentro del proceso de
  verificación
• El requisito es variable en función del nivel de
  criticalidad
•  
• Para nivel A y B debe haber trazabilidad desde
  requisitos sistema hasta código fuente
• Para nivel C trazabilidad desde requisitos
  sistema hasta requisitos componentes sw (LLR)
•  
• Para nivel D entre requisitos sistema y
  requisitos sw.
•  

24
Procesos RTCA 178 B

• Verificación (1)
• Tres tipos de actividades de Revisión, Análisis,
  Pruebas.
• Los objetivos de las actividades de verificación
  están definidas en las tablas del Anexo A
• La independencia en la realización de la
  verificación depende del nivel
• Revisión de
• Planes
• Requisitos
• Arquitectura y Diseño
• Código
• Casos de Prueba
• Resultados de Pruebas
• Análisis
• Peor caso para tiempos de ejecución
• Análisis de cobertura de pruebas frente a
  requisitos (HLR y LLR)
• Análisis de cobertura estructural de las pruebas

25
Procesos RTCA 178 B

• Verificación (2)
• Tres tipos de prueba 
• HW/SW Integration Testing (que asociamos a
  ensayos de calificación contra requisitos sw
  corriendo en el target). 
• Integración (que asociamos a integración entre
  componentes para validar la arquitectura) 
• Low Level (unitarias y de componentes)
• Dos criterios de definición de casos prueba  
• Cobertura de requisitos (high y low)
• Cobertura estructural 
• Los requisitos de cobertura estructural dependen
  del nivel de criticalidad del sw.
• Nivel C cobertura de sentencias
• Nivel B cobertura de decisiones
• Nivel A MCDC

26
Procesos RTCA 178 B

• Gestión de Configuración
• Actividades
• Identificación
• Baselining
• Control de Cambio (Trazabilidad,
  Identificación,informe)
• Archivo protegido de cambios,
• Recuperación de archivo (Retrieval),
• Autorización (Release)
• Retención (Conservación durante un tiempo)
• Gestión de Problemas generados durante el proceso
  de Verificación o durante la operación. La
  gestión de problemas esta conectada con el
  Control de Cambios.
• Control de Configuración del Entorno de
  Desarrollo. 
• Control de la Carga 

27
Procesos RTCA 178 B

• Garantía de Calidad
• Audita la realización de los procesos de acuerdo
  a los Planes.
• Comprueba las condiciones de terminación de cada
  subproceso de desarrollo
• Comprueba la realización de las actividades de
  verificación previstas en el Plan
• Comprueba la realización de las actividades de
  gestión de configuración previstas en el Plan
• Realiza un auditoria SW Conformity Review
  previa a por cada entrega de una versión de
  vuelo
• Paso previo a la emisión de SAS y de CI
•  

28
(No Transcript)