Caso de garantia: um caso de segurança fundamentado



source



Qual é a melhor maneira de avaliar a segurança sem perder nada? É possível reunir toda a variedade de artefatos de segurança em um documento (ou diagrama) e organizá-los de forma que qualquer aspecto possa ser visualizado com um nível de detalhe compreensível?



Os técnicos ficariam felizes em inventar essa “pedra filosofal” que, mesmo que não oferecesse segurança, pelo menos a avaliassem com o nível de completude exigido. Tais desenvolvimentos existem há mais de 20 anos, porém são praticamente desconhecidos para o leitor de língua russa. Tratará da metodologia Assurance Case (ou Safety Case), que significa um conjunto estruturado de argumentos e evidências documentais que justificam a conformidade de um sistema ou serviço com os requisitos especificados.



Introdução



Antes de ler o artigo, gostaria de chamar sua atenção para alguns pontos importantes. O material indicado é aplicável, em primeiro lugar, para objetos de infraestrutura crítica de informação (CII). Para tais objetos, em particular para sistemas de informação e controle, uma análise de segurança deve ser realizada. Os resultados da análise de segurança são apresentados na forma de relatórios apropriados. Tudo isso há décadas, porém, os relatórios, via de regra, apresentam uma forma de texto arbitrária, cuja lógica nem sempre é fácil de entender.



A ideia principal da abordagem apresentada é que os resultados da análise de segurança podem ser apresentados em forma gráfica usando notações semiformais, com todas as vantagens decorrentes. Assim, o Caso de Garantia é uma forma de uma visão integrada de todas as medidas para garantir e avaliar a segurança, sem substituir ou cancelar métodos privados como, por exemplo, teste, análise de código estático, cálculo de confiabilidade, FMEA, análise de risco, etc. Este artigo continua a série de segurança publicada anteriormente .



Mapas de argumento e suas origens filosóficas



Como podemos entender ou afirmar que algum objeto é seguro? Obviamente, uma série de critérios devem ser introduzidos para isso. No entanto, para esses critérios, precisamos determinar quão confiável é nosso conhecimento sobre o objeto? Por que podemos confiar nesse conhecimento? O que torna nosso raciocínio e raciocínio verdadeiramente credíveis? Tendo mergulhado em tais problemas, não se pode prescindir de disciplinas filosóficas como ontologia, epistemologia, epistemologia, lógica e, também, sem grandes pensadores que se preocuparam com essas questões. No mundo antigo, assim eram Aristóteles e Platão, e na era dos "tempos modernos" Francis Bacon é considerado o fundador do método científico moderno.



O que pode ser feito para justificar ou avaliar a segurança de uma forma razoável e lógica? Essa abordagem é baseada na teoria da argumentação. Um novo impulso para o desenvolvimento moderno da argumentação foi dado na obra do filósofo britânico Stephen Toulmin intitulada "The Uses of Argument", publicada em 1958. Tulmin estendeu a inferência implícita lógica com parâmetros adicionais e propôs representar esta operação em forma gráfica. A notação de Tulmin opera com as seguintes entidades: dados (D) - dados iniciais para análise, afirmação (C) - o objetivo da implicação lógica (Se D So C), garantia (W) - um argumento adicional, qualificador (Q) - o grau de confiança nos resultados da lógica saída, refutável (R) é um contra-argumento adicional (Figura 1).





Figura 1. Notação de Stephen Tulmin



Mapas de argumentos ou argumento ( Argumento o Mapa ) usados ​​com o propósito de visualização e raciocínio para Toulmin, mas foi ele quem mais conseguiu resumir o modelo estrutural para a análise e verificação de argumentos. Observe que os mapas de argumento modernos, via de regra, não usam a notação de Tulmin, tudo é simplificado, por exemplo, como na figura abaixo. Esta é a notação usada pelo serviço online pago Rational (existe uma versão gratuita, mas é extremamente limitada em funcionalidade) (Figura 2). A versão paga é capaz de transformar os diagramas resultantes em texto estruturado de forma lógica. Há também guias e tutoriais gratuitos disponíveis no site sobre pensamento crítico e mapeamento de argumentos.





Figura 2. Mapa de argumentos desenvolvido com o serviçoRacional



Como você pode ver, tudo é bastante transparente, existem apenas quatro entidades e três tipos de relacionamento entre elas. O resultado da entrada lógica é chamado de Contenção, confirmando o argumento - Razão (conexão porque), contra-argumento - Objeção (conexão, mas), mas o contra-argumento para o contra-argumento tem um nome especial - Réplica (conexão, entretanto).



Atualmente, não há notação geralmente aceita para construir mapas de argumento. Não há uniformidade na notação usada para a estrutura dos argumentos. Por exemplo, o resultado da inferência pode ser chamado de afirmação, contenção, conclusão, objetivo. Os argumentos podem ser chamados de premissa, justificativa, etc. Há uma série de iniciativas e comunidades internacionais na área de modelagem de argumento (por exemplo, Argument Interchange Format, AIF), mas eles não resolveram as questões da unificação. Existem pesquisas que traçam paralelos entre mapas de argumento e mapas mentais (Mind Map, provavelmente todo mundo já ouviu falar deles). Na verdade, os recursos dos editores do Mind Map permitem que você construa um análogo do mapa de argumento.



Conceito e história do caso de garantia



O que tudo isso tem a ver com segurança? Para responder a essa pergunta, vamos nos voltar para a segunda metade do século XX, onde se originam a teoria e a prática modernas de garantir a segurança. Então, como resultado do desenvolvimento de indústrias tecnogênicas complexas, como energia nuclear, tecnologia espacial, petróleo e gás e indústrias químicas, transportes, a humanidade enfrentou desastres causados ​​pelo homem em escala sem precedentes.



Em seguida, apareceram os primeiros relatórios de análise de segurança, que reuniram todos os requisitos relevantes, bem como informações que confirmam sua conformidade. Posteriormente, surgiu o termo Safety Case (na verdade, um relatório analítico sobre segurança), que foi o antecessor do Assurance Case. Observe que os termos "Caso de segurança" ou "Caso de garantia" não podem ser traduzidos diretamente para o russo; neste contexto, a tradução mais lógica é "caso de segurança". Embora, por exemplo, nas traduções russas da série de padrões ISO / IEC 15026 (Engenharia de sistemas e software - garantia de sistemas e software), "Caso de garantia" seja traduzido como "caso de garantia".



Deve-se observar que em alguns setores o termo Caso de Segurança ainda é usado, junto com o Caso de Garantia. Caso de Garantia, por ser um termo mais moderno, é contrastado com Caso de Segurança no sentido de que hoje o sistema deve atender não só à segurança (segurança funcional), mas também à segurança (segurança da informação). Portanto, propõe-se utilizar o conceito de Caso de Garantia e considerar o Caso de Segurança como um caso especial.



Caso de Garantia, no sentido moderno deste termo, significa um relatório sobre a análise de segurança realizada, incluindo uma representação visual na forma de um gráfico ou tabela, obtida por meio de notações semiformais (as notações serão discutidas a seguir). Ao mesmo tempo, obtém-se alguma discrepância do mesmo termo, uma vez que é possível interpretar o Caso de Garantia, por um lado, como um documento (relatório de análise de segurança ou relatório de caso de segurança), e, por outro lado, como um sistema de argumentação em notação semiformal ... Idealmente, um Caso de Garantia pode incluir ambos os componentes, ou seja, o documento de avaliação de segurança é construído com base em um modelo de argumento.



Voltemos, porém, ao século XX. O primeiro documento regulamentar exigindo o desenvolvimento e a análise de um Caso de Segurança para instalações industriais potencialmente perigosas foi o CIMAH (Controle de Riscos de Acidentes Industriais Maiores), originalmente emitido no Reino Unido em 1984 e depois adaptado em vários outros países. A implementação mais ampla do Plano de Segurança em prática começou após o acidente sem precedentes na plataforma de petróleo Piper Alpha no Mar do Norte, que matou 167 pessoas em 1988.



Na década de 1990, os pesquisadores continuaram a buscar novas abordagens para avaliar a segurança. A ideia parece estar na superfície: vamos desenvolver uma notação especial para justificar a conformidade de objetos e sistemas feitos pelo homem com os requisitos de segurança. Duas equipes de universidades britânicas assumiram o controle, a Universidade de Londres, onde a empresa spin-off Adelard foi formada, e a Universidade de York. Devo dizer que hoje Adelard e a University of York ocupam posições de liderança na promoção de Caso de Garantia.



Para desenvolver as notações, a ênfase foi colocada no raciocínio lógico de que uma propriedade ou componente do sistema atende aos requisitos declarados. As obras de Stephen Tulmin, que já examinamos, foram escolhidas como base teórica. Como um humanista, Toulmin dificilmente pensava em sistemas feitos pelo homem, no entanto, ele entrou para a história, entre outras coisas, como o fundador da argumentação para o Caso de Garantia.



Tomando a notação de Toulmin como base, os britânicos logo desenvolveram a metodologia de Caso de Garantia (chamada de Caso de Segurança na época) e trouxeram os resultados para implementações industriais práticas. Na University of York, o Goal Structuring Notation (GSN) foi desenvolvido e promovido pelo estudante de doutorado Tim Kelly sob a orientação do Professor John McDermid. Como resultado, houve aquele caso raro em que a dissertaçãoArgumentando sobre segurança: uma abordagem sistemática para gerenciar casos de segurança. Tese de doutorado. University of York, 1998 ” foi considerada um clássico por mais de 20 anos e continua a ser ativamente citada. No entanto, a abordagem para resolver o problema de segurança foi, na minha opinião, mais acadêmica e, como resultado, por algum motivo, uma etapa aparentemente compreensível e lógica não foi tomada relacionada ao desenvolvimento de uma ferramenta de software para suportar o Assurance Case.



Em contraste, Adelard, liderado por Robin Bloomfield e Peter Bishop, estava principalmente preocupado em comercializar os resultados. Em paralelo com York, a notação Claim, Argument and Evidence (CAE) foi desenvolvida em Londres, bem como a ferramenta de software Adelard ASCE(Assurance and Safety Case Environment), que suporta CAE e GSN. No Reino Unido, o desenvolvimento de um Caso de Garantia (Caso de Segurança) é exigido por leis e padrões em muitas áreas relacionadas à segurança, portanto, a ASCE tem um mercado bastante forte aqui. ASCE foi e continua sendo a ferramenta de desenvolvimento de casos de garantia mais usada. A parte principal da ferramenta é um editor gráfico, no qual informações adicionais de texto ou hiperlink podem ser anexadas a blocos gráficos (Figura 3). Você não pode baixar o software ASCE do site da Adelard por conta própria. Você deve preencher uma solicitação para um teste de 30 dias ou licença acadêmica, após o qual a solicitação será analisada pela empresa.





Figura 3. A interface do programa Adelard ASCE



Agora vamos dar uma olhada nas duas notações básicas usadas para desenvolver um Caso de Garantia (CAE e GSN).



Notação CAE (Reivindicação, Argumento e Evidência)



A notação CAE (Reivindicação, Argumento e Evidência) opera com três entidades especificadas: os objetivos indicam a realização das propriedades necessárias do sistema, as confirmações fornecem uma base documentada para a argumentação que demonstra o cumprimento ou não dos objetivos, os argumentos são construídos usando regras de inferência e link confirmação com propósitos. Argumentos como determinístico (ou lógico), probabilístico e qualitativo são comumente usados. Para designar objetivos, argumentos e evidências, são introduzidos primitivos gráficos que possuem várias formas (Figura 4).



Figura 4. Notação de reivindicação, argumento e evidência (CAE): componentes principais



Construir uma hierarquia de metas e submetas é a primeira etapa no desenvolvimento de um Caso de garantia. Conforme mostrado no diagrama, a estrutura de objetivos, argumentos e asserções não é necessariamente em três camadas, por exemplo, submetas adicionais podem ser usadas para apoiar a argumentação. A notação CAE também é facilmente transformada em forma tabular. As colunas de tal tabela serão todos os mesmos alvos, argumentos e confirmações, entre os quais os links serão agora estabelecidos dentro dos registros da tabela. Uma abordagem semelhante para o desenvolvimento de um caso de garantia é usada, por exemplo, por exida .



GSN (notação de estruturação de metas)



GSN opera com tais componentes como um objetivo (um objetivo, denotado por um retângulo e é um análogo de uma afirmação em CAE), uma estratégia de argumentação (uma estratégia, denotada por um paralelogramo, e é um análogo do argumento) e uma solução (denotada por um círculo e é análogo à evidência) (Figura 5). O contexto é usado para suporte de informações de metas. Suposições e justificativas podem ser usadas para apoiar o argumento. A estrutura de objetivos é hierárquica.





Figura 5. Notação de Estruturação de Objetivo (GSN): componentes principais



Ao comparar CAE e GSN, deve-se notar que CAE presta mais atenção à justificativa para argumentos individuais. Para isso, é realizado um desenho detalhado das etapas da argumentação. GSN se concentra mais em estruturas de argumento genéricas (padrões). Devido ao maior número de entidades, o GSN é menos estrito e, ao mesmo tempo, com uma descrição mais concisa, pode ser reduzido a CAE. O uso de cada uma das notações pode ser bastante subjetivo, visto que a abordagem para a construção dos argumentos depende de quem realiza essa tarefa. Alguns profissionais do Caso de Garantia observam que há uma série de lacunas nas notações associadas à integridade da definição de elementos semânticos.



Aconteceu que hoje o GSN é mais comum. Formato GSN fixado no padrãoGoal Structuring Notation (GSN) Community Standard , bem como o modelo de dados Structured Assurance Case Metamodel (SACM) do Object Management Group (OMG).



Base de conhecimento: indústrias, padrões, pesquisa, ferramentas, notações alternativas



A Caixa de Garantia é usada principalmente nos setores em que seu uso é regulamentado por documentos regulamentares. O líder aqui é a Grã-Bretanha e alguns outros países da Comunidade Britânica. O relatório da UK Health Foundation usando casos de segurança na indústria e saúde (2012) descreve a experiência regulatória do Caso de Garantia (Caso de Segurança) nas indústrias de saúde, aviação, energia nuclear, automotiva, defesa, petroquímica e ferroviária.



Considerando os requisitos para a aplicação de um Caso de Garantia fora do Reino Unido, deve-se observar:

  • norma automotiva ISO 26262: 2011, Veículos rodoviários - Segurança funcional, parte da família de padrões de segurança funcional detalhando os requisitos da 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”, (, , , , , , , , );
  • normas da série ISO / IEC 15026, Engenharia de sistemas e software - garantia de sistemas e software, que inclui quatro partes: Parte 1: Conceitos e vocabulário (2019); Parte 2: Caso de garantia (2011); Parte 3: Níveis de integridade do sistema (2015); Parte 4: Garantia no ciclo de vida (2012).



Também digno de nota é uma série de organizações (além da já mencionada Adelard e do Grupo de Engenharia de Sistemas de Alta Integridade da Universidade de York) que estão trabalhando ativamente na área de Casos de Garantia. Esses incluem:



Adelard ASCE (Case Case and Safety Case Environment) continua a ser o software de suporte Assurance Case mais conhecido . A maioria dos projetos mencionados em anos diferentes não atingiu um nível sério. A NASA anunciou a criação do software AdvoCATE , mas eles o usam para seus próprios fins e não planejam lançá-lo no mercado. Dada a simplicidade da notação, você pode usar, por exemplo, o MS Visio para desenhar diagramas de Caso de garantia e complementá-los com hiperlinks.



Abordagens alternativas para desenvolver Caso de Garantia incluem a ferramenta de software NOR-STA... Seria desenvolvido pela empresa polonesa Argevide (spinoff da Universidade de Tecnologia de Gdansk). NOR-STA suporta sua própria notação TRUST-IT. A diferença é que em vez de uma representação gráfica, o NOR-STA usa uma lista hierárquica estruturada (Figura 6).







Figura 6. Notação Trust-IT: Componentes Principais e Exemplo de Uso



Entidades na lista hierárquica de objetivos de Caso de Garantia são denotados por ícones diferentes. Uma estratégia de argumentação é usada para confirmar a conformidade com uma declaração, e fatos ou observações, justificativas, suposições e declarações adicionais são usados ​​como um análogo de evidência. Ao contrário do Adelard ASCE para desktop, o NOR-STA é usado online e oferece suporte ao trabalho em equipe distribuído.



Além disso, o Caso de Garantia é usado para resolver as seguintes aplicações:

  • avaliação de atributos de propriedades complexas, como Qualidade, Confiabilidade, Segurança;
  • apoiar a certificação e padronização, transformando os requisitos dos padrões em uma estrutura de argumento;
  • Desenvolvimento Baseado em Garantia (ABD) ou desenvolvimento de produto baseado em garantia é uma forma de Desenvolvimento Baseado em Modelo (MBD);
  • gestão do conhecimento, por exemplo, modelando a estrutura da documentação ou determinando os vínculos estruturais em qualquer área de atividade (processos de negócios, workflows, gestão de mudanças, etc.).


Caso de garantia para segurança da informação



Caso de segurança (confiabilidade) é conhecido como uma das variedades de caso de garantia. Se necessário, o Caso de Segurança pode ser complementado com componentes do Caso de Segurança. Na verdade, a ideia por trás do Caso de Garantia é combinar os atributos de proteção e segurança. Na área de certificação, há desenvolvimentos para a norma ISO / IEC 15408 (Critérios Gerais), para a qual os requisitos foram convertidos para uma estrutura compatível com a estrutura do Caso de Garantia. Essa conversão pode ser feita para outros padrões relevantes, como ISO 27000 ou IEC 62443 ou qualquer outra estrutura.



Um exemplo é o snippet de casos de garantia de segurançapostado no site US-CERT. Este snippet analisa a prova de implementação do Software Development Life Cycle (SDLC). O foco está na eliminação de defeitos de codificação (em particular Buffer Overflow), para os quais métodos como treinamento de programadores, revisões de código, análise estática e testes são usados. Pode-se, é claro, argumentar sobre a integridade desse fragmento, mas ele é dado apenas como ilustração (Figura 7).





Figura 7. Fragmento de Casos de Garantia de Segurança



Assim, embora a segurança da informação seja a aplicação onde o Caso de Garantia poderia ser mais procurado, deve-se notar que, apesar de seu potencial e de uma série de estudos piloto, o Caso de Garantia não se tornou uma prática bem conhecida nesta área.



Caso de garantia de estudo de caso



Finalmente, vamos ver um exemplo de como isso pode funcionar. Baseia-se em uma abordagem baseada no desenvolvimento de argumentos estruturados .



Argumentos estruturados



Vamos imaginar o processo de desenvolvimento de argumentos em duas etapas sequenciais (Figura 8). A primeira etapa, denominada Etapa de Raciocínio (RS), é a análise das submetas (SC), que visam atingir o objetivo principal (C). Nesta etapa, a estrutura da argumentação se desenvolve. Na segunda etapa, chamada de Etapa de Prova (ES), as confirmações (Evidece, E) são formuladas em apoio às subobjetivas (SC) geradas na etapa anterior. Para formalizar ainda mais as etapas RS e ES, modelos típicos de Texto Estruturado (ST) são usados.





Figura 8. Etapas e componentes de argumentos estruturados



Hierarquia de requisitos



Imagine uma hierarquia ou pirâmide de requisitos que formam uma estrutura que corresponde à coluna Caso de garantia. A maioria dos requisitos regulamentares para sistemas de computador ou software tem uma estrutura de requisitos de 3 ou 4 níveis (Figura 9).





Figura 9. Hierarquia de requisitos e sua relação com as etapas de argumentação O



nível zero é uma meta-meta, segundo a qual o sistema avaliado deve atender a todos os requisitos de segurança. No primeiro nível, os objetivos globais de segurança são alcançados, por exemplo, os seguintes objetivos seguem os requisitos IEC 61508 para segurança funcional:

  • um sistema de gerenciamento de segurança deve ser implementado;
  • durante o desenvolvimento do sistema (ou software), o ciclo de vida da segurança deve ser aplicado;
  • um conjunto suficiente de medidas para proteção contra falhas acidentais deve ser aplicado ao sistema;
  • para o sistema (ou software), um conjunto suficiente de medidas deve ser aplicado para proteção contra falhas sistemáticas e de software, incluindo proteção contra ataques cibernéticos.


No segundo nível, os grupos de requisitos oferecem suporte a uma meta global específica. Por exemplo, requisitos de gerenciamento de segurança(de acordo com IEC 61508) incluem grupos de requisitos para gerenciamento de pessoal, gerenciamento de configuração, gerenciamento de documentos e outros. A estrutura de links entre o zero, primeiro e segundo níveis é uma árvore bastante simples. Essa estrutura não requer uma elaboração detalhada dos argumentos, uma vez que esses argumentos são típicos e foram repetidamente testados em vários projetos. No entanto, ao passar do segundo nível para os inferiores, são necessários argumentos estruturados. Nesse caso, os requisitos dos níveis inferiores podem ser compostos (ou seja, incluir uma série de requisitos separados) ou simples (atômicos). Se todos os requisitos forem atômicos (não há requisitos compostos), esse nível passa a ser o terceiro e está diretamente relacionado aos subgrupos de requisitos. Se houver requisitos compostos, obteremos uma estrutura de quatro níveis mais complexa.



Para o nível mais baixo, além do RS, o ES também deve ser aplicado. Por ser inconveniente adicionar informações detalhadas sobre o conteúdo dos argumentos à estrutura do grafo, cada um dos nós do grafo Caso de Garantia, a partir do segundo nível, é marcado com uma descrição dos argumentos em texto estruturado (ST). O gráfico do Caso de garantia no nível inferior não é mais uma árvore, porque a mesma confirmação (E) pode suportar diferentes subobjetivos (SC).



Caso de garantia para um grupo de requisitos de RH (IEC 61508)



Como ilustração, considere o fragmento do Caso de Garantia em relação aos requisitos de RH IEC 61508 ( IEC 61508-1 cláusula 6 ).



Texto estruturado que descreve e combina etapas de raciocínio (RS) para todos os requisitos relevantes
Reasoning Step (Human Resource Management)

Context

Connection between the group of Human Resource Management requirements of the Assurance Case Level 2 and composite and separate requirements of Level 3

Docs

Human Resource Management Plan

Claim

Human Resource Management complies with IEC 61508 requirements

Subclaim SC1 (IEC 61508-1, 6.2.1), SEPARATE

Persons responsible for specific activities shall be appointed

Subclaim SC2 (IEC 61508-1, 6.2.3), SEPARATE

Project participants shall understand their roles and responsibilities

Subclaim SC3 (IEC 61508-1, 6.2.4), SEPARATE

Communications of the project participants shall be defined

Subclaim SC4 (IEC 61508-1, 6.2.13), SEPARATE

Evaluation and assurance of the project participants’ competencies shall be performed

Subclaim SC5 (IEC 61508-1, 6.2.14a,…,k), COMPOSITE

Competencies shall be considered in relation to the particular application, taking into account all relevant factors

Subclaim SC6 (IEC 61508-1, 6.2.15), SEPARATE

Competencies of all responsible persons shall be documented

Subclaim SC7 (IEC 61508-1, 6.2.16), SEPARATE

Human resource management activities shall be implemented and monitored

Justification

Structure and content of the Human Resource Management Plan

END Reasoning Step



Um total de sete requisitos de gerenciamento de pessoal foram extraídos da IEC 61508. Do ponto de vista da argumentação estruturada, esses requisitos são subobjetivos (SC1, ..., SC7). Apenas um dos subobjetivos (SC5) é composto, todos os outros são atômicos. Para passar de um subobjetivo composto (SC5) para o atômico (SC5.1, ..., SC5.11), é realizada mais uma etapa de raciocínio (RS). Entende-se que de acordo com os requisitos da IEC 61508, um Plano de Gestão de Recursos Humanos foi desenvolvido para um projeto relacionado à criação de um produto abstrato. Este plano interpreta os requisitos da norma no contexto do projeto.



Texto Estruturado para Etapas de Confirmação (ES)
Evidential Step ES1,…,ES6

Context

Connection with the subclaims of the Levels 3 and the Level 4

Docs

Human Resource Management Plan; Communications Plan; Training Plans; Training Reports

Claim

SC1,…, SC7

Evidence E1

Organizational Chart

Evidence E2

Project Roles Description

Evidence E3

Participants and Signature List

Evidence E4

Participants Communications Plan

Evidence E5

Competency Matrix

Evidence E6

Training Plans and Reports

Claim -> Evidence

SC1 -> E1&E2; SC2 -> E3; SC3 -> E4; SC4 -> E5&E6; SC5 -> E5&E6; SC6 -> E5&E6; SC7 -> E1&E2

Justification

Structure and content of E1,…,E6

END Evidential Step



Para todas as etapas de confirmação (ES), é proposto o uso de um texto estruturado comum indicando as ligações entre os sub-objetivos (SG) das confirmações (E). Usaremos a relação SG -> E para denotar a relação entre o subobjetivo correspondente (SG) e as confirmações (E) que o suportam.



Análise de requisitos compostos SC5
S5 . , (ES). , (RS) (ES). .







«» (RS), , , (ES).



Todas as relações SG -> E obtidas podem ser transformadas em uma coluna Caso de Garantia, de acordo com a notação GSN, modificada para argumentação estruturada (Figura 10). Este gráfico reflete todo o grupo de requisitos relacionados à gestão de pessoal de acordo com a IEC 61508. Este gráfico também pode ser usado como um modelo para avaliar a conformidade com os requisitos da IEC 61508.





Figura 10. Gráfico de caso de garantia derivado de argumentos estruturados para o grupo de requisitos de RH (IEC 61508)



À primeira vista, tudo isso é longo e difícil, mas, mesmo assim, o Caso de Garantia tem sua aplicação prática. Esta é a abordagem que usamos ao certificar o PLC RdICS para conformidade com IEC 61508 .



Conclusão



O método Assurance Case (Safety Case) tem sido usado por mais de 20 anos para analisar a segurança das instalações CII. Este método é mais amplamente utilizado no Reino Unido e em vários países da Comunidade Britânica para indústrias como saúde, aviação, energia nuclear, automotiva, defesa, petroquímica e ferroviária.



As vantagens do Caso de Garantia incluem todas as vantagens alcançadas ao visualizar relacionamentos em uma área de assunto complexa, melhorando nossa percepção e compreensão. As desvantagens devem-se à subjetividade do método em termos de sua dependência da experiência das pessoas que realizam a avaliação. A "falha épica" mais famosa no aplicativo Assurance Case é descrita aqui... Resumindo: em 2 de setembro de 2006, um incêndio eclodiu no Afeganistão a bordo de um Nimrod da Força Aérea Britânica. O problema surgiu de um vazamento de combustível. Todas as 14 pessoas a bordo morreram. Um relatório de caso de segurança anterior confirmou a segurança da aeronave. A investigação mostrou que a modificação do sistema de combustível não era totalmente correta em aeronaves de produção, e problemas semelhantes surgiram antes, mas por algum motivo ninguém prestou atenção a eles como um erro do sistema. No relatório de 600 páginas divulgado, este incidente foi nomeado nada mais do que "uma falha de liderança, cultura e prioridades."



A propósito, notações gráficas não foram usadas no relatório do Nimrod. Uma das consequências dessa catástrofe foi o aprofundamento das pesquisas na área de construção da argumentação. No entanto, não foi desenvolvida uma abordagem geral que satisfaça a todos.



Hoje, o principal motivador da implementação do Caso de Garantia são os requisitos regulamentares e legais, não a conveniência, viabilidade ou custo-benefício. Obviamente, existem grandes oportunidades para inteligência artificial na área de Caso de Garantia, mas de alguma forma não encontrei publicações sobre esse assunto.

No entanto, o problema associado à avaliação da segurança de sistemas complexos permanece aberto. É possível que algum progresso nesta área possa ser alcançado com a implementação ativa do Caso de Garantia, porque este método é baseado em todos aqueles pontos importantes que ocuparam a humanidade desde o início da pesquisa filosófica.



All Articles