Seguridad del software

La documentación exhaustiva del proceso completo de desarrollo y aseguramiento es un requisito prácticamente indispensable para todas las normas de seguridad de software. Por lo general, esta documentación es revisada y avalada por terceros, siendo un requisito previo para la aprobación del software relacionado con la seguridad. La documentación abarca diversos documentos de planificación, especificaciones de requisitos, documentación de arquitectura y diseño de software, casos de prueba en distintos niveles de abstracción, informes de cualificación de herramientas, evidencia de revisión, resultados de verificación y validación, etc. La figura C.2 de la norma EN 50716 ^{[ 3 ]} enumera 32 documentos que deben crearse a lo largo del ciclo de vida del desarrollo.

La trazabilidad es la práctica de establecer relaciones entre diferentes tipos de requisitos y entre los requisitos y los artefactos de diseño, implementación y prueba. Según la norma EN 50716, ^{[ 3 ]} el objetivo es “garantizar que se pueda demostrar que todos los requisitos se han cumplido correctamente y que no se ha introducido ningún material no trazable”. Al documentar y mantener la trazabilidad, es posible seguir, por ejemplo, un requisito de seguridad en el diseño de un sistema (para verificar si se ha considerado adecuadamente), más adelante en el código fuente del software (para verificar si el código cumple el requisito) y hasta un caso de prueba apropiado y su ejecución (para verificar si el requisito de seguridad se ha probado adecuadamente).

Las normas de seguridad pueden tener requisitos que afectan directamente a la implementación del software en el código fuente, como por ejemplo la selección de un lenguaje de programación adecuado, el tamaño y la complejidad de las funciones, el uso de ciertas construcciones de programación y la necesidad de estándares de codificación. La parte 3 de la norma IEC 61508 contiene los siguientes requisitos y recomendaciones:

• Uso de un lenguaje de programación fuertemente tipado. Algunos lenguajes son más adecuados que otros para sistemas relacionados con la seguridad. Los lenguajes que admiten tipado fuerte pueden detectar más fallos durante el proceso de compilación que, de otro modo, solo se detectarían en tiempo de ejecución. Por lo tanto, generalmente se desaconseja el uso de lenguaje ensamblador, mientras que se recomiendan lenguajes de alto nivel especialmente orientados al mercado de la seguridad (por ejemplo, ADA ).
• Utilizar un estándar de codificación apropiado que defina un subconjunto de lenguaje "seguro", por ejemplo, MISRA-C . MISRA-C es un estándar de codificación para el lenguaje de programación C que busca mejorar la calidad y la seguridad del código al prohibir construcciones propensas a errores o características que dependen del compilador (y cuyo comportamiento, por lo tanto, no está definido).
• Limitar el uso de recursión, punteros e interrupciones (ya que son propensos a errores).
• Prohibir el “flujo de control no estructurado en los programas”, es decir, evitar saltos de forma no estructurada, por ejemplo, mediante el uso de instrucciones tipo “ goto ”.

Es necesario demostrar una cobertura de pruebas adecuada, es decir, dependiendo del nivel de seguridad, se deben aplicar esquemas de prueba más rigurosos. Un requisito bien conocido con respecto a la cobertura de pruebas según el nivel de software se establece en DO-178C: ^{[ 4 ]}

• Nivel C: Se requiere cobertura de sentencias, es decir, "cada sentencia del programa se ha invocado al menos una vez" durante las pruebas.
• Nivel B: Se requiere cobertura de sucursales, es decir, "cada punto de entrada y salida del programa se ha invocado al menos una vez y cada decisión del programa se ha tomado considerando todos los resultados posibles al menos una vez".
• Nivel A: Cobertura de condiciones/decisiones modificada: una extensión de la cobertura de ramas, con el requisito de que "se haya demostrado que cada condición en una decisión afecta de forma independiente el resultado de esa decisión".

Los estándares de seguridad de software generalmente requieren que algunas actividades se ejecuten de forma independiente, es decir, por una persona diferente, por una persona con líneas jerárquicas diferentes, o incluso por una organización independiente. Esto garantiza que se eviten los conflictos de intereses y aumenta las posibilidades de que se identifiquen fallos (por ejemplo, en el diseño del software). Por ejemplo, la figura 2 de EN 50716 ^{[ 3 ]} requiere que los roles de "implementador", "probador" y "verificador" sean desempeñados por personas diferentes, el rol de "validador" por una persona con una línea jerárquica diferente y el rol de "evaluador" por una persona de una unidad organizativa diferente. DO-178C ^{[ 4 ]} y DO-278A ^{[ 5 ]} requieren que varias actividades (por ejemplo, verificación de cobertura de pruebas, actividades de aseguramiento) se ejecuten "de forma independiente", entendiendo la independencia como "separación de responsabilidades que garantiza el logro de una evaluación objetiva".

En la ingeniería de seguridad de sistemas, es común establecer límites superiores para las tasas de fallo de subsistemas o componentes. Posteriormente, debe demostrarse que estos subsistemas o componentes no superan dichas tasas de fallo; de lo contrario, se deben emplear mecanismos de redundancia u otros mecanismos de tolerancia a fallos. Este enfoque no es práctico para el software, ya que las tasas de fallo no pueden predecirse con precisión. Aunque se han realizado investigaciones significativas en el campo de la confiabilidad del software (véase, por ejemplo, Lyu (1996), ^{[ 12 ]} las normas de seguridad de software actuales no requieren que se utilice ninguno de estos métodos o incluso desaconsejan su uso, por ejemplo, DO178C ^{[ 4 ]} (p. 73) afirma: “Se han publicado muchos métodos para predecir la confiabilidad del software basados ​​en métricas de desarrollo, por ejemplo, estructura del software, tasa de detección de defectos, etc. Este documento no proporciona orientación para ese tipo de métodos, porque en el momento de su redacción, los métodos disponibles actualmente no proporcionaban resultados en los que se pudiera confiar”. ARP 4761 ^{[ 13 ]} cláusula 4.1.2 establece que los errores de diseño de software “no son lo mismo que las fallas de hardware. A diferencia de las fallas de hardware, las probabilidades de tales errores no se pueden cuantificar”.

En algunos casos , la seguridad del software y la protección del mismo pueden tener intereses contrapuestos. Por un lado, el software relacionado con la seguridad que no es seguro puede suponer un riesgo para la seguridad; por otro lado, algunas prácticas de seguridad (por ejemplo, la aplicación frecuente y oportuna de parches) contradicen las prácticas de protección establecidas (pruebas y verificaciones rigurosas antes de realizar cualquier cambio en un sistema operativo).

El software que emplea técnicas de inteligencia artificial, como el aprendizaje automático, sigue un ciclo de vida radicalmente diferente. Además, su comportamiento es más difícil de predecir que el de un sistema desarrollado tradicionalmente. Por lo tanto, la cuestión de si estas tecnologías pueden utilizarse y cómo, se encuentra actualmente en investigación. En la actualidad, las normas generalmente no avalan su uso. Por ejemplo, la norma EN 50716 (Tabla A.3) establece que la inteligencia artificial y el aprendizaje automático no se recomiendan para ningún nivel de integridad de seguridad.

El desarrollo ágil de software , que normalmente incluye muchas iteraciones, a veces todavía se estigmatiza como demasiado caótico para el desarrollo de software relacionado con la seguridad. Esto podría deberse en parte a afirmaciones como "software funcional por encima de documentación exhaustiva", que se encuentra en el manifiesto para el desarrollo ágil. ^{[ 14 ]} Aunque la mayoría de los estándares de seguridad de software presentan el ciclo de vida del software en la secuencia tradicional tipo cascada , algunos contienen afirmaciones que permiten ciclos de vida más flexibles. DO-178C establece que "Los procesos de un ciclo de vida de software pueden ser iterativos, es decir, entrar y volver a entrar". EN 50716 contiene el Anexo C que muestra cómo se pueden utilizar los ciclos de vida de desarrollo iterativos de acuerdo con los requisitos del estándar.