Arquitecturas De Desarrollo Para Sistemas Con Requisitos De Seguridad
Páginas: 13 (3114 palabras)
Publicado: 8 de octubre de 2012
Arquitecturas de desarrollo para sistemas con requisitos de seguridad
Contenidos
1 INTRODUCCIÓN 3
2 ARQUITECTURAS DE DESARROLLO 5
2.1 Programación defensiva 5
2.1.1 Técnicas y recomendaciones 5
2.2 Programación con múltiples versiones 7
2.3 Programación con aserciones 9
3 CONCLUSIONES 11
4 REFERENCIAS 12
1 Introducción
El estándar EN-50128 se aplica al desarrollo deaplicaciones de control y protección en sistemas ferroviarios, si bien es cierto que puede ser fácilmente reutilizado para el diseño e implementación de cualquier sistema que tenga requisitos de seguridad. Este estándar cubre todo el proceso de desarrollo software, desde la especificación de requisitos, la elección de la arquitectura de desarrollo hasta las técnicas y lenguajes de programaciónutilizados.
Este trabajo se centra en las arquitecturas de desarrollo para aplicaciones con requisitos de seguridad. Se han seleccionado tres arquitecturas como caso de estudio, teniendo para ello en cuenta que este conjunto forma una combinación de técnicas aprobada para el desarrollo de software con requisitos de seguridad de niveles tres y cuatro.
La lista completa de arquitecturas de desarrollopropuestas por el estándar puede verse en la Tabla 1.
Técnica Nivel de seguridad
0 1 2 3 4
1. Defensive Programming - R R HR HR
2. Fault Detection & Diagnosis - R R HR HR
3. Error Correcting Codes - - - - -
4. Error Detecting Codes - R R HR HR
5. Failure Assertion Programming - R R HR HR
6. Safety Bag Techniques - R R R R
7. Diverse Programming - R R HR HR
8. Recovery Block - R R R R9. Backward Recovery - NR NR NR NR
10. Forward Recovery - NR NR NR NR
11. Re-try Fault Recovery Mechanisms - R R R R
12. Memorising Executed Cases - R R HR HR
13. Artificial Intelligence – Full Correction - NR NR NR NR
14. Dynamic Reconfiguration of Software - NR NR NR NR
15. Software Errors Effects Análisis - R R HR HR
16. Fault Tree Analysis R R R HR HR
Tabla 1. Arquitecturassoftware.
Para cada una de estas técnicas el estándar da una recomendación, según el nivel de seguridad requerido. Estas recomendaciones quedan recogidas en la Tabla 2.
Recomendación Significado
M Mandatory (imprescindible)
HR Highly recommended (altamente recomendado)
R Recommended (recomendado)
- Sin recomendación
NR Not recommended (no recomendado)
F Forbidden (prohibido)
Tabla2. Valores de las recomendaciones del estándar.
Observando la Tabla 1 podemos observar cómo el estándar presenta un conjunto de técnicas recomendadas en su mayoría, con mayor o menor énfasis dependiendo de los requisitos de seguridad de la aplicación. Sin embargo, cuatro de las técnicas incluidas aparecen como no recomendadas para ninguno de los niveles de seguridad. Fijándonos bien,podemos ver que esas cuatro técnicas son las que intentan corregir o reconfigurar el sistema ante la presencia de un fallo. Esto es especialmente representativo, ya que demuestra el énfasis del estándar por la seguridad, ya que un intento de corrección de un error no esperado podría tener consecuencias aún peores que las del propio error si las medidas tomadas no son las adecuadas.
Para finalizar,el estándar propone un conjunto de posibles combinaciones de las técnicas presentadas para cada uno de los niveles de seguridad. Algunas de las posibles combinaciones son:
• Niveles 3 y 4: Los siguientes conjuntos de técnicas deben ser aplicados:
a. 1, 7 y una de 4, 5 ó 12.
b. 1, 4 y 5.
c. 1, 4 y 12.
d. 1, 2 y 4.
e. 1, 7 y una de 15 ó 16.
Niveles 1 y 2: A excepción de las técnicas norecomendadas (3, 9, 10, 13 y 14), aplicar una o varias técnicas de la tabla.
Como ya se dijo al comienzo de este apartado, este trabajo se centra en describir una de las combinaciones de técnicas recomendadas para garantizar los niveles de seguridad tres y cuatro. Esta combinación es la formada por: programación defensiva (defensive programming), programación con múltiples versiones (diverse...
Contenidos
1 INTRODUCCIÓN 3
2 ARQUITECTURAS DE DESARROLLO 5
2.1 Programación defensiva 5
2.1.1 Técnicas y recomendaciones 5
2.2 Programación con múltiples versiones 7
2.3 Programación con aserciones 9
3 CONCLUSIONES 11
4 REFERENCIAS 12
1 Introducción
El estándar EN-50128 se aplica al desarrollo deaplicaciones de control y protección en sistemas ferroviarios, si bien es cierto que puede ser fácilmente reutilizado para el diseño e implementación de cualquier sistema que tenga requisitos de seguridad. Este estándar cubre todo el proceso de desarrollo software, desde la especificación de requisitos, la elección de la arquitectura de desarrollo hasta las técnicas y lenguajes de programaciónutilizados.
Este trabajo se centra en las arquitecturas de desarrollo para aplicaciones con requisitos de seguridad. Se han seleccionado tres arquitecturas como caso de estudio, teniendo para ello en cuenta que este conjunto forma una combinación de técnicas aprobada para el desarrollo de software con requisitos de seguridad de niveles tres y cuatro.
La lista completa de arquitecturas de desarrollopropuestas por el estándar puede verse en la Tabla 1.
Técnica Nivel de seguridad
0 1 2 3 4
1. Defensive Programming - R R HR HR
2. Fault Detection & Diagnosis - R R HR HR
3. Error Correcting Codes - - - - -
4. Error Detecting Codes - R R HR HR
5. Failure Assertion Programming - R R HR HR
6. Safety Bag Techniques - R R R R
7. Diverse Programming - R R HR HR
8. Recovery Block - R R R R9. Backward Recovery - NR NR NR NR
10. Forward Recovery - NR NR NR NR
11. Re-try Fault Recovery Mechanisms - R R R R
12. Memorising Executed Cases - R R HR HR
13. Artificial Intelligence – Full Correction - NR NR NR NR
14. Dynamic Reconfiguration of Software - NR NR NR NR
15. Software Errors Effects Análisis - R R HR HR
16. Fault Tree Analysis R R R HR HR
Tabla 1. Arquitecturassoftware.
Para cada una de estas técnicas el estándar da una recomendación, según el nivel de seguridad requerido. Estas recomendaciones quedan recogidas en la Tabla 2.
Recomendación Significado
M Mandatory (imprescindible)
HR Highly recommended (altamente recomendado)
R Recommended (recomendado)
- Sin recomendación
NR Not recommended (no recomendado)
F Forbidden (prohibido)
Tabla2. Valores de las recomendaciones del estándar.
Observando la Tabla 1 podemos observar cómo el estándar presenta un conjunto de técnicas recomendadas en su mayoría, con mayor o menor énfasis dependiendo de los requisitos de seguridad de la aplicación. Sin embargo, cuatro de las técnicas incluidas aparecen como no recomendadas para ninguno de los niveles de seguridad. Fijándonos bien,podemos ver que esas cuatro técnicas son las que intentan corregir o reconfigurar el sistema ante la presencia de un fallo. Esto es especialmente representativo, ya que demuestra el énfasis del estándar por la seguridad, ya que un intento de corrección de un error no esperado podría tener consecuencias aún peores que las del propio error si las medidas tomadas no son las adecuadas.
Para finalizar,el estándar propone un conjunto de posibles combinaciones de las técnicas presentadas para cada uno de los niveles de seguridad. Algunas de las posibles combinaciones son:
• Niveles 3 y 4: Los siguientes conjuntos de técnicas deben ser aplicados:
a. 1, 7 y una de 4, 5 ó 12.
b. 1, 4 y 5.
c. 1, 4 y 12.
d. 1, 2 y 4.
e. 1, 7 y una de 15 ó 16.
Niveles 1 y 2: A excepción de las técnicas norecomendadas (3, 9, 10, 13 y 14), aplicar una o varias técnicas de la tabla.
Como ya se dijo al comienzo de este apartado, este trabajo se centra en describir una de las combinaciones de técnicas recomendadas para garantizar los niveles de seguridad tres y cuatro. Esta combinación es la formada por: programación defensiva (defensive programming), programación con múltiples versiones (diverse...
Leer documento completo
Regístrate para leer el documento completo.