Capítulo 15 Garantía de Confiabilidad y seguridad · Este caso de confiabilidad puede requerir...

Capítulo 15 Garantía de Confiabilidad y seguridad

Conferencia 1

1Chapter 15 Dependability and Security Assurance

Temas Tratados

²Análisis estático²Pruebas de Fiabilidad²Pruebas de Seguridad²Aseguramiento del proceso²Casos de seguridad y confiabilidad


Validación de Sistemas Críticos

²Los costos de verificación y validación para sistemas críticos implican más procesos de validación y análisis que para los sistemas no críticos:

§Los costos y las consecuencias del fracaso son elevadas por lo que es más barato encontrar y eliminar las fallas que pagar por el fracaso del sistema.§Puede que tenga que hacer un caso formal a los clientes o a un regulador para que el sistema cumpla sus requerimientos de confiabilidad. Este caso de confiabilidad puede requerir actividades específicas de V&V (Verificación y Validación) para ser llevado a cabo.


Costos de Validación

²Debido a las actividades adicionales involucradas, los costos de validación de sistemas críticos suelen ser significativamente más elevados que los de sistemas no críticos. ²Normalmente, los costos de V & V ocupan más del 50% de los costos totales del desarrollo del sistema. ²El resultado del proceso de validación es una evidencia tangible que demuestra el nivel de fiabilidad de un sistema de software


Análisis Estático

²Las técnicas de análisis estático son técnicas de verificación de sistemas que no implican la ejecución de un programa. ²El trabajo en una representación fuente del software - ya sea un modelo o el código propio del programa. ²Inspecciones y revisiones son una forma de análisis estático.²Técnicas cubiertas aquí:

§Verificación formal§Comprobación de modelo§Análisis automatizado de programa


Verificación y métodos formales

²Los métodos formales se pueden utilizar cuando se produce una especificación matemática del sistema. ²Estos son las técnicas máximas de verificación que se puede utilizar en diferentes etapas en el proceso de desarrollo:

§Una especificación formal puede ser desarrollada y analizada matemáticamente para identificar inconsistencias. Esto ayuda a descubrir errores y omisiones de especificación. §Pueden ser desarrollados argumentos formales para que un programa se ajuste a su especificación matemática. Esto es efectivo en el descubrimiento de errores de programación y diseño.


Argumentos a favor de los métodos formales

²Producir una especificación matemática requiere de un análisis detallado de los requerimientos y es probable que se descubran errores.²Los sistemas concurrentes pueden ser analizados para descubrir las condiciones de carrera que pueden llevar a un bloqueo mutuo. Las pruebas para tales problemas son muy difíciles. ²Estos pueden detectar errores de implementación antes de las pruebas, cuando el programa se analiza junto con la especificación. ²


Argumentos en contra de los métodos formales

²Requieren notaciones especializadas que no pueden ser entendidas a menos que sean expertos del dominio. ²Muy costoso para desarrollar una especificación e incluso más costoso para mostrar que un programa cumple con esa especificación. ²Las pruebas pueden contener errores. ²Puede ser posible alcanzar el mismo nivel de confianza en un programa más barato utilizando otras técnicas de V & V.


Comprobación de modelo

²Involucra la creación de un modelo de estados finitos extendido de un sistema y, usando un sistema especializado (un verificador de modelos), comprobando ese modelo de errores. ²El verificador de modelos explora todas las rutas posibles a través del modelo y comprueba que una propiedad especificada por el usuario sea válida para cada camino. ²La comprobación de modelo es particularmente valiosa para la verificación de sistemas concurrentes, los cuales son difíciles de probar. ²Aunque la comprobación de modelo es computacionalmente muy costosa, ahora es práctico usarlo en la verificación de sistemas críticos pequeños a medianos. ²²


Comprobación de modelo


Análisis estático automático

²Los analizadores estáticos son herramientas de software para el procesamiento de texto fuente.²Estos analizan el texto del programa y tratan de descubrir condiciones potencialmente erróneas y mostrarlas para captar la atención del equipo de V & V. ²Estos son muy efectivos como una ayuda para las inspecciones – ellos son un suplemento, pero no un reemplazo para las inspecciones


Comprobaciones de análisis estático Automatizado

Clase de Fallas Comprobación de análisis estático

Fallas de datos Variables usadas antes de inicialización.Variables declaradas pero nunca usadas.Variables asignadas dos veces pero nunca usadas entreasignaciones.Posible s violaciones de límites de arreglo.Variables no declaradas.

Fallas de control Código inalcanzable.Ramas incondicionales en ciclos.

Fallas de entrada/salida Variables de salida dobles sin intervención de asignación.

Fallas de interfaz Incompatibilidad del tipo de parámetro.Incompatibilidad del número de parámetro.No se usan los resultados de funciones.Funciones y procedimientos no llamados.

Fallas de gestión dealmacenamiento

Punteros no asignados.Aritmética de punteros.Fugas de memoria.


Niveles de análisis estático

²Comprobación de error característico§El analizador estático puede buscar patrones en el código que sean característicos de errores cometidos por los programadores utilizando un lenguaje en particular.

²Comprobación de error definido por el usuario§Los usuarios de un lenguaje de programación definen patrones de error, por lo tanto, se extienden los tipos de error que pueden detectarse. Esto permite que las reglas específicas que aplican al programa sean comprobadas.

²Comprobación de aserción§Los desarrolladores incluyen aserciones formales en su programa y las relaciones que deben sostener. El analizador estático ejecuta simbólicamente el código y destaca los problemas potenciales


Uso del análisis estático

²Particularmente valioso cuando se utiliza un lenguaje como C, el cual tiene una tipificación débil, por lo tanto, muchos errores no son detectados por el compilador. ²Particularmente valioso para la comprobación de seguridad –el analizador estático puede descubrir áreas de vulnerabilidad, tales como desbordamiento de buffer o entradas sin verificar. ²El análisis estático se utiliza ahora de manera rutinaria en el desarrollo de muchos sistemas críticos de seguridad.


Pruebas de Fiabilidad

²La validación de fiabilidad implica el ejercicio del programa para evaluar si se ha alcanzado o no el nivel requerido de fiabilidad.²Esto no puede normalmente ser incluido como una parte de un proceso normal de pruebas de defectos porque los datos para las pruebas de defecto son (usualmente) atípicos de los datos de uso reales.²Por lo tanto, la medición de la confiabilidad requiere de un conjunto de datos especialmente diseñados que reproducen el patrón de las entradas para ser procesados por el sistema.


Actividades de validación de la Confiabilidad

²Establecer el perfil operativo para el sistema. ²Construir datos de prueba que reflejen el perfil operativo. ²Probar el sistema y observar el número de fallas y los momentos de estas fallas. ²Calcular la fiabilidad después de haber observado un número estadísticamente significativo de fallas.


Medición de la Confiabilidad


Pruebas Estadísticas

²Probar el software para la fiabilidad más que para la deteccíón de fallas. ²La medición del número de errores permite predecir la fiabilidad del software. Tenga en cuenta que, por razones estadísticas, deben ser inducidos más errores de los permitidos en la especificación de fiabilidad.²Un nivel aceptable de fiabilidad debe ser especificado y el software probado y modificado hasta que se alcance ese nivel de fiabilidad. ².


Problemas de medición de la Confiabilidad

²Incertidumbre del perfil operativo §El perfil operativo puede no ser un reflejo preciso del uso real del sistema.

²Altos costos de la generación de datos de prueba§Los costos pueden ser muy elevados si los datos de prueba para el sistema no se pueden generar de forma automática.

²La incertidumbre estadística§Se necesita un número estadísticamente significativo de fallas para calcular la fiabilidad, pero sistemas altamente fiables raramente fallarán.

²Reconociendo la falla §No siempre es evidente cuando se ha producido un fallo, ya que puede haber interpretaciones conflictivas de una especificación.


Perfiles operativos

²Un perfil operativo es un conjunto de datos de prueba cuya frecuencia coincide con la frecuencia real de estas entradas de uso "normal" del sistema. Una coincidencia cercana con el uso real es necesaria de lo contrario la fiabilidad medida no se reflejará en el uso real del sistema. ²Puede ser generado a partir de datos reales recogidos de un sistema existente o (más a menudo) depende de los supuestos realizados sobre el patrón de uso de un sistema.


Un perfil operativo


Generación de perfiles operacionales

²Debe ser generado de forma automática siempre que sea posible.²La generación automática de perfiles es difícil para los sistemas interactivos. ²Puede ser fácil para las entradas "normales", pero es difícil predecir entradas "improbables" y crear datos de prueba para ellas. ²El patrón de uso de los nuevos sistemas es desconocido. ²Los perfiles operacionales no son estáticos, sino que cambian a medida que los usuarios aprenden acerca de un nuevo sistema y cambian la forma en que lo utilizan.


Puntos clave

²El análisis estático es una aproximación a la V & V, que examina el código fuente (u otra representación) de un sistema en busca de errores y anomalías. Permite que todas las partes de un programa sean revisadas, no sólo aquellas partes que se ejercitan mediante pruebas del sistema. ²La comprobación del modelo es un enfoque formal al análisis estático que comprueba de forma exhaustiva todos los estados en un sistema en busca de errores potenciales. ²Las pruebas estadísticas se utilizas para evaluar la fiabilidad del software. Se apoyan probar el sistema con un conjunto de datos de prueba que refleja el perfil operativo del software.


Capítulo 15 Garantía de Confiabilidad y seguridad

Conferencia 2


Pruebas de seguridad

²Prueba de la medida en que el sistema puede protegerse a sí mismo de ataques externos. ²Los problemas con las pruebas de seguridad

§Los requerimientos de seguridad son los que definen ‘lo que no se debe hacer’, ellos especifican lo que no debe suceder. Normalmente, no es posible definir los requerimientos de seguridad tales como restricciones simples que pueden ser verificadas por el sistema. §Las personas que atacan a un sistema son inteligentes y buscan vulnerabilidades. Pueden experimentar para descubrir las debilidades y lagunas en el sistema.

²El análisis estático se puede utilizar para guiar al equipo de pruebas a las áreas del programa que pueden incluir errores y vulnerabilidades.


La validación de seguridad

²Validación basada en la experiencia §El sistema es revisado y analizado contra los tipos de ataque que son conocidos por el equipo de validación.

²Equipos ‘tigre’§Se establece un equipo cuyo objetivo es violar la seguridad del sistema mediante la simulación de ataques al sistema.

²Validación basada en herramientas §Varias herramientas de seguridad, tales como verificadores de contraseñas se utilizan para analizar el sistema en funcionamiento.

²La verificación formal §El sistema se verifica contra una especificación formal de seguridad. §


Ejemplos de entradas de una lista de control de seguridad

Lista de verificación de seguridad 1. ¿Todos los archivos que se crean en la aplicación tienen permisos adecuados de acceso? Los permisos incorrectos de acceso pueden conducir a que usuarios no autorizados tengan acceso a esos archivos2. ¿El sistema termina automáticamente las sesiones de usuario después de un período de inactividad ? Las sesiones que se mantienen activas pueden permitir el acceso no autorizado a través de un ordenador desatendido .3. Si el sistema está escrito en un lenguaje de programación sin comprobación de límites de arreglo, ¿existen situaciones donde pueda explotarse el desbordamiento de buffer? El desbordamiento de buffer puede permitir que los atacantes envíen cadenas de código al sistema y luego las ejecuten .4. Si se establecen contraseñas, ¿el sistema comprueba que las contraseñas sean "fuertes" ? Las contraseñas fuertes constan de letras , números y signos de puntuación mezclados, y no son entradas normales de diccionario. Son más difíciles de romper que las contraseñas simples.5. ¿ Las entradas procedentes del entorno del sistema siempre se comprueban contra una especificación de entrada? El procesamiento incorrecto de entradas mal formadas es una causa común de las vulnerabilidades de seguridad.


Aseguramiento del proceso

²El aseguramiento del proceso implica definir un proceso confiable y asegurar que este proceso es seguido durante el desarrollo del sistema. ²El aseguramiento del proceso se centra en:

§¿Tenemos los procesos correctos? ¿Son los procesos adecuados para el nivel de fiabilidad requerido. Deben incluir requerimientos de gestión, gestión de cambios, revisiones e inspecciones, etc.§¿Estamos realizando los procesos correctamente? ¿Estos procesos han sido seguidos por el equipo de desarrollo?

²El aseguramiento del proceso genera documentación §Por lo tanto los procesos ágiles rara vez se utilizan para los sistemas críticos.


Procesos para la garantía de la seguridad

²El aseguramiento del proceso es importante para el desarrollo de sistemas de seguridad crítica:

§Los accidentes son eventos inusuales por lo que las pruebas pueden no detectar todos los problemas; §Los requerimientos de seguridad son a veces 'no debe' requerimientos por lo que no pueden ser demostrados a través de pruebas.

²Las actividades de garantía de la seguridad pueden ser incluidas en el proceso de software que registra los análisis que se han llevado a cabo y las personas responsables de los mismos.

§La responsabilidad personal es importante como las fallas del sistema pueden dar lugar a acciones legales posteriores.


Actividades de los procesos relacionados con la seguridad

²Creación de un registro de riesgos y el sistema de monitoreo. ²Nombramiento de los ingenieros de seguridad de proyectos que tienen la responsabilidad explícita de la seguridad del sistema. ²Uso extensivo de los exámenes de seguridad.²Creación de un sistema de certificación de la seguridad, donde la seguridad de los componentes críticos se certifica formalmente. ²Gestión de la configuración detallada (véase el capítulo 25).


Análisis del peligro

²El análisis de peligros consiste en la identificación de riesgos y sus causas fundamentales.²Debe haber trazabilidad clara de los riesgos identificados a través de su análisis a las medidas adoptadas durante el proceso para asegurar que dichos riesgos se hayan cubierto.²Un registro de riesgos puede ser utilizado para realizar un seguimiento a los peligros (riesgos) durante todo el proceso.


Una entrada de registro de peligros simplificado


Casos de protección y confiabilidad

²Los casos de seguridad y confiabilidad son documentos estructurados que establecen argumentos y evidencias detallados de que un nivel requerido de seguridad o fiabilidad se ha logrado.²Ellos son normalmente requeridos por los reguladores antes de que un sistema sea certificado para su uso operativo. La responsabilidad del regulador es comprobar que un sistema es tan seguro y confiable como práctico.²Los reguladores y los desarrolladores trabajan juntos y negociar lo que debe incluirse en un caso de la seguridad / fiabilidad del sistema .


El caso de confiabilidad del sistema

²Un estudio de seguridad es:§Una evidencia documentada que proporciona un argumento convincente y válido de que un sistema está adecuadamente protegido para una aplicación determinada en un entorno determinado.

²Los argumentos en un caso de seguridad o fiabilidad pueden basarse en pruebas formales, diseño de lógica, pruebas de seguridad, etc. Factores de proceso también pueden ser incluidos.²Un caso de seguridad/fiabilidad de software es parte de un caso de seguridad / fiabilidad de un sistema más amplio.


Contenido de un caso de protección de softwareFalto la traducción

Capitulo Descripcion

Descripcion del sistema Una visión general del sistema y una descripción de sus componentes críticos.

Requerimientos de seguridad

Los requisitos de seguridad abstraídas de la especificación de requisitos del sistema. Detalles deotros requisitos relevantes del sistema también se pueden incluir.

Analisis de preligros y riegos

Documentos que describen los peligros y riesgos que han sido identificados y las medidasadoptadas para reducir el riesgo. Peligro de análisis y registros de peligro.

Diseno y analisis Un conjunto de argumentos estructurados (véase la sección 15.5.1) que justifican por qué eldiseño es seguro.

Verificacion y validacion Una descripción de los procedimientos de V & V utilizados y, en su caso, los planes de pruebapara el sistema. Los resúmenes de los resultados de las pruebas que presenten lesiones que hansido detectados y corregidos. Si se han utilizado los métodos formales, una especificación delsistema formal y todos los análisis de esa especificación. Los registros de los análisis estáticos delcódigo fuente.

Revisar los informes Los registros de todas las revisiones de diseño y de seguridad.

Competencias de equipo Evidencia de la competencia de todo el equipo involucrado en el desarrollo de sistemasrelacionados con la seguridad y validación.

Procesos QA Los registros de los procesos de garantía de calidad (véase el capítulo 24) llevó a cabo durante eldesarrollo del sistema.

Cambio y gestion de procesos

Los registros de todos los cambios propuestos, las medidas adoptadas y, en su caso, lajustificación de la seguridad de estos cambios. Información sobre los procedimientos de gestión deconfiguración y los registros de gestión de la configuración.

Casos asociados a la seguridad

Las referencias a otros casos de seguridad que pueden afectar a la justificación de la seguridad.35Chapter 15 Dependability and Security Assurance

Argumentos estructurados

²Los casos de seguridad/confiabilidad deberán basarse en argumentos estructurados que presenten evidencia para justificar las afirmaciones hechas en estos argumentos.²El argumento justifica por qué una afirmación acerca de la confiabilidad/seguridad del sistema se justifica por la evidencia disponible.


Argumentos estructurados


Argumento de la seguridad de la bomba de insulina

²Los argumentos se basan en alegaciones y pruebas (evidencias).²La seguridad de la bomba de insulina:

§Afirmación: La máxima dosis de insulina para ser entregada (currentDose) no excederá MaxDose.§Evidencia: El argumento de protección para la bomba de insulina (explicado más adelante)§Evidencia: Los datos de prueba para la bomba de insulina. El valor de currentDose se calculó correctamente en 400 pruebas §Evidencia: Informe de análisis estático para el software de la bomba de insulina no reveló anomalías que afectan el valor de CurrentDose§Argumento: La evidencia presentada demuestra que la dosis máxima de insulina que puede ser calculada = MaxDose.


Argumentos estructurados de protección

²Los argumentos estructurados que demuestran que un sistema cumple con sus obligaciones de protección.²No es necesario demostrar que el programa funciona como se esperaba; el objetivo es simplemente demostrar la protección.²Generalmente basados en una jerarquía de afirmación.

§Usted comienza en las hojas de la jerarquía y demuestra la protección. Esto implica que las demandas de más alto nivel son verdaderas.


Una jerarquía de afirmaciones de protección para la bomba de insulina


Argumentos de protección

²Los argumentos de protección pretenden demostrar que el sistema no puede llegar en estado inseguro. ²Estos son más débiles que los argumentos de corrección que deben demostrar que el código del sistema se ajusta a su especificación.²Ellos se basan generalmente en la prueba por reducción al absurdo (contradicción)

§Suponga que un estado inseguro puede ser alcanzado; §Demuestre que esto se contradice por el código del programa.

²Un modelo gráfico del argumento de protección puede ser desarrollado.


La construcción de un argumento de protección

²Establezca las condiciones de salida de seguridad para un componente o un programa.²A partir del final del código, trabajar hacia atrás hasta que haya identificado todas las rutas que conducen a la salida del código.²Suponga que la condición de salida es falsa.²Demuestre que, para cada ruta que conduce a la salida que las asignaciones realizadas en esa ruta contradicen el supuesto de una salida peligrosa del componente.


Cálculo de dosis de insulina con los controles de seguridad

-- La dosis de insulina a adminisrtar es función del nivel de azúcar en la sangre,-- la dosis previa administrada y el momento de administración de la dosis previa

currentDose = computeInsulin () ;

// Comprobación de protección — ajustar currentDose si es necesario.// enunciado if 1if (previousDose == 0){

if (currentDose > maxDose/2)currentDose = maxDose/2 ;

}else

if (currentDose > (previousDose * 2) )currentDose = previousDose * 2 ;

// enunciado if 2if ( currentDose < minimumDose )

currentDose = 0 ;else if ( currentDose > maxDose )

currentDose = maxDose ;administerInsulin (currentDose) ;


Argumentos de protección informales basados en contradicciones de demostración


Rutas del programa

²Ninguna rama del enunciado if 2 se ejecuta §Sólo puede ocurrir si currentDose es> = minimumDose y <= maxDose.

²A continuación, se ejecuta la rama then del enunciado if 2

§currentDose = 0.²Se ejecuta la rama else-if del enunciado if 2

§currentDose = maxDose.²En todos los casos, las condiciones posteriores contradicen la situación de inseguridad de que la dosis administrada es mayor que maxDose.


Puntos clave

²La validación de la seguridad es difícil debido a que los requerimientos de seguridad establecen lo que no debería ocurrir en un sistema, en lugar de lo que debería. Más aún, los atacantes del sistemas son inteligentes y pueden dedicarse a investigar las debilidades más tiempo que el disponible para las pruebas de seguridad.²La validación de seguridad puede llevarse a cabo utilizando el análisis basado en la experiencia, el análisis basado en herramientas o equipos 'tigre' que simulan ataques a un sistema.²Es importante contar con un proceso certificado bien definido para el desarrollo de sistemas críticos de protección. El proceso debe incluir la identificación y seguimiento de los peligros potenciales.


Puntos clave

²Los casos de protección y confiabilidad reúnen toda la evidencia que demuestra que un sistema es seguro y confiable. Los casos de protección son necesarios cuando un regulador externo debe certificar el sistema antes de su uso.²Por lo general, los casos de protección se basan en argumentos estructurados. Los argumentos estructurados de protección muestran que una condición peligrosa identificada nunca ocurrirá, al considerar todas las rutas del programa que conduzcan a una condición no protegida y al probar que la condición no puede sostener.


Capítulo 15 Garantía de Confiabilidad y seguridad · Este caso de confiabilidad puede requerir...

Documents

Transcript of Capítulo 15 Garantía de Confiabilidad y seguridad · Este caso de confiabilidad puede requerir...