La seguridad del software (a veces denominada seguridad del sistema de software) es una disciplina de ingeniería que tiene como objetivo garantizar que el software que se utiliza en sistemas relacionados con la seguridad (es decir, software relacionado con la seguridad) no contribuya a los peligros que dichos sistemas podrían plantear. Existen numerosas normas que rigen la forma en que se debe desarrollar y garantizar la seguridad del software relacionado con la seguridad en diversos ámbitos. La mayoría de ellas clasifican el software según su criticidad y proponen técnicas y medidas que se deben emplear durante el desarrollo y la garantía:
La seguridad del sistema es la disciplina general que tiene como objetivo lograr la seguridad mediante la reducción de los riesgos en los sistemas técnicos a un nivel aceptable. Según la norma de seguridad de sistemas IEC 61508 , ampliamente adoptada , [1] la seguridad es “la ausencia de riesgos inaceptables de daño”. Como el software por sí solo, que puede considerarse como información pura, no puede causar ningún daño por sí mismo, el término seguridad del software a veces se descarta y se reemplaza por “seguridad del sistema de software” (por ejemplo, el Joint Software Systems Safety Engineering Handbook [8] y MIL-STD-882E [9] utilizan esta terminología). Esto enfatiza que el software solo puede causar daño en el contexto de un sistema técnico (consulte la Guía de seguridad del software de la NASA, [10] capítulo 2.1.2), que tiene algún efecto en su entorno.
El objetivo de la seguridad del software es garantizar que el software no cause ni contribuya a generar ningún peligro en el sistema en el que se utiliza y que se pueda asegurar y demostrar que así es. Esto se logra normalmente mediante la asignación de un "nivel de seguridad" al software y la selección de procesos adecuados para el desarrollo y la garantía del software.
Uno de los primeros pasos al crear software relacionado con la seguridad es clasificar el software según su criticidad de seguridad. Varias normas sugieren diferentes niveles, por ejemplo, los niveles de software AE en DO-178C , [4] SIL (nivel de integridad de seguridad) 1-4 en IEC 61508, [1] ASIL (nivel de integridad de seguridad automotriz) AD en ISO 26262. [ 2] La asignación se realiza normalmente en el contexto de un sistema general, donde se investigan las peores consecuencias de los fallos del software. Por ejemplo, la norma automotriz ISO 26262 requiere la realización de una evaluación de riesgos y peligros ("HARA") a nivel del vehículo para derivar el ASIL del software ejecutado en un componente.
Es esencial utilizar un proceso de desarrollo y aseguramiento adecuado, con métodos y técnicas apropiados, acorde con la criticidad de seguridad del software. Las normas de seguridad del software recomiendan y a veces prohíben el uso de tales métodos y técnicas, dependiendo del nivel de seguridad. La mayoría de las normas sugieren un modelo de ciclo de vida (por ejemplo, EN 50716, [3] SIL (Nivel de integridad de seguridad) 1-4 en IEC 61508 [1] sugiere, entre otros, un modelo V) y prescriben actividades requeridas que se ejecutarán durante las diversas fases del software. Por ejemplo, IEC 61508 requiere que el software se especifique adecuadamente (por ejemplo, mediante el uso de métodos formales o semiformales), que el diseño del software sea modular y comprobable, que se utilicen lenguajes de programación adecuados, se realicen revisiones de código documentadas y que las pruebas se realicen en varias capas para lograr una cobertura de prueba adecuadamente alta. El enfoque en el proceso de desarrollo y garantía de software se deriva del hecho de que la calidad del software (y por lo tanto la seguridad) está fuertemente influenciada por el proceso del software, como lo sugiere IEC 25010. [11] Se afirma que el proceso influye en los atributos de calidad interna del software (por ejemplo, la calidad del código) y estos a su vez influyen en los atributos de calidad externa del software (por ejemplo, la funcionalidad y la confiabilidad).
Las siguientes actividades y temas abordados en el proceso de desarrollo contribuyen a un software seguro.
Prácticamente todas las normas de seguridad del software exigen una documentación exhaustiva de todo el proceso de desarrollo y garantía. Normalmente, esta documentación es revisada y avalada por terceros y, por lo tanto, es un requisito previo para la aprobación del software relacionado con la seguridad. La documentación abarca desde diversos documentos de planificación, especificaciones de requisitos, documentación de diseño y arquitectura del software, casos de prueba en varios niveles de abstracción, informes de calificació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 se han cumplido correctamente todos los requisitos y que no se ha introducido ningún material no rastreable”. Al documentar y mantener la trazabilidad, se hace posible seguir, por ejemplo, un requisito de seguridad en el diseño de un sistema (para verificar si se ha tenido en cuenta 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 adecuado y la ejecución de la prueba (para verificar si el requisito de seguridad se ha probado adecuadamente).
Las normas de seguridad pueden tener requisitos que afecten 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 estructuras de programación y la necesidad de normas de codificación. La Parte 3 de la norma IEC 61508 contiene los siguientes requisitos y recomendaciones:
Es necesario demostrar una cobertura de prueba adecuada, es decir, en función del nivel de seguridad, se deben aplicar esquemas de prueba más rigurosos. En DO-178C se incluye un requisito bien conocido en relación con la cobertura de prueba en función del nivel de software: [4]
Las normas de seguridad del software suelen exigir que algunas actividades se ejecuten con independencia, es decir, por una persona diferente, por una persona con diferentes líneas de informes 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 norma EN 50716 [3] Figura 2 exige que los roles de "implementador", "probador" y "verificador" los ocupen personas diferentes, el rol de "validador" lo ocupe una persona con una línea de informes diferente y el rol de "evaluador" lo ocupe una persona de una unidad organizativa diferente. Las normas DO-178C [4] y DO-278A [5] exigen que varias actividades (por ejemplo, verificación de la cobertura de pruebas, actividades de aseguramiento) se ejecuten "con independencia", definiéndose la independencia como "la separación de responsabilidades que garantiza el logro de una evaluación objetiva".
En la ingeniería de seguridad de sistemas, es común asignar límites superiores para las tasas de falla de los subsistemas o componentes. Luego se debe demostrar que estos subsistemas o componentes no exceden sus tasas de falla asignadas, o de lo contrario se debe emplear redundancia u otros mecanismos de tolerancia a fallas. Este enfoque no es viable para el software. Las tasas de falla del software no se pueden predecir con certeza. Aunque se han llevado a cabo investigaciones significativas en el campo de la confiabilidad del software (ver por ejemplo Lyu (1996), [12] los estándares actuales de seguridad del software no requieren que se use ninguno de estos métodos o incluso desalientan su uso, por ejemplo DO178C [4] (p. 73) establece: “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 esos tipos de métodos, porque al momento de escribir, los métodos actualmente disponibles no proporcionaron resultados en los que se pueda 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”.
La seguridad del software puede tener intereses diferentes en algunos casos. Por un lado, el software relacionado con la seguridad que no es seguro puede representar 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 seguridad establecidas (pruebas y verificaciones rigurosas antes de cambiar algo 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 de forma tradicional. Por ello, actualmente se está investigando si se pueden utilizar estas tecnologías y cómo hacerlo. En la actualidad, las normas no suelen avalar 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 de software ágil , que normalmente incluye muchas iteraciones, a veces todavía se estigmatiza por ser demasiado caótico para el desarrollo de software relacionado con la seguridad. Esto puede deberse en parte a afirmaciones como "software funcional en lugar de documentación exhaustiva", que se encuentra en el manifiesto para el desarrollo ágil. [14] Aunque la mayoría de las normas de seguridad de software presentan el ciclo de vida del software en la secuencia tradicional en cascada , algunas contienen declaraciones 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, ingresados y reingresados". 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 de la norma.
Este artículo incorpora material de dominio público del Manual de software del Ejército de los Estados Unidos .