28
Seminararbeit Probabilistische Risikoanalyse zur Bewertung der IT-Sicherheit Heinrich Pettenpohl 27. Januar 2014 Gutachter: Prof. Dr. Jan J¨ urjens Dipl.-Inform. Andreas Schmitz Prof. Dr. Jan J¨ urjens Lehrstuhl 14 Software Engineering Fakult¨ at Informatik Technische Universit¨ at Dortmund Otto-Hahn-Straße 14 44227 Dortmund http://www-jj.cs.uni-dortmund.de/secse

Probabilistische Risikoanalyse zur Bewertung der IT-Sicherheit · Sicherheitsmaˇnahmen f ur die Daten besteht, wurde der Standard \Guidelines for the Management of IT Security (GMITS)"[Gmi]

  • Upload
    lamanh

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

Seminararbeit

Probabilistische Risikoanalyse zurBewertung der IT-Sicherheit

Heinrich Pettenpohl27. Januar 2014

Gutachter: Prof. Dr. Jan JurjensDipl.-Inform. Andreas Schmitz

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmundhttp://www-jj.cs.uni-dortmund.de/secse

Heinrich [email protected]: 124838Studiengang: Master Angewandte Informatik

(Sicherheit und Softwareengineering Seminar)Thema: Probabilistische Risikoanalyse zur Bewertung der IT-Sicherheit

Eingereicht: 27. Januar 2014

Betreuer: Andreas Schmitz

Prof. Dr. Jan Jurjens Lehrstuhl 14 Software EngineeringFakultat InformatikTechnische Universitat DortmundOtto-Hahn-Straße 1444227 Dortmund

i

ii

iii

Ehrenwortliche Erklarung

Ich erklare hiermit ehrenwortlich, dass ich die vorliegende Arbeit selbststandig ange-fertigt habe; die aus fremden Quellen direkt oder indirekt ubernommenen Gedankensind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prufungsbehorde vorgelegt und auch nochnicht veroffentlicht.

Dortmund, den 27. Januar 2014

Heinrich Pettenpohl

iv

INHALTSVERZEICHNIS v

Inhaltsverzeichnis

Abbildungsverzeichnis vii

1 Einleitung 11.1 Motivation und Hintergrund . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Risikoanalyse zur Bewertung der IT-Sicherheit 32.1 Definition von Risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 GMITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Probabilistische Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 Initiale Ereignisse analysieren . . . . . . . . . . . . . . . . . . 62.3.2 Event Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.3 Fault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.4 Fault Tree Analyse (FTA) . . . . . . . . . . . . . . . . . . . . 82.3.5 Event Tree Analyse (ETA) . . . . . . . . . . . . . . . . . . . . 8

3 PRA am Beispiel einer doppelten Firewall 93.1 Event Tree konstruieren . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Fault Tree konstruieren . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Fault Tree Analyse (FTA) . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Event Tree Analyse (ETA) . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Fazit und Ausblick 15

Literaturverzeichnis 17

vi INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS vii

Abbildungsverzeichnis

2.1 Fundamentale Fault Tree Struktur (vgl. [HK96] S. 167) . . . . . . . . 7

3.1 Aufbau des Firewall Beispiels [NSK08] . . . . . . . . . . . . . . . . . 93.2 Event Tree fur das Firewall Beispiel [NSK08] . . . . . . . . . . . . . . 103.3 Event Tree und Fault Tree des Firewall Beispiels [NSK08] . . . . . . . 11

viii ABBILDUNGSVERZEICHNIS

KAPITEL 1. EINLEITUNG 1

1 Einleitung

In der heutigen Welt sind Computersysteme allgegenwartig. Viele besitzen einenoder mehrere PCs, Laptops, Smartphones oder andere elektronische Gerate. Diesgilt sowohl fur den privaten als auch fur den beruflichen Alltag. Die Systeme sindhaufig vernetzt und mit dem Internet verbunden, wodurch jeder in kurzer Zeit daraufzugreifen kann. Dieser Zugriff kann allerdings auch von Angreifern benutzt werden,um Daten zu stehlen. Dementsprechend ist IT-Sicherheit in unserer modernen undvernetzten Welt ein wichtiges Thema. Dabei geht es darum, die Daten auf den IT-Systemen vor unerlaubten Zugriffen zu schutzen. Dies geschieht meistens virtuelldurch zum Beispiel Zugangskontrollen und andere Verfahren. Dabei durchdringtdie IT-Sicherheit viele Bereiche einer Software und muss schon wahrend der Soft-wareentwicklung berucksichtigt werden. Um festzustellen, welches Risiko trotz derSicherheitsmaßnahmen fur die Daten besteht, wurde der Standard “Guidelines forthe Management of IT Security (GMITS)” [Gmi] etabliert, welcher in dieser Ausar-beitung vorgestellt wird. Das Risiko wird dabei mit Hilfe einer Formel berechnet.Einen anderen Ansatz verfolgen Naoki Satoh, Hiromitsu Kumamoto und YasunobuKino in ihrem Artikel “Viewpoint of ISO GMITS and Probabilistic Risk Assessmentin Information Security” [NSK08]. Dort nutzen sie das Verfahren der Probabilis-tischen Risikoanalyse (PRA), welches neu im Bereich der IT-Sicherheit ist. Dabeiwird das Risiko probabilistisch, also mit Hilfe von Wahrscheinlichkeiten oder Hau-figkeiten, uber verschiedene Unfalls- bzw. Angriffsszenarien berechnet. Auch diesesVerfahren wird in dieser Ausarbeitung vorgestellt und anschließend beispielhaft aufein IT-System mit zwei Firewalls angewandt.Zusatzlich zu dem oben erwahnten Artikel wurde als weiterfuhrende, grundlegendeLiteratur “An Application of Probabilistic Risk Assessment to Information Securi-ty Audit” [NS09a] von Naoki Satoh, Hiromitsu Kumamoto verwendet, in welchemGMITS genauer beschrieben wird. Die Grundlagen fur die PRA wurden hauptsach-lich aus dem Buch “Probabilistic Risk Assessment and Management for Engineersand Scientists” von H. Kumamoto und E.J. Henley entnommen.

1.1 Motivation und Hintergrund

GMITS ist spezfiziert von der ISO/IEC (International Organization for Standardi-zation / International Electrotechnical Commission) im ISO/IEC 13335 Standard[Gmi]. Es ist daher ein internationaler Standard fur Informations- und Kommunika-tionssicherheit. Die PRA dagegen wurde das erste Mal in der “WASH-1400 Reactorsafety Study” [USN75] benutzt, welche 1975 veroffentlicht wurde. Dort wurde die Si-cherheit von Atomkraftwerken mit Hilfe der PRA beurteilt. Mittlerweile ist die PRA

2 1.2. AUFBAU DER ARBEIT

eine Standardmethode fur die Qualifikation von Unfallrisiken bei Atomkraftwerken[ME02]. Auch andere Industrien setzen die PRA zur Beurteilung von Risiken ein,wie zum Beispiel die NASA fur die Luft- und Raumfahrt [SD11]. Im Umfeld der IT-Sicherheit ist die PRA allerdings ein neues Verfahren, welches in dieser Ausarbeitungmit dem etablierten Standard GMITS verglichen wird.

1.2 Aufbau der Arbeit

Die Arbeit ist in 4 Kapitel unterteilt, das erste Kapitel ist die Einleitung.

Im zweiten Kapitel werden die Grundlagen der Risikobewertung von IT-Sicherheiterklart. Dafur wird als erstes der Begriff Risiko definiert. Danach wird GMITS vorge-stellt, welches den Standard in der IT-Sicherheit darstellt. Dabei wird hauptsachlichauf die Formel eingegangen, mit der das Risiko fur ein IT-System berechnet werdenkann. Anschließend wird die in diesem Gebiet neue PRA vorgestellt. Dazu werdendie Begriffe Event Tree Analyse (ETA) und Fault Tree Analyse (FTA) erlautert.

Im dritten Kapitel wird die PRA auf ein Beispiel aus der IT-Sicherheit angewandt.In diesem Fall ist dies eine doppelte Firewall, welche einen Server mit vertraulichenDaten schutzt.

Abschließend fasst das letzte Kapitel diese Arbeit zusammen, beurteilt die PRA zurBewertung der IT-Sicherheit und gibt einen Ausblick auf weitere Uberlegungen.

KAPITEL 2. RISIKOANALYSE ZUR BEWERTUNG DER IT-SICHERHEIT 3

2 Risikoanalyse zur Bewertung der IT-Sicherheit

Dieses Kapitel definiert zunachst den Begriff Risiko, um eine Grundlage zu schaf-fen. Danach wird in Abschnitt 2.2 auf GMITS eingegangen, welches einen Standardfur Risikomanagement in der IT-Sicherheit ist. Der Großteil des GMITS Abschnittsbasiert auf dem Artikel “An Application of Probabilistic Risk Assessment to Infor-mation Security Audit” [NS09a] von Naoki Satoh und Hiromitsu Kumamoto.Abschließend wird im Abschnitt 2.3 die Probabilistische Risikoanalyse vorgestellt,welche als neues Verfahren gegenuber GMITS im Bereich der IT-Sicherheit einge-setzt werden soll. Dieser Abschnitt beruht auf dem Buch “Probabilistic Risk Assess-ment and Management for Engineers and Scientists” von H. Kumamoto und E.J.Henley.

2.1 Definition von Risiko

Hans-Peter Konigs definiert das Risiko in seinem Buch “IT-Risikomanagement mitSystem” wie folgt ([Ko13] S.10):

“Risiko ist eine nach Wahrscheinlichkeit (Haufigkeit) und Auswirkung bewertete Be-drohung eines zielorientierten Systems1. Das Risiko betrachtet dabei stets die negati-ve, unerwunschte und ungeplante Abweichung von System-Zielen und deren Folgen.”

Diese allgemeingultige Definition lasst sich gut auf die Risiken in IT-Systeme uber-tragen, indem daraus die folgenden Fragen abgeleitet werden [KG81]:

1. Was kann passieren?

2. Wie wahrscheinlich ist das Eintreten?

3. Welche Konsequenzen folgen aus dem Eintreten?

Fur die Beantwortung der ersten Frage mussen sogenannte “accident scenarios” erar-beitet werden [SD11]. Diese Szenarien bestehen aus einem oder mehreren Ereignissendie eintreten konnen. Jedes Szenario hat eine bestimmte Eintrittswahrscheinlichkeit,die von den Ereignissen abhangt, welche mit der zweiten Frage evaluiert werden. DieAntwort auf die letzte Frage erklart abschließend die Auswirkung auf das System,wenn das Szenario eintritt.In jedem dieser Punkte stecken Unsicherheiten. Diese beruhen auf der Variabilitat

1Hierbei ist ein allgemeines System gemeint, “das beispielsweise ein okonomisches, ein gesell-schaftliches oder ein technisches System mit zielorientierten Werten sein kann” ([Ko13] S.10)

4 2.2. GMITS

und den Grenzen der verfugbaren Informationen (vgl. [SD11] S. 2-1).

Aus der oben genannten Definition lasst sich eine Formel zur Bestimmung des Ri-sikos herleiten. Sie besteht aus zwei Faktoren, der Eintrittswahrscheinlichkeit einesungewollten Ereignisses und dessen Konsequenzen nach dem Eintreten. (vgl. [Gmi])Risiko = Wahrscheinlichkeit * Konsequenz

2.2 GMITS

Der international anerkannte Standard GMITS (Guidelines for the Management ofIT Security) wurde von der ISO (International Organization for Standardization)definiert. Er besteht aus den folgenden 5 Teilen (vgl. [Gmi]):

Teil 1 : Konzepte und Modelle fur IT-Sicherheit,

Teil 2 : Management und Planung von IT-Sicherheit,

Teil 3 : Techniken fur das Management von IT-Sicherheit

Teil 4 : Selektion von Schutzmaßnahmen, und

Teil 5 : Sicherheit fur externe Schnittstellen

In diesen Teilen werden verschiedene IT-Sicherheitskonzepte und Modelle beschrie-ben. Zusatzlich werden Informationen und Material zur Verfugung gestellt, die Im-plementierung und Beobachtung der IT-Sicherheit ermoglichen (vgl. [Gmi]). Da sichdiese Ausarbeitung mit dem Thema der Risikoanalyse beschaftigt, wird im Folgen-den nur auf die Analyse von Risiken im Rahmen von GMITS eingegangen.

GMITS berechnet das Risiko mit Hilfe der drei Variablen “Information Asset (In-formationsbestand)”, “Threat (Bedrohung)”, und “Vulnerability (Verwundbarkeit)”.Dabei stellt die Variable “Information Asset” die Konsequenz des Risikos dar, wah-rend die anderen beiden Variablen die Wahrscheinlichkeit des Eintretens definieren.Die Multiplikation dieser drei Variablen ergibt das Riskio. (vgl. [Gmi])

Risk Value = Information Asset Value * Threat Value * VulnerabilityValue

Die Variable “Information Asset Value” ist abhangig von der jeweiligen Informationund wie wichtig der Schutz dieser ist. Zum Beispiel legen einige Firmen viel Wert aufden Datenschutz ihrer Kunden, wohingegen andere dies weniger tun. “Threat Value”gibt an, wie hoch die Angriffsfrequenz und Auswirkungen auf den Informationsbe-stand sind. “Vulnerability Value” beschreibt die Schwache der Sicherheitskontrollen.Diese Variable wird großer je schwacher die Sicherheit ist. (vgl. [NS09a])

Mit dieser relativ einfachen Formel beschreibt GMITS wie anfallig ein System gegen-uber Angreifern ist. Diese Formel zeigt allerdings nicht auf, aus welchen spezifischenGrunden ein System versagen konnte. Hierzu bedarf es anderer Verfahren, wie zumBeispiel der nachfolgend beschriebenen probabilistischen Risikoanalyse.

KAPITEL 2. RISIKOANALYSE ZUR BEWERTUNG DER IT-SICHERHEIT 5

2.3 Probabilistische Risikoanalyse

Die Probabilistische Risikoanalyse (PRA) bestimmt das Risiko der IT-Sicherheit,indem verschiedene Szenarien aufgestellt werden, welche aus Ereignissen bestehen,die anschließend in einer meist negativen Konsequenz fur das System enden. DieSzenarien werden bewertet und bekommen Eintrittswahrscheinlichkeiten zugewie-sen. Jedes Szenario beschreibt nach der Definition aus Abschnitt 2.1 ein Risiko. ImFolgenden werden die theoretischen Grundlagen der PRA erklart. Diese Grundlagenwerden anschließend im Kapitel 3 am Beispiel einer doppelten Firewall angewandt.

Die PRA wurde 1975 das erste Mal in einer Sicherheitsstudie uber Atomkraftwerkebenutzt, welche als WASH-1400 bekannt wurde [USN75]. Dies war wohl die erste,groß angelegte Analyse einer großen, komplexen Anlage, um umfassend alle Risiko-szenarien zu analysieren (vgl. [SD11] S.3-2). Spater wurde die PRA als Standard imBereich der Atomkraftwerke [ME02] und anderen Industrien definiert und angewen-det.

Es gibt insgesamt 3 PRA Level, die aufeinander aufbauen, wobei die Level 1 PRAdas grundlegende Level darstellt. Die Level 1 PRA analysiert das Risiko fur einSystem und definiert dabei welche Unfallszenarien wie haufig auftreten konnen. DieLevel 2 PRA erweitert die Level 1 PRA um die Analyse der Folgen, welche nachdem Unfall auftreten konnen. Bei einem Atomkraftwerk ware das zum Beispiel dieAnalyse wie viel radioaktives Material austritt. Die Level 3 PRA erweitert die Le-vel 2 PRA und analysiert welcher Schaden fur die Umgebung und die Bevolkerungeintreffen kann.2

Um den Umfang dieser Ausarbeitung in einem uberschaubaren Rahmen zu halten,wird im Folgenden nur die Level 1 PRA betrachtet. Diese besteht aus den folgendenAktivitaten (vgl. [HK96] S. 117):

1. Initiale Ereignisse analysieren

2. Event Tree (ET) konstruieren

3. Fault Tree (FT) konstruieren

4. Fault Tree Analyse (FTA)

5. Event Tree Analyse (ETA)

Wie am Anfang bereits erwahnt, entwickelt die PRA verschiedene Szenarien. DieseSzenarien starten mit einem initialen Ereignis, welche durch weitere Ereignisse ineiner Konsequenz enden. Diese meist negative Konsequenz stellt den Unfall bzw.das Risiko fur das System dar.

2vgl. http://www.nrc.gov/about-nrc/regulatory/risk-informed/pra.html (26.01.2014)

6 2.3. PROBABILISTISCHE RISIKOANALYSE

2.3.1 Initiale Ereignisse analysieren

Initiale Ereignisse sind erste Storungen die zu einem Eingreifen von automatischenoder manuellen Sicherheitsmaßnahmen fuhren. Um die initialen Ereignisse zu finden,gibt es zwei mogliche Vorgehensweisen. Zum einen konnen alle Informationen, welcheuber das System zur Verfugung stehen, evaluiert und daraus die initialen Ereignissezusammengestellt werden. Zum anderen kann als eher formale Vorgehensweise ei-ne Checkliste durch verschiedene Verfahren, wie zum Beispiel “preliminary hazardanalysis (PHA), failure mode and effects analysis (FMEA), hazard and operabilitystudy(HAZOPS), or master logic diagramms (MLD)” [HK96] erstellt werden3. Diemit den oben genannten Verfahren entwickelte Checkliste, listet systematisch alleProblem- und Unfallquellen auf. Aus dieser konnen anschließend initiale Ereignisseidentifiziert werden. (vgl. [HK96] S. 104)

Die gefundenen, initialen Ereignisse mussen anschließend analysiert werden. So mussidentifiziert werden, welche Sicherheitsfunktionen vorhanden sind, um zu verhindern,dass ein initiales Ereignis sich in eine negative Konsequenz verwandelt. Als Beispielkann als initiales Ereignis ein Angriff auf ein Server genommen werden. Der An-griff wird durch eine Firewall verhindert, bevor der Angreifer Zugriff auf das Systemerlangt. Solche Sicherheitsfunktionen konnen aufgrund von anderen Ereignissen al-lerdings auch ausfallen. Daraus baut sich eine Kette von Ereignissen, sogenannteUnfallszenarien, auf. Diese Unfallszenarien beginnen mit einem initialen Ereignisund fuhren uber weitere Ereignisse zu einer zu definierenden Konsequenz, beispiels-weise der unerlaubte Zugriff auf die gesamten Daten des Servers. Wenn alle initialenEreignisse analysiert sind, wird fur jedes initiale Ereignis ein Event Tree erstellt.

2.3.2 Event Tree

Ein Event Tree wird grafisch als binarer Baum dargestellt. Dabei stellt das initialeEreignis die Wurzel des Baumes dar und jedes weitere Ereignis einen Knoten. JedeEbene des Event Trees stellt eine Sicherheitsmaßnahme zum Schutz des Systemsdar. Ein Ereignis bzw. Knoten gliedert den Baum in den Erfolg oder einen Fehlerbzw. Versagen der Sicherheitsmaßnahme auf. Die Blatter des Baums sind die Kon-sequenzen aus den erfolgreichen oder fehlgeschlagenen Sicherheitsmaßnahmen. DiePfade stellen die unterschiedlichen Szenarien dar.

Jeder Fehler eines Ereignisses hat eine Eintrittswahrscheinlichkeit und/oder Ein-trittshaufigkeit, welche bestimmt werden muss. Im Folgenden wird der Einfachheits-halber nur noch von (Eintritts-)Haufigkeiten ausgegangen, auch wenn man (Ein-tritts-)Wahrscheinlichkeiten verwenden kann.

Das Finden der Haufigkeiten eines Fehlers ist eine schwierige Aufgabe. Es kanndie Effektivitat der PRA begrenzen, wenn keine realistischen und aussagekraftigen

3In dieser Ausarbeitung sollen die angegebenen Verfahren nicht weiter vertieft werden, da hiernur festgestellt werden soll, ob die PRA fur die IT-Sicherheit verwendet werden kann.

KAPITEL 2. RISIKOANALYSE ZUR BEWERTUNG DER IT-SICHERHEIT 7

Haufigkeiten abgeschatzt werden konnen [RGH07]. Deswegen werden meistens FaultTrees entwickelt, welche das Abschatzen vereinfachen. Diese werden im nachsten Ab-schnitt vorgestellt.

2.3.3 Fault Tree

Abbildung 2.1: Fundamentale Fault Tree Struktur (vgl. [HK96] S. 167)

Um das Abschatzen der Eintrittshaufigkeiten eines Fehlers in einem Event Tree zuvereinfachen, kommen Fault Trees (FT) zum Einsatz. Eine Ubersicht uber die funda-mentale Struktur eines Fault Trees ist in Abbildung 2.1 dargestellt. Fur jeden Fehlerim Event Tree wird ein Fault Tree erstellt, welcher mit dem Fehler als TOP-Ereignisstartet (top oder root event). Im FT werden daraus ruckwarts weitere Ereignisseabgeleitet. Hierbei ist es wichtig zu sehen, dass die Fault Trees umgekehrt zu denEvent Trees arbeiten. So starten FTs mit dem Fehler/Unfall und gehen anschlie-ßend zuruck zur Ursache, wohingegen die ETs bei dem initialen Ereignis, also derUrsache, starten und vorwarts zur Konsequenz bzw. zum Unfall gehen. Deswegenwird das Konstruieren der ETs auch als induktives Verfahren bezeichnet, wahrend

8 2.3. PROBABILISTISCHE RISIKOANALYSE

das Konstruieren der FTs als deduktives Verfahren bezeichnet wird (vgl. [HK96] S.100; [RGH07] S. 588).

Bei den FTs werden aus dem unerwunschten TOP-Ereignis also ruckwarts weitereEreignisse abgeleitet, die zum TOP-Ereignis fuhren. Um den Zusammenhang zwi-schen den Ereignissen und dem TOP-Ereignis zu zeigen, werden AND, OR oderandere logische Gates verwendet (vgl. [HK96] S. 167f). Bei einem AND-Gate trittdas daraus resultierende Ereignis ein, wenn alle Eingangsereignisse eintreten. Beieinem OR-Gate reicht schon das Eintreten eines Ereignisses, um das resultierendeEreignis zu erfullen.

Wie bei den Event Trees bilden sich Sequenzen von Ereignissen die zum TOP-Ereignis fuhren. Die Blatter des Baums sind Basis-Ereignisse, welche das niedrigs-te Level des FTs reprasentieren und auch die hochste Auflosung. Fur die Basis-Ereignisse sind Haufigkeiten definiert oder konnen leicht ermittelt werden.

2.3.4 Fault Tree Analyse (FTA)

Das TOP-Ereignis kann meistens aus mehreren Grunden eintreffen. Alle Zusam-menstellungen von Basis-Ereignissen, die zum Eintreffen des TOP-Ereignis fuhren,werden Cut Sets genannt. Um festzustellen, welches die wichtigsten Basis-Ereignissesind, wird versucht die “minimal cut sets” zu finden. Diese entsprechen der kleinstenAnzahl von zutreffenden Ereignissen, so dass das TOP-Ereignis eintritt. Dies ist dasqualitative Ergebnis der FTA (vgl. [HK96] S. 227ff). Dadurch kann festgestellt wer-den, welche Ereignisse den großten Einfluss auf das Ergebnis des TOP-Ereignisseshaben. Es konnen anschließend gezielt weitere Maßnahmen getroffen werden, umdas Risiko zu minimieren.

Fur das quantitative Ergebnis der FTA wird die Haufigkeit des TOP-Ereignissesanhand der Basis-Ereignisse berechnet. Das Ergebnis kann anschließend in den ETubertragen werden. (Vgl. [RGH07] S.588)

2.3.5 Event Tree Analyse (ETA)

Wenn die Eintrittshaufigkeit eines jeden Knoten bestimmt wurde, kann der EventTree analysiert werden, dies wird Event Tree Analyse (ETA) genannt. Dafur wirdjeder Pfad als einzelnes Szenario definiert. Ein Szenario beginnt dementsprechendmit dem initialen Ereignis und geht anschließend uber die verschiedenen Ereignissezur Konsequenz. Dabei werden die Eintrittshaufigkeiten der Ereignisse fur jedes Sze-nario multipliziert. So wird fur jede Konsequenz bestimmt wie haufig diese eintritt.

KAPITEL 3. PRA AM BEISPIEL EINER DOPPELTEN FIREWALL 9

3 PRA am Beispiel einer doppelten Firewall

In diesem Kapitel wird die Probabilistische Risikoanalyse (PRA) bei einem IT-System angewandt. Dies erfolgt am Beispiel einer doppelten Firewall, welches vonNaoki Satoh und Hiromitsu Kumamoto [NSK08; SK08; NS09b] entwickelt wurde. Indiesem Beispiel gibt es eine primare Firewall, welche hauptsachlich aktiv ist und dasdahinter liegende System schutzt, wie in der Abbildung 3.1 dargestellt ist. Sollte dieprimare Firewall ausfallen, wird ein Alarm ausgelost, damit ein Administrator dieDatenubertragung umleiten kann. Nach der Umstellung schutzt die Ersatz-Firewalldas System vor dem Angreifer.

Abbildung 3.1: Aufbau des Systems [NSK08]

3.1 Event Tree konstruieren

Die PRA soll nun feststellen, mit welcher Haufigkeit ein Angreifer auf einen mit einerdoppelten Firewall geschutzten Server zugreifen kann. Zur Ermittlung der Zugriffs-haufigkeit wird ein Event Tree aufgestellt, wie er in Abbildung 3.2 dargestellt ist.Als initiales Ereignis wird angenommen, dass ein Angreifer das System attackiert.Wenn die Firewall diesem Angriff standhalt und funktionsfahig bleibt, ist das Sys-tem sicher. Eine andere Moglichkeit ware das Versagen der Firewall. In diesem Fallwird normalerweise ein Alarm ausgelost und der Administrator entdeckt das Versa-gen der Firewall. Er kann das System auf die Ersatz-Firewall umstellen. Allerdingskann es auch passieren, dass das Ausfallen der Firewall nicht entdeckt wird. Dieskonnte zum Beispiel passieren, weil der Alarm nicht ausgelost wurde. In dem Fall istdas System schutzlos und der Angreifer kann auf die Daten zugreifen. Ein weiteresAusfallszenario ware, dass das Umschalten auf die Ersatz-Firewall fehlschlagt, zumBeispiel aufgrund von falschen Einstellungen.Mit dem Durchbrechen der ersten Firewall hat der Angreifer kurzzeitig die Zugriffs-moglichkeit auf die Daten bis die zweite Firewall aktiv geschaltet wird. Deswegenwird Szenario 2 in zwei Falle unterteilt. Sollte der Angreifer zum Zeitpunkt des Um-schaltens anwesend sein, kann er auf die ungeschutzten Daten kurzzeitig zugreifen.

In diesem Beispiel konnen dementsprechend 4 Szenarien eintreffen.

10 3.2. FAULT TREE KONSTRUIEREN

Szenario 1 - Die Firewall halt den Angriffen stand und funktioniert weiterhin nor-mal

Szenario 2 - Die Firewall fallt aus, der Alarm wird ausgelost, die zweite Firewallwird erfolgreich aktiviert und schutzt das System

Szenario 2.1 - Der Angreifer war zu langsam, um wahrend des Zeitfenstersan die Daten zu gelangen

Szenario 2.2 - Der Angreifer hat bis zur Aktivierung der Ersatz-Firewall aufdie Daten zugegriffen

Szenario 3 - Die Firewall fallt aus, der Alarm wird ausgelost, das Umschalten aufdie Ersatz-Firewall schlagt fehl

Szenario 4 - Die Firewall fallt aus, der Alarm wird nicht ausgelost oder wahrge-nommen

Abbildung 3.2: Event Tree fur das Firewall Beispiel [NSK08]

Mit welcher Haufigkeit ein Szenario eintrifft kann erstmal nicht analysiert werden,da erst die Fault Trees konstruiert werden mussen. Diese berechnen die notigenHaufigkeiten der jeweiligen Ereignisse in einem Szenario.

3.2 Fault Tree konstruieren

Zu jedem Fehler im Event Tree wird ein Fault Tree erstellt. Diese sind in Abbildung3.3 eingezeichnet. Mit dem Fault Tree zum Ausfall der Firewall wird gezeigt, dassdiese aus zwei Grunden ausfallen kann. Dies kann durch ein Absturzen der Firewallpassieren oder durch die falsche Konfiguration der Firewall. Beide Grunde konnenselbst wieder einen Fault Tree darstellen. So kann die Firewall zum Beispiel aufgrundeines Software- oder Hardwareproblems absturzen. Der Einfachheit halber wird die-ser Fall nicht weiter betrachtet.Zu einem Erkennungsfehler beim Alarm konnen mehrere Grunde fuhren. Diese sind

KAPITEL 3. PRA AM BEISPIEL EINER DOPPELTEN FIREWALL 11

Abbildung 3.3: Event Tree und Fault Tree des Firewall Beispiels [NSK08]

im gleichnamigen Fault Tree beispielhaft aufgefuhrt. Zum einen kann der Alarmeine Fehlfunktion haben, zum anderen kann der Administrator den Alarm aus un-terschiedlichen Grunden nicht mitbekommen.Die Ersatz-Firewall kann fehlerhaft geschaltet werden, wenn es beim Umschalten einProblem gibt oder wenn sie bereits ausgefallen ist. Dies kann zum Beispiel passierenwenn eine falsche Konfiguration zu Grunde liegt oder wenn die Firewall abgesturtztist.

12 3.3. FAULT TREE ANALYSE (FTA)

3.3 Fault Tree Analyse (FTA)

Um die FTA durchfuhren zu konnen muss fur jedes Basis-Ereignis (Blatter der FaultTrees) die Eintrittshaufigkeit und/oder die Eintrittswahrscheinlichkeit angegebenwerden. Anschließend werden daraus die TOP-Ereignisse der Fault Trees berechnet,wie sie in Abbildung 3.3 zu sehen sind.

Als Beispiel wird die Eintrittshaufigkeit fur die fehlerhafte Konfiguration der Fire-wall mit 0,005 Mal im Monat und das Absturzen der Firewall ebenfalls mit 0,005Mal im Monat festgelegt. Wenn nun davon ausgegangen wird, dass alle Ereignisseunabhangig sind, kann hergeleitet werden, dass die Eintrittshaufigkeit des Ausfal-lens der Firewall 0,01 Mal im Monat ist. Im Event Tree ist demnach P2 = 0,01.Ebenfalls kann die Fehlfunktion des Alarms beim Ausfall der Firewall mit einerWahrscheinlichkeit von 0,01 angenommen werden, sowie das Ubersehen des Alarmsauch mit 0,01. Daraus folgt eine Eintrittswahrscheinlichkeit von P3 = 0,02 fur einenErkennungsfehler. Außerdem kann fur ein Problem beim Umschalten auf die Ersatz-Firewall angenommen werden, dass dieses mit einer Wahrscheinlichkeit von 0,01passiert. Wenn nun noch fur das Absturzen 0,005 und fur das falsche Einstellen derKonfiguration 0,005 angenommen wird, folgt daraus ein fehlerhaftes Umschalten aufdie Ersatz-Firewall mit einer Wahrscheinlichkeit von P4 = 0,02. Zusatzlich wird an-genommen, dass der Angreifer in der Halfte der Falle P5 = 0,5 anwesend ist, umwahrend des Umschaltens der Firewalls an die Daten zu gelangen.

Nun sind alle Eintrittshaufigkeiten und Eintrittswahrscheinlichkeiten der TOP-Ereignissedefiniert und damit auch die aquivalenten Fehler im Event Tree. Dieser wird im fol-genden analysiert.

3.4 Event Tree Analyse (ETA)

Fur jedes Szenario des Event Trees kann jetzt berechnet werden wie haufig dieseeintreffen, falls das initiale Ereignis, der Angriff auf die Firewall, stattfindet. In die-sen Fallen ist F1 = 1. Hierbei sind nur die Szenarien 2.2, 3 und 4 interessant, dadies die Fehlerfalle sind in denen der Angreifer an die Daten gelangt.

In Szenario 2.2 fallt die Firewall P2 = 0,01 Mal im Monat aus. Das Erkennen desAlarms hat die Wahrscheinlichkeit von (1-P3) = 0,98 und das erfolgreiche Umschal-ten auf die Ersatz-Firewall ist ebenfalls (1-P4)=0,98. Der Angreifer ist in der Halfteder Falle P5 = 0,5 anwesend. Wenn das initiale Ereignis eintrifft, ist die Eintritts-haufigkeit dieses Szenarios P2*(1-P3)*(1-P4)*P5 = 0,01*0,98*0,98*0,5 = 0,0048 Malim Monat.

In Szenario 3 fallt die Firewall P2 = 0,01 Mal im Monat aus. Der Alarm wird miteiner Wahrscheinlichkeit von (1-P3) = 0,98 erkannt und das Umschalten auf dieErsatzfirewall schlagt mit P4 = 0,02 Mal im Monat fehl. Dementsprechend ist dieEintrittshaufigkeit dieses Szenarios P2*(1-P3)*P4 = 0,01*0,98*0,02 = 0,000196 Mal

KAPITEL 3. PRA AM BEISPIEL EINER DOPPELTEN FIREWALL 13

im Monat, wenn das initiale Ereignis eintrifft.

In Szenario 4 fallt die Firewall P2 = 0,01 Mal im Monat aus. Der Alarm wird miteiner Wahrscheinlichkeit von P3 = 0,02 Mal nicht erkannt. Bei einem Angriff istdieses Szenario P2*P3 = 0,01*0,02 = 0,0002 Mal im Monat moglich.

Ubersichtlich dargestellt sehen die Eintrittshaufigkeiten der Szenarien wie folgt aus:

Szenario Eintrittshaufigkeit2.2 0,00483 0,0001964 0,0002

Tabelle 3.1: Szenarien und Eintrittshaufigkeit uber einen Zeitraum von einem Monat

Nun kann aus diesen Ergebnissen berechnet werden, wie lange das System pro Monatdurchschnittlich unsicher ist. Dafur wird angenommen, dass der Administrator 10Minuten braucht, um den Alarm zu erkennen und das System auf die Ersatz-Firewallumzustellen. Fur Szenario 2.2 folgt daraus, dass fur 0,0048*10 min = 0,048 Minutenim Monat ein unerlaubter Zugriff auf das System stattfindet. Um diese Zeit zu re-duzieren, muss das Erkennen des Alarms und das Umstellen auf die Ersatz-Firewallbeschleunigt werden.Fur Szenario 3 und 4 sind weitere beispielhafte Annahmen notwendig. So wird an-genommen, dass das System jeden Monat einmal grundlich kontrolliert wird. Beider Kontrolle wird das System gegebenenfalls in einen sicheren Zustand zuruck ge-fuhrt. Außerdem wird der Einfachheit halber angenommen, dass die beiden Szenarienwahrend der Halfte des Inspektionsintervalls stattfinden. Das waren 15 Tage bezie-hungsweise 21600 Minuten vor der nachsten Inspektion. Dementsprechend findetbei Szenario 3 fur 0,000196*21600=4,23 Minuten unerlaubter Zugriff auf die Datenstatt. Das entspricht ungefahr 88 mal langer als der Zugriff in Szenario 2.2. Bei Sze-nario 4 finden 0,0002*21600=4,32 Minuten unerlaubter Zugriff statt, was ungefahr90 mal langer als Szenario 2.2 ist. Um diese Zeit zu reduzieren muss die Inspektionhaufiger stattfinden. Die Tabelle kann demnach wie folgt erweitert werden:

Szenario Eintrittshaufigkeit Dauer des Zugriffs2.2 0,0048 0,048 Minuten3 0,000196 4,23 Minuten4 0,0002 4,32 Minuten

Tabelle 3.2: Szenarien, Eintrittshaufigkeit und Dauer des Zugriffs pro Monat

Der Tabelle 3.2 ist zu entnehmen, dass die Eintrittshaufigkeit von Szenario 2.2 zwarhoher als bei den anderen beiden Szenarien ist, allerdings ist die Dauer des Zugriffsbei Szenario 3 und 4 wesentlich hoher. Am wichtigsten ist es demnach, den Inspek-tionsintervall zu reduzieren, da dadurch Szenario 3 und 4 einen wesentlich geringereunerlaubte Zugriffszeit pro Monat gewahren.

14 3.4. EVENT TREE ANALYSE (ETA)

KAPITEL 4. FAZIT UND AUSBLICK 15

4 Fazit und Ausblick

In dieser Ausarbeitung wurde die probabilistische Risikoanalyse im Bereich der IT-Sicherheit beschrieben und beispielhaft angewandt. Dafur wurde zuerst aufgegrif-fen, wie der Begriff Risiko in der IT-Sicherheit definiert ist. Das Risiko ist eineunerwunschte Abweichung vom System-Ziel die mit einer Wahrscheinlichkeit (Hau-figkeit) eintreffen kann. Nach dem internationalen Standard GMITS kann das Risikomit Hilfe einer Formel berechnet werden, welche in dieser Arbeit vorgestellt wurde.Dabei werden die Werte von Informationsbestand, Bedrohung und Verwundbarkeiteines Systems multipliziert. Dieses Verfahren uberzeugt durch seine Einfachheit, er-klart allerdings nicht, aus welchen spezifischen Grunden das System einem Risikoausgesetzt ist und verkettet dabei auch keine Ereignisse. Allerdings ist die Risiko-analyse auch nur ein kleiner Teilbereich von GMITS, da der Großteil sich mit demManagement von IT-Sicherheit beschaftigt.

Mit der vorgestellten probabilistische Risikoanalyse (PRA) ist dies allerdings mog-lich. Die PRA wurde bisher auf physische Systeme angewandt und beruht nichtwie GMITS, ausnahmslos auf der virtuellen Welt von IT-Systemen. Die PRA wirddementsprechend auf ein neues Themengebiet angewandt, wobei die Funktionsweisegleich bleibt. So wird zuerst analysiert, welche initialen Ereignisse eintreffen kon-nen, die zu einem Unfall fuhren konnen. Diese werden als Startpunkt einer Sequenzgenommen, welche eine Verknupfung von darauffolgenden Ereignissen darstellt, dieanschließend in eine Konsequenz, zum Beispiel dem Versagen des Systems, endet.Die Ereignisse bekommen Haufigkeiten(Wahrscheinlichkeiten) zugewiesen. Darauslasst sich fur jede Konsequenz berechnen, wie haufig oder mit welcher Wahrschein-lichkeit diese eintrifft. Eine negative Konsequenz, samt ihrer Wahrscheinlichkeit, istnach der oben genannten Definition ein Risiko fur das System.

PRA und GMITS im Vergleich

Die PRA hat den Vorteil, dass durch das Aufzeichnen und Berechnen der SequenzenAbhangigkeiten von Ereignissen offensichtlich werden. Außerdem kann ermittelt wer-den, aus welchen Grunden ein Teilsystem versagen kann und welche Konsequenzenwiederum fur das Gesamtsystem entstehen. Dies ist fur das Risikomanagement, demErgreifen von Maßnahmen gegen unerwunschte Risiken, ein entscheidender Vorteil.Anhand der Sequenzen konnen kritische Teilsysteme erkannt und entsprechend bes-ser geschutzt werden. Im PRA Beispiel dieser Arbeit, kann durch das Reduzieren derInspektionszyklen auch die Dauer der illegale Zugriffe auf die Daten reduziert wer-

16

den. Allerdings ist das vollstandige Entwerfen und Analysieren der Event und FaultTrees sehr aufwandig. Gerade das Finden der Haufigkeiten fur die Basis-Ereignisseist besonders schwierig und kann das Ergebnis der PRA maßgeblich beeinflussen.Im Gegensatz zum GMITS Ansatz erfordert die PRA einen großeren Aufwand, wel-cher im praktischen Umfeld bei besonders wichtigen Systemen allerdings betriebenwerden sollte. Die Risikoanalyse der PRA ist fur die IT-Sicherheit wertvoll.

Die PRA bietet zwar klare Vorteile gegenuber dem internationalen Standard GMITS.Allerdings besteht GMITS aus mehr, als der in dieser Arbeit vorgestellten Formel.Wie der Name “Guidelines for the Management of IT Security” erlautert, ist GMITSeine Richtlinie fur das Management von IT-Sicherheit, wohingegen die PRA auf dieAnalyse von Risiken spezialisiert ist. Dementsprechend werden zwei Systeme vergli-chen, die unterschiedlich ausgelegt sind.

Ausblick

Da die beiden Verfahren GMITS und PRA unterschiedlich ausgelegt sind, kannversucht werden die PRA um den fehlenden wichtigen Managementteil zu erwei-tern. Genau diese Erweiterung wird fur allgemeine Systeme im Buch “ProbabilisticRisk Assessment and Management for Engineers and Scientists” von H. Kumamotound E.J. Henley erlautert. Die PRA wird zur sogenannten PRAM (ProbabilistischeRisikoanalyse und Management). Aus dieser konnte ein Gesamtkonzept fur die IT-Sicherheit hergeleitet werden, welches anschließend dem internationalen StandardGMITS ebenburtig gegenuber gestellt werden kann.

LITERATUR 17

Literatur

[Gmi] The Guidelines for the managemen t of IT security. TR13335. ISO. 2000.

[HK96] Ernest J. Henley Hiromitsu Kumamoto. Probabilistic Risk Assessmentand Management for Engineers and Scientists. 2. Aufl. IEEE Press, 1996.isbn: 0-7803-1004-7.

[KG81] Stanley Kaplan und B. John Garrick.”On The Quantitative Definition

of Risk“. In: Risk Analysis 1.1 (1981), S. 11–27. issn: 1539-6924. doi:10.1111/j.1539-6924.1981.tb01350.x. url: http://dx.doi.org/10.1111/j.1539-6924.1981.tb01350.x.

[Ko13] Hans-Peter Konigs. IT-Risikomanagement mit System. Springer Fachme-dien Wiesbaden, 2013. isbn: 978-3-8348-2165-2. url: http://www.ub.tu-dortmund.de/katalog/titel/1371649.

[ME02] American Society of Mechanical Engineers. Standard for ProbabilisticRisk Assessment for Nuclear Power Plant Applications. ASME RA-S-2002. American Society of Mechanical Engineers, 2002. isbn: 9780791827451.url: http://books.google.de/books?id=jn2xAAAACAAJ.

[NS09a] Nikos E. Mastorakis u. a., Hrsg. An Application of Probabilistic Risk As-sessment to Information Security Audit. Moscow, Russia: World Scienti-fic, Engineering Academy und Society (WSEAS), 2009, S. 436–443. isbn:978-960-474-107-6.

[NS09b] Hiromitsu Kumamoto Naoki Satoh.”Analysis of Information Security

Problem by Probabilistic Risk Assessment“. In: International Journal ofComputers 3 (3 2009), S. 337–347.

[NSK08] Hiromitsu Kumamoto Naoki Satoh und Yasunobu Kino.”Viewpoint of

ISO GMITS and Probabilistic Risk Assessment in Information Securi-ty“. In: International Journal of Systems Applications, Engineering andDevelopment 2 (4 2008), S. 237–244.

[RGH07] P.A.S. Ralston, J.H. Graham und J.L. Hieb.”Cyber security risk assess-

ment for {SCADA} and {DCS} networks“. In: {ISA} Transactions 46.4(2007), S. 583 –594. issn: 0019-0578. doi: http://dx.doi.org/10.1016/j.isatra.2007.04.003. url: http://www.sciencedirect.com/science/article/pii/S0019057807000754.

[SD11] Michael Stamatelatos und Homayoon Dezfuli. Probabilistic Risk Assess-ment Procedures Guide for NASA Managers and Practitioners. NASAHeadquarters. 2011.

18 LITERATUR

[SK08] Comparison of ISO GMITS and Probabilistic Risk Assessment in Infor-mation Security. 2008, S. 351–355.

[USN75] USNRC. Reactor safety study: An assessment of accident risk in U.S.commercial nuclear power plants. Techn. Ber. WASH1400, NUREG-75/014.USNRC, 1975.