seguridad en sistemas digitales embarcados. proprietary information concepto certificación...

Seguridad en sistemas digitales embarcados

Proprietary Information

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 AC+Orders+ Special Condition

CS 25 AMC+GM+CRI

• 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


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


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


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


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.


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.


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


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


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


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 (FPGA´s,PLD´s) y SW y que vienen reglamentadas por :

RTCA DO 178 B / ED 12 BRTCA DO 254 / ED 80


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).


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)


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


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)


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


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)


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


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


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


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


• Terminación

• Revisión con los criterios Anexo A



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


• Terminación

• Revisión del código con los criterios Anexo A



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.


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


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


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


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

seguridad en sistemas digitales embarcados. proprietary information concepto certificación...

Documents

proceso de anlisis

requisitos de procesos

seguridad conforme

proceso de validacin

dal asignado

procesos de gestin

implementacindel sistema

sae arp