Assurance Case: Ein begründeter Sicherheitsfall

Quelle



Was ist der beste Weg, um die Sicherheit zu bewerten und nichts zu verpassen? Ist es möglich, alle Arten von Sicherheitsartefakten in einem Dokument (oder Diagramm) zu sammeln und so zu organisieren, dass jeder Aspekt mit einem verständlichen Detaillierungsgrad visualisiert werden kann?



Techniker würden gerne einen solchen "Stein der Weisen" erfinden, der, selbst wenn er keine Sicherheit bietet, ihn zumindest mit dem erforderlichen Grad an Vollständigkeit bewertet. Solche Entwicklungen gibt es seit über 20 Jahren, sie sind dem russischsprachigen Leser jedoch praktisch unbekannt. Es geht um die Assurance Case- (oder Safety Case-) Methodik, dh eine strukturierte Reihe von Argumenten und dokumentarischen Nachweisen, die die Konformität eines Systems oder einer Dienstleistung mit bestimmten Anforderungen rechtfertigen.

Einführung

Bevor ich den Artikel lese, möchte ich Sie auf einige wichtige Punkte aufmerksam machen. Das angegebene Material gilt zunächst für Objekte mit kritischer Informationsinfrastruktur (CII). Für solche Objekte, insbesondere für Informations- und Steuerungssysteme, muss eine Sicherheitsanalyse durchgeführt werden. Die Ergebnisse der Sicherheitsanalyse werden in Form entsprechender Berichte dargestellt. All dies geschieht seit Jahrzehnten, Berichte haben jedoch in der Regel eine willkürliche Textform, deren Logik nicht immer leicht zu verstehen ist.



Die Hauptidee des vorgestellten Ansatzes besteht darin, dass die Ergebnisse der Sicherheitsanalyse in grafischer Form unter Verwendung semiformaler Notationen mit allen sich daraus ergebenden Vorteilen dargestellt werden können. Somit ist der Assurance Case eine Möglichkeit einer integrierten Ansicht aller Maßnahmen zur Gewährleistung und Bewertung der Sicherheit, ohne private Methoden wie z. B. Tests, statische Code-Analyse, Zuverlässigkeitsberechnung, FMEA, Risikoanalyse usw. zu ersetzen oder abzubrechen. Dieser Artikel setzt die zuvor veröffentlichte Sicherheitsreihe fort .

Argumentkarten und ihre philosophischen Ursprünge

Wie können wir verstehen oder behaupten, dass ein Objekt sicher ist? Natürlich müssen hierfür eine Reihe von Kriterien eingeführt werden. Für diese Kriterien müssen wir jedoch bestimmen, wie zuverlässig unser Wissen über das Objekt ist. Warum können wir diesem Wissen vertrauen? Was macht unser Denken und Denken wirklich glaubwürdig? Wenn man sich mit solchen Problemen befasst, kann man nicht ohne philosophische Disziplinen wie Ontologie, Erkenntnistheorie, Erkenntnistheorie, Logik und auch ohne große Denker auskommen, die sich über diese Fragen Sorgen machten. In der Antike waren dies Aristoteles und Platon, und in der Zeit der "Neuzeit" gilt Francis Bacon als Begründer der modernen wissenschaftlichen Methode.



Was kann getan werden, um die Sicherheit auf vernünftige und logische Weise zu rechtfertigen oder zu bewerten? Dieser Ansatz basiert auf der Argumentationstheorie. Einen neuen Impuls für die moderne Entwicklung der Argumentation gab das 1958 veröffentlichte Werk des britischen Philosophen Stephen Toulmin mit dem Titel "The Uses of Argument". Tulmin erweiterte die logische implizite Inferenz um zusätzliche Parameter und schlug vor, diese Operation in grafischer Form darzustellen. Die Notation von Tulmin arbeitet mit den folgenden Entitäten: Daten (D) - Anfangsdaten für die Analyse, Behauptung () - Zweck der logischen Implikationsinferenz (wenn D So C), Gewähr (W) - ein zusätzliches Argument, Qualifizierer (Q) - Grad des Vertrauens in die Ergebnisse der Logik Ausgabe, widerlegbar (R) ist ein zusätzliches Gegenargument (Abbildung 1).





Abbildung 1. Notation von Stephen Tulmin



Karten von Argumenten oder Argumenten ( Argument the Map ), die zum Zwecke der Visualisierung und Argumentation für Toulmin verwendet wurden, aber er war es, der das Strukturmodell für die Analyse und Verifizierung von Argumenten am erfolgreichsten zusammenfasste. Beachten Sie, dass moderne Argumentkarten in der Regel nicht die Tulmin-Notation verwenden. Alles ist beispielsweise vereinfacht, wie in der folgenden Abbildung dargestellt. Dies ist die Notation, die vom kostenpflichtigen Onlinedienst Rational verwendet wird (es gibt eine kostenlose Version, deren Funktionalität jedoch äußerst eingeschränkt ist) (Abbildung 2). Die kostenpflichtige Version kann die resultierenden Diagramme in logisch strukturierten Text umwandeln. Auf der Website finden Sie außerdem kostenlose Anleitungen und Tutorials zu kritischem Denken und Argumenten.





Abbildung 2. Mit dem Dienst entwickelte ArgumentzuordnungRational



Wie Sie sehen können, ist alles ziemlich transparent, es gibt nur vier Entitäten und drei Arten von Beziehungen zwischen ihnen. Das Ergebnis der logischen Eingabe heißt Contention und bestätigt das Argument - Grund (Verbindung weil), Gegenargument - Einspruch (Verbindung aber), aber das Gegenargument für das Gegenargument hat einen speziellen Namen - Widerlegung (Verbindung jedoch).



Derzeit gibt es keine allgemein akzeptierte Notation zum Erstellen von Argumentkarten. Die für die Struktur der Argumente verwendete Notation ist nicht einheitlich. Zum Beispiel kann das Inferenzergebnis als Anspruch, Streit, Schlussfolgerung, Ziel bezeichnet werden. Argumente können als Prämisse, Rechtfertigung usw. bezeichnet werden. Es gibt eine Reihe internationaler Initiativen und Gemeinschaften auf dem Gebiet der Argumentmodellierung (z. B. Argument Interchange Format, AIF)), aber sie haben die Fragen der Vereinigung nicht gelöst. Es gibt Forschungen , die Parallelen zwischen Argumentkarten und Mind Maps ziehen (Mind Map, von denen wahrscheinlich jeder gehört hat). Mit den Funktionen der Mind Map-Editoren können Sie in der Tat ein Analogon zur Argumentkarte erstellen.

Assurance Fallgeschichte und Konzept

Was hat das alles mit Sicherheit zu tun? Um diese Frage zu beantworten, wenden wir uns der zweiten Hälfte des 20. Jahrhunderts zu, in der die moderne Theorie und Praxis der Gewährleistung der Sicherheit ihren Ursprung hat. Infolge der Entwicklung komplexer technogener Industrien wie Kernenergie, Weltraumtechnologie, Öl- und Gasindustrie sowie Chemieindustrie war die Menschheit mit von Menschen verursachten Katastrophen von beispiellosem Ausmaß konfrontiert.



Zu diesem Zeitpunkt erschienen die ersten Sicherheitsanalyseberichte, in denen alle relevanten Anforderungen sowie Informationen zur Bestätigung ihrer Einhaltung zusammengefasst waren. Später erschien der Begriff Safety Case (in der Tat ein analytischer Sicherheitsbericht), der der Vorgänger des Assurance Case war. Beachten Sie, dass die Begriffe "Sicherheitsfall" oder "Sicherheitsfall" nicht direkt ins Russische übersetzt werden können. In diesem Zusammenhang ist die logischste Übersetzung "Sicherheitsfall". Obwohl beispielsweise in russischen Übersetzungen der Normenreihe ISO / IEC 15026 (System- und Softwareentwicklung - System- und Software-Assurance) "Assurance Case" als "Garantiefall" übersetzt wird.



Es ist zu beachten, dass in einigen Branchen der Begriff Sicherheitsfall zusammen mit dem Versicherungsfall weiterhin verwendet wird. Assurance Case, ein moderner Begriff, steht im Gegensatz zu Safety Case in dem Sinne, dass das System heute nicht nur der Sicherheit (funktionale Sicherheit), sondern auch der Sicherheit (Informationssicherheit) entsprechen muss. Daher wird vorgeschlagen, das Konzept des Assurance Case zu verwenden und den Safety Case als Sonderfall zu betrachten.



Assurance Case bedeutet im modernen Sinne dieses Begriffs einen Bericht über die durchgeführte Sicherheitsanalyse, einschließlich einer visuellen Darstellung in Form eines Diagramms oder einer Tabelle, die unter Verwendung semiformaler Notationen erhalten wird (die Notationen werden nachstehend erörtert). Gleichzeitig ergibt sich eine gewisse Diskrepanz desselben Begriffs, da der Assurance-Fall einerseits als Dokument (Sicherheitsanalysebericht oder Sicherheitsfallbericht) und andererseits als Argumentationssystem in semiformaler Notation interpretiert werden kann ... Im Idealfall kann ein Assurance-Fall beide Komponenten enthalten, dh das Dokument zur Bewertung der Sicherheit wird auf der Grundlage eines Argumentmodells erstellt.



Kehren wir jedoch zum 20. Jahrhundert zurück. Das erste Regulierungsdokument, das die Entwicklung und Analyse eines Sicherheitsnachweises für potenziell gefährliche Industrieanlagen erfordert, war die CIMAH-Verordnung (Control of Industrial Major Accidents Hazards), die ursprünglich 1984 in Großbritannien herausgegeben und dann in mehreren anderen Ländern angepasst wurde. Die umfassendere Umsetzung des Safety Case in der Praxis begann nach dem beispiellosen Unfall auf der Piper Alpha- Ölplattform in der Nordsee, bei dem 1988 167 Menschen ums Leben kamen.



In den neunziger Jahren suchen Forscher weiterhin nach neuen Ansätzen zur Bewertung der Sicherheit. Die Idee scheint an der Oberfläche zu sein: Lassen Sie uns eine spezielle Notation entwickeln, um die Übereinstimmung von künstlichen Objekten und Systemen mit den Sicherheitsanforderungen zu rechtfertigen. Zwei britische Universitätsteams übernahmen, die University of London, an der das Spin-off-Unternehmen Adelard gegründet wurde, und die University of York. Ich muss sagen, dass Adelard und die University of York heute führende Positionen bei der Förderung von Assurance Case einnehmen.



Bei der Entwicklung von Notationen wurde der Schwerpunkt auf die logische Begründung gelegt, dass eine Eigenschaft oder Komponente des Systems die angegebenen Anforderungen erfüllt. Die Werke von Stephen Toulmin, die wir bereits betrachtet haben, wurden als theoretische Grundlage ausgewählt. Als humanitärer Helfer dachte Toulmin kaum an vom Menschen geschaffene Systeme, ging jedoch unter anderem als Begründer der Argumentation für den Assurance-Fall in die Geschichte ein.



Auf der Grundlage von Toulmins Notation entwickelten die Briten bald die Assurance-Case-Methodik (damals als Safety-Case bezeichnet) und brachten die Ergebnisse in praktische industrielle Implementierungen ein. An der University of York wurde die Zielstrukturierungsnotation (GSN) von Doktorand Tim Kelly unter der Leitung von Professor John McDermid entwickelt und gefördert. Infolgedessen gab es diesen seltenen Fall bei der DissertationArgumentieren für Sicherheit: Ein systematischer Ansatz zur Verwaltung von Sicherheitsfällen. Doktorarbeit. University of York, 1998 “ gilt seit über 20 Jahren als Klassiker und wird weiterhin aktiv zitiert. Der Ansatz zur Lösung des Sicherheitsproblems war jedoch meiner Meinung nach akademischer, weshalb aus irgendeinem Grund kein scheinbar verständlicher und logischer Schritt in Bezug auf die Entwicklung eines Softwaretools zur Unterstützung von Assurance Case unternommen wurde.



Im Gegensatz dazu befasste sich Adelard unter der Leitung von Robin Bloomfield und Peter Bishop hauptsächlich mit der Kommerzialisierung der Ergebnisse. Parallel zu York wurde in London die Notation Claim, Argument and Evidence (CAE) sowie das Adelard ASCE- Softwaretool entwickelt(Assurance and Safety Case Environment), die sowohl CAE als auch GSN unterstützt. In Großbritannien ist die Entwicklung eines Assurance Case (Safety Case) in vielen sicherheitsrelevanten Bereichen gesetzlich vorgeschrieben, sodass ASCE hier einen ziemlich starken Markt hat. ASCE war und ist das am häufigsten verwendete Assurance Case-Entwicklungstool. Der Hauptteil des Tools ist ein Grafikeditor, in dem zusätzliche Text- oder Hyperlinkinformationen an Grafikblöcke angehängt werden können (Abbildung 3). Sie können die ASCE-Software nicht selbst von der Adelard-Website herunterladen. Sie müssen einen Antrag auf eine 30-Tage-Testversion oder eine akademische Lizenz stellen. Anschließend wird der Antrag vom Unternehmen geprüft.





Abbildung 3. Die Schnittstelle des Adelard ASCE-Programms



Schauen wir uns nun die beiden Grundnotationen an, die zur Entwicklung eines Assurance Case (CAE und GSN) verwendet wurden.

CAE-Notation (Claim, Argument and Evidence)

Die CAE-Notation (Claim, Argument and Evidence) arbeitet mit drei angegebenen Entitäten: Ziele geben das Erreichen der erforderlichen Eigenschaften des Systems an, Bestätigungen bieten eine dokumentierte Grundlage für die Argumentation, zeigen das Erreichen oder Nichterreichen von Zielen, Argumente werden mithilfe von Inferenzregeln erstellt und verbunden Bestätigung mit Zwecken. Argumente wie deterministisch (oder logisch), probabilistisch und qualitativ werden häufig verwendet. Um Ziele, Argumente und Beweise zu bestimmen, werden grafische Grundelemente mit verschiedenen Formen eingeführt (Abbildung 4).



Abbildung 4. CAE-Notation (Claim, Argument and Evidence): Hauptkomponenten



Der Aufbau einer Hierarchie von Zielen und Unterzielen ist der erste Schritt bei der Entwicklung eines Assurance-Falls. Wie im Diagramm gezeigt, ist die Struktur von Zielen, Argumenten und Behauptungen nicht unbedingt dreistufig. Beispielsweise können zusätzliche Unterziele zur Unterstützung der Argumentation verwendet werden. Die CAE-Notation lässt sich auch leicht in Tabellenform umwandeln. Die Spalten einer solchen Tabelle sind alle dieselben Ziele, Argumente und Bestätigungen, zwischen denen nun Verknüpfungen innerhalb der Tabellendatensätze hergestellt werden. Ein ähnlicher Ansatz zur Entwicklung eines Assurance- Falls wird beispielsweise von exida verwendet .

GSN (Goal Structuring Notation)

GSN arbeitet mit solchen Komponenten wie einem Ziel (einem Ziel, das durch ein Rechteck gekennzeichnet ist und ein Analogon eines Anspruchs in CAE ist), einer Argumentationsstrategie (eine Strategie, die durch ein Parallelogramm bezeichnet wird und ein Analogon des Arguments ist) und einer Lösung (bezeichnet durch einen Kreis und ist ein Analogon von Beweisen) (5). Der Kontext wird zur Informationsunterstützung von Zielen verwendet. Annahmen und Begründungen können verwendet werden, um das Argument zu stützen. Die Struktur der Ziele ist hierarchisch.





Abbildung 5. Zielstrukturierungsnotation (GSN): Hauptkomponenten



Beim Vergleich von CAE und GSN ist zu beachten, dass CAE der Begründung einzelner Argumente mehr Aufmerksamkeit schenkt. Hierzu wird ein detaillierter Entwurf der Argumentationsschritte durchgeführt. GSN konzentriert sich mehr auf generische Argumentstrukturen (Muster). Aufgrund der größeren Anzahl von Entitäten ist GSN weniger streng und kann gleichzeitig mit einer präziseren Beschreibung auf CAE reduziert werden. Die Verwendung jeder der Notationen kann sehr subjektiv sein, da der Ansatz zur Konstruktion von Argumenten von der Person abhängt, die diese Aufgabe ausführt. Einige Assurance Case-Praktiker stellen fest, dass die Notationen, die mit der Vollständigkeit der Definition semantischer Elemente verbunden sind, eine Reihe von Lücken aufweisen.



Es stellte sich heraus, dass GSN heute häufiger ist. GSN-Format im Standard festgelegtCommunity-Standard für Zielstrukturierungsnotation (GSN) sowie das SACM- Datenmodell (Structured Assurance Case Metamodel) der Object Management Group (OMG).

Wissensbasis: Branchen, Standards, Forschung, Werkzeuge, alternative Notationen

Assurance Case wird hauptsächlich in Branchen verwendet, in denen seine Verwendung durch behördliche Dokumente geregelt ist. Der Führer hier ist Großbritannien und einige andere Länder des britischen Commonwealth. Der Bericht der UK Health Foundation unter Verwendung von Sicherheitsfällen in Industrie und Gesundheitswesen (2012) berichtet über die regulatorischen Erfahrungen mit dem Assurance Case (Sicherheitsfall) in den Branchen Gesundheitswesen, Luftfahrt, Atomkraft, Automobil, Verteidigung, Petrochemie und Schiene.



In Anbetracht der Anforderungen für die Anwendung eines Assurance-Falls außerhalb des Vereinigten Königreichs ist Folgendes zu beachten:

• Automobilnorm ISO 26262: 2011, Straßenfahrzeuge - Funktionale Sicherheit, Teil der Familie der funktionalen Sicherheitsstandards, in denen die Anforderungen der IEC 61508 aufgeführt sind;
• 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”, (, , , , , , , , );
• Normen der ISO / IEC 15026-Reihe, System- und Softwareentwicklung - System- und Software-Sicherheit, die vier Teile umfasst: Teil 1: Konzepte und Vokabeln (2019); Teil 2: Versicherungsfall (2011); Teil 3: Systemintegritätsstufen (2015); Teil 4: Sicherheit im Lebenszyklus (2012).
  
  

Erwähnenswert sind auch eine Reihe von Organisationen (neben dem bereits erwähnten Adelard und der High Integrity Systems Engineering Group der University of York), die im Bereich Assurance Cases tätig sind. Diese beinhalten:

• US-CERT (United States Computer Emergency Readiness Team) nennen sie ihre Methodik 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 und Safety Case Environment) ist nach wie vor die bekannteste Assurance Case-Support-Software . Die meisten der in verschiedenen Jahren genannten Projekte haben kein ernstes Niveau erreicht. Die NASA kündigte die Entwicklung der AdvoCATE- Software an , verwendet sie jedoch für ihre eigenen Zwecke und plant nicht, sie auf den Markt zu bringen. Aufgrund der Einfachheit der Notation können Sie beispielsweise MS Visio verwenden, um Assurance-Case-Diagramme zu erstellen und diese durch Hyperlinks zu ergänzen.



Alternative Ansätze zur Entwicklung von Assurance Case umfassen das NOR-STA- Softwaretool... Es würde von der polnischen Firma Argevide (Ausgründung der Technischen Universität Danzig) entwickelt. NOR-STA unterstützt eine eigene TRUST-IT-Notation. Der Unterschied besteht darin, dass NOR-STA anstelle einer grafischen Darstellung eine strukturierte hierarchische Liste verwendet (Abbildung 6).







Abbildung 6. Trust-IT-Notation: Kernkomponenten und Fallstudieneinheiten



in der hierarchischen Liste der Ziele des Assurance-Falls werden durch verschiedene Symbole gekennzeichnet. Eine Argumentationsstrategie wird verwendet, um die Einhaltung einer Aussage zu bestätigen, und Fakten oder Beobachtungen, Begründungen, Annahmen und zusätzliche Aussagen werden als Beweisanalog verwendet. Im Gegensatz zum Desktop Adelard ASCE wird NOR-STA online verwendet und unterstützt verteilte Teamarbeit.



Darüber hinaus wird der Assurance Case verwendet, um die folgenden Anwendungen zu lösen:

• Bewertung von Attributen komplexer Eigenschaften wie Qualität, Zuverlässigkeit, Sicherheit;
• Unterstützung der Zertifizierung und Standardisierung durch Umwandlung der Anforderungen der Standards in eine Argumentstruktur;
• Assurance Based Development (ABD) oder garantiebasierte Produktentwicklung ist eine Form der Model-Based Development (MBD).
• Wissensmanagement, zum Beispiel Modellierung der Dokumentationsstruktur oder Ermittlung struktureller Verknüpfungen in einem beliebigen Tätigkeitsbereich (Geschäftsprozesse, Workflow, Änderungsmanagement usw.).

Assurance Case für Informationssicherheit

Security (Trustworthiness) Case ist als eine der Varianten von Assurance Case bekannt. Bei Bedarf kann der Security Case durch Safety Case-Komponenten ergänzt werden. Tatsächlich besteht die Idee hinter dem Assurance Case darin, die Sicherheitsattribute zu kombinieren. Im Zertifizierungsbereich gibt es Entwicklungen für die Norm ISO / IEC 15408 (Allgemeine Kriterien), für die die Anforderungen in eine Struktur umgewandelt wurden, die mit der Assurance Case-Struktur kompatibel ist. Diese Konvertierung kann für andere relevante Normen durchgeführt werden, beispielsweise für ISO 27000 oder IEC 62443 oder ein anderes Framework.



Ein Beispiel ist das Snippet "Security Assurance Cases"veröffentlicht auf der US-CERT-Website. In diesem Snippet wird der Nachweis der Implementierung des Software Development Life Cycle (SDLC) überprüft. Der Schwerpunkt liegt auf der Beseitigung von Codierungsfehlern (insbesondere Pufferüberlauf), für die Methoden wie Schulungsprogrammierer, Codeüberprüfungen, statische Analysen und Tests verwendet werden. Sie können natürlich mit der Vollständigkeit dieses Fragments argumentieren, aber es dient nur zur Veranschaulichung (Abbildung 7).





Abbildung 7. Fragment der



Sicherheitsversicherungsfälle Obwohl Informationssicherheit die Anwendung ist, bei der der Sicherheitsfall am gefragtesten sein könnte, sollte beachtet werden, dass der Sicherheitsfall trotz seines Potenzials und einer Reihe von Pilotstudien in diesem Bereich keine bekannte Praxis geworden ist.

Fallstudien-Assurance-Fall

Schauen wir uns zum Schluss ein Beispiel an, wie dies funktionieren kann. Es basiert auf einem Ansatz, der auf der Entwicklung strukturierter Argumente basiert .

Strukturierte Argumente

Stellen wir uns vor, wie Argumente in zwei aufeinander folgenden Schritten entwickelt werden (Abbildung 8). Der erste Schritt, der als Reasoning Step (RS) bezeichnet wird, ist die Analyse von Unterzielen (SC), die darauf abzielen, das Hauptziel (C) zu erreichen. In diesem Schritt wird die Struktur der Argumentation entwickelt. Im zweiten Schritt, der als Evidential Step (ES) bezeichnet wird, werden Bestätigungen (Evidece, E) zur Unterstützung der im vorherigen Schritt generierten Unterziele (SC) formuliert. Zur weiteren Formalisierung der RS- und ES-Schritte werden typische ST-Vorlagen (Structured Text) verwendet.





Abbildung 8. Schritte und Komponenten strukturierter Argumente

Hierarchie der Anforderungen

Stellen Sie sich eine Hierarchie oder Pyramide von Anforderungen vor, die eine Struktur bilden, die der Spalte Assurance Case entspricht. Die meisten gesetzlichen Anforderungen für Computersysteme oder Software haben eine Anforderungsstruktur auf 3 oder 4 Ebenen (Abbildung 9).





Abbildung 9. Die Hierarchie der Anforderungen und ihre Beziehung zu den Argumentationsschritten



Stufe Null ist ein Metaziel, nach dem das zu bewertende System alle Sicherheitsanforderungen erfüllen muss. Auf der ersten Ebene werden globale Sicherheitsziele erreicht, beispielsweise ergeben sich die folgenden Ziele aus den Anforderungen an die funktionale Sicherheit nach IEC 61508 :

• ein Sicherheitsmanagementsystem muss implementiert werden;
• Während der System- (oder Software-) Entwicklung muss der Sicherheitslebenszyklus angewendet werden.
• Auf das System müssen ausreichende Maßnahmen zum Schutz vor versehentlichem Ausfall angewendet werden.
• Für das System (oder die Software) müssen ausreichende Maßnahmen zum Schutz vor systematischen Fehlern und Softwarefehlern, einschließlich des Schutzes vor Cyberangriffen, getroffen werden.

Auf der zweiten Ebene unterstützen Anforderungsgruppen ein bestimmtes globales Ziel. Zum Beispiel Sicherheitsmanagementanforderungen(gemäß IEC 61508) umfassen Gruppen von Anforderungen für Personalmanagement, Konfigurationsmanagement, Dokumentenmanagement und andere. Die Struktur der Verknüpfungen zwischen der Null-, der ersten und der zweiten Ebene ist ein ziemlich einfacher Baum. Eine solche Struktur erfordert keine detaillierte Ausarbeitung der Argumente, da diese Argumente typisch sind und in verschiedenen Projekten wiederholt getestet wurden. Beim Übergang von der zweiten zur unteren Ebene sind jedoch strukturierte Argumente erforderlich. In diesem Fall können die Anforderungen der unteren Ebenen zusammengesetzt (dh eine Reihe separater Anforderungen enthalten) oder einfach (atomar) sein. Wenn alle Anforderungen atomar sind (es gibt keine zusammengesetzten Anforderungen), wird diese Ebene zur dritten und steht dann in direktem Zusammenhang mit den Untergruppen der Anforderungen. Wenn es zusammengesetzte Anforderungen gibt, erhalten wir eine komplexere vierstufige Struktur.



Für die niedrigste Stufe sollte neben RS auch ES angewendet werden. Da es unpraktisch ist, der Struktur des Diagramms detaillierte Informationen zum Inhalt der Argumente hinzuzufügen, wird jeder der Knoten des Assurance Case-Diagramms ab der zweiten Ebene mit einer Beschreibung der Argumente unter Verwendung von strukturiertem Text (ST) markiert. Das Assurance-Case-Diagramm auf der untersten Ebene ist kein Baum mehr, da dieselbe Bestätigung (E) verschiedene Unterziele (SC) unterstützen kann.

Assurance Case für eine Gruppe von HR-Anforderungen (IEC 61508)

Betrachten Sie zur Veranschaulichung das Assurance Case-Snippet in Bezug auf die HR-Anforderungen der IEC 61508 ( IEC 61508-1, Abschnitt 6 ).





Aus der IEC 61508 wurden insgesamt sieben Anforderungen an das Personalmanagement extrahiert. Unter dem Gesichtspunkt der strukturierten Argumentation sind diese Anforderungen Unterziele (SC1, ..., SC7). Nur eines der Unterziele (SC5) ist zusammengesetzt, alle anderen sind atomar. Um von einem zusammengesetzten Unterziel (SC5) zu einem atomaren (SC5.1, ..., SC5.11) zu gelangen, wird ein weiterer Argumentationsschritt (RS) ausgeführt. Es versteht sich, dass gemäß den Anforderungen der IEC 61508 ein Personalmanagementplan für ein Projekt entwickelt wurde, das sich auf die Erstellung eines abstrakten Produkts bezieht. Dieser Plan interpretiert die Anforderungen des Standards im Kontext des Projekts.





Für alle Bestätigungsschritte (ES) wird vorgeschlagen, einen gemeinsamen strukturierten Text zu verwenden, der die Verknüpfungen zwischen Unterzielen (SG) von Bestätigungen (E) angibt. Wir werden die Beziehung SG -> E verwenden, um die Beziehung zwischen dem entsprechenden Unterziel (SG) und den Bestätigungen (E) zu bezeichnen, die dies unterstützen.





Alle erhaltenen Relationen SG -> E können gemäß der GSN-Notation in eine Assurance-Case-Spalte umgewandelt werden, die für eine strukturierte Argumentation modifiziert wurde (Abbildung 10). Dieses Diagramm spiegelt die gesamte Gruppe von Anforderungen in Bezug auf das Personalmanagement gemäß IEC 61508 wider. Dieses Diagramm kann auch als Vorlage für die Bewertung der Einhaltung der Anforderungen von IEC 61508 verwendet





werden (IEC 61508)



Auf den ersten Blick ist dies alles lang und schwierig, aber dennoch hat der Assurance Case seine praktische Anwendung. Dies ist der Ansatz, den wir bei der Zertifizierung der RdICS-SPS für die Konformität mit IEC 61508 verwendet haben .

Fazit

Die Assurance Case (Safety Case) -Methode wird seit über 20 Jahren verwendet, um die Sicherheit von CII-Einrichtungen zu analysieren. Diese Methode wird in Großbritannien und einer Reihe von Ländern des britischen Commonwealth am häufigsten für Branchen wie Gesundheitswesen, Luftfahrt, Kernenergie, Automobilindustrie, Verteidigung, Petrochemie und Eisenbahn eingesetzt.



Zu den Vorteilen des Assurance-Falls gehören alle Vorteile, die durch die Visualisierung von Beziehungen in einem komplexen Themenbereich und die Verbesserung unserer Wahrnehmung und unseres Verständnisses erzielt werden. Die Nachteile sind auf die Subjektivität der Methode in Bezug auf ihre Abhängigkeit vom Fachwissen der Personen zurückzuführen, die die Bewertung durchführen. Der bekannteste "epische Fehler" in der Assurance Case-Anwendung wird hier beschrieben... Kurzum: Am 2. September 2006 brach in Afghanistan an Bord einer britischen Luftwaffe Nimrod ein Feuer aus. Das Problem ergab sich aus einem Kraftstoffleck. Alle 14 Menschen an Bord wurden getötet. Ein früherer Sicherheitsbericht bestätigte die Sicherheit des Flugzeugs. Die Untersuchung ergab, dass die Änderung des Treibstoffsystems bei Serienflugzeugen nicht vollständig korrekt war und ähnliche Probleme bereits zuvor aufgetreten waren, aber aus irgendeinem Grund niemand sie als Systemfehler beachtete. In dem veröffentlichten 600-seitigen Bericht wurde dieser Vorfall lediglich als "Misserfolg von Führung, Kultur und Prioritäten" bezeichnet.



Übrigens wurden im Bericht für Nimrod keine grafischen Notationen verwendet. Eine der Folgen dieser Katastrophe war die Vertiefung der Forschung im Bereich der Argumentationskonstruktion. Ein allgemeiner Ansatz, der alle zufriedenstellt, wurde jedoch nicht entwickelt.



Heutzutage sind die regulatorischen und rechtlichen Anforderungen der Haupttreiber für die Implementierung von Assurance Case, nicht die Bequemlichkeit, Durchführbarkeit oder Kosteneffizienz. Natürlich gibt es im Bereich Assurance Case große Möglichkeiten für künstliche Intelligenz, aber irgendwie bin ich nicht auf Veröffentlichungen zu diesem Thema gestoßen.

Das mit der Bewertung der Sicherheit komplexer Systeme verbundene Problem bleibt jedoch offen. Es ist möglich, dass mit der aktiven Umsetzung des Assurance-Falls einige Fortschritte in diesem Bereich erzielt werden können, da diese Methode auf all den wichtigen Punkten basiert, die die Menschheit seit Beginn der philosophischen Forschung beschäftigt haben.