Caso de garantía: un caso de seguridad razonado

fuente



¿Cuál es la mejor manera de evaluar la seguridad y no perderse nada? ¿Es posible recopilar toda la variedad de artefactos de seguridad en un documento (o diagrama) y organizarlos de tal manera que cualquier aspecto pueda visualizarse con un nivel de detalle comprensible?



Los técnicos estarían encantados de inventar una "piedra filosofal" de este tipo que, incluso si no proporcionara seguridad, al menos la evaluarían con el nivel requerido de integridad. Tales desarrollos existen desde hace más de 20 años, sin embargo, son prácticamente desconocidos para el lector de habla rusa. Se tratará de la metodología Assurance Case (o Safety Case), que significa un conjunto estructurado de argumentos y evidencia documental que justifica el cumplimiento de un sistema o servicio con requisitos específicos.

Introducción

Antes de leer el artículo, me gustaría llamar su atención sobre un par de puntos importantes. El material indicado es aplicable, en primer lugar, para objetos de infraestructura de información crítica (CII). Para tales objetos, en particular para los sistemas de información y control, se debe realizar un análisis de seguridad. Los resultados del análisis de seguridad se presentan en forma de informes apropiados. Todo esto se ha hecho durante décadas, sin embargo, los informes, por regla general, tienen una forma de texto arbitraria, cuya lógica no siempre es fácil de entender.



La idea principal del enfoque presentado es que los resultados del análisis de seguridad se pueden presentar en forma gráfica utilizando notaciones semiformales, con todas las ventajas consiguientes. Por lo tanto, Assurance Case es una forma de visión integrada de todas las medidas para garantizar y evaluar la seguridad, sin reemplazar o cancelar métodos privados como, por ejemplo, pruebas, análisis de código estático, cálculo de confiabilidad, FMEA, análisis de riesgos, etc. Este artículo continúa la serie de seguridad publicada anteriormente .

Mapas de argumentos y sus orígenes filosóficos

¿Cómo podemos entender o afirmar que algún objeto es seguro? Evidentemente, para ello deben introducirse una serie de criterios. Sin embargo, para estos criterios, necesitamos determinar qué tan confiable es nuestro conocimiento sobre el objeto. ¿Por qué podemos confiar en este conocimiento? ¿Qué hace que nuestro razonamiento y nuestro razonamiento sean verdaderamente creíbles? Habiendo ahondado en tales problemas, no se puede prescindir de disciplinas filosóficas como la ontología, la epistemología, la epistemología, la lógica, y también, sin grandes pensadores que se preocuparon por estas cuestiones. En el mundo antiguo, tales eran Aristóteles y Platón, y en la era de los "tiempos modernos" Francis Bacon es considerado el fundador del método científico moderno.



¿Qué se puede hacer para justificar o evaluar la seguridad de una manera lógica y razonable? Este enfoque se basa en la teoría de la argumentación. El trabajo del filósofo británico Stephen Toulmin titulado "Los usos del argumento", publicado en 1958, dio un nuevo impulso al desarrollo moderno de la argumentación . Tulmin amplió la inferencia implicativa lógica con parámetros adicionales y propuso representar esta operación en forma gráfica. La notación de Tulmin opera con las siguientes entidades: datos (D) - datos iniciales para el análisis, afirmación () - el propósito de la inferencia de implicación lógica (Si D So C), justifica (W) - un argumento adicional, calificador (Q) - el grado de confianza en los resultados de la lógica salida, refutable (R) es un contraargumento adicional (Figura 1).





Figura 1. Notación de Stephen Tulmin



Mapas de argumentos o argumentación ( Argument the Map ) utilizados con fines de visualización y razonamiento a Toulmin, pero fue él quien resumió con mayor éxito el modelo estructural para el análisis y verificación de argumentos. Tenga en cuenta que los mapas de argumentos modernos, por regla general, no utilizan la notación de Tulmin, todo está simplificado, por ejemplo, como en la figura siguiente. Esta es la notación utilizada por el servicio en línea de pago Rational (existe una versión gratuita, pero tiene una funcionalidad extremadamente limitada) (Figura 2). La versión paga es capaz de transformar los diagramas resultantes en texto estructurado lógicamente. También hay guías y tutoriales gratuitos disponibles en el sitio sobre pensamiento crítico y mapeo de argumentos.





Figura 2. Mapa de argumentos desarrollado con el servicioRacional



Como ves, todo es bastante transparente, solo hay cuatro entidades y tres tipos de relaciones entre ellas. El resultado de la entrada lógica se llama Contención, confirmando el argumento - Razón (conexión porque), contraargumento - Objeción (conexión pero), pero el contraargumento para el contraargumento tiene un nombre especial - Refutación (conexión sin embargo).



Actualmente no existe una notación generalmente aceptada para construir mapas de argumentos. No hay uniformidad en la notación utilizada para la estructura de los argumentos. Por ejemplo, el resultado de la inferencia puede llamarse afirmación, contención, conclusión, meta. Los argumentos se pueden llamar premisa, justificación, etc. Hay una serie de iniciativas y comunidades internacionales en el campo del modelado de argumentos (por ejemplo, Argument Interchange Format, AIF), pero no resolvieron las cuestiones de la unificación. Hay investigaciones que establecen paralelismos entre los mapas de argumentos y los mapas mentales (Mapa mental, probablemente todos hayan oído hablar de ellos). De hecho, las capacidades de los editores de mapas mentales le permiten construir un análogo del mapa de argumentos.

Aseguramiento Historia y concepto del caso

¿Qué tiene que ver todo esto con la seguridad? Para responder a esta pregunta, vayamos a la segunda mitad del siglo XX, donde se origina la teoría y la práctica modernas de garantizar la seguridad. Luego, como resultado del desarrollo de industrias tecnogénicas complejas, como la energía nuclear, la tecnología espacial, las industrias de petróleo y gas y químicas, el transporte, la humanidad se enfrentó a desastres provocados por el hombre de una escala sin precedentes.



Luego aparecieron los primeros informes de análisis de seguridad, que reunieron todos los requisitos relevantes, así como información que confirma su cumplimiento. Más tarde, apareció el término Safety Case (de hecho, un informe analítico sobre seguridad), que fue el antecesor del Assurance Case. Tenga en cuenta que los términos "Caso de seguridad" o "Caso de garantía" no se pueden traducir directamente al ruso; en este contexto, la traducción más lógica es "Caso de seguridad". Aunque, por ejemplo, en las traducciones al ruso de la serie de normas ISO / IEC 15026 (Ingeniería de sistemas y software - Aseguramiento de sistemas y software), "Caso de garantía" se traduce como "caso de garantía".



Cabe señalar que en algunas industrias todavía se utiliza el término Caso de seguridad, junto con Caso de garantía. Assurance Case, siendo un término más moderno, se contrasta con Safety Case en el sentido de que hoy el sistema debe cumplir no solo con la seguridad (seguridad funcional), sino también con la seguridad (seguridad de la información). Por lo tanto, se propone utilizar el concepto de caso de garantía y considerar el caso de seguridad como un caso especial.



Caso de aseguramiento, en el sentido moderno de este término, significa un informe sobre el análisis de seguridad realizado, que incluye una representación visual en forma de gráfico o tabla, obtenido mediante notaciones semiformales (las notaciones se analizarán a continuación). Al mismo tiempo, se obtiene cierta discrepancia del mismo término, ya que es posible interpretar el Caso de Aseguramiento, por un lado, como un documento (informe de análisis de seguridad o informe de caso de seguridad), y, por otro lado, como un sistema de argumentación mediante notación semiformal. ... Idealmente, un caso de garantía puede incluir ambos componentes, es decir, el documento que evalúa la seguridad se construye sobre la base de un modelo de argumentos.



Sin embargo, volvamos al siglo XX. El CIMAH (Control of Industrial Major Accidents Hazards), originalmente emitido en el Reino Unido en 1984 y luego adaptado en varios otros países, fue el primer documento reglamentario que requirió el desarrollo y análisis de un Caso de Seguridad para instalaciones industriales potencialmente peligrosas. La implementación más amplia del Caso de Seguridad en la práctica comenzó después del accidente sin precedentes en la plataforma petrolera Piper Alpha en el Mar del Norte, que mató a 167 personas en 1988.



En la década de 1990, los investigadores continúan buscando nuevos enfoques para evaluar la seguridad. La idea parece estar en la superficie: desarrollemos una notación especial para justificar el cumplimiento de los objetos y sistemas artificiales con los requisitos de seguridad. Dos equipos universitarios británicos se hicieron cargo, la Universidad de Londres, donde se formó la empresa derivada Adelard, y la Universidad de York. Debo decir que hoy Adelard y la Universidad de York ocupan posiciones de liderazgo en la promoción de Assurance Case.



Para el desarrollo de notaciones, se hizo hincapié en el razonamiento lógico de que una propiedad o componente del sistema cumple con los requisitos establecidos. Las obras de Stephen Toulmin, que ya hemos considerado, fueron elegidas como base teórica. Como humanista, Toulmin casi no pensaba en los sistemas creados por el hombre, sin embargo, pasó a la historia, entre otras cosas, como el fundador de la argumentación para Assurance Case.



Tomando la notación de Toulmin como base, los británicos pronto desarrollaron la metodología Assurance Case (llamada Safety Case en ese momento) y llevaron los resultados a implementaciones industriales prácticas. En la Universidad de York, la Notación de Estructuración de Objetivos (GSN) fue desarrollada y promovida por el estudiante de doctorado Tim Kelly bajo la dirección del profesor John McDermid. Como resultado, hubo ese raro caso en que la disertaciónArgumentando la seguridad: un enfoque sistemático para la gestión de casos de seguridad. Tesis doctoral. University of York, 1998 ” se ha considerado un clásico durante más de 20 años, y continúa siendo citado activamente. Sin embargo, el enfoque para resolver el problema de seguridad fue, en mi opinión, más académico y, como resultado, por alguna razón, no se dio un paso aparentemente comprensible y lógico relacionado con el desarrollo de una herramienta de software para respaldar Assurance Case.



Por el contrario, Adelard, dirigido por Robin Bloomfield y Peter Bishop, se preocupó principalmente por comercializar los resultados. Paralelamente a York, London desarrolló la notación Claim, Argument and Evidence (CAE), así como la herramienta de software Adelard ASCE(Assurance and Safety Case Environment), que admite tanto a CAE como a GSN. En el Reino Unido, el desarrollo de un caso de garantía (caso de seguridad) es requerido por leyes y estándares en muchas áreas relacionadas con la seguridad, por lo que ASCE tiene un mercado bastante sólido aquí. ASCE ha sido y sigue siendo la herramienta de desarrollo de casos de garantía más utilizada. La parte principal de la herramienta es un editor gráfico, en el que se puede adjuntar texto adicional o información de hipervínculo a bloques gráficos (Figura 3). No puede descargar el software ASCE del sitio web de Adelard usted mismo. Debe completar una solicitud de una licencia académica o de prueba de 30 días, después de lo cual la empresa revisará la solicitud.





Figura 3. La interfaz del programa Adelard ASCE



Ahora veamos las dos notaciones básicas que se utilizan para desarrollar un caso de garantía (CAE y GSN).

Notación CAE (reclamo, argumento y prueba)

La notación CAE (Claim, Argument and Evidence) opera en tres entidades específicas: los objetivos indican el logro de las propiedades requeridas del sistema, las confirmaciones proporcionan una base documentada para la argumentación, demostrando el logro o no logro de los objetivos, los argumentos se construyen usando reglas de inferencia y conectan Confirmación con fines. Se utilizan habitualmente argumentos como el determinista (o lógico), el probabilístico y el cualitativo. Para designar objetivos, argumentos y evidencias, se introducen primitivas gráficas que tienen varias formas (Figura 4).



Figura 4. Notación de afirmaciones, argumentos y pruebas (CAE): componentes principales



La construcción de una jerarquía de objetivos y subobjetivos es el primer paso para desarrollar un caso de aseguramiento. Como se muestra en el diagrama, la estructura de objetivos, argumentos y afirmaciones no es necesariamente de tres niveles; por ejemplo, se pueden utilizar subobjetivos adicionales para apoyar la argumentación. La notación CAE también se transforma fácilmente en forma tabular. Las columnas de dicha tabla serán todos los mismos objetivos, argumentos y confirmaciones, entre los cuales ahora se establecerán vínculos dentro de los registros de la tabla. Se utiliza un enfoque similar para el desarrollo de una caja de aseguramiento, por ejemplo, por exida .

GSN (notación de estructuración de objetivos)

GSN opera con componentes tales como un objetivo (un objetivo, denotado por un rectángulo y es un análogo de una afirmación en CAE), una estrategia de argumentación (una estrategia, denotada por un paralelogramo y es un análogo del argumento) y una solución (denotada por un círculo y es un análogo de la evidencia) (Figura 5). El contexto se utiliza para apoyar la información de las metas. Se pueden utilizar supuestos y justificaciones para respaldar el argumento. La estructura de metas es jerárquica.





Figura 5. Notación de estructuración de objetivos (GSN): componentes principales



Al comparar CAE y GSN, debe tenerse en cuenta que CAE presta más atención a la justificación de los argumentos individuales. Para ello, se realiza un diseño detallado de los pasos de la argumentación. GSN se centra más en estructuras de argumentos genéricos (patrones). Debido al mayor número de entidades, GSN es menos estricto y, al mismo tiempo, con una descripción más concisa, se puede reducir a CAE. El uso de cada una de las notaciones puede ser bastante subjetivo, ya que el enfoque para construir argumentos depende de la persona que realiza esta tarea. Algunos profesionales del caso de aseguramiento señalan que hay una serie de lagunas en las notaciones asociadas con la completitud de la definición de elementos semánticos.



Resultó que hoy GSN es más común. Formato GSN fijado en el estándarEstándar comunitario de notación de estructuración de objetivos (GSN) , así como el modelo de datos del metamodelo de caso de garantía estructurada (SACM) del Grupo de gestión de objetos (OMG).

Base de conocimientos: industrias, estándares, investigación, herramientas, notaciones alternativas

Assurance Case se utiliza principalmente en aquellas industrias en las que su uso está regulado por documentos reglamentarios. El líder aquí es Gran Bretaña y algunos otros países de la Commonwealth británica. El informe de la UK Health Foundation Using Safety Cases in Industry and Healthcare (2012) informa sobre la experiencia regulatoria del Assurance Case (Safety Case) en las industrias de salud, aviación, energía nuclear, automotriz, defensa, petroquímica y ferroviaria.



Teniendo en cuenta los requisitos para solicitar un caso de garantía fuera del Reino Unido, debe tenerse en cuenta:

• norma automotriz ISO 26262: 2011, Vehículos de carretera - Seguridad funcional, parte de la familia de normas de seguridad funcional que detallan los requisitos de IEC 61508;
• European Organisation for the Safety of Air Navigation (EUROCONTROL): “Safety Case Development Manual, 2006”, “EAD (European Aeronautical Information System Database) Safety Case, 2009”, “EAD (European Aeronautical Information System Database) Safety Case Guidance, 2010”;
• “Licensing of safety critical software for nuclear reactors – Common position of international nuclear regulators and authorised technical support organisations, 2018”, (, , , , , , , , );
• estándares de la serie ISO / IEC 15026, Ingeniería de sistemas y software - Aseguramiento de sistemas y software, que incluye cuatro partes: Parte 1: Conceptos y vocabulario (2019); Parte 2: Caso de aseguramiento (2011); Parte 3: Niveles de integridad del sistema (2015); Parte 4: Aseguramiento en el ciclo de vida (2012).
  
  

También cabe destacar una serie de organizaciones (además de la ya mencionada Adelard y el Grupo de Ingeniería de Sistemas de Alta Integridad de la Universidad de York) que están trabajando activamente en el campo de Casos de Aseguramiento. Éstas incluyen:

• US-CERT (Equipo de Preparación para Emergencias Informáticas de Estados Unidos), llaman a su metodología Casos de Garantía de Seguridad ;
• SEI/CMU (Sofrware Engineering Institute – Carnegie Mellon University), , CERT Division, SEI, Assurance Case US-CERT;
• NASA (National Aeronautics and Space Administration) Scientific and Technical Information (STI) Assurance Case ;
• , , John Rushby, SRI International ( Stanford Research Institute), , “The Interpretation and Evaluation of Assurance Cases”, .

Adelard ASCE (Case Case y Safety Case Environment) sigue siendo el software de soporte Assurance Case más conocido . La mayoría de los proyectos mencionados en diferentes años no han alcanzado ningún nivel serio. La NASA anunció la creación del software AdvoCATE , pero lo usan para sus propios fines y no planean lanzarlo al mercado. Dada la simplicidad de la notación, puede utilizar, por ejemplo, MS Visio para elaborar diagramas de casos de garantía y complementarlos con hipervínculos.



Los enfoques alternativos para desarrollar Assurance Case incluyen la herramienta de software NOR-STA... Sería desarrollado por la empresa polaca Argevide (spin-off de la Universidad Tecnológica de Gdansk). NOR-STA admite su propia notación TRUST-IT. La diferencia es que en lugar de una representación gráfica, NOR-STA usa una lista jerárquica estructurada (Figura 6).







Figura 6. Notación de Trust-IT: Los componentes básicos y las



entidades de casos de estudio en la lista jerárquica de objetivos de Assurance Case se indican con diferentes iconos. Se utiliza una estrategia de argumentación para confirmar el cumplimiento de una declaración, y los hechos u observaciones, justificaciones, suposiciones y declaraciones adicionales se utilizan como un análogo de la evidencia. A diferencia del Adelard ASCE de escritorio, NOR-STA se utiliza en línea y admite el trabajo en equipo distribuido.



Además, el Assurance Case se utiliza para resolver las siguientes aplicaciones:

• evaluación de atributos de propiedades complejas, tales como calidad, confiabilidad, seguridad;
• apoyar la certificación y la estandarización transformando los requisitos de las normas en una estructura de argumentos;
• El desarrollo basado en garantía (ABD) o el desarrollo de productos basado en garantía es una forma de desarrollo basado en modelos (MBD);
• gestión del conocimiento, por ejemplo, modelando la estructura de la documentación o determinando relaciones estructurales en cualquier área de actividad (procesos de negocio, flujo de trabajo, gestión de cambios, etc.).

Caso de garantía para la seguridad de la información

El caso de seguridad (confiabilidad) se conoce como una de las variedades de caso de garantía. Si es necesario, el estuche de seguridad se puede complementar con componentes del estuche de seguridad. De hecho, la idea detrás de Assurance Case es combinar los atributos de seguridad y protección. En el área de certificación, existen desarrollos para la norma ISO / IEC 15408 (Criterios Generales), para los cuales los requisitos se han convertido a una estructura compatible con la estructura Assurance Case. Esta conversión se puede realizar para otras normas relevantes, como ISO 27000 o IEC 62443, o cualquier otro marco.



Un ejemplo es un fragmento de casos de garantía de seguridadpublicado en el sitio web de US-CERT. Este fragmento revisa la prueba de implementación del ciclo de vida del desarrollo de software (SDLC). El objetivo es eliminar los defectos de codificación (en particular, el desbordamiento de búfer), para lo que se utilizan métodos como la formación de programadores, revisiones de código, análisis estático y pruebas. Por supuesto, se puede discutir la integridad de este fragmento, pero se ofrece solo como ilustración (Figura 7).





Figura 7. Fragmento de casos de garantía de seguridad



Por lo tanto, aunque la seguridad de la información es la aplicación donde el Caso de garantía podría tener más demanda, debe tenerse en cuenta que a pesar de su potencial y una serie de estudios piloto, el Caso de garantía no se ha convertido en una práctica conocida en esta área.

Caso de estudio de caso de garantía

Finalmente, veamos un ejemplo de cómo puede funcionar esto. Se basa en un enfoque basado en el desarrollo de argumentos estructurados .

Argumentos estructurados

Imaginemos el proceso de desarrollar argumentos en dos pasos secuenciales (Figura 8). El primer paso, llamado Paso de Razonamiento (RS), es el análisis de subobjetivos (CE), que tienen como objetivo lograr el objetivo principal (C). En este paso, se desarrolla la estructura de la argumentación. En el segundo paso, llamado Paso Evidencial (ES), se formulan confirmaciones (Evidencia, E) en apoyo de los subobjetivos (SC) generados en el paso anterior. Para formalizar aún más los pasos RS y ES, se utilizan plantillas típicas de texto estructurado (ST).





Figura 8. Pasos y componentes de argumentos estructurados

Jerarquía de requisitos

Imagine una jerarquía o pirámide de requisitos que forman una estructura que corresponde a la columna Caso de aseguramiento. La mayoría de los requisitos reglamentarios para sistemas informáticos o software tienen una estructura de requisitos de 3 o 4 niveles (Figura 9).





Figura 9. La jerarquía de requisitos y su relación con los pasos de argumentación El



nivel cero es un meta-objetivo, según el cual el sistema evaluado debe cumplir con todos los requisitos de seguridad. En el primer nivel, se logran los objetivos de seguridad global, por ejemplo, los siguientes objetivos se derivan de los requisitos de IEC 61508 para seguridad funcional:

• se debe implementar un sistema de gestión de la seguridad;
• durante el desarrollo del sistema (o software), se debe aplicar el ciclo de vida de la seguridad;
• se debe aplicar al sistema un conjunto suficiente de medidas para proteger contra fallas accidentales;
• para el sistema (o software), se debe aplicar un conjunto suficiente de medidas para proteger contra fallas sistemáticas y de software, incluida la protección contra ataques cibernéticos.

En el segundo nivel, los grupos de requisitos apoyan un objetivo global particular. Por ejemplo, requisitos de gestión de seguridad(según IEC 61508) incluyen grupos de requisitos para la gestión de personal, gestión de configuración, gestión de documentos y otros. La estructura de vínculos entre los niveles cero, primero y segundo es un árbol bastante simple. Esta estructura no requiere una elaboración detallada de los argumentos, ya que estos argumentos son típicos y han sido probados repetidamente en varios proyectos. Sin embargo, al pasar del segundo nivel a los inferiores, se requieren argumentos estructurados. En este caso, los requisitos de los niveles inferiores pueden ser compuestos (es decir, incluir varios requisitos separados) o simples (atómicos). Si todos los requisitos son atómicos (no hay requisitos compuestos), este nivel se convierte en el tercero y luego está directamente relacionado con los subgrupos de requisitos. Si hay requisitos compuestos, obtenemos una estructura de cuatro niveles más compleja.



Para el nivel más bajo, además de RS, también se debe aplicar ES. Dado que es inconveniente agregar información detallada sobre el contenido de los argumentos a la estructura del gráfico, cada uno de los nodos del gráfico de Caso de Aseguramiento, a partir del segundo nivel, se marca con una descripción de los argumentos utilizando texto estructurado (ST). El gráfico del caso de aseguramiento en el nivel inferior ya no es un árbol, porque la misma confirmación (E) puede soportar diferentes subobjetivos (SC).

Caso de garantía para un grupo de requisitos de recursos humanos (IEC 61508)

Como ilustración, considere el fragmento del caso de aseguramiento en relación con los requisitos de IEC 61508 HR ( IEC 61508-1 cláusula 6 ).





Se han extraído un total de siete requisitos de gestión de personal de IEC 61508. Desde el punto de vista de la argumentación estructurada, estos requisitos son subobjetivos (CE1, ..., CE7). Solo uno de los subobjetivos (SC5) es compuesto, todos los demás son atómicos. Para pasar de un subobjetivo compuesto (SC5) a atómico (SC5.1, ..., SC5.11), se realiza un paso más de razonamiento (RS). Se entiende que, de acuerdo con los requisitos de la IEC 61508, se desarrolló un Plan de Gestión de Recursos Humanos para un proyecto relacionado con la creación de un producto abstracto. Este plan interpreta los requisitos de la norma en el contexto del proyecto.





Para todos los pasos de confirmación (ES), se propone utilizar un texto estructurado común que indique los vínculos entre los subobjetivos (SG) de las confirmaciones (E). Usaremos la relación SG -> E para denotar la relación entre el correspondiente subobjetivo (SG) y las confirmaciones (E) que lo sustentan.





Todas las relaciones obtenidas SG -> E se pueden transformar en una columna de Caso de Aseguramiento, de acuerdo con la notación GSN modificada para la argumentación estructurada (Figura 10). Este gráfico refleja todo el grupo de requisitos relacionados con la gestión de personal de acuerdo con IEC 61508. Este gráfico también se puede utilizar como plantilla para evaluar el cumplimiento de los requisitos de IEC 61508.





Figura 10. Gráfico de caso de garantía derivado de argumentos estructurados para el grupo de requisitos de recursos humanos (IEC 61508)



A primera vista, todo esto es largo y difícil, pero, sin embargo, el Assurance Case tiene su aplicación práctica. Este es el enfoque que usamos al certificar el PLC RdICS para cumplir con IEC 61508 .

Conclusión

El método Assurance Case (Caso de seguridad) se ha utilizado durante más de 20 años para analizar la seguridad de las instalaciones de CII. Este método se utiliza más ampliamente en el Reino Unido y en varios países de la Commonwealth británica para industrias como la de salud, aviación, energía nuclear, automotriz, defensa, petroquímica y ferroviaria.



Las ventajas del Assurance Case incluyen todas las ventajas logradas al visualizar las relaciones en un área temática compleja, mejorando nuestra percepción y comprensión. Las desventajas se deben a la subjetividad del método en términos de su dependencia de la experiencia de las personas que realizan la evaluación. El "error épico" más famoso de la aplicación Assurance Case se describe aquí.... En resumen: el 2 de septiembre de 2006, se produjo un incendio en Afganistán a bordo de un Nimrod de la Fuerza Aérea Británica. El problema surgió por una fuga de combustible. Las 14 personas a bordo murieron. Un informe anterior de Safety Case confirmó la seguridad de la aeronave. La investigación mostró que la modificación del sistema de combustible no era del todo correcta en la aeronave de producción y que antes habían surgido problemas similares, pero por alguna razón nadie les prestó atención como un error del sistema. En un informe de 600 páginas publicado, este incidente fue nombrado nada menos que "una falla de liderazgo, cultura y prioridades".



Por cierto, las notaciones gráficas no se utilizaron en el informe de Nimrod. Una de las consecuencias de esta catástrofe fue la profundización de la investigación en el área de la construcción de la argumentación. Sin embargo, no se ha desarrollado un enfoque general que satisfaga a todos.



Hoy en día, el principal impulsor de la implementación de Assurance Case son los requisitos reglamentarios y legales, no la conveniencia, la viabilidad o la rentabilidad. Obviamente, existen grandes oportunidades para la inteligencia artificial en el campo de Assurance Case, pero de alguna manera no he encontrado publicaciones sobre este tema.

Sin embargo, el problema asociado con la evaluación de la seguridad de sistemas complejos permanece abierto. Es posible que se logren algunos avances en esta área con la implementación activa del Assurance Case, porque este método se basa en todos aquellos puntos importantes que han ocupado a la humanidad desde los inicios de la investigación filosófica.