Sicher ist sicher Einheitliche Betrachtung von Funktions- und Informationssicherheit

Ordnungsmerkmale

erschienen in: <kes> 2006#4, Seite 47

Rubrik: Management und Wissen

Schlagwort: Safety und Security

Zusammenfassung: So wie die Trennung von Informations- und Steuerungstechnik zunehmend verschwindet, so bedarf es auch einer einheitlichen Bewertung der Vertrauenswürdigkeit kritischer IT-gesteuerter Systeme. Der vorliegende Beitrag illustriert Probleme und Fortschritte hierbei, vor allem aus der Perspektive internationaler Standardisierung, und empfiehlt ein ganzheitliches Vorgehen.

Autor: Von Francesca Saglietti, Erlangen

In der Vergangenheit konzentrierten sich Verlässlichkeitsnachweise kritischer Anwendungen entweder auf die Untersuchung funktionaler oder aber datenbezogener Sicherheitsaspekte, je nachdem, ob der Schutz der menschlichen Gesundheit oder der zugrunde liegenden Information als dominierendes Schutzziel betrachtet wurde.

Solange Rechner mit verantwortungsvollen Aufgaben in einer abgeschlossenen Umgebung operierten (typischerweise durch Einsatz eingebetteter Software zur Steuerung technischer Prozesse) reichten die Begriffe "funktionale" beziehungsweise "technische Sicherheit" aus, um die Vertrauenswürdigkeit softwarebasierter Systeme hinsichtlich der Abwesenheit von Gefahren für existentielle oder materielle Werte infolge eines potenziellen funktionalen Fehlverhaltens zu kennzeichnen.

Sobald Softwaresysteme zwecks Datenaustausch vernetzt wurden, kamen jedoch zum funktionalen Fehlverhalten softwarebasierter Steuerungen neue Risiken hinzu: die Beeinträchtigung der Vertraulichkeit, Integrität oder Verfügbarkeit zu verarbeitender Informationen infolge von Missbrauch oder höherer Gewalt. In diesem Zusammenhang wurde ein neuer Begriff erforderlich, um die Vertrauenswürdigkeit von IT-Systemen hinsichtlich der Abwesenheit unerwünschter Gefahren für geschäftliche oder ideelle Werte zu kennzeichnen: Informationssicherheit (bzw. Datensicherheit).

Da heute zunehmend große vernetzte Systeme die Verantwortung bei der Steuerung sicherheitskritischer technischer Prozesse übernehmen, muss zusätzlich zur funktionalen Sicherheit auch die Informationssicherheit des zugrunde liegenden Kommunikationsnetzes in angemessenem Grad gewährleistet sein. Dadurch nimmt in modernen kritischen IT-Infrastrukturen die Interaktion zwischen Funktions- und Informationssicherheit sowohl an Relevanz als auch an Komplexität kontinuierlich zu.

Die Kombination beider Bedrohungsarten erfordert die systematische Untersuchung potenzieller Interaktionen zwischen funktionalem und datenbezogenem Fehlverhalten. Typische Beispiele sind die Speicherung von Patientendaten, deren unkontrollierte Manipulation zur Anwendung medizinisch oder technisch inadäquater Therapien führen kann, sowie die rechnergestützte Steuerung von Verkehrssystemen mittels Datenübertragung (etwa funkgesteuerte Zuggeschwindigkeitsanpassung oder ferngesteuerte Softwarepflege im Automobil).

Interaktionen zwischen funktionalen und Informationssicherheitsaspekten können dabei in beiden Richtungen auftreten: Einerseits können Datensicherheitslücken zu technischen Unfallszenarien beitragen, etwa wenn Angriffe auf die Datenintegrität zu Rechnerversagen mit lebensgefährlichen Folgen führen können. Andererseits können Schwachstellen im Entwurf ebenfalls zu Informationssicherheitsverletzungen führen, etwa im Falle logischer Fehler mit funktionalem Fehlverhalten in einem komplexen Zugriffskontrollsystem. In Abhängigkeit von der übergeordneten Zielsetzung der zu betrachtenden Anwendung kann eine der beiden genannten kausalen Relationen zwischen funktionaler Sicherheit und Informationssicherheit von überwiegendem Interesse sein.

Gutachter und Genehmigungsbehörden können aber nicht mehr – wie es früher üblich und sinnvoll war – auf das klassische Prinzip der Trennung der Belange setzen. Es werden somit Standards benötigt, die eine einheitliche Bewertung der Vertrauenswürdigkeit kritischer IT-Infrastrukturen erfordern und unterstützen.

Einheitliche Risiko-Analyse

Funktionale Sicherheit und Informationssicherheit lassen sich anhand folgender, weitgehend gemeinsamer Terminologie in einem einheitlichen Rahmen analysieren und nachweisen. Im Allgemeinen kann die Fehlerfreiheit komplexer IT-Systeme nicht vorausgesetzt werden, sondern man muss von der Existenz inhärenter Schwachstellen ausgehen, die etwa infolge logischer Entwurfsfehler oder unbedachter Verwundbarkeiten bedingt sein und zu unerwünschten Ereignissen mit kritischen Konsequenzen führen können.

Bedrohungsszenarien kennzeichnen dabei Ereignisse außerhalb des IT-Systems, die in Kombination mit Schwachstellen innerhalb des IT-Systems zu Verlusten führen können. Beispiele für Bedrohungsszenarien sind kriminelle Angriffe, organisatorische Mängel, menschliche Irrtümer, technische Unfälle oder höhere Gewalt. Falls Vorfälle das Eintreten von Bedrohungsszenarien in Kombination mit Systemschwachstellen kennzeichnen, so versteht man unter der Vertrauenswürdigkeit eines IT-Systems die Abwesenheit von Vorfällen, selbst bei Vorhandensein externer Bedrohungsquellen.

Um im Einzelfall Entwicklungs- und Genehmigungsprozesse zu präzisieren, die für funktions- und datenbezogenene Sicherheitsrisiken der geplanten Anwendung adäquat sind, muss eine sorgfältige Systemanalyse sowohl den Schweregrad potenzieller Verluste als auch die Natur von Schwachstellen und Bedrohungen berücksichtigen. Das Hauptziel funktionaler Sicherheitsmechanismen ist dabei der Schutz der Umgebung des IT-Systems vor dessen Fehlverhalten, während das Hauptziel der Informationssicherheitsmechanismen der Schutz des IT-Systems vor unerwünschten Einwirkungen aus dessen Umgebung ist.

In diesem Zusammenhang stellt sich die Frage, nach welchen Kriterien die Qualitätsanforderungen an den Entwicklungsprozess und an das zu entwickelnde Produkt systematisch zu ermitteln sind. Vergleicht man bisherige Standards, die entweder auf Informations- oder auf funktionale Sicherheit abzielen, so zeigt sich, dass die Einstufung des Schweregrads der zu betrachtenden Anwendung nach unterschiedlichen Gesichtspunkten erfolgt: Auf der einen Seite basieren die sieben Evaluation Assurance Levels (EALs) aus den Common Criteria [1,2] auf einer steigenden Skala zum Abgleich der zu erzielenden Qualität mit dem einzusetzenden Aufwand und der zu erwartenden Realisierbarkeit der angestrebten Qualitätssicherung – sie sind also im Wesentlichen durch zunehmende Anforderungen an den durch Funktionalität, Entwurf, Verifikation und Test geprägten Entstehungs-Prozess eines Produkts charakterisiert. Auf der anderen Seite schlagen die meisten Safety-Standards (s. u.) eine objektive, reproduzierbare Zuordnung zwischen Risiko und Sicherheitsklasse vor, die sich im Allgemeinen am Schweregrad der potenziellen Verluste orientiert.

Safety-Standards

Alle im Folgenden betrachteten Ansätze erfordern (obgleich auf unterschiedlichen Detaillierungsebenen) eine vorausgehende Risiko-Analyse mit dem Ziel, den Schweregrad inkorrekten Softwareverhaltens zu erfassen und zu klassifizieren. Daraus ergibt sich eine Sicherheitsklassifikation, auf deren Basis die meisten heutigen Standards entsprechende Qualitätsgrade identifizieren, die zum Zweck der Genehmigung nachzuweisen sind.

IEC 61508

Die Sicherheitsklassifikation des generischen Standards IEC 61508 beruht auf der probabilistischen Quantifizierung minimaler Softwarezuverlässigkeitsanforderungen aufgrund eines Vergleichs der Risiken, die durch die softwarebasierte Automatisierung induziert werden, mit den der technischen Anwendung inhärenten Risiken.

Um entsprechend dem Schweregrad einer rechnerbasierten Anwendung die Anforderungen an die Rigorosität ihres Entwicklungs- und Genehmigungsprozesses skalieren zu können, ist es zunächst erforderlich, für jede identifizierte Bedrohung ihren Schweregrad im Sinne des damit verbundenen Risikos quantitativ zu erfassen: als Produkt der Vorfallswahrscheinlichkeit und des vorfallsbedingt zu erwartenden Schadens. Hierzu werden für alle Elemente im Einflussbereich der Anwendung Bedrohungsarten ermittelt, die diese beeinträchtigen können. Anschließend schätzt man für jede identifizierte Bedrohungsart die Eintrittswahrscheinlichkeit zugehöriger Vorfälle und die Höhe zu erwartender verlustbedingter Kosten. Aus der Risikoanalyse ergibt sich so eine von vier möglichen Klassen von Zuverlässigkeitsanforderungen, die so genannten Safety Integrity Levels (SILs), wobei zwischen diskreten und stetigen Betriebsmodi unterschieden wird (s. Tab. 1 – Anmerkung: um die Standards korrekt wiederzugeben, wurden die Inhalte der Tabellen nicht übersetzt).

Auf der Basis der im Einzelfall identifizierten SIL definiert der Standard gestaffelte Anforderungen an den Entwicklungsprozess (einschließlich Nachweisführung) und an das zu entwickelnde Produkt. Damit wurde erstmals ein generischer Ansatz entwickelt, der sich an die speziellen Eigenarten einer Reihe von Anwendungsbereichen anpassen lässt.

Safety Integrity Level average probability p of failure on demand failure rate λ per hour
4 10−5 ≤ p < 10−4 10−9 ≤ λ < 10−8
3 10−4 ≤ p < 10−3 10−8 ≤ λ < 10−7
2 10−3 ≤ p < 10−2 10−7 ≤ λ < 10−6
1 10−2 ≤ p < 10−1 10−6 ≤ λ < 10−5

Tabelle 1: Sicherheitsklassifikation nach IEC 61508

IEC 62304

Um die zum Teil problematische Bestimmung probabilistischer Kenngrößen zu vermeiden, empfehlen andere standardisierte Vorgehensweisen eine deterministische Skalierung der Sicherheitsanforderungen in Abhängigkeit von den schlimmstenfalls zu erwartenden Szenarien (worst case). Dies trifft zum Beispiel für die Genehmigung von Software für medizinische Geräte gemäß IEC 62304 zu (s. Tab. 2).

Class A No injury may occur to the patient or to the operator resulting from a hazard to which the software item may be a contributing factor.
Class B Non-serious injury may occur to the patient or to the operator resulting from a hazard to which the software item may be a contributing factor.
Class C Death or serious injury may occur to the patient or to the operator resulting from a hazard to which the software item may be a contributing factor.

Tabelle 2: Sicherheitsklassifikation nach IEC 62304

MISRA Guidelines

Eine weitere Sicherheitsklassifikation deterministischer Natur wurde von der britischen Automobilindustrie erarbeitet [5]. In Anbetracht der menschlichen Präsenz und Mitwirkung beim Fahren eines Autos berücksichtigt dieser Ansatz die Chancen des Fahrers, unerwartetem Softwareversagen während des Betriebs durch menschliche Reaktion entgegenzusteuern. Diese Klassifikation möglicher Mensch-Maschine-Interaktion auch unter extremen Randbedingungen führt zu den in Tabelle 3 dargelegten Sicherheitskategorien mit zugehörigen gestaffelten Anforderungen an die Softwarequalität.

Bis auf anwendungsspezifische Unterschiede werden analoge Vorgehensweisen auch für softwarebasierte Steuerungen in folgenden industriellen Bereichen eingesetzt: Verfahrenstechnik (IEC 61511), Kerntechnik (IEC 61226 und IEC 62138), Maschinenbau (IEC 62061), Bahntechnik (EN 50128).

Categories Definition
Uncontrollable This relates to failures whose effects are not controllable by the vehicle occupants, and which are most likely to lead to extremely severe outcomes. The outcome cannot be influenced by a human response.
Difficult to control This relates to failures whose effects are not normally controllable by the vehicle occupants but could, under favourable circumstances, be influenced by a mature human response. They are likely to lead to very severe outcomes.
Debilitating This relates to failures whose effects are usually controllable by a sensible human response and, whilst there is a reduction in the safety margin, can usually be expected to lead to outcomes which are at worst severe.
Distracting This relates to failures which produce operational limitations, but a normal human response will limit the outcome to no worse than minor.
Nuisance only This relates to failures where safety is not normally considered to be affected, and where customer satisfaction is the main consideration.

Tabelle 3: Sicherheitsklassifikation nach MISRA

Einheitliche Standardisierung

Wie bereits erwähnt, adressieren die meisten bisherigen Standards entweder funktionale Sicherheit oder Datensicherheit. Eine einheitliche Vorgehensweise zur Genehmigung der übergeordneten Vertrauenswürdigkeit ist noch Gegenstand laufender Normierungsbestrebungen. Die International Electrotechnical Commission (IEC) hat das Thema jedoch in einem neueren Entwurf behandelt, der in IEC 62443 "Security for Industrial Process Measurement and Control – Network and System Security" münden soll [6].

Der derzeitige Vorschlag sieht vor, eine qualitative Analyse der Faktoren durchzuführen, die Möglichkeit und Schweregrad von Angriffen beeinflussen; für jeden Faktor wird anschließend ein angemessener Grad an Informationssicherheit, der so genannte Security Level ermittelt. Darauf aufbauend bestimmt der maximale Grad unter allen betrachteten Einflussfaktoren den übergeordneten Security Requirement Level (SRL) der Anwendung. Die hier vorgeschlagene Vorgehensweise stellt also insgesamt eine Vergröberung der Risiko-Analyse dar; die dadurch zu erwartende Genauigkeit darf deshalb in Frage gestellt werden. Andererseits hat dieser Ansatz den Verdienst, erstmals eine systematische Analyse der Datensicherheit im Rahmen industrieller Automatisierungssysteme zu betrachten.

Eine genauere, wenn auch ungleich aufwändigere Analysetechnik ist mittels klassischer Fehlerbaumanalyse zu erzielen: Für jede identifizierte Bedrohung der funktionalen Sicherheit werden "top-down" diejenigen Unterereignisse hergeleitet, die zum Auftreten der jeweiligen Bedrohung führen können – darunter eventuell auch Informationssicherheitsverletzungen. Anhand der minimalen Schnittmengen des sich ergebenden Fehlerbaums werden anschließend angemessene Anforderungen an Schutzmechanismen beziehungsweise Zuverlässigkeitsnachweise hergeleitet, die zur systematischen Vermeidung oder Beherrschung der identifizierten Szenarien einzusetzen beziehungsweise zu führen sind. Dies geschieht in Abhängigkeit von dem Schweregrad des anfänglich betrachteten unsicheren Ereignisses sowie vom Verantwortungsgrad der identifizierten dazu führenden Unterereignisse. Diese Vorgehensweise wird im Folgenden an einem konkreten Beispiel veranschaulicht.

Beispiel zur Fehlerbaumanalyse

Das betrachtete Bedrohungsereignis aus der Automobilindustrie lautet "Lebensgefährdung infolge softwarebedingten Aussetzens der Motorsteuerung" (s. Abb. 1). Es wird vom gleichzeitigen Eintreten der beiden Unterereignisse "softwarebedingtes Aussetzen der Motorsteuerung" und "besondere Situation bei der Fahrt (etwa Überholvorgang)" ausgelöst. Das softwarebedingte Aussetzen der Motorsteuerung kann seinerseits durch fehlerhafte Softwareentwicklung, durch zufallsbedingte physikalische Veränderung des Arbeitsspeichers verursacht oder im Laufe des Überschreibvorgangs im Zuge ferngesteuerter Softwarepflege angestoßen worden sein. Letztere Gefährdung könnte durch (dank fehlerkorrigierender Übertragungscodes eher unwahrscheinliche) Übertragungsfehler oder durch eine Sabotage-Aktion bedingt sein, die ihrerseits die erfolgreiche Durchführung einer externen Attacke mangels adäquater Schutzmaßnahmen voraussetzt. Den sich ergebenden Fehlerbaum zeigt Abbildung 1. Entsprechende Erfahrungswerte für die einzelnen Ereignisse führen zu einer systematischen Priorisierung der im Einzelfall zu fordernden Schutzmaßnahmen.

[Illustration]
Abbildung 1: Fehlerbaum zur Darstellung des kausalen Zusammenhangs zwischen funktionaler Sicherheit und Informationssicherheit am Beispiel eines gefährlichen Ereignisses im Automobil.

Fazit

Die Ermittlung adäquater Anforderungen an funktionale Sicherheit und an Informationssicherheit birgt Unterschiede und Gemeinsamkeiten. In Anbetracht der heute zunehmenden Verbreitung kritischer IT-Infrastrukturen wird eine einheitliche Vorgehensweise als dringend notwendig erachtet. Zu diesem Zeck wird der Einsatz einer erweiterten Fehlerbaumanalyse empfohlen, die es ermöglicht, Informationssicherheitsverletzungen als Unterereignisse zu übergeordneten Verletzungen funktionaler Sicherheit zu integrieren.

Prof. Francesca Saglietti (saglietti@informatik.uni-erlangen.de) ist Inhaberin des Lehrstuhls für Software Engineering an der Universität Erlangen-Nürnberg.

Literatur

[1]
Bundesamt für Sicherheit in der Informationstechnik (BSI), Gemeinsame Kriterien für die Prüfung und Bewertung der Sicherheit von Informationstechnik, [externer Link] www.bsi.bund.de/cc/
[2]
Common Criteria Portal, [externer Link] www.commoncriteriaportal.org
[3]
International Electrotechnical Commission (IEC), Functional Safety of Electrical / Electronic / Programmable Electronic Safety-Related Systems, Part 3: Software Requirements, International Standard IEC 61508-3, 1998, [externer Link] http://webstore.iec.ch/
[4]
International Electrotechnical Commission (IEC), Medical Device Software – Software Life Cycle Processes, IEC 62304, 2006, [externer Link] http://webstore.iec.ch/
[5]
Motor Industry Software Reliability Association (MISRA), Development Guidelines for Vehicle-Based Software, 1994, ISBN 0-9524156-0-7, PDF-Version zum Download verfügbar über [externer Link] www.misra.org.uk/public.htm#label-htext (Registrierung erforderlich)
[6]
International Electrotechnical Commission (IEC), Security for Industrial Process Measurement and Control – Network and System Security, im Standardisierungsprozess zu IEC 62443 Ed. 1.0
[7]
Francesca Saglietti, Interaktion zwischen funktionaler Sicherheit und Datensicherheit, in: Gesellschaft für Informatik, Sicherheit 2006: Sicherheit – Schutz und Zuverlässigkeit, Lecture Notes in Informatics P-77, 2006, ISBN 3-88579-171-4