Proseminar:

Werkzeugunterstützung für sichere Software

Software Engineering

Sommersemester 2015

Proseminar

Security Engineering Stephen Wienkamp

8. Juli 2015

Technische Universität Dortmund Fakultät Informatik

Lehrstuhl 14 Software Engineering – Prof. Dr. Jan Jürjens

betreut durch: Jens Bürger

I

Stephen Wienkamp

Stephen.Wienkamp@udo.edu Matrikelnummer: 172224 Studiengang: Bachelor Informatik

Werkzeugunterstützung für sichere Software Thema: Security Engineering

Eingereicht: 8. Juli 2015

Betreuer: Jens Bürger

Prof. Dr. Jan Jürjens Lehrstuhl 14 Software Engineering Fakultät Informatik Technische Universität Dortmund Otto-Hahn-Straße 14 44227 Dortmund

II

Ehrenwörtliche Erklärung Ich erkläre hiermit ehrenwörtlich, dass ich die vorliegende Arbeit selbstständig angefertigt habe. Sämtliche aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und noch nicht veröffentlicht.

Dortmund, den 8. Juli 2015 ___________________________

Unterschrift

III

Abstract This paper gives a quick Overview of the most important tools and techniques of Security Engineering. It gives a short introduction into general construction principles of software engineering. It starts with a structure analysis to define the general outline of an IT-System. This information is used to extract all objects that need to be secured. The next step that is explained is to categorise these object into categories of how important they are and how good their security has to be. After that the threat analysis comes into play and takes the new found results to find scenarios that can cause harm to assets. To gather information about the necessity of which security standard to use, a risk analysis is explained.

Inhaltsverzeichnis IV

Inhaltsverzeichnis

Ehrenwörtliche Erklärung ........................................................................................................... II

Abstract ..................................................................................................................................... III

Inhaltsverzeichnis ...................................................................................................................... IV

1 Einleitung ............................................................................................................................ 1

2 Entwicklungsprozess ........................................................................................................... 2

2.1 Allgemeine Konstruktionsprinzipien ........................................................................... 2

2.2 Konstruktionsphasen ................................................................................................... 3

3 Strukturanalyse ................................................................................................................... 5

3.1 Erfassung der Anwendungen und der zugehörigen Informationen ............................ 5

3.2 Netzplanerhebung ....................................................................................................... 6

3.3 Erhebung der IT-Systeme ............................................................................................ 7

3.4 Erfassung der Räume ................................................................................................... 7

4 Schutzbedarfsermittlung .................................................................................................... 7

5 Bedrohungsanalyse ............................................................................................................ 9

5.1 Bedrohungsmatrix ....................................................................................................... 9

5.2 Bedrohungsbaum ...................................................................................................... 10

6 Risikoanalyse .................................................................................................................... 11

7 Fazit und Ausblick ............................................................................................................. 13

Literaturverzeichnis .................................................................................................................. 14

1. Einleitung 1

1 Einleitung Das Security Engineering ist ein Thema das heutzutage eine zunehmende Rolle spielt bei der Erstellung von neuen und vor allem sicheren IT-Systemen, aber auch bei bereits integrierten Systemen. Es beschäftigt sich mit den Frage „Wie kann ich mein System schützen?“, „Wie gehe ich vor um Lücken in meinem System zu finden?“ und „wie entscheide ich, ob oder wie sehr muss ich bestimmten Stellen meines Systems schützen?“ Diese Arbeit gibt einen Überblick über die frühe Phase des Security Engineerings und fokussiert speziell auf die Struktur-, Bedrohungs- und Risikoanalyse. Maßnahmen zur Bekämpfung der gefunden Probleme werden dahingegen nur sehr flüchtig behandelt.

Diese Arbeit versucht einen gröbere Übersicht über das Security Engineering zu schaffen um einen schnelleren Einblick zu bekommen in die Aufgaben die man zu bewältigen hat um sicherer Systeme hervorzubringen.

Es beginnt mit einer kurzen Einleitung und einer Übersicht über den kompletten Prozess des Security Engineerings im zweiten Kapitel. Hier werden auch allgemeine Konstruktionsprinzipien erklärt, die ein Fundament für die folgenden Kapitel liefern. Im dritten Kapitel geht es mit der Strukturanalyse weiter, die einen Überblick über das System schaffen soll und zudem die Grundlage der nächsten Kapitel bildet. Kapitel 4 beschäftigt sich mit dem Schützen von Objekten und wie man einschätzt, wie stark oder schwach ein Objekt geschützt werden muss. Diese Information wird dann in Kapitel 5 genutzt, um mögliche Bedrohungsszenarien zu entwickeln, in denen beschrieben wird, wie man Zugriff zu den zu schützenden Objekten erlangt. Hat man auch diese Analyse vollzogen so kann man eine Risikoanalyse zur Einschätzung verschiedener Szenarien durchführen. Diese wird in Kapitel 6 genauer beschrieben.

2. Entwicklungsprozess 2

2 Entwicklungsprozess Der Entwicklungsprozess für Sichere System sollte immer auf Grundlage eines Entwicklungsmodelles geschehen. Diese erhöhen das Sicherheitsniveau von Software drastisch, wenn man sie gewissenhaft und vollständig anwendet. 1 Etablierte und vollständige Rahmenwerke für solche Entwicklungsmodelle sind z.B. Microsofts SDL2 oder das Software Assurance Forum for Excellence in Code (SAFECode)3. In diesen Rahmenwerken finden sich allerdings Gemeinsamkeiten in der Generellen Struktur des Vorgehens sowie in den Vorgeschlagenen Tools und Methoden zur Erhöhung der Sicherheit von Software. Strukturanalyse, Bedrohungsanalyse und Risikoanalyse sind eben solche Tools, die direkt als solche oder in ähnlicher Form immer wieder auftauchen, wenn man sich mit der Erstellung von sicheren Systemen beschäftigt. Diese werden in dieser Arbeit in späteren Kapiteln detaillierter vorgestellt.

Darüber hinaus gibt es Forschungsansätze zur Schließung signifikanter Lücken bei der Erstellung von sicherer Software.4 Dazu zählt das Projekt Bauhaus5 der Universitäten Stuttgart und Bremen, welches zur Analyse von Programmverhalten und Architektur genutzt werden kann. Des Weiteren stellt SAFE6 ein hierarchisches Programmiermodell zur sicheren Erweiterbarkeit von Webanwendungen dar.

Im weiteren Verlauf dieses Kapitels werden allgemeine Konstruktionsprinzipien sowie eine grobe Übersicht über die Konstruktionsphasen von Sicherer Software vorgestellt.

2.1 Allgemeine Konstruktionsprinzipien Schon 1975 haben Saltzer und Schroeder 7 sich Gedanken über die Konstruktion Sicherer Software gemacht und haben dafür verschieden allgemeine Prinzipien erstellt die auch heut noch immer ihre Gültigkeit haben.

- Erlaubnisprinzip (engl. fail-safe dafaults): Es wird gefordert, dass grundsätzlich jeder Zugriff und jede Aktion verboten ist solange es keine explizite Erlaubnis dafür gibt.

- Vollständigkeitsprinzip (engl. complete mediation):

1 Vgl. Mic13

2 https://www.microsoft.com/en-us/sdl/default.aspx

3 http://www.safecode.org

4 Vgl. WMM13 S.17

5 http://www.iste.uni-stuttgart.de/ps/projekt-bauhaus.html

6 RGB12

7 SaSc75

2. Entwicklungsprozess 3

Jeder Zugriff ist zu kontrollieren. Das bedeutet z.B. das Zugriffsrechte auf eine Dateie in einem System nicht nur beim Öffnen und schreiben kontrolliert werden muss, sondern auch dann wenn sich die Leserechte ändern, da sonst jemand, der vor der Rechteänderung lesen durfte, auch nach der Änderung lesen kann, gegeben das er die Datei während der Änderung bereits geöffnet hatte. Ein System, in dem dies nicht überprüft wird, würde das Vollständigkeitsprinzip verletzen.

- Minimale Rechte Prinzip (engl. need-to-know): Jeder Akteur im System darf nur genau die Rechte bekommen, die er zur Erfüllung seiner Aufgaben benötig. Ein Superuser, der uneingeschränkt in seinem Handeln ist, verstößt gegen dieses Prinzip.

- Akzeptanz (engl. economy of mechanism): Das Prinzip der (Benutzer)Akzeptanz fordert, dass die Mechanismen, die zur Einhaltung der Sicherheit genutzt werden, einfach anzuwenden sind.

- Offener Entwurf (eng. Open design): Das Prinzip des offenen Entwurfs verlangt, dass Verfahren und Methoden, die in einem System verwendet werden, offen gelegt werden. Die Sicherheit des Systems darf nicht durch Geheimhaltung der Verfahren, sowie deren Funktionsweise, gewährleistet sein.

2.2 Konstruktionsphasen Die Konstruktion von sicheren Systemen kann in vier Phasen eingeteilt werden, welche in Abbildung 2.1 dargestellt sind. Die Phasen werden iterierend durchlaufen.8

Planungsphase:

Es werden Anforderungen an das zu erstellende System aufgestellt und z.B. in einem Pflichtenheft festgehalten. Um die Anforderungen zu erarbeiten kann eine Strukturanalyse durchgeführt werden, welche in Kapitel 3 genauer erläutert wird. Sind diese Punkte abgearbeitet muss der Schutzbedarf ermittelt werden. Die Vorgehensweise dabei wird in Kapitel 4 vorgestellt. Ist der Schutzbedarf ermittelt kann eine Bedrohungsanalyse, sowie eine Risikoanalyse durchgeführt werden. Diese werden in Kapitel 5 bzw. 6 erläutert. Danach kann man in die nächste Phase übergehen.

Ausführungsphase:

Mit den Ergebnissen der Planungsphase können nun die Sicherheitsanforderungen formuliert werden. Zudem kann die Systemarchitektur zur Erfüllung der Sicherheitsanforderungen

8 Vgl. Eck12 S.189

2. Entwicklungsprozess 4

entworfen werden.9 „Zur Realisierung der Architektur werden Maßnahmen, Dienste und Protokolle benötigt, durch deren Einsatz ein funktionsfähiges System konstruiert wird.“10

Prüfungsphase:

Diese Phase setzt ein funktionsfähiges System voraus und dient zur Validierung des erstellten Systems. Es wird überprüft, ob das System die in der ersten Phasen erstellten Anforderungen erfüllt. Abweichungen von den erwarteten Ergebnissen werden in der nächsten Phase gehandhabt.

Anpassungsphase:

Sind Fehler oder Verbesserungen erkannt worden während der vorrangegangen Phase können nun die Anforderungen „ergänzt verfeinert oder präzisiert“11 werden. Dies kann zur Folge haben, dass sich Bedrohungen und deren Bewertung verändern und die Maßnahmen zur Bekämpfung dieser revidiert werden müssen.

Abbildung 2.1 Vorgehen (Eck12 S. 189 Abbildung 4.1)

9 Vgl. Eck12 S.190

10 Eck12 S.190

11 Eck12 S.190

3. Strukturanalyse 5

3 Strukturanalyse „Die Strukturanalyse dient der Vorerhebung von Informationen, die für die weitere Vorgehensweise in der Erstellung eines Sicherheitskonzepts nach IT-Grundschutz benötigt werden.“12 Die Analyse kann in vier Teilaufgaben aufgeteilt werden, die in den folgenden Unterkapiteln genauer erläutert werden. Dieses Vorgehen orientiert sich stark an den Vorgaben aus dem BSI-Standard 100-213 und nutzt ein Beispiel aus dem Standard, um die einzelnen Aufgabengebiete zu erläutern.

Um die Komplexität dieser Analyse zu reduzieren, können Gruppen von Objekten gebildet werden, die z.B. aus dem Blick der Sicherheit den gleichen Schutzbedarf benötigen oder vom gleichen Typ sind. Aus dieser Gruppierung kann geschlossen werden, dass wenn man Stichproben einer Gruppe auf Sicherheitsaspekte überprüft diese als Repräsentant der Gruppe gelten und Ergebnisse auf die gesamte Gruppe projiziert werden können.

3.1 Erfassung der Anwendungen und der zugehörigen Informationen Zur Erfassung und Dokumentierung der relevanten Informationen und zur einfachen Strukturierung bietet es sich an, diese in Tabellenform darzustellen. Tabelle 3.1 dient hierbei als Beispiel, wie so eine Dokumentierung aussehen kann. Man erkennt schnell die verschiedenen Anwendung, sowie welche Benutzer(-gruppen) diese benutzen und welche Informationen ihnen zur Ausführung ihrer Arbeit bereitgestellt werden müssen.

Die Geschäftsprozesse sind so gegliedert, dass nach dem Kürzel GP die Nummer des Hauptprozesses und danach gegebenenfalls nach einem Bindestrich die Nummer des Unterprozesses geschrieben ist. Zudem muss immer notiert werden, wer für welche Anwendungen zuständig ist, damit man bei Fragen direkt weiß an wen man sich wenden muss.

Allerdings müssen nur die Anwendungen, Geschäftsprozesse oder Fachaufgaben betrachtet werden, die „ein Mindestniveau an Geheimhaltung (Vertraulichkeit) (…), Korrektheit und Unverfälschtheit (Integrität) oder Verfügbarkeit erfordern.“14 Es kann dabei hilfreich sein die Verantwortlichen für die Anwendungen und Geschäftsprozesse nach ihrer Einschätzung zu befragen.

Die Art der Informationen ist Unterteilt in Personenbezogene Daten(P), verwaltungsspezifische Informationen(V), wie z.B. Dienstanweisungen, fachliche Informationen (F), wie z.B. Korrespondenz mit den Kunden, und systemspezifische Informationen(S), wie z.B. Konfigurationsdateien von IT-Systemen.

12 Vgl. BSI08A S. 39

13 BSI08A

14 BSI08A S.41

3. Strukturanalyse 6

Nr. Anwendung Art der Information

Verantwort-lich

Benutzer Geschäfts-prozesse

A1 Personaldatenverarbeitung P Z1 Z1 GP0-1, GP0-2

A2 Beihilfeabwicklung P Z2 alle GP0-2

A3 Reisekostenabrechnung P/V/F Z2 alle GP0-1, GP0-3

A4 Benutzer-Authentisierung P/S IT1 alle GP0, GP5, GP6

A5 Systemmanagement S IT3 IT3 alle

A6 Bürokommunikation P/V/F/S IT3 alle alle

A7 zentrale Dokumenten-verwaltung

P/V/F/S Z1 alle GP0, GP5

A8 USB-Sticks zum Daten-trägeraustausch

P/V/F IT3 IT3 GP0-1, GP0-3

Tabelle 3.1 Beispiel BOV (vgl. BSI08A S.42)

3.2 Netzplanerhebung Der Netzplan stellt eine Übersicht über die einzelnen IT-Komponenten dar. Wie in allen Teilaufgaben der Strukturanalyse können auch hier Komponenten zu Gruppen zusammengefasst werden. In so einem Netzplan sollte deutlich gemacht werden um was für Komponenten es sich handelt und wie diese verbunden sind. In Abbildung 3.1 ist ein Beispiel von einem Netzplan dargestellt.

Obwohl alle Clients nahezu gleich konfiguriert werden müssen sind sie nicht in eine Gruppe zusammengefasst, da sie unterschiedliche Informationen verarbeiten müssen und somit unterschiedlich in das Netz eingebunden werden.

Um den Prozess der Erstellung des Netzplans zu beschleunigen oder zu vereinfachen sollte man zuerst schauen ob vielleicht bereits ein Netzplan vorhanden ist, und dieser gegebenenfalls nur noch erweitert werden oder auf den aktuellsten Stand gebracht werden muss. Die Beschreibung der einzelnen Komponenten(-gruppen) des Netzplans wird im nächsten Schritt genauer spezifiziert.

4. Schutzbedarfsermittlung 7

Abbildung 3.1 Beispiel eines Netzplans (vgl. BSI08A S.45)

3.3 Erhebung der IT-Systeme In diesem Schritt werden die im vorherigen Schritt gefundenen Komponentengruppen strukturiert erfasst. Es sollte eine Beschreibung jeder Gruppe, die genutzte Plattform (Betriebssystem), die Anzahl an Komponenten, den Aufstellungsort, den Betriebsstatus sowie die Anwender strukturiert aufgelistet werden.

Um einen Bezug zu den in Schritt 1 herausgefundenen Anwendungen zu schaffen, sollte niedergeschrieben werden, welche Anwendung auf / mit welchen IT-Systemen operiert.

3.4 Erfassung der Räume Es müssen alle Räume in denen schützenwerte Güter aufbewahrt werden aufgelistet werden. Darüber hinaus sollte jeder Raum eine eindeutige Bezeichnung haben, die Art des Raumes (z.B. Serverraum), den Ort (z.B. Gebäude), die IT-Systeme, aus den beiden vorrangegangenen Schritten, die sich in dem Raum befinden sowie den Schutzbedarf für die Räume. Wobei der Schutzbedarf an dieser Stelle noch nicht eingetragen wird. Er wird lediglich an dieser Stelle eingetragen sobald er ermittelt wurde. Wie dies funktioniert wird im nächsten Kapitel erklärt.

4 Schutzbedarfsermittlung „Die Schutzbedarfsermittlung der Komponenten eines IT-Verbundes geschieht auf Basis der Daten der Strukturanalyse. Da Metriken für die Bestimmung des Schutzbedarfs oft fehlen“ 15schlägt der IT-Grundschutz eine Einreihung in die drei Kategorien „normal“, „hoch“ und

15 DiHa08 S.200

4. Schutzbedarfsermittlung 8

„sehr hoch“ vor.16 Hierbei gilt ein Schadensfall als „normal“, wenn die Schadensauswirkung überschaubar ist. Können die Auswirkungen beträchtliche Ausmaße annehmen so ist ein Objekt in die Kategorie „hoch“ einzuordnen. Schäden, die existentielle oder katastrophale Ausmaße annehmen können sind in die Kategorie „sehr hoch“ einzustufen.

Generell gibt es die folgenden sechs Schadenszenarien17:

- Verstoß gegen Gesetze/Vorschriften/Verträge, - Beeinträchtigung des informationellen Selbstbestimmungsrechts, - Beeinträchtigung der persönlichen Unversehrtheit, - Beeinträchtigung der Aufgabenerfüllung, - negative Innen- oder Außenwirkung und - finanzielle Auswirkungen.

Es folgen nun drei Beispiele die einen groben Überblick geben sollen was man unter den Schutzkategorien verstehen kann.

Beispiel 1: Ein Unternehmen muss Konkurs anmelden, da es Vertragsvereinbarungen verletzt hat die immense Geldstrafen zur Folge hatten. Dieses Szenario würde in die Kategorie „sehr hoch“ eingeordnet werden.

Beispiel 2: Durch eintreten eines bestimmten Ereignisses kann eine Beeinträchtigung der persönlichen Unversehrtheit nicht absolut ausgeschlossen werden. Dies Ereignis müsste in die Kategorie „hoch“ eingeordnet werden.

Beispiel 3: Es sind nur geringe Auswirkungen auf das Äußere Aussehen einer Firma zu befürchten oder es sind nur Interne Ansehensverluste zu erwarten. Dieses Szenario wird in die Kategorie „normal“ eingestuft.

„Vereinfacht kann man sagen, dass bei einer Schutzbedarfsermittlung systematisch Fragen der Art: was wäre wenn, . . . zu stellen und zu beantworten sind.“18 Diese Fragen müssen für alle Schützenswerten Objekte gemacht werden. Es sollte, analog zur Strukturanalyse, jeweils für IT-Systeme, Räume sowie für die Verbindungen der Schutzbedarf festgestellt werden.

Als nächster Schritt muss nun der Ist-Zustand des Systems in Hinsicht auf Sicherheit festgestellt werden. Des Weiteren müssen die Lücken zwischen Soll-Zustand, der gerade ermittelt worden ist, und Ist-Zustand gefunden werden. Hierzu empfiehlt es sich, eine Bedrohungs-, so wie eine Risikoanalyse durch zu führen. Diese werden in den nächsten Kapitelt erläutert.

16 BSI08A S.49

17Vgl. BSI08A S.49

18 Eck12 S. 200

5. Bedrohungsanalyse 9

5 Bedrohungsanalyse Die Bedrohungsanalyse stellt eine wichtige Vorgehensweise, um Bedrohungen aus organisatorischen, technischen und benutzerbedingten Quellen und deren potenziellen Schäden zu ermitteln. „Zur Unterstützung einer methodischen Vorgehensweise zur Erfassung der relevanten Bedrohungen kann man einen matrix- oder einen baumorientierten Analyseansatz wählen.“19 Zudem gibt es verschiedene Tools, die einem bei der Erstellung der Analyse helfen können. Zu diesen Tools gehörten z.B. TRIKE, das ein konzeptionelles Framework für Sicherheitsüberwachung aus der Sicht des Risikomanagements zur Erstellung von Bedrohungsmodellen bietet. 20

In den nächsten beiden Unterkapiteln werden jeweils die Bedrohungsmatrix sowie die Bedrohungsbaum vorgestellt. Im dritten und letzten Unterkapitel werden dann noch einmal beide Methoden mit einander verglichen und Vor- und Nachteile aufgestellt.

5.1 Bedrohungsmatrix Die Zeilen einer Bedrohungsmatrix bilden Gefährdungsbereiche. Die in Tabelle 5.1 Tabelle 5.1 Bedrohungsmatrix (Vgl. Eck12 S.202)sind nur Beispielbereiche und können frei gewählt werden. Die Spalten bilden die potentiellen Auslöser von Bedrohungen. In die einzelnen Felder trägt man nun die verschiedenen potentiellen Szenarien ein die von einem der Auslöser auf einen bestimmten Bereich ausgeübt werden könnte.

Programmierer Interner Benutzer

Externer Benutzer

Mobiler Code

Externe

Angriffe

u.a. Vandalismus

Beobachten der Passworteingabe

- -

Interne

Angriffe

Direkter Spei-cherzugriff

Logische Bomben

Passwort knacken

Viren

Verfügbarkeit Speicher beleben

Prozesse erzeugen

Netzlast erzeugen

Monopoli-sieren der CPU

Tabelle 5.1 Bedrohungsmatrix (Vgl. Eck12 S.202)

Um einmal ein Beispiel genauer zu erläutern könnte z.B. ein Externen Benutzer versuchen die Verfügbarkeit eines Online-Services oder einer Website mit einer so genannt Denial-of-Service Attacke zu beeinträchtigen. Bei so einem Angriff versucht man so viel Last auf einen Server

19 Eck12 S.201

20 Vgl. SLE05 S.1

5. Bedrohungsanalyse 10

der Firmen auszuüben, bis dieser keine weiteren Anfragen mehr verarbeiten kann und niemand mehr die Seite oder den Service nutzen kann.

5.2 Bedrohungsbaum Als alternative zu einer Bedrohungsmatrix kann man auch einen Bedrohungs- oder Angriffsbaum erarbeiten. Hierbei wird durchgespielt in welcher Reihenfolge Ereignisse eintreten müssen damit Schützenswerte Objekte beeinträchtigt oder gefährdet sind.

In Abbildung 5.1 sieht man ein Beispiel von einem Bedrohungsbaum. Dargestellt ist ein Szenario, um einen Tresor zu öffnen. Um diesen Tresor zu öffnen muss der Angreifer, entweder das Schloss knacken oder die Kombination kennen. Um die Kombination zu kennen, müsste er entweder die Kombination auf einem Zettel finden und merken oder den Besitzer (Opfer) belauschen und ihn dazu verleiten, die Kombination preiszugeben.

Abbildung 5.1 Bedrohungsbaum Vgl. Ruh14

Da ein solcher Bedrohungsbaum sehr schnell sehr groß werden kann, wenn man sich Komplexere Angriffsszenarien anschaut, gibt aus auch noch die Möglichkeit diesen Baum in textueller auszuschreiben. Ein Ausschnitt, Abbildung 5.1 in solch einer Form würde wie folgt aussehen.

Ziel: Tresor öffnen

ODER Subziel 1: Schloss knacken

Tresor öffnen

Schloss knackenKombination

kennen

Kombination vom Opfer

Bedrohen Belauschen

Zur Preisgabe der Kombination

verleiten

Kombination nicht vom Opfer

Kombination auf Zettel lesen

6. Risikoanalyse 11

Subziel 2: Kombination kennen

ODER Subziel 2.1: Kombination vom Opfer

Subziel 2.2: Kombination nicht vom Opfer

Man erkennt sehr einfach das „Angriffsbäume (…)eine geeignete Technik sind, um sich auf eine systematische Weise die verschiedenen Wege zum Erreichen eines Angriffsziels klar zu machen“21.

6 Risikoanalyse Hat man nun alle Bedrohungen erfasst, so kann man eine Risikoanalyse zur Bewertung dieser durchführen. Hierbei versucht man mit möglichst geringem Aufwand festzustellen, „ob und in welcher Hinsicht über den IT-Grundschutz hinaus Handlungsbedarf zur Begrenzung von Risiken für die Informationsverarbeitung besteht.“22 Es wird bei dieser Methode strukturiert in fünf Schritten vorgegangen. Diese fünf Schritte sind folgende23:

- Erstellung einer Gefährdungsübersicht - Ermittlung zusätzliche Gefährdungen - Gefährdungsbewertung - Behandlung von Risiken - Konsolidierung des Sicherheitskonzepts

Die ersten beiden Punkt sollten bereits durch die Durchführung einer Bedrohungsanalyse überdeckt sein und werden deshalb nur kurz beschrieben, da die Ergebnisse der Bedrohungsanalyse für die weiteren Schritte verwendet werden können.

Ist keine Bedrohungsanalyse durchgeführt worden, so muss zuerst eine Übersicht über potenzielle Gefährdungen erstellt werden. Diese sollten einzelnen Objekten aus der Strukturanalyse zugeordnet werden können. Zudem werden nur Gefährdungen betrachtet die vom IT-Grundschutzkatalog abgedeckt werden.

Im zweiten Schritt sollen nun zusätzliche Gefährdungen gefunden werden, die nicht vom IT-Grundschutzkatalog abgedeckt werden. Dies kann dann der Fall sein wenn z.B. besondere Technologien oder spezielle Produkte eine Bedrohung entsteht oder die Voraussetzung für eine Bedrohung sehr speziell ist.

„Im nächsten Schritt wird die Gefährdungsübersicht systematisch abgearbeitet und für jedes Zielobjekt und jede Gefährdung geprüft, ob die bereits umgesetzten oder zumindest im Sicherheitskonzept vorgesehenen Sicherheitsmaßnahmen einen ausreichenden Schutz

21 Eck12, S. 207

22 BSI08B, S. 4

23 Vgl. BSI08B, S.5 Abbildung 1

6. Risikoanalyse 12

bieten.“24 Die Ergebnisse werden notiert, sodass erkenntlich ist, welche Objekte und Gefährdungen ausreichend geschützt sind bzw. gehandhabt werden. Für die Objekte und Gefährdungen, für die keine Lösungen gefunden wurden, werden im nächsten Schritt Alternativen gesucht.

Im Grunde gibt es vier alternative Möglichkeiten zum Umgang mit Risiken. Die erste Möglichkeit ist, die Reduktion des Risikos durch zusätzliche oder strengere Sicherheitsmaßnahmen. Als zweite Möglichkeit steht eine Umstrukturierung zur Verfügung, die unter Umständen auch Risiken minimieren oder gänzlich vermeiden kann. Möglichkeit drei ist es das Risiko in Kauf zu nehmen, da der Eintritt des Bedrohungsszenarios nur unter ganz bestimmt Voraussetzungen eintreten kann. Die letzte Alternative ist es das Risiko an eine andere Institution weiterzuleiten, z.B. durch Abschluss eines Versicherungsvertrages.

Der letzte Schritt beschäftigt sich damit noch einmal alle gesammelten Informationen zu durchleuchten und zu hinterfragen, ob die Maßnahmen ausreichen um Gefahren abzuwehren, sie als Ganzes funktionieren, die Benutzer die Sicherheitsmaßnahmen akzeptieren und diese der Gefahr der sie entgegenstehen gewachsen sind.

Mit den Ergebnissen der Hinterfragung sollte das Sicherheitskonzept noch einmal durchgegangen und gegebenenfalls angepasst werden.

24 BSI08B S.15

7. Fazit und Ausblick 13

7 Fazit und Ausblick Die Arbeit hat einen groben Überblick über das Security Engineering und speziell die Analyse Tools zur Erkennung von Lücken in der Sicherheit eines Systems zusammengefasst. Es wurde grundlegende Konstruktionsprinzipien erklärt, die in jedem Sicheren System berücksichtigt werden sollten. Struktur-, Bedrohungs- und Risikoanalyse wurden anhand von Beispielen ausführlich erklärt.

An dieser Stelle sei gesagt, dass der Prozess des Security Engineerings nicht mit der Erstellung eines Sicherheitskonzeptes Endet, sondern direkt im Anschluss das System getestet werden muss. Darüber hinaus ist eine stetige Überprüfung des Systems durchzuführen. Ein System das heute sicher ist muss nicht in einem Monat oder einem Jahr noch sicher sein. In der Zukunft werden dafür immer bessere Tools erstellt werden, die immer mehr Automatisch testen und analysieren, sowie Systemadministrationen über neue Sicherheitsrelevante Änderungen informieren.

Vor allem im Bereich der Erstellung und Umsetzung des System Entwurfes bleiben immer noch Fragen offen. Hier könnten weitere Ansätze gefunden werden um mehr Übersicht zu schaffen. Genauer können auch die Einzelnen Testmöglichkeiten eines Systems beschrieben werden. Es wurden nur die drei meist verbreiteten Verfahren genannt, welche Vor- und Nachteile sie im Einzelnen haben wurde nicht gesagt und bleibt offen für eine andere Arbeit, sich damit zu beschäftigen.

Literaturverzeichnis 14

Literaturverzeichnis [And08] R. Anderson. Security Engineering – A Guide to Build Dependable Distributed Systems.

2nd ed.. Wiley. Cambridge, 2008.

[BSI08A] BSI – Bundesamt für Sicherheit in der Informationstechnik. BSI-Standard 100-2 IT-Grundschutz-Vorgehensweise. Version 2.0. Bonn, 2008.

[BSI08B] BSI – Bundesamt für Sicherheit in der Informationstechnik. BSI-Standard 100-3 Risikoanalyse auf der Basis von IT-Grundschutz. Bonn, 2008

[BSI14] BSI – Bundesamt für Sicherheit in der Informationstechnik. IT-Grundschutz-Kataloge. http://www.bsi.bund.de/gshb . Bonn, 2014.

[DiHa08] J. Dinger. H. Hartenstein. Netzwerk- und IT-Sicherheitsmanagement. Universitätsverlag Karlsruhe. 2008

[Eck12]Prof. Dr. C. Eckert. IT-Sicherheit Konzepte-Verfahren-Protokolle. 7. Aufl. Oldenbourg Verlag. München, 2012. pp. 187-230.

[HS09] C. Hammer. G. Snelting. Flow-Sensitive, Context-Sensitive, and Object- ensitive Information Flow Control Based on Program Dependence Graphs. In: International Journal of Information Security 8. Dezember 2009. Nr. 6, S. 399–422

[Mic13] Microsoft. SDL Helps Build More Secure Software. http://www.microsoft.com/en-us/sdl/about/benefits.aspx . 2013

[Ruh14] Dr. T. P. Ruhroth. Foliensatz Sicherheit:Fragen und Lösungsansätze. Lehrstuhl 12. Dortmund 2014.

[SLE05] P. Saitta. B. Larcom. M. Eddington. Trike v.1 Methodology Document. http://www.octotrike.org/papers/Trike_v1_Methodology_Document-draft.pdf. Juli 2005

[SaSc75] J.H. Saltzer. M.D. Schroeder. „Protection of Information in Computer Systems“. In: Proceedings of the IEEE. 63(9) (1975). pp. 1278 – 1308

[RBG12]R. Reischuk. M. Backes. J. Gehrke. SAFE Extensibility for Data-Driven Web Applications. In: WWW’12: Proceedings of the 21st International Conference on World Wide Web. Lyon, France. 2012

[WMM13] M. Weidener. M. Backes. J. Müller-Quade. Entwicklung sicherer Software durch Security by Design. Frauenhofer Verlag. Mai 2013