Assurance Case: un dossier de sécurité raisonné

source



Quelle est la meilleure façon d'évaluer la sécurité et de ne rien manquer? Est-il possible de rassembler toute la variété des artefacts de sécurité dans un seul document (ou diagramme) et de les organiser de telle manière que n'importe quel aspect puisse être visualisé avec un niveau de détail compréhensible?



Les techniciens seraient heureux d'inventer une telle «pierre philosophale» que, même si elle n'apportait pas de sécurité, au moins l'évaluerait avec le niveau d'exhaustivité requis. De tels développements existent depuis plus de 20 ans, cependant, ils sont pratiquement inconnus du lecteur russophone. Il s'agira de la méthodologie du dossier d'assurance (ou dossier de sécurité), qui signifie un ensemble structuré d'arguments et de preuves documentaires justifiant la conformité d'un système ou d'un service aux exigences spécifiées.

introduction

Avant de lire l'article, je voudrais attirer votre attention sur quelques points importants. Le matériel indiqué est applicable, tout d'abord, pour les objets de l'infrastructure d'information critique (CII). Pour de tels objets, en particulier pour les systèmes d'information et de contrôle, une analyse de sécurité doit être réalisée. Les résultats de l'analyse de sûreté sont présentés sous la forme de rapports appropriés. Tout cela a été fait pendant des décennies, cependant, les rapports, en règle générale, ont une forme de texte arbitraire, dont la logique n'est pas toujours facile à comprendre.



L'idée principale de l'approche présentée est que les résultats de l'analyse de sécurité peuvent être présentés sous forme graphique à l'aide de notations semi-formelles, avec tous les avantages qui en découlent. Ainsi, le cas d'assurance est un moyen de présentation intégrée de toutes les mesures visant à garantir et à évaluer la sécurité, sans remplacer ni annuler des méthodes privées telles que, par exemple, les tests, l'analyse de code statique, le calcul de fiabilité, l'AMDE, l'analyse des risques, etc. Cet article continue la série de sécurité publiée précédemment .

Cartes d'arguments et leurs origines philosophiques

Comment pouvons-nous comprendre ou affirmer qu'un objet est sûr? Evidemment, un certain nombre de critères doivent être introduits pour cela. Cependant, pour ces critères, nous devons déterminer la fiabilité de nos connaissances sur l'objet? Pourquoi pouvons-nous faire confiance à ces connaissances? Qu'est-ce qui rend nos arguments et notre raisonnement vraiment crédibles? Après avoir fouillé de tels problèmes, on ne peut se passer de disciplines philosophiques telles que l'ontologie, l'épistémologie, l'épistémologie, la logique, et aussi, sans de grands penseurs qui s'inquiètent de ces questions. Dans le monde antique, tels étaient Aristote et Platon, et à l'ère des «temps modernes», Francis Bacon est considéré comme le fondateur de la méthode scientifique moderne.



Que peut-on faire pour justifier ou évaluer la sécurité d'une manière raisonnable et logique? Cette approche est basée sur la théorie de l'argumentation. Un nouvel élan au développement moderne de l'argumentation a été donné dans l'ouvrage du philosophe britannique Stephen Toulmin intitulé «The Uses of Argument», publié en 1958. Tulmin a étendu l'inférence logique implicative avec des paramètres supplémentaires et a proposé de représenter cette opération sous forme graphique. La notation de Tulmin fonctionne avec les entités suivantes: data (D) - données initiales pour l'analyse, revendication () - le but de l'inférence d'implication logique (If D So C), warrant (W) - un argument supplémentaire, qualificatif (Q) - le degré de confiance dans les résultats de la logique la sortie, réfutable (R) est un contre-argument supplémentaire (Figure 1).





Figure 1. Notation par Stephen Tulmin



Cartes d'arguments ou d'arguments ( Argument the Map ) utilisées à des fins de visualisation et de raisonnement à Toulmin, mais c'est lui qui a le plus réussi à résumer le modèle structurel pour l'analyse et la vérification des arguments. Notez que les cartes d'arguments modernes, en règle générale, n'utilisent pas la notation de Tulmin, tout est simplifié, par exemple, comme dans la figure ci-dessous. Il s'agit de la notation utilisée par le service en ligne payant Rational (il existe une version gratuite, mais ses fonctionnalités sont extrêmement limitées) (Figure 2). La version payante est capable de transformer les diagrammes résultants en texte structuré logiquement. Il existe également des guides et des tutoriels gratuits disponibles sur le site sur la pensée critique et la cartographie des arguments.





Figure 2. Une carte d'arguments développée avec le serviceRationnel



Comme vous pouvez le voir, tout est assez transparent, il n'y a que quatre entités et trois types de relations entre elles. Le résultat de l'entrée logique est appelé Contention, confirmant que l'argument est Raison (la relation parce que), le contre-argument est Objection (la relation mais), mais le contre-argument pour le contre-argument a un nom spécial - Réfutation (la relation cependant).



Il n'existe actuellement aucune notation généralement acceptée pour la construction de mappages d'arguments. Il n'y a pas d'uniformité dans la notation utilisée pour la structure des arguments. Par exemple, le résultat de l'inférence peut être appelé revendication, contention, conclusion, objectif. Les arguments peuvent être appelés prémisse, justification, etc. Il existe un certain nombre d'initiatives et de communautés internationales dans le domaine de la modélisation des arguments (par exemple, Argument Interchange Format, AIF), mais ils n'ont pas résolu les questions de l'unification. Il existe des recherches qui établissent des parallèles entre les cartes argumentatives et les cartes mentales (Mind Map, tout le monde en a probablement entendu parler). En effet, les capacités des éditeurs de Mind Map vous permettent de construire un analogue de l'argument map.

Histoire et concept du cas d'assurance

Qu'est-ce que tout cela a à voir avec la sécurité? Pour répondre à cette question, tournons-nous vers la seconde moitié du XXe siècle, d'où proviennent la théorie et la pratique modernes de la sécurité. Puis, du fait du développement d'industries technogéniques complexes, telles que l'énergie nucléaire, la technologie spatiale, les industries pétrolière et gazière et chimique, les transports, l'humanité a été confrontée à des catastrophes d'origine humaine d'une ampleur sans précédent.



Puis sont apparus les premiers rapports d'analyse de sûreté, regroupant toutes les exigences pertinentes, ainsi que des informations confirmant leur conformité. Plus tard, le terme Safety Case (en fait, un rapport analytique sur la sécurité) est apparu, qui était le prédécesseur de l'Assurance Case. Notez que les termes «dossier de sécurité» ou «dossier d'assurance» ne peuvent pas être traduits directement en russe; dans ce contexte, la traduction la plus logique est «dossier de sécurité». Bien que, par exemple, dans les traductions russes de la série de normes ISO / CEI 15026 (Ingénierie des systèmes et du logiciel - Assurance des systèmes et des logiciels), «cas d'assurance» est traduit par «cas de garantie».



Il convient de noter que dans certaines industries, le terme «dossier de sécurité» est encore utilisé, avec le dossier d'assurance. Assurance Case, étant un terme plus moderne, s'oppose à Safety Case en ce sens qu'aujourd'hui le système doit respecter non seulement la sécurité (sécurité fonctionnelle), mais aussi la sécurité (sécurité de l'information). Par conséquent, il est proposé d'utiliser le concept de cas d'assurance et de considérer le cas de sécurité comme un cas particulier.



Cas d'assurance, au sens moderne de ce terme, signifie un rapport sur l'analyse de sûreté effectuée, comprenant une représentation visuelle sous forme de graphique ou de tableau, obtenue à l'aide de notations semi-formelles (les notations seront discutées ci-dessous). Dans le même temps, une certaine divergence du même terme est obtenue, car il est possible d'interpréter le cas d'assurance, d'une part, comme un document (rapport d'analyse de sûreté ou rapport de justification de sûreté), et, d'autre part, comme système d'argumentation utilisant la notation semi-formelle ... Idéalement, un dossier d'assurance peut inclure les deux composants, c'est-à-dire que le document évaluant la sécurité est construit sur la base d'un modèle d'argument.



Revenons cependant au vingtième siècle. Le premier document réglementaire exigeant l'élaboration et l'analyse d'un dossier de sécurité pour les installations industrielles potentiellement dangereuses était le règlement CIMAH (Contrôle des risques d'accidents majeurs industriels), initialement publié au Royaume-Uni en 1984 puis adapté dans plusieurs autres pays. La mise en œuvre plus large du dossier de sécurité a commencé après l'accident sans précédent survenu sur la plate-forme pétrolière Piper Alpha en mer du Nord, qui a tué 167 personnes en 1988.



Dans les années 90, les chercheurs continuent de rechercher de nouvelles approches pour évaluer la sécurité. L'idée semble être à la surface: développons une notation spéciale pour justifier la conformité des objets et des systèmes fabriqués par l'homme aux exigences de sécurité. Deux équipes universitaires britanniques ont pris le relais, l'Université de Londres, où la société dérivée Adelard a été créée, et l'Université de York. Je dois dire qu'aujourd'hui Adelard et l'Université de York occupent des positions de premier plan dans la promotion de Assurance Case.



Pour développer les notations, l'accent a été mis sur le raisonnement logique selon lequel une propriété ou un composant du système répond aux exigences énoncées. Les travaux de Stephen Toulmin, que nous avons déjà considérés, ont été choisis comme base théorique. En tant qu'humanitaire, Toulmin ne pensait guère aux systèmes créés par l'homme, mais il est entré dans l'histoire, entre autres, en tant que fondateur de l'argumentation pour le cas d'assurance.



Prenant la notation de Toulmin comme base, les Britanniques ont rapidement développé la méthodologie Assurance Case (appelée à l'époque Safety Case) et ont apporté les résultats à des implémentations industrielles pratiques. À l'Université de York, la notation de structuration des objectifs (GSN) a été développée et promue par le doctorant Tim Kelly sous la direction du professeur John McDermid. En conséquence, il y a eu ce cas rare où la thèseArgumenter en matière de sécurité: une approche systématique de la gestion des dossiers de sécurité. Thèse de doctorat. University of York, 1998 » est considérée comme un classique depuis plus de 20 ans et elle continue d'être activement citée. Cependant, l'approche pour résoudre le problème de sécurité était, à mon avis, plus académique et, par conséquent, pour une raison quelconque, une étape apparemment compréhensible et logique n'a pas été prise en relation avec le développement d'un outil logiciel pour soutenir Assurance Case.



En revanche, Adelard, dirigé par Robin Bloomfield et Peter Bishop, était principalement préoccupé par la commercialisation des résultats. Parallèlement à York, la notation Claim, Argument and Evidence (CAE) a été développée à Londres, ainsi que l'outil logiciel Adelard ASCE(Assurance and Safety Case Environment), qui prend en charge à la fois CAE et GSN. Au Royaume-Uni, le développement d'un dossier d'assurance (dossier de sécurité) est requis par les lois et les normes dans de nombreux domaines liés à la sécurité, de sorte que l'ASCE dispose d'un marché assez fort ici. L'ASCE a été et reste l'outil de développement de cas d'assurance le plus utilisé. La partie principale de l'outil est un éditeur graphique, dans lequel des informations supplémentaires de texte ou d'hyperlien peuvent être associées à des blocs graphiques (Figure 3). Vous ne pouvez pas télécharger vous-même le logiciel ASCE depuis le site Web d'Adelard. Vous devez remplir une demande pour une licence d'essai ou universitaire de 30 jours, après quoi la demande sera examinée par l'entreprise.





Figure 3. L'interface du programme Adelard ASCE



Examinons maintenant les deux notations de base utilisées pour développer un cas d'assurance (CAE et GSN).

Notation CAE (Claim, Argument and Evidence)

La notation CAE (Claim, Argument and Evidence) fonctionne avec trois entités spécifiées: les objectifs indiquent la réalisation des propriétés requises du système, les confirmations fournissent une base documentée pour l'argumentation qui démontre la réalisation ou la non-réalisation des objectifs, les arguments sont construits à l'aide de règles d'inférence et se connectent confirmation avec des fins. Des arguments tels que déterministe (ou logique), probabiliste et qualitatif sont couramment utilisés. Pour désigner des objectifs, des arguments et des preuves, des primitives graphiques sont introduites qui ont différentes formes (Figure 4).



Figure 4. Notation des réclamations, arguments et preuves (CAE): principaux composants



La construction d'une hiérarchie d'objectifs et de sous-objectifs est la première étape de l'élaboration d'un dossier d'assurance. Comme le montre le diagramme, la structure des objectifs, des arguments et des assertions n'a pas besoin d'être à trois niveaux, par exemple, des sous-objectifs supplémentaires peuvent être utilisés pour soutenir l'argumentation. La notation CAE est également facilement transformée en forme tabulaire. Les colonnes d'une telle table seront toutes les mêmes cibles, arguments et confirmations, entre lesquels des liens seront désormais établis dans les enregistrements de la table. Une approche similaire pour l'élaboration d'un dossier d'assurance est utilisée, par exemple, par exida .

GSN (Notation de structuration des objectifs)

GSN fonctionne avec ces composants comme un objectif (un objectif, désigné par un rectangle et est un analogue d'une revendication dans CAE), une stratégie d'argumentation (une stratégie, désignée par un parallélogramme et est un analogue de l'argument) et une solution (désignée par un cercle et est analogue à la preuve) (Figure 5). Le contexte est utilisé pour le support d'information des objectifs. Des hypothèses et des justifications peuvent être utilisées pour étayer l'argument. La structure des objectifs est hiérarchique.





Figure 5. Notation de structuration des objectifs (GSN): principaux composants



Lorsqu'on compare CAE et GSN, il convient de noter que CAE accorde plus d'attention à la justification des arguments individuels. Pour cela, une conception détaillée des étapes d'argumentation est effectuée. GSN se concentre davantage sur les structures d'arguments génériques (modèles). En raison du plus grand nombre d'entités, GSN est moins strict et, en même temps, avec une description plus concise, il peut être réduit à CAE. L'utilisation de chacune des notations peut être assez subjective, car l'approche de construction des arguments dépend de la personne qui effectue cette tâche. Certains praticiens des cas d'assurance notent qu'il existe un certain nombre de lacunes dans les notations associées à l'exhaustivité de la définition des éléments sémantiques.



C'est arrivé de sorte qu'aujourd'hui GSN est plus courant. Format GSN fixé dans la normeNorme communautaire GSN (Goal Structuring Notation) , ainsi que le modèle de données Structured Assurance Case Metamodel (SACM) du Object Management Group (OMG).

Base de connaissances: industries, normes, recherche, outils, notations alternatives

Assurance Case est principalement utilisé dans les industries dans lesquelles son utilisation est réglementée par des documents réglementaires. Le chef de file ici est la Grande-Bretagne et certains autres pays du Commonwealth britannique. Le rapport de la UK Health Foundation , Using Safety Cases in Industry and Healthcare (2012), fait état de l'expérience réglementaire de l'Assurance Case (Safety Case) dans les secteurs de la santé, de l'aviation, de l'énergie nucléaire, de l'automobile, de la défense, de la pétrochimie et du rail.



Compte tenu des exigences relatives à l'application d'un dossier d'assurance en dehors du Royaume-Uni, il convient de noter:

• norme automobile ISO 26262: 2011, Véhicules routiers - Sécurité fonctionnelle, faisant partie de la famille des normes de sécurité fonctionnelle détaillant les exigences de la CEI 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”, (, , , , , , , , );
• normes de la série ISO / CEI 15026, Ingénierie des systèmes et du logiciel - Assurance des systèmes et des logiciels, qui comprend quatre parties: Partie 1: Concepts et vocabulaire (2019); Partie 2: Cas d'assurance (2011); Partie 3: Niveaux d'intégrité du système (2015); Partie 4: Assurance dans le cycle de vie (2012).
  
  

Il convient également de noter un certain nombre d'organisations (en plus de l'Adelard déjà mentionné et du High Integrity Systems Engineering Group de l'Université de York) qui travaillent activement dans le domaine des dossiers d'assurance. Ceux-ci inclus:

• US-CERT (United States Computer Emergency Readiness Team), ils appellent leur méthodologie Security Assurance Cases ;
• 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 and Safety Case Environment) reste le logiciel de support Assurance Case le plus connu . La plupart des projets mentionnés au cours des différentes années n'ont pas atteint un niveau sérieux. La NASA a annoncé la création du logiciel AdvoCATE , mais ils l'utilisent à leurs propres fins et ne prévoient pas de le commercialiser. Compte tenu de la simplicité de la notation, vous pouvez utiliser, par exemple, MS Visio pour créer des diagrammes de cas d'assurance et les compléter avec des hyperliens.



Les approches alternatives pour développer un dossier d'assurance incluent l'outil logiciel NOR-STA... Il serait développé par la société polonaise Argevide (spin-off de l'Université de technologie de Gdansk). NOR-STA prend en charge sa propre notation TRUST-IT. La différence est qu'au lieu d'une représentation graphique, NOR-STA utilise une liste hiérarchique structurée (Figure 6).







Figure 6. Notation Trust-IT: Composants principaux et exemples d'utilisation Les



entités de la liste hiérarchique des objectifs du dossier d'assurance sont identifiées par différentes icônes. Une stratégie d'argumentation est utilisée pour confirmer la conformité à une déclaration, et des faits ou des observations, des justifications, des hypothèses et des déclarations supplémentaires sont utilisés comme un analogue de la preuve. Contrairement au bureau Adelard ASCE, NOR-STA est utilisé en ligne et prend en charge le travail d'équipe distribué.



De plus, le cas d'assurance est utilisé pour résoudre les applications suivantes:

• évaluation des attributs de propriétés complexes, telles que la qualité, la fiabilité, la sécurité;
• soutenir la certification et la normalisation en transformant les exigences des normes en une structure argumentative;
• Le développement basé sur l'assurance (ABD) ou le développement de produit basé sur la garantie est une forme de développement basé sur un modèle (MBD);
• la gestion des connaissances, par exemple, modéliser la structure de la documentation ou déterminer les liens structurels dans tout domaine d'activité (processus métier, workflow, gestion du changement, etc.)

Cas d'assurance pour la sécurité de l'information

Le cas de sécurité (fiabilité) est connu comme l'une des variétés de cas d'assurance. Si nécessaire, le boîtier de sécurité peut être complété par des composants du boîtier de sécurité. En fait, l'idée derrière le cas d'assurance est de combiner les attributs de sûreté et de sécurité. Dans le domaine de la certification, il existe un historique de la norme ISO / CEI 15408 (Critères généraux), pour laquelle les exigences ont été converties en une structure compatible avec la structure du dossier d'assurance. Cette conversion peut être effectuée pour d'autres normes pertinentes, telles que ISO 27000 ou CEI 62443, ou tout autre cadre.



Un exemple est l' extrait de code Security Assurance Casespublié sur le site Web US-CERT. Cet extrait examine la preuve de la mise en œuvre du cycle de vie du développement logiciel (SDLC). L'accent est mis sur l'élimination des défauts de codage (en particulier Buffer Overflow), pour lesquels des méthodes telles que la formation des programmeurs, les révisions de code, l'analyse statique et les tests sont utilisées. On peut, bien entendu, argumenter sur l'exhaustivité de ce fragment, mais il n'est donné qu'à titre d'illustration (figure 7).





Figure 7. Fragment des cas d'assurance de la sécurité



Ainsi, bien que la sécurité de l'information soit l'application où le cas d'assurance pourrait être le plus demandé, il convient de noter que malgré son potentiel et un certain nombre d'études pilotes, le cas d'assurance n'est pas devenu une pratique courante dans ce domaine.

Étude de cas Cas d'assurance

Enfin, regardons un exemple de la façon dont cela peut fonctionner. Il repose sur une approche basée sur le développement d'arguments structurés .

Arguments structurés

Imaginons le processus de développement des arguments en deux étapes séquentielles (Figure 8). La première étape, appelée étape de raisonnement (RS), est l'analyse des sous-objectifs (SC), qui visent à atteindre l'objectif principal (C). A ce stade, la structure de l'argumentation se développe. Dans la deuxième étape, appelée étape de preuve (ES), des confirmations (Evidece, E) sont formulées à l'appui des sous-objectifs (SC) générés à l'étape précédente. Pour formaliser davantage les étapes RS et ES, des modèles de texte structuré (ST) typiques sont utilisés.





Figure 8. Étapes et composants des arguments structurés

Hiérarchie des exigences

Imaginez une hiérarchie ou une pyramide d'exigences qui forment une structure qui correspond à la colonne Cas d'assurance. La plupart des exigences réglementaires pour les systèmes informatiques ou les logiciels ont une structure d'exigences à 3 ou 4 niveaux (Figure 9).





Figure 9. La hiérarchie des exigences et sa relation avec les étapes de l'argumentation Le



niveau zéro est un méta-objectif, selon lequel le système évalué doit répondre à toutes les exigences de sécurité. Au premier niveau, les objectifs globaux de sécurité sont atteints, par exemple, les objectifs suivants découlent des exigences de la CEI 61508 pour la sécurité fonctionnelle:

• un système de gestion de la sécurité doit être mis en place;
• pendant le développement du système (ou du logiciel), le cycle de vie de la sécurité doit être appliqué;
• un ensemble suffisant de mesures de protection contre les pannes accidentelles doit être appliqué au système;
• pour le système (ou logiciel), un ensemble suffisant de mesures doit être appliqué pour se protéger contre les pannes systématiques et logicielles, y compris la protection contre les cyberattaques.

Au deuxième niveau, les groupes d'exigences soutiennent un objectif global particulier. Par exemple, les exigences de gestion de la sécurité(selon CEI 61508) comprennent des groupes d'exigences pour la gestion du personnel, la gestion de la configuration, la gestion des documents et autres. La structure des liens entre les niveaux zéro, premier et deuxième est un arbre assez simple. Cette structure n'exige pas une élaboration détaillée des arguments, car ces arguments sont typiques et ont été testés à plusieurs reprises dans divers projets. Cependant, lors du passage du deuxième niveau au niveau inférieur, des arguments structurés sont nécessaires. Dans ce cas, les exigences des niveaux inférieurs peuvent être composites (c'est-à-dire inclure un certain nombre d'exigences distinctes) ou simples (atomiques). Si toutes les exigences sont atomiques (il n'y a pas d'exigences composites), alors ce niveau devient le troisième, puis il est directement lié aux sous-groupes d'exigences. S'il y a des exigences composées, nous obtenons une structure à quatre niveaux plus complexe.



Pour le niveau le plus bas, outre RS, ES doit également être appliqué. Puisqu'il n'est pas pratique d'ajouter des informations détaillées sur le contenu des arguments à la structure du graphique, chacun des nœuds du graphe de cas d'assurance, à partir du deuxième niveau, est marqué d'une description des arguments en utilisant un texte structuré (ST). Le graphique de cas d'assurance de niveau inférieur n'est plus un arbre, car la même confirmation (E) peut prendre en charge différents sous-objectifs (SC).

Cas d'assurance pour un groupe d'exigences RH (CEI 61508)

À titre d'illustration, considérons l'extrait de cas d'assurance par rapport aux exigences CEI 61508 HR ( CEI 61508-1 clause 6 ).





Au total, sept exigences en matière de gestion du personnel ont été extraites de la CEI 61508. Du point de vue de l'argumentation structurée, ces exigences sont des sous-objectifs (SC1, ..., SC7). Un seul des sous-objectifs (SC5) est composite, tous les autres sont atomiques. Afin de passer d'un sous-objectif composite (SC5) à atomique (SC5.1, ..., SC5.11), une étape supplémentaire de raisonnement (RS) est effectuée. Il est entendu que, conformément aux exigences de la CEI 61508, un plan de gestion des ressources humaines a été élaboré pour un projet lié à la création d'un produit abstrait. Ce plan interprète les exigences de la norme dans le contexte du projet.





Pour toutes les étapes de confirmation (ES), il est proposé d'utiliser un texte structuré commun indiquant les liens entre les sous-objectifs (SG) des confirmations (E). Nous utiliserons la relation SG -> E pour désigner la relation entre le sous-but correspondant (SG) et les confirmations (E) qui le soutiennent.





Toutes les relations obtenues SG -> E peuvent être transformées en une colonne de cas d'assurance, selon la notation GSN modifiée pour l'argumentation structurée (Figure 10). Ce graphique reflète l'ensemble du groupe d'exigences liées à la gestion du personnel conformément à la norme CEI 61508. Ce graphique peut également être utilisé comme modèle pour évaluer la conformité aux exigences de la CEI 61508.





Figure 10. Graphique de cas d'assurance dérivé d'arguments structurés pour un groupe d'exigences RH (CEI 61508)



À première vue, tout cela est long et difficile, mais, néanmoins, le cas d'assurance a son application pratique. C'est l'approche que nous avons utilisée lors de la certification de l'automate RdICS pour sa conformité à la norme CEI 61508 .

Conclusion

La méthode Assurance Case (Safety Case) est utilisée depuis plus de 20 ans pour analyser la sûreté des installations CII. Cette méthode est la plus largement utilisée au Royaume-Uni et dans un certain nombre de pays du Commonwealth britannique pour des secteurs tels que la santé, l'aviation, l'énergie nucléaire, l'automobile, la défense, la pétrochimie et les chemins de fer.



Les avantages du cas d'assurance comprennent tous les avantages obtenus en visualisant les relations dans un domaine complexe, en améliorant notre perception et notre compréhension. Les inconvénients sont dus à la subjectivité de la méthode en termes de sa dépendance à l'expertise des personnes effectuant l'évaluation. Le "échec épique" le plus connu de l'application Assurance Case est décrit ici... En bref: le 2 septembre 2006, un incendie s'est déclaré en Afghanistan à bord d'un Nimrod de l'armée de l'air britannique. Le problème provenait d'une fuite de carburant. Les 14 personnes à bord ont été tuées. Un rapport de cas de sécurité antérieur a confirmé la sécurité de l'avion. L'enquête a montré que la modification du système d'alimentation en carburant n'était pas tout à fait correcte sur les avions de série et que des problèmes similaires étaient survenus auparavant, mais pour une raison quelconque, personne n'y a prêté attention comme une erreur du système. Dans le rapport de 600 pages publié, cet incident a été nommé rien de moins qu'un «échec du leadership, de la culture et des priorités».



À propos, les notations graphiques n'ont pas été utilisées dans le rapport de Nimrod. L'une des conséquences de cette catastrophe a été l'approfondissement de la recherche dans le domaine de la construction de l'argumentation. Cependant, une approche générale qui satisfait tout le monde n'a pas été développée.



Aujourd'hui, le principal moteur de la mise en œuvre des cas d'assurance est les exigences réglementaires et légales, et non la commodité, la faisabilité ou la rentabilité. De toute évidence, il existe de grandes opportunités pour l'intelligence artificielle dans le domaine de l'assurance Case, mais je n'ai pas rencontré de publications sur ce sujet.

Néanmoins, le problème associé à l'évaluation de la sécurité des systèmes complexes reste ouvert. Il est possible que des progrès dans ce domaine puissent être réalisés avec la mise en œuvre active du cas d'assurance, car cette méthode est basée sur tous ces points importants qui ont occupé l'humanité depuis le tout début de la recherche philosophique.