Captulo 12 - Confiabilidad y Especificacin de Seguridad.

Lectura 1 UNMSM-FCM-CC

Chapter 12 Dependability and Security Specification

Temas Tratados
Especificacin orientada al riesgo Especificacin de la Proteccin. Especificacin de la Seguridad. Especificacin de fiabilidad de software.

Chapter 12 Dependability and Security Specification

Requerimientos de confiabilidad
Requisitos funcionales define la comprobacin de errores, recuperacin y proteccin contra fallas del sistema. Los requerimientos no funcionales define la fiabilidad requerida y disponibilidad del sistema. Excepcin de requisitos define los estados y condiciones que no deben presentarse.

Chapter 12 Dependability and Security Specification

Especificacin orientada al riesgo

Las especificaciones de los sistemas crticos deben ser impulsados hacia el riesgo. Este enfoque ha sido ampliamente utilizado en los sistemas de proteccin y de seguridad-crticos. El objetivo del proceso de especificacin debe ser: entender los riesgos (proteccin, seguridad, etc) que son enfrentados por el sistema y definir los requerimientos para reducir estos riesgos.

Chapter 12 Dependability and Security Specification

Etapas del anlisis basado en el riesgo

Identificacin de Riesgos. Se identifican los riesgos potenciales que puedan surgir. Anlisis de riesgos y la clasificacin. Se evala la gravedad de cada riesgo. Descomposicin de riesgos. Se descomponen los riesgos para descubrir sus causas potenciales. Evaluacin de la reduccin del riesgo Definen cmo cada riesgo debe ser inducido a su eliminacin o reducido cuando el sistema est diseado.
Chapter 12 Dependability and Security Specification 5

Riesgo impulsada por especificacin.

Chapter 12 Dependability and Security Specification

Fases de anlisis de riesgos.

Anlisis preliminar del riesgo. Identifica los riesgos del entorno de los sistemas. El objetivo es desarrollar un conjunto inicial de seguridad del sistema y los requisitos de confiabilidad. Ciclo de vida del anlisis de riesgos. Identifica los riesgos que surgen durante el diseo y desarrollo; por ejemplo, riesgos que estn asociados con las tecnologas utilizadas para la construccin del sistema. Los requisitos se extienden a la proteccin contra estos riesgos. Anlisis de riesgo operacional. Los riesgos estn asociados con la interfaz de usuario del sistema y errores del operador. Otros requisitos de proteccin se pueden aadir para hacer frente a estos riesgos.

Chapter 12 Dependability and Security Specification

Especificacin de la Proteccin
El objetivo es identificar los requisitos de proteccin que aseguran que las fallas del sistema no causen lesiones, muerte o daos ambientales. La identificacin del riesgo = Identificacin del peligro. El anlisis de riesgo = Evaluacin del peligro. Descomposicin del Riesgo = Anlisis del peligro. La reduccin del riesgo = especificaciones de requerimientos de la proteccin

Chapter 12 Dependability and Security Specification

Identificacin del peligro

Identificar los riesgos que puedan amenazar al sistema. La identificacin del peligro puede basarse en diferentes tipos de peligros: Peligros fsicos Peligros elctricos Peligros biolgicos Peligros de fallo de servicio Etc.

Chapter 12 Dependability and Security Specification

Riesgos de la bomba de insulina.

Sobredosis de insulina (falla del servicio). Dosis insuficiente de insulina (falla del servicio). Fallo en encender el servicio debido a la batera agotada (elctrico). Interferencia elctrica con otros equipos mdicos (elctrico). Ineficiencia en el sensor y en el actuador de contacto (fsico). Piezas de la mquina rotas o desprendidas (fsico). Infeccin causada por el uso de la mquina contaminada (biolgica). Reaccin alrgica a los materiales o a la insulina (biolgico).
Chapter 12 Dependability and Security Specification 10

Evaluacin del peligro.

Este proceso est relacionado con el entendimiento de la probabilidad del aparecimiento de un riesgo y las posibles consecuencias en caso de que ocurra un accidente o incidente. Los riesgos se pueden clasificar como: Intolerable. Nunca debe surgir o resultar en un accidente As low as reasonably practical (ALARP ). Debe minimizar la posibilidad de riesgo dadas las limitaciones de costo y cronograma. Aceptable. Las consecuencias de los riesgos son aceptables y ningn gasto adicional debe ser realizado para reducir la probabilidad de riesgo
Chapter 12 Dependability and Security Specification 11

Tringulo de Riesgo

Chapter 12 Dependability and Security Specification

12

La aceptacin social del riesgo

La aceptabilidad de un riesgo se determina por consideraciones humanas, sociales y polticas. En la mayora de las sociedades, sus individuos estn menos dispuestos a aceptar el riesgo mientras avanza el tiempo Por ejemplo, los costos de la limpieza de la contaminacin pueden ser menos costosos que la prevencin de ella, pero esto no puede ser socialmente aceptable. La evaluacin de riesgos es subjetiva Los riesgos son identificados como probables, improbables, etc. Esto depende de quin est haciendo la evaluacin.
Chapter 12 Dependability and Security Specification 13

Evaluacin del peligro

Estimar la probabilidad del riesgo y la severidad del riesgo. Normalmente no es posible hacer esto precisamente. Por lo tanto, valores relativos son utilizados como "poco probable", "raro", "muy alto", etc. El objetivo debe ser el de excluir los riesgos que puedan surgir o que tengan alta gravedad.

Chapter 12 Dependability and Security Specification

14

Clasificacin de riesgo para la bomba de insulina

Peligro identificado
1. Clculo de sobredosis de insulina 2. Clculo de dosis insuficiente de insulina

Probabilidad de riesgo
Medio Medio Medio Alto Alto

Severidad del accidente

Alto Bajo Medio Bajo Alto

Riesgo estimado Aceptabilidad

Alto Bajo Bajo Bajo Alto Intolerable Aceptable ALARP Aceptable Intolerable

3. Fallo del sistema de monitoreo de hardware

4. Falla de energa 5. Mquina instalada incorrectamente

6. La mquina deja de funcionar durante el tratamiento

7. Infeccin causada por mquinas 8. Interferencia elctrica 9. Reaccin alrgica

Bajo

Alto

Medio

ALARP

Medio Bajo Bajo

Medio Alto Bajo

Medio Medio Bajo

ALARP ALARP Aceptable

Chapter 12 Dependability and Security Specification

15

Anlisis del peligro

Interesado por el descubrimiento de las causas de los riesgos en un sistema en particular. Las tcnicas han sido en su mayora derivadas de la proteccin de los sistemas crticos y pueden ser Inductivos, tcnicas de abajo hacia arriba. Comienza con un fallo del sistema propuesto y evala los riesgos que puedan derivarse de ese fracaso. Deductivo, tcnicas de arriba hacia abajo. Comienza con un peligro y deduce cules seran sus posibles causas.

Chapter 12 Dependability and Security Specification

16

Anlisis del rbol de fallos

Tcnica deductiva de arriba hacia abajo. Pone el riesgo o peligro en la raz del rbol e identifica los estados del sistema que podran conducir a ese peligro. En este caso, vincularlos con condiciones "and" o "or". Un objetivo debe ser reducir al mnimo el nmero de causas de un fallo del sistema.

Chapter 12 Dependability and Security Specification

17

Ejemplo de rbol de fallos de software

Chapter 12 Dependability and Security Specification

18

Anlisis del rbol de fallos

Tres condiciones posibles que pueden conducir a la entrega de dosis incorrecta de insulina Medicin incorrecta del nivel de azcar en la sangre Fallo del sistema de entrega Dosis administrada en el momento equivocado Mediante el anlisis del rbol de fallas, las causas fundamentales de estos peligros relacionados con el software son: Error algortmico Error aritmtico
Chapter 12 Dependability and Security Specification 19

Reduccin de riesgo
El objetivo de este proceso es identificar los requisitos de confiabilidad que especifican cmo los riesgos deben ser gestionados y asegurar que los accidentes / incidentes no lleguen a ocurrir. Estrategias de reduccin de riesgos Evitar los riesgos; Deteccin y remocin del riesgo; Limitacin de daos.

Chapter 12 Dependability and Security Specification

20

Estrategia de uso
Normalmente, en los sistemas crticos, una combinacin de estrategias de reduccin de riesgos se utilizan. En un sistema de control de un establecimiento qumico, el sistema incluye sensores para detectar y corregir el exceso de presin en el reactor. Sin embargo, tambin se incluye un sistema de proteccin independiente que abre una vlvula de alivio, si una presin peligrosamente alta se detecta.

Chapter 12 Dependability and Security Specification

21

Bomba de insulina - los riesgos del software

Error aritmtico Un clculo hace que el valor de una variable se desborde o sea insuficiente. Puede incluirse un controlador de excepciones para cada tipo de error aritmtico. Error algortmico. Compara dosis que se entregarn con la dosis anterior o la dosis ms segura. Reduce la dosis si es demasiado alto.

Chapter 12 Dependability and Security Specification

22

Ejemplos de requisitos de la Proteccin

SR1: El sistema no emitir una sola dosis de insulina que es mayor que una dosis mxima especificada por un usuario del sistema. SR2: El sistema no deber entregar una dosis diaria acumulativa de la insulina que es mayor que una dosis diaria mxima especificada por un usuario del sistema. SR3: El sistema incluir un centro de diagnstico de hardware que se llevar a cabo por lo menos cuatro veces por hora. SR4: El sistema debe incluir un controlador de excepciones para todas las excepciones que se identifican en la Tabla 3. SR5: La alarma audible debe sonar cuando cualquier hardware o software tenga una anomala detectada, y un mensaje de diagnstico, tal como se define en la Tabla 4, se mostrar. SR6: En caso de una alarma, la administracin de insulina se suspender hasta que el usuario reinicie el sistema y borra la alarma.
Chapter 12 Dependability and Security Specification 23

Puntos clave
El anlisis de riesgos es una actividad importante en la especificacin de requisitos de seguridad y confiabilidad. Se trata de identificar los riesgos que pueden resultar en accidentes o incidentes. Una aproximacin basada en el riesgo se puede utilizar para comprender los requisitos de la proteccin de un sistema. Usted identifica peligros potenciales y se descomponen estos (utilizando mtodos como el anlisis de rbol de fallos) para descubrir sus causas primordiales. Requisitos de seguridad deben ser incluidos para asegurar que los riesgos y los accidentes no se produzcan o, si esto no es posible, para limitar el dao causado por la falla del sistema. Chapter 12 Dependability and Security Specification 24

Captulo 12 - Confiabilidad y especificacin de seguridad.

Lectura 2 UNMSM-FCM-CC

Chapter 12 Dependability and Security Specification

25

Especificacin del sistema confiabilidad

La fiabilidad es un atributo del sistema mensurable por lo que los requisitos no funcionales de fiabilidad se puede especificar cuantitativamente. stas definen el nmero de fallos que son aceptables durante el uso normal del sistema o el tiempo en el que el sistema deber estar disponible. Los requisitos funcionales de fiabilidad definen las funciones del sistema y software que evitan, detectan o toleran fallos en el software, y adems aseguran que estos fallos no conduzcan a un fallo del sistema. Los requerimientos de fiabilidad del software tambin se pueden incluir para hacer frente a un fallo de hardware o un error del operador.
Chapter 12 Dependability and Security Specification 26

Confiabilidad proceso de especificacin

Identificacin de riesgos Identificar los tipos de fallo del sistema que pueden dar lugar a prdidas econmicas. Anlisis de riesgos Estimacin de los costos y las consecuencias de los diferentes tipos de fallo de software. Riesgo de descomposicin Identificar las causas de fallo del sistema. Reduccin de riesgos Generar especificaciones de fiabilidad, incluidos los requisitos cuantitativos que definen los niveles aceptables de error.
Chapter 12 Dependability and Security Specification 27

Tipos de fallo del sistema

Tipo de falla Prdida del servicio Descripcin El sistema no est disponible y no puede prestar servicios a los usuarios. Usted puede separar esto en la prdida de servicios crticos y la prdida de servicios no crticos, donde las consecuencias de un fallo en los servicios no crticos son menos que las consecuencias de la falla en el servicio crtico. El sistema no proporciona un servicio correcto a los usuarios. Una vez ms, esto puede ser especificada en trminos de errores menores y mayores o errores en la entrega de servicios crticos y no crticos. El fracaso del sistema provoca daos en el sistema mismo o en sus datos. Esto generalmente pero, no necesariamente, estar en conjuncin con otros tipos de fallos.

La prestacin de servicios incorrecta

Corrupcin del sistema / datos

Chapter 12 Dependability and Security Specification

28

Mtricas de fiabilidad
Las mtricas de fiabilidad son las unidades de medida de la fiabilidad del sistema. La fiabilidad del sistema se mide contando el nmero de fallos operativos, y, cuando es apropiado, relacionndolos con las demandas hechas en el sistema y con el tiempo en el cual el sistema ha estado en funcionamiento. Un programa de medicin a largo plazo es necesario para evaluar la fiabilidad de los sistemas crticos. Mtrica La probabilidad de fallos en demanda Tasa de ocurrencia de fallos / tiempo medio entre fallos Disponibilidad
Chapter 12 Dependability and Security Specification 29

Probability of failure on demand (POFOD)

La probabilidad de falla en demanda

Esta es la probabilidad de que el sistema falle cuando una solicitud de servicio es realizada. Es til cuando la demanda de servicio son intermitentes y no son frecuentes. Adecuado para la proteccin de sistemas, donde los servicios son demandados de vez en cuando y en donde hay serias consecuencias si el servicio no es entregado. Relevante para muchos sistemas crticos de proteccin a excepcin de los componentes de administracin. Sistema de apagado de emergencia en una planta qumica.

Chapter 12 Dependability and Security Specification

30

Rate of fault occurrence (ROCOF)

Tasa de ocurrencia de fallo Refleja la tasa de ocurrencia de fallo en el sistema. ROCOF de 0,002 significa que 2 fallos son probables en cada 1000 unidades de tiempo operacionales; por ejemplo, 2 fallos por cada 1000 horas de funcionamiento. Relevantes para sistemas en los que se tiene que procesar un gran nmero de peticiones similares en un breve periodo de tiempo Sistema de procesamiento de tarjetas de crdito, el sistema de reservas areas. Lo recproco de ROCOF es MEAN TIME TO FAILURE (tiempo medio entre fallos) (MTTF) Relevantes para los sistemas con transacciones largas; es decir, cuando el sistema de procesamiento tarda mucho tiempo (por ejemplo, los sistemas de CAD). MTTF debe ser ms largo que la longitud transaccin prevista.
Chapter 12 Dependability and Security Specification 31

Disponibilidad
Medida de la fraccin del tiempo en el cual el sistema est disponible para su uso. Toma el tiempo de reparacin y reinicio en cuenta Una disponibilidad de 0.998 significa que el software est disponible unas 998 veces de 1000 unidades de tiempo. Relevante para sistemas non-stop y que se ejecutan continuamente Sistemas de sealizacin ferroviaria

Chapter 12 Dependability and Security Specification

32

Especificacin de la disponibilidad
Disponibilidad 0.9 Explicacin El sistema est disponible el 90% de l tiempo. Esto significa que, en un perodo de 24-horas (1.440 minutos), el sistema no estar disponible durante 144 minutos.

0.99
0.999 0.9999

En un perodo de 24-horas, el sistema no est disponible durante 14,4 minutos.

El sistema no est disponible durante 84 segundos en un periodo de 24-horas. El sistema no est disponible durante 8,4 segundos en un periodo de 24-horas. Aproximadamente, un minuto por semana.

Chapter 12 Dependability and Security Specification

33

Consecuencias de las fallas

Al especificar la fiabilidad, no es slo el nmero de fallas en el sistema que interesan, sino las consecuencias de estas fallas. Las fallas que tienen consecuencias graves son claramente ms dainas que aquellas en que la reparacin y la recuperacin es inmediata. En algunos casos, por lo tanto, diferentes especificaciones de fiabilidad para los diferentes tipos de fallas pueden ser definidos.

Chapter 12 Dependability and Security Specification

34

Exceso de especificacin de fiabilidad

El exceso de especificacin de fiabilidad es una situacin en la que un nivel alto de fiabilidad se especifica pero no es rentable para lograrlo. En muchos casos, es ms barato aceptar y hacer frente a las fallas en lugar de evitar que se produzcan. Para evitar un exceso de especificacin Especificar los requisitos de fiabilidad para los diferentes tipos de fracaso. Fallos menores pueden ser aceptables. Especificar los requisitos para los diferentes servicios por separado. Los servicios crticos deben tener los ms altos requisitos de fiabilidad. Decidir si la alta fiabilidad es realmente necesario o, si las metas confiabilidad se pueden lograr de otra manera.

Chapter 12 Dependability and Security Specification

35

Pasos para una especificacin de fiabilidad

Para cada subsistema, analizar las consecuencias de posibles errores del sistema. Del anlisis de fallos del sistema, los fallos de particin estarn en clases apropiadas. Para cada clase de fracaso identificado, se establece la fiabilidad utilizando una mtrica apropiada. Diferentes mtricas pueden usarse para diferentes requisitos de fiabilidad. Identificar los requisitos funcionales de fiabilidad para reducir las posibilidades de errores crticos.

Chapter 12 Dependability and Security Specification

36

Especificacin de la bomba de insulina.

Probabilidad de fallo (POFOD) es la mtrica ms apropiada. Fallas transitorias que puedan ser reparadas por acciones del usuario como una nueva calibracin del equipo. Un valor relativamente bajo de POFOD es aceptable (por ejemplo 0,002) - un fallo puede ocurrir en cada 500 demandas. Fallos permanentes requieren que el software sea re-instalado por el fabricante. Esto debera ocurrir no ms de una vez al ao. POFOD para esta situacin debe ser menor que 0,00002.

Chapter 12 Dependability and Security Specification

37

Requisitos funcionales de fiabilidad.

La comprobacin de los requisitos que identifican los controles para asegurar que los datos incorrectos sean detectados antes que conduzcan a un fracaso. Requisitos de recuperacin que estn orientados a ayudar a la recuperacin del sistema despus de que un fallo se haya producido. Requisitos de redundancia que especifican caractersticas redundantes del sistema para ser incluidos. Requisitos del proceso para la fiabilidad que especifican el proceso de desarrollo a usar, tambin pueden ser incluidos.

Chapter 12 Dependability and Security Specification

38

Ejemplos de requisitos funcionales de fiabilidad para MHC-PMS(Mental Health Care-Patient Management System)
RR1: Un rango predefinido para todas las entradas del operador se definir y el sistema comprobar que todas las entradas del operador estn dentro de este rango predefinido. (Comprobacin) RR2: Las copias de la base de datos del paciente se mantendr en dos servidores separados que no se alojan en el mismo edificio. (Recuperacin, redundancia) RR3: N-versin de programacin se utiliza para implementar el sistema de control de frenado. (Redundancia) RR4: El sistema debe ser implementado en un subconjunto seguro de Ada y comprobado mediante un anlisis esttico. (Proceso)

Chapter 12 Dependability and Security Specification

39

Especificacin de seguridad
Especificacin de Seguridad tiene algo en comn con la especificacin de requisitos de proteccin - en ambos casos, su preocupacin es evitar que ocurra algo malo. Cuatro grandes diferencias Los problemas de proteccin son accidentales - el software no est funcionando en un ambiente hostil. En seguridad, usted debe asumir que los atacantes tengan conocimiento de las deficiencias del sistema Cuando se producen fallos de proteccin, se puede buscar la causa raz o debilidad que llev al fracaso. Cuando un fracaso resulta de un ataque deliberado, el atacante puede ocultar la causa de la falla. El cierre de un sistema puede evitar un fallo relacionado con la proteccin. Causar un apagado puede ser el objetivo de un ataque. Eventos relacionados con la proteccin no se generan a partir de un adversario inteligente. Un atacante puede sondear las defensas para descubrir las debilidades.
Chapter 12 Dependability and Security Specification 40

Tipos de requisitos de seguridad

Requisitos de identificacin. Requisitos de autenticacin. Requisitos de autorizacin. Requisitos de inmunidad. Requisitos de integridad. Requisitos de deteccin de intrusos. Requisitos de non-repudiation Requisitos de privacidad. Requisitos de seguridad de auditora. Requisitos del mantenimiento de la seguridad del sistema
Chapter 12 Dependability and Security Specification 41

El proceso de evaluacin del riesgo previo de los requisitos de seguridad.

Chapter 12 Dependability and Security Specification

42

Evaluacin de riesgos de la seguridad

Identificacin de activos Identificar los activos clave del sistema (o servicios) que tienen que ser protegidos. Evaluacin del valor de los activos Estimar el valor de los activos identificados. Evaluacin de la exposicin. Evaluar las prdidas potenciales asociados a cada activo. Identificacin de amenaza. Identificar las amenazas ms probables a los activos del sistema
Chapter 12 Dependability and Security Specification 43

Evaluacin de riesgos de la seguridad

Evaluacin de ataque. Descomponer amenazas en posibles ataques en el sistema y las formas en que estos pueden ocurrir. Identificacin del control. Proponer los controles que pueden ser aplicadas para proteger un activo. Evaluacin de la factibilidad. Evaluar la factibilidad tcnica y el costo de los controles. Definicin de los requerimientos de seguridad. Definir los requisitos de seguridad del sistema. Estos pueden ser de infraestructura o requisitos de aplicacin del sistema.
Chapter 12 Dependability and Security Specification 44

Anlisis de activos en un informe preliminar de evaluacin de riesgos para el MHC-PMS

Activo El sistema de informacin Valor Alta. Necesario para respaldar todas las consultas clnicas. Potencialmente crtica para la proteccin. Exposicin Alta. La prdida financiera como clnicas pueden tener que ser cancelado. Costos de restauracin del sistema. Posible dao al paciente si el tratamiento no puede ser prescrito. Alta. La prdida financiera como clnicas pueden tener que ser cancelado. Costos de restauracin del sistema. Posible dao al paciente si el tratamiento no puede ser prescrito. Escasas prdidas directas pero s la posible prdida de reputacin.

La base de datos de pacientes

Alta. Necesario para respaldar todas las consultas clnicas. Potencialmente crtica para la proteccin.

Registro de cada paciente

Normalmente baja, aunque puede ser alta para determinados pacientes de alto perfil.

Chapter 12 Dependability and Security Specification

45

Anlisis de amenaza y control en un informe preliminar de evaluacin de riesgos.

Amenaza Usuarios no autorizados obtienen acceso de usuario como administrador del sistema y hace que el sistema no est disponible Un usuario no autorizado obtiene acceso como usuario del sistema y tiene acceso a informacin confidencial alto Probabilidad Control Slo permita la gestin del sistema desde lugares especficos que son fsicamente seguro. Factibilidad Bajo coste de implementacin pero se debe tener cuidado con la distribucin de claves para asegurar que las claves estn disponibles en el caso de una emergencia.

bajo

Requerir que todos los Solucin tcnicamente factible usuarios se autentiquen pero de alto costo. Resistencia mediante un mecanismo posible del usuario. biomtrico. Simple y transparente para Registrar todos los implementar y tambin es cambios en la compatible con la recuperacin. informacin del paciente para realizar un seguimiento del uso del sistema.

Chapter 12 Dependability and Security Specification

46

Poltica de seguridad
Una poltica de seguridad de la organizacin se aplica a todos los sistemas y establece lo que se debe y no se debe permitir. Por ejemplo, una poltica militar podra ser: Los lectores slo puede examinar los documentos cuya clasificacin es la misma o est por debajo de los lectores de investigacin. Una poltica de seguridad establece las condiciones que deben ser mantenidas por un sistema de seguridad y por lo tanto ayuda a identificar los requisitos de seguridad del sistema.

Chapter 12 Dependability and Security Specification

47

Requisitos de seguridad para el MHC-PMS

La informacin del paciente se puede descargar en el inicio de una sesin clnica a una zona segura que es utilizado por el personal clnico. Toda la informacin del paciente en el sistema (cliente) ser encriptado. La informacin del paciente se carga en la base de datos despus de una sesin clnica haya terminado y se eliminan del equipo del cliente. Un registro en un equipo independiente del servidor de base de datos debe ser mantenido con todos los cambios realizados en la base de datos del sistema.
Chapter 12 Dependability and Security Specification 48

Especificacin formal
Especificacin formal es parte de una coleccin ms general de las tcnicas que se conocen como "mtodos formales". Estn todas basadas en representacin matemtica y anlisis de software. Los mtodos formales incluyen: Especificacin formal; Especificacin de anlisis y pruebas; Desarrollo transformacional; Verificacin del programa.

Chapter 12 Dependability and Security Specification

49

Uso de mtodos formales

Las ventajas principales de los mtodos formales estn en la reduccin del nmero de fallos en los sistemas. En consecuencia, su principal rea de aplicacin es en la ingeniera de sistemas crticos. Ha habido varios proyectos exitosos donde los mtodos formales han sido utilizados en esta rea. En esta rea, el uso de mtodos formales es ms probable que sea rentable porque los altos costos de las fallas del sistema deben ser evitados.

Chapter 12 Dependability and Security Specification

50

Especificacin en el proceso de software

Las especificaciones y el diseo estn inextricablemente entremezclados. El diseo arquitectnico es esencial para estructurar una especificacin y el proceso de especificacin. Las especificaciones formales se expresan en una notacin matemtica con un vocabulario definido, la sintaxis y la semntica precisas.

Chapter 12 Dependability and Security Specification

51

Especificacin formal en un proceso de software

Chapter 12 Dependability and Security Specification

52

Beneficios de la especificacin formal.

El desarrollo de una especificacin formal requiere de los requisitos del sistema para ser analizadas en detalle. Esto ayuda a detectar problemas, inconsistencias y omisiones en los requisitos. A medida que la especificacin se expresa en un lenguaje formal, puede ser automticamente analizado para descubrir inconsistencias y omisiones. Si se utiliza un mtodo formal como el mtodo B, se puede transformar la especificacin formal en un programa correcto. Los costos del programa de pruebas se puede reducir si el programa est oficialmente verificados contra sus especificaciones.

Chapter 12 Dependability and Security Specification

53

La aceptacin de mtodos formales.

Los mtodos formales han tenido un impacto limitado en el desarrollo prctico de software: Propietarios del problema no pueden entender una especificacin formal y, por lo tanto no se puede evaluar si se trata de una representacin exacta de sus necesidades. Es fcil evaluar los costos de desarrollar una especificacin formal pero ms difcil de evaluar los beneficios. Los gerentes por lo tanto, pueden no estar dispuestos a invertir en mtodos formales. Los ingenieros de software no estn familiarizados con este enfoque y, por tanto, estn reacios en proponer el uso de mtodos formales. Los mtodos formales son todava difciles de escalar hasta grandes sistemas. Especificacin formal no es realmente compatible con los mtodos de desarrollo giles.
Chapter 12 Dependability and Security Specification 54

Puntos clave
Los requisitos de fiabilidad se puede definir cuantitativamente. Incluyen probabilidad de falla en demanda (POFOD), la tasa de ocurrencia de fallos (ROCOF) y disponibilidad (AVAIL). Los requisitos de seguridad son ms difciles de identificar que los requisitos de proteccin porque un atacante del sistema puede utilizar el conocimiento de las vulnerabilidades del sistema para planificar un ataque, y se puede aprender acerca de las vulnerabilidades de los ataques fallidos. Para especificar los requisitos de seguridad, es necesario identificar los activos que van a ser protegidos y definir cmo las tcnicas de seguridad y tecnologa deben utilizarse para proteger estos activos. Los mtodos formales de desarrollo de software se basan en una especificacin del sistema que se expresa como un modelo matemtico. El uso de mtodos formales evita la ambigedad en una especificacin de sistemas crticos.
Chapter 12 Dependability and Security Specification 55