Capítulo 12 – Especificaciones de Fiabilidad y

Seguridad

Lectura 1

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 1

Temas tratados

 Especificación dirigida a riesgos

 Especificaciones de protección
 Especificaciones de seguridad
 Especificación de la fiabilidad del software

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 2

Requerimientos de Fiabilidad

 Requerimientos funcionales para definir comprobación

de errores y recuperación de instalaciones y protección
contra fallos del sistema.
 Requerimientos no funcionales definiendo la fiabilidad
requerida y la disponibilidad del sistema.
 Requerimientos excluíbles que definen los estados y
condiciones que no deben surgir.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 3

Especificación dirigida a riesgos

 La especificación de los sistemas críticos debe ser

dirigido por riesgo.
 Este enfoque ha sido ampliamente utilizado en los
sistemas de protección y críticos para la seguridad.
 El objetivo del proceso de especificación debe ser
entender los riesgos (de protección, de seguridad, etc.)
enfrentados por el sistema y definir los requerimientos
que reduzcan estos riesgos.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 4

Etapas de análisis basado en riesgos

 Identificación de riesgos
 Identificar los riesgos potenciales que puedan surgir.
 Análisis y clasificación de riesgos
 Evaluar la gravedad de cada riesgo.
 Descomposición de riesgos
 Descomponer los riesgos para descubrir sus potenciales causas
fundamentales.
 Evaluación de la reducción de riesgos
 Definir cómo se debe tomar cada riesgo en eliminarse o
reducirse cuando el sistema está diseñado.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 5

Especificación dirigida a riesgos

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 6

Análisis de riesgo en fases

 Análisis preliminar de riesgos

 Identifica los riesgos del entorno de sistemas. El objetivo es
desarrollar un conjunto inicial de la seguridad del sistema y los
requerimientos de confiabilidad.
 Análisis de riesgos del ciclo de vida
 Identifica los riesgos que surgen durante el diseño y desarrollo.
Por ejemplo, riesgos que están asociados con las tecnologías
utilizadas para la construcción del sistema. Los requerimientos
se extienden a la protección contra estos riesgos.
 Análisis de riesgo operacional
 Los riesgos asociados con la interfaz y los errores de operador
de usuario del sistema. Requerimientos de protección
adicionales se pueden añadir para hacer frente a estos.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 7
Especificaciones de protección

 El objetivo es identificar los requerimientos de protección

que aseguren que los fallos del sistema no causen
lesiones o muerte, o daños ambientales.
 Identificación de riesgos = Identificación de peligros
 Análisis de riesgos = Evaluación de peligros
 Descomposición de riesgos = Análisis de peligros
 La reducción del riesgo = especificación de los
requerimientos de protección

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 8

Identificación de los peligros

 Identificar los peligros que puedan amenazar el sistema.

 La identificación de peligros puede basarse en
diferentes tipos de peligro:
 Peligros físicos
 Peligros eléctricos
 Peligros biológicos
 Peligros de falla de servicio
 Etcétera

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 9

Riesgos de la bomba de insulina

 La sobredosis de insulina (falla de servicio).

 Dosis insuficiente de insulina (falla de servicio).
 Falla de energía debido a la batería agotada (eléctrico).
 Interferencia eléctrica con otros equipos médicos
(eléctrico).
 Contacto deficiente del sensor y del accionador (físico).
 Partes de la máquina se rompen en el cuerpo (físico).
 Infección causada por la introducción de la máquina
(biológico).
 Reacción alérgica a los materiales o la insulina
(biológico).
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 10
Evaluación del peligro

 El proceso tiene que ver con la comprensión de la

probabilidad de que surja un riesgo y las potenciales
consecuencias si ocurriese un accidente o incidente.
 Los riesgos pueden ser clasificados como:
 Intolerable. Nunca debe surgir o resultar en un accidente
 Tan bajo como sea razonablemente factible (ALARP). Debe
reducir al mínimo la posibilidad de riesgo dadas las restricciones
de costo y horario
 Aceptable. Las consecuencias de los riesgos son aceptables y
no hay costos adicionales que deben ser incurridos para reducir
la probabilidad de peligro

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 11

La triángulo de riesgo

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 12

La aceptación social del riesgo

 La aceptabilidad de un riesgo se determina por

consideraciones humanas, sociales y políticas.
 En la mayoría de las sociedades, los límites entre las
regiones son empujados hacia arriba con el tiempo, es
decir, la sociedad está menos dispuesta a aceptar el
riesgo
 Por ejemplo, los costos de la limpieza de la contaminación
pueden ser menores que los costos de la prevención, pero esto
puede no ser socialmente aceptable.
 La evaluación del riesgo es subjetiva
 Los riesgos se identifican como probable, poco probable, etc
Esto depende de quién está haciendo la evaluación.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 13

Valoración de peligros

 Estimar la probabilidad del riesgo y la gravedad del

riesgo.
 Normalmente no es posible hacer esto precisamente,
entonces se utilizan valores relativos como "improbable",
"raro", "muy alto", etc.
 El objetivo debe ser para excluir los riesgos que puedan
surgir o que tienen alta gravedad.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 14

 Clasificación de riesgos de la bomba de insulina

Peligro identificado Probabilidad de Peligros Gravedad del accidente Riesgo Aceptabilidad

estimado
1. Cómputo de Medio Alto Alto Intolerable
sobredosis de insulina
2. Cómputo de dosis Medio Bajo Bajo Aceptable
insuficiente de insulina
3. Fallo de sistema de Medio Medio Bajo ALARP
monitoreo de hardware
4. Falla de energía Alto Bajo Bajo Aceptable

5. Máquina colocada Alto Alto Alto Intolerable

incorrectamente
6. Máquina se rompe en Bajo Alto Medio ALARP
el paciente
7. Máquina causa Medio Medio Medio ALARP
infección
8. Interferencia eléctrica Bajo Alto Medio ALARP

9. Reacción alérgica Bajo Bajo Bajo Aceptable

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 15

Análisis de peligros

 Preocupados por el descubrimiento de las causas

fundamentales de los riesgos en un sistema en
particular.
 Las técnicas se han derivado principalmente de los
sistemas críticos para la protección y pueden ser
 Técnicas inductivas, de abajo hacia arriba. Comienza con una
falla en el sistema propuesto y evalúa los riesgos que podrían
resultar de dicha falla;
 Técnicas deductivas, de arriba hacia abajo. Comienza con un
peligro y deduce cuáles podrían ser las posibles causas.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 16

Análisis del árbol de fallas

 Una técnica deductiva de arriba hacia abajo.

 Poner el riesgo o peligro en la raíz del árbol e identificar
los estados del sistema que podrían llevar a ese peligro.
 Cuando sea necesario, vincular estos con condiciones
'y' ó 'o'.
 La meta debe ser el minimizar el número de causas
individuales de falla del sistema.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 17

Un ejemplo de un árbol de fallas de un software

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 18

Análisis del árbol de fallas

 Tres condiciones posibles que pueden conducir a la

entrega de la dosis incorrecta de insulina
 Medición incorrecta del nivel de azúcar en la sangre
 Falla del sistema de entrega
 Dosis administrada en el momento equivocado
 Mediante el análisis del árbol de fallas, las causas
fundamentales de estos peligros relacionados con el
software son:
 Error de algoritmo
 Error aritmético

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 19

Reducción de riesgos

 El objetivo de este proceso es identificar los

requerimientos de confiabilidad que especifican cómo se
deben administrar los riesgos y garantizar que no se
producen accidentes/incidentes.
 Estrategias de reducción de riesgos
 Evitar el riesgo;
 Detección y eliminación de riesgos;
 Limitación de daños.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 20

Uso de estrategias

 Normalmente, en sistemas críticos, se utiliza una

combinación de estrategias de reducción de riesgos.
 En un sistema de control de planta química, el sistema
incluirá sensores para detectar y corregir el exceso de
presión en el reactor.
 Sin embargo, también incluirá un sistema de protección
independiente que se abre una válvula de alivio, si se
detecta alta presión peligrosa.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 21

Bomba de insulina - Riesgos de software

 Error aritmético
 Un cálculo hace que el valor de una variable se exceda o se
disminuya;
 Tal vez incluir un controlador de excepciones para cada tipo de
error aritmético.
 Error algorítmico
 Comparar la dosis que se suministrará con una dosis anterior o
las dosis máximas seguras. Reduzca la dosis si es demasiado
alta.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 22

Ejemplos de los requerimientos de protección

SR1: El sistema no suministrará una sola dosis de insulina que sea mayor que
una dosis máxima especificada para un usuario del sistema.
SR2: El sistema no suministrará una dosis acumulativa diaria de insulina que sea
mayor que una dosis diaria máxima especificada para un usuario del sistema.
SR3: El sistema incluirá un centro de diagnóstico de hardware que se ejecuta al
menos cuatro veces por hora.
SR4: El sistema incluirá un controlador de excepciones para todas las
excepciones que se identifican en la Tabla 3.
SR5: La alarma audible sonará cuando se descubra cualquier anomalía de
hardware o software y se mostrará un mensaje de diagnóstico, tal como se
define en la Tabla 4.
SR6: En caso de una alarma, se suspenderá la administración de insulina hasta
que el usuario haya restablecido el sistema y apagado la alarma.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 23

Puntos clave

 El análisis de riesgos es una actividad importante en la

especificación de los requerimientos de seguridad y fiabilidad. Se
trata de identificar los riesgos que pueden resultar en accidentes o
incidentes.
 Se puede utilizar un enfoque dirigido a riesgos para comprender los
requerimientos de protección para un sistema. Identificas peligros
potenciales y éstos se descomponen (utilizando métodos como el
análisis del árbol de fallas) para descubrir sus causas
fundamentales.
 Los requerimientos de seguridad deben incluirse para garantizar
que los riesgos y los accidentes no se producen o, si esto es
imposible, para limitar los daños causados ​por la falla del sistema.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 24

Capítulo 12 – Especificaciones de Fiabilidad y
Seguridad

Lectura 2

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 25

Especificación de la fiabilidad del sistema

 La fiabilidad es un atributo del sistema medible por lo que los

requerimientos de fiabilidad no funcionales pueden ser
especificados cuantitativamente. Estos definen el número de fallos
que son aceptables durante el uso normal del sistema o el tiempo
en el que el sistema debe estar disponible.
 Los requerimientos funcionales de fiabilidad definen las funciones
del sistema y del software que evitan, detectan o toleran fallos en el
software y así asegurarse de que estas fallas no conduzcan a la
falla del sistema.
 Los requerimientos de fiabilidad de software también pueden
incluirse para hacer frente a un fallo de hardware o un error del
operador.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 26

Proceso de especificación de confiabilidad

 Identificación de riesgos
 Identificar los tipos de falla del sistema que pueden conducir a
pérdidas económicas.
 Análisis de riesgos
 Estimar los costos y consecuencias de los diferentes tipos de
falla de software.
 Descomposición de riesgos
 Identificar las causas fundamentales de la falla del sistema.
 Reducción de riesgos
 Generar especificaciones de fiabilidad, incluyendo
requerimientos cuantitativos que definen los niveles aceptables
de falla.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 27
Tipos de falla del sistema

Tipo de falla Descripción

Pérdida de servicio El sistema no está disponible y no puede prestar sus servicios a los
usuarios. Usted puede separar esto en la pérdida de servicios críticos
y la pérdida de los servicios no críticos, en los que las consecuencias
de un fallo en los servicios no críticos son menos que las
consecuencias de la falla de servicios críticos.

Entrega de servicios incorrecta El sistema no proporciona un servicio correctamente a los usuarios.

Una vez más, esto puede ser especificada en términos de errores o
errores menores y mayores en la prestación de los servicios críticos y
no críticos.

Corrupción del sistema/ datos El fallo del sistema causa daños en el mismo sistema o en sus datos.
Esto normalmente, pero no necesariamente, estará en conjunción
con otros tipos de fallos.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 28

Métricas de fiabilidad

 Las métricas de fiabilidad son las unidades de medida

de la fiabilidad del sistema.
 La fiabilidad del sistema se mide contando el número de
fallos operacionales y, en su caso, relacionando éstos a
las demandas hechas en el sistema y el tiempo que el
sistema ha estado operacional.
 Se requiere un programa de medición a largo plazo para
evaluar la fiabilidad de los sistemas críticos.
 Métricas
 La probabilidad de falla en demanda
 Tasa de incidencia de fallas/tiempo medio al fallo
 Disponibilidad

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 29

Probabilidad de fallo en demanda (POFOD)

 Esta es la probabilidad de que el sistema fallará cuando

se realiza una solicitud de servicio. Es útil cuando las
demandas de servicio son intermitentes y relativamente
poco frecuentes.
 Apropiado para los sistemas de protección, donde los
servicios se exigen en ocasiones y en los que hay serias
consecuencias si el servicio no es entregado.
 Relevante para muchos sistemas críticos para la
protección con componentes de gestión de excepciones
 Sistema de parada de emergencia en una planta química.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 30

Tasa de incidencia de fallo (ROCOF)

 Refleja la tasa de ocurrencia de fallo en el sistema.

 ROCOF de 0,002 significa 2 fallos son probables en cada 1.000
unidades de tiempo de funcionamiento. Por ejemplo, 2 fallos por
cada 1000 horas de funcionamiento.
 Relevante para sistemas donde el sistema tiene que procesar un
gran número de peticiones similares en un corto tiempo
 Sistema de procesamiento de tarjetas de crédito, sistema de reservas
aéreas.
 El recíproco de ROCOF es el Tiempo Medio para el Gallo (MTTF)
 Relevante para los sistemas con transacciones largas, es decir, donde el
procesamiento del sistema tarda mucho tiempo (por ejemplo, sistemas de CAD).
El MTTF debe ser más largo que la longitud de la transacción esperada.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 31

Disponibilidad

 Medida de la fracción del tiempo que el sistema está

disponible para su uso.
 Toma en cuenta la reparación y el tiempo de reinicio
 Una disponibilidad de 0.998 significa que el software
está disponible para 998 de 1000 unidades de tiempo.
 Relevante para sistemas de funcionamiento continuo,
sin paros
 sistemas de conmutación telefónica, sistemas de señalización
ferroviaria.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 32

Especificación de disponibilidad

Disponibilidad Explicación

0.9 El sistema está disponible para 90% del tiempo. Esto significa que, en
un período de 24 horas (1440 minutos), el sistema no estará disponible
durante 144 minutos.

0.99 En un período de 24 horas, el sistema no está disponible para 14,4

minutos.

0.999 El sistema no está disponible durante 84 segundos en un periodo de 24

horas.

0.9999 El sistema no está disponible por 8,4 segundos en un período de 24

horas. A grandes rasgos, un minuto por semana.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 33

Consecuencias de las fallas

 Al especificar la confiabilidad, no es sólo importan el

número de fallos en el sistema, sino también las
consecuencias de estos fallos.
 Las fallas que tienen consecuencias graves son
claramente más dañinos que aquellos en los que la
reparación y la recuperación es sencilla.
 En algunos casos, por lo tanto, pueden ser definidas
diferentes especificaciones de fiabilidad para los
diferentes tipos de fallos.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 34

 Exceso de especificación de fiabilidad

 El exceso de especificación de fiabilidad es una

situación en la que se especifica un alto nivel de
fiabilidad, pero no es rentable para lograrlo.
 En muchos casos, es más barato aceptar y lidiar con
fallos en lugar de evitar que ocurran.
 Para evitar el exceso de especificación
 Especificar los requerimientos de fiabilidad para los diferentes
tipos de fallas. Fallos menores pueden ser aceptables.
 Especificar los requerimientos para los distintos servicios por
separado. Los servicios críticos deben tener los más altos
requerimientos de fiabilidad.
 Decidir si una alta fiabilidad es realmente necesaria o si las
metas de confiabilidad se puede lograr de otra manera.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 35

Pasos para una especificación de fiabilidad

 Para cada sub-sistema, analizar las consecuencias de

posibles fallos del sistema.
 Desde el análisis de fallos del sistema, particionar los
fallos en clases apropiadas.
 Para cada clase de fallo identificado, se establece la
fiabilidad utilizando una métrica apropiada. Pueden
usarse diferentes métricas para diferentes
requerimientos de fiabilidad.
 Identificar los requerimientos de seguridad funcional
para reducir las posibilidades de fallos críticos.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 36

Especificación de la bomba de insulina

 La probabilidad de fallo (POFOD) es la métrica más

apropiada.
 Los fallos transitorios que pueden ser reparados por las
acciones del usuario, como la recalibración de la
máquina. Un valor relativamente bajo de POFOD es
aceptable (por ejemplo 0.002) - un fallo puede ocurrir en
cada 500 demandas.
 Las fallas permanentes requieren que el software sea
re-instalado por el fabricante. Esto debería ocurrir no
más de una vez al año. La POFOD para esta situación
debe ser menor que 0,00002.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 37

Requerimientos de fiabilidad funcional

 Comprobación de los requerimientos que identifican a

controles para garantizar que se detectan datos
incorrectos antes de que conduce a un fallo.
 Requerimientos de recuperación que están orientados a
ayudar al sistema a recuperarse después de producirse
un fallo.
 Requerimientos de redundancia que especifican
características redundantes del sistema que deben
incluirse.
 Requerimientos de proceso para la fiabilidad, que
especifican el proceso de desarrollo que se utilizará,
también pueden ser incluidos.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 38
Ejemplos de requerimientos funcionales de
fiabilidad para MHC-PMS

RR1: Se definirá un rango predefinido para todas las entradas de operador y el

sistema comprobará que todas las entradas del operador se encuentran dentro
de este rango predefinido. (Comprobación)
RR2:Las copias de la base de datos de pacientes deberán mantenerse en dos
servidores separados que no están alojados en el mismo edificio. (Recuperación,
redundancia)
RR3:Programación N-versión se utilizará para implementar el sistema de control
de frenado. (Redundancia)
RR4:El sistema debe ser implementado en un subconjunto de seguro de Ada y
comprobado utilizando análisis estático. (Proceso)

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 39

Especificación de seguridad

 La especificación de seguridad tiene algo en común con especificación de

los requerimientos de seguridad - en ambos casos, tu preocupación es
evitar que suceda algo malo.
 Cuatro diferencias principales
 Los problemas de seguridad son accidentales - el software no está funcionando
en un ambiente hostil. En seguridad, se debe asumir que los atacantes tengan
conocimiento de las debilidades del sistema
 Cuando se producen fallos de seguridad, se puede buscar la causa principal o
debilidad que llevó al fallo. Cuando el fallo resulta de un ataque deliberado, el
atacante puede ocultar la causa del fallo.
 El apagado de un sistema puede evitar un fallo relacionado con la seguridad.
Causar un apagado puede ser el objetivo de un ataque.
 Eventos relacionados con la seguridad no se generan a partir de un adversario
inteligente. Un atacante puede sondear las defensas a través del tiempo para
descubrir los puntos débiles.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 40

Tipos de requerimientos de seguridad

 Requerimientos de identificación.
 Requerimientos de autenticación.
 Requerimientos de autorización.
 Requerimientos de inmunidad.
 Requerimientos de integridad.
 Requerimientos de detección de intrusiones.
 Requerimientos de no-repudio.
 Requerimientos de privacidad.
 Requerimientos de auditoría de seguridad.
 Requerimientos de seguridad de mantenimiento del
sistema. Capítulo 12 Especificaciones de Fiabilidad y Seguridad 41
La proceso preliminar de evaluación del riesgo
para los requerimientos de seguridad

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 42

Evaluación de riesgos de seguridad

 Identificación de activos
 Identificar los activos clave del sistema (o servicios) que tienen
que ser protegidos.
 Evaluación de valor de activos
 Estimar el valor de los activos identificados.
 Evaluación de la exposición
 Evaluar las pérdidas potenciales asociados a cada activo.
 Identificación de amenazas
 Identificar las amenazas más probables a los activos del sistema

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 43

Evaluación de riesgos de seguridad

 Evaluación de ataque
 Descomponer amenazas sobre posibles ataques contra el
sistema y las formas en que éstos pueden ocurrir.
 Identificación de Control
 Proponer los controles que se pueden poner en práctica para
proteger un activo.
 Evaluación de la viabilidad
 Evaluar la viabilidad técnica y el coste de los controles.
 Definición de requerimientos de seguridad
 Definir los requerimientos de seguridad del sistema. Estas
pueden ser los requerimientos de infraestructura o sistema de
aplicación.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 44
Análisis de activos en un informe preliminar de
evaluación de riesgos para el MHC-PMS

Activo Valor Exposición

La sistema de información
Alto. Requerido para admitir todas
las consultas clínicas.
Potencialmente crítico para la
seguridad.
Alto. La pérdida financiera como
clínicas puede tener que ser
cancelada. Los costos de
restauración del sistema. Posible
daño al paciente si el tratamiento
no puede ser prescrito.

La base de datos del paciente
Alto. Requerido para admitir todas
las consultas clínicas.
Potencialmente crítico para la
seguridad.
Alto. La pérdida financiera como
clínicas puede tener que ser
cancelada. Los costos de
restauración del sistema. Posible
daño al paciente si el tratamiento
no puede ser prescrito.

Un registro de cada paciente Normalmente baja, aunque puede Pérdidas directas bajas, pero
ser alta para los pacientes de alto posible pérdida de reputación.
perfil específicos.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 45

Análisis de amenazas y control en un informe
preliminar de evaluación de riesgos

Amenaza Probabilidad Control Factibilidad

Usuario no autorizado Bajo Sólo permitirá la gestión Bajo coste de aplicación pero se
obtiene acceso como del sistema desde debe tener cuidado con la
administrador del ubicaciones específicas que distribución de claves y para
sistema y hace que el son físicamente seguras. asegurar que las claves estén
sistema no esté disponibles en el caso de una
disponible emergencia.

Un usuario no autorizado Alto Requiere que todos los Técnicamente posible, pero es una
tiene acceso como usuarios se autentifiquen solución de alto costo. Resistencia
usuario del sistema y mediante un mecanismo posible al usuario.
tiene acceso a biométrico.
información confidencial Simple y transparente para
Registrar todos los cambios implementar y también es
en la información del compatible con la recuperación.
paciente para realizar un
seguimiento del uso del
sistema.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 46

Política de seguridad

 Una política de seguridad organizacional se aplica a

todos los sistemas y establece lo que se debe y no se
debe permitir.
 Por ejemplo, una política militar podría ser:
 Los lectores no conozcan los documentos cuya clasificación es
igual o por debajo del nivel de los lectores de investigación de
antecedentes.
 Una política de seguridad establece las condiciones que
deben ser mantenidos por un sistema de seguridad y
por lo tanto ayuda a identificar los requerimientos de
seguridad del sistema.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 47

Requerimientos de seguridad para el MHC-PMS

 La información del paciente se puede descargar en el

inicio de una sesión clínica a una zona segura en el
cliente sistema que es utilizado por el personal clínico.
 Toda la información del paciente en el sistema cliente
será encriptada.
 La información del paciente se carga en la base de
datos después de que una sesión clínica ha terminado y
suprimido desde la computadora cliente.
 Un registro en una computadora independiente del
servidor de base de datos debe ser mantenido de todos
los cambios realizados en la base de datos del sistema.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 48
Especificación formal

 La especificación formal es parte de una colección más

general de las técnicas que se conocen como "métodos
formales".
 Estos se basan en la representación matemática y
análisis de software.
 Los métodos formales incluyen
 Especificación formal;
 Análisis y prueba de la especificación;
 Desarrollo transformacional;
 Verificación de programas.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 49

El uso de métodos formales

 Los principales beneficios de los métodos formales son

en la reducción del número de fallos en los sistemas.
 En consecuencia, su principal área de aplicación es en
ingeniería de sistemas críticos. Se han realizado varios
proyectos exitosos donde se han utilizado los métodos
formales en esta área.
 En esta área, el uso de métodos formales es más
probable que sea rentable porque los altos costos de
falla del sistema deben ser evitados.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 50

Especificación en el proceso de software

 Las especificaciones y el diseño están inextricablemente

entremezclados.
 El diseño arquitectónico es fundamental para estructurar
una especificacón y el proceso de especificación.
 Las especificaciones formales se expresan en una
notación matemática con vocabulario, sintaxis y
semántica definidos precisamente.

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 51

Formal especificación de un software basado en
el plan proceso

Capítulo 12 Especificaciones de Fiabilidad y Seguridad 52

Beneficios de la especificación formal

 El desarrollo de una especificación formal requiere los

requerimientos del sistema para ser analizadas en detalle.
Esto ayuda a detectar problemas, inconsistencias e
incompletitud de los requerimientos.
 A medida que la especificación es expresada en un lenguaje
formal, se puede analizar automáticamente para descubrir
inconsistencias e incompletitud.
 Si se utiliza un método formal, como el método B, se puede
transformar la especificación formal en un programa
"correcto".
 Los costos de las pruebas del programa podrán ser reducidos
si el programa se verificó formalmente contra su
especificación.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 53
La aceptación de los métodos formales

 Los métodos formales han tenido un impacto limitado en

el desarrollo de software práctico:
 Propietarios de problemas no pueden entender una
especificación formal y por tanto no puede evaluar si se trata de
una representación exacta de sus requerimientos.
 Es fácil evaluar los costos de desarrollar una especificación
formal, pero es más difícil evaluar los beneficios. Por lo tanto,
los gerentes pueden no estar dispuestos a invertir en métodos
formales.
 Los ingenieros de software no están familiarizados con este
enfoque y por lo tanto son reacios a proponer el uso de MF.
 Los métodos formales siguen siendo difíciles de escalar hasta
grandes sistemas.
 La especificación formal no es realmente compatible con los
métodos de desarrollo ágil.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 54
Puntos clave

 Los requerimientos de confiabilidad se pueden definir cuantitativamente.

Éstos incluyen la probabilidad de fallo en demanda (POFOD), la tasa de
ocurrencia de fallos (ROCOF) y disponibilidad (DISP).
 Los requerimientos de seguridad son más difíciles de identificar que los
requerimientos de protección debido a que un atacante de sistema puede
utilizar el conocimiento de las vulnerabilidades del sistema para planificar
un ataque al sistema, y ​se puede aprender acerca de las vulnerabilidades
de los ataques fallidos.
 Para especificar los requerimientos de seguridad, es necesario identificar
los activos que van a ser protegidos y definir cómo se deben utilizar las
técnicas y la tecnología de seguridad para proteger estos activos.
 Los métodos formales de desarrollo de software se basan en una
especificación del sistema que se expresa como un modelo matemático. El
uso de métodos formales evita la ambigüedad en una especificación de
sistemas críticos.
Capítulo 12 Especificaciones de Fiabilidad y Seguridad 55